#garagekidztweetz

#garagekidztweetz

id:garage-kid@76whizkidz のライフログ・ブログ!

#hcj13w A会場 午後 (5) "いかにしてHadoopにデータを集めるか" のメモ

スポンサーリンク

このエントリーをはてなブックマークに追加 全体のまとめは ➤ こちら
hcj13w 5つ目のセッションは Fluend のセッションに参加してきました。
前 2 つのセッション (Pig | HBase)と並んで大変勉強になりました。
何より情報量が多いのがすばらしい。
開発だけでなくエヴァンジェリストとしての活動も怠らない開発者がオススメするFluentdの解説記事まとめ - NAVER まとめのようなものを準備する姿勢も見習いたい。

16:30 (7F 国際会議場) いかにしてHadoopにデータを集めるか 古橋 貞之(Treasure Data)

Hadoop世界では殆どの人が大容量データを如何に保存し、また処理をするかという点に主眼を置いていますが、'データを如何に安定して集めるか'という点はあまり語られていません。本講演ではHadoopに大量データをリアルタイムで収集する際のソリューションであるFluentdとFlumeについて、開発者視点からの現状を説明します。

➤自己紹介
  • @frsryuki
  • We're hiring.
➤ 集まった人たちの課題
  • Big data -> Report & Monitoring ではないですか?
  • 間には
  • Collect、Store、Process、Visualize

  • Store、Process
  • のところに、Hadoop、Hiveで改善されてきた
  • 問題の Collect
  • 何気に難しい問題ではないか?
➤どう難しいのか?
  • 貧相なやり方の例(資料)と問題点
  • 確実に壊れているデータが混ざってる
  • Time Series Data 、プログラムで格納可能なデータ形式に変えないといけない
  • 読み書きに時間
  • 一回一回のTry & Error に時間
  • NW コスト増大
  • これがデータサイエンティストの仕事だとしたらあまりにも非生産的

  • ✔ Basic theories to collect data.
  • Divide & Conquer
  • 細かく分割されていれば、一部にエラーがあっても、そこだけやり直せば良い
  • Divide & Conquer & Retry
  • そしてリトライする

  • Streaming
  • ビッグデータ処理は Hadoopにやらせよう

  • そこで
  • Apache Flume と Fluentd
➤ Apache Flume
  • Agent が Collector にデータを送る
  • OGとNGとふたつのバージョン
  • OG はマスターに ack が届かないともう一回やりなおす→MasterがBottleneckに
  • NGはひとつひとつが ack を返す

  • Pipeline
  • Source と Sink
  • NG は間に Channel が追加された
  • データの取りこぼしをなくすため、一時的なバッファリングを行う

  • configuration
  • Master を使って全体の設定を更新する→ ✔ 具体的な設定内容のスライド
    source , channel, sink の設定
➤ Fluentd
  • 伝書鳩のロゴ

  • NW topology
  • Flume とほとんど同じ

  • Pipeline
  • input, Buffer, Output
  • Buffer 、信頼性と同時に性能もあげる

  • configuration
  • chef, puppet などの専門的なツールをつかってくれることを期待している
  • ✔ 具体的な設定内容
  • flume より見やすく分かりやすいのではないか、製作者バイアスがかかってるかもしれないがw

  • Fluentd 、プラグインを配るためのプラットフォームがある
    • $ fluent-gem search -rd fluent-plugin
    • $ fluent-gem install fluent-plugin-mongo
➤ Fluentd のコンセプト
  • Plugin→カスタマイズ
  • Fluentd のコアが Plugin をつくることを補助する
➤ Fluentd Plugins
  • どんなものがあるか?
  • in_tail →ログを読んでとばす
  • out_mongo→MongoDBに書き出す、JSON フォーマット、バッファリング機能あり、バルクでの書き込み、失敗してもリトライし続ける
  • out_s3 →S3 に書き出すプラグイン、時間で区切って書き出す機能、
  • out_webhdfs, out_forward, etc...
➤ Fluentd examples.
  • Treasure Data での事例
    • in_exec, Thrift API, out_tdlog, out_metricsense
➤ Plugin Development
  • write with Ruby
  • 継承してカスタマイズ可能
➤ Fluentd V11
  • Error stream
  • Streaming processing
  • Better DSL
  • Multiprocess
➤ Fluentd 解説記事まとめ
➤ QA
  • 海外の導入事例は?
  • slide share が一番の分かりやすい
  • 海外のコミッターもいる

  • Flume との比較
  • データ到達の保証
  • システム全体で保証した方がいい
  • Flume OG とは違ったが NG とはあまり違わない

  • ログのフォーマットが途中で変わったとき
  • Fluentd は再起動しないと設定を再ロードはできない

  • RDB からのインプット
  • 定期的にデータをクエリで書き出すPluginはあるが

  • Streaming の負荷については自分で面倒をみないといけない
  • 負荷分散したい例があれば開発のヒントにはなるが