"Hbase at Facebook" に行ってきた

名称表記が揺れてて微妙だけど Hbase at FaceBook on Zusaar このイベントに行ってきた。Facebookの人は "HBase Tokyo meetup" と認識していたようだ。
内容のまとめはやらないので、以下の各ページなどをご覧になると良いのではないでしょうか。

Tokyo HBase Meetup - Realtime Big Data at Facebook with Hadoop and HB…
Hbase at FaceBookのまとめ - Togetterまとめ
FacebookがHBaseを大規模リアルタイム処理に利用している理由（前編） － Publickey
FacebookがHBaseを大規模リアルタイム処理に利用している理由（後編） － Publickey

セッションの内容と自分が考えたことと人としゃべったことをいっしょくたにここに書いておく。分けるのがめんどい。

データ量と書き込みスループットの問題

• データ量的にHDFSに書きたい
  • 1ファイルに複数の場所から書けず、ファイルを分けるのも割と面倒で、ディレクトリ分けるとMR時にめんどくさい
  • ひとつの書き込み対象リソースとして扱えて、高スループットが出るものが欲しい
• hbase !
  • ただし、そこまでの書き込み量になるデータを持っているところがどんだけあるか？ は微妙

処理モデルと実時間追従の話 (あるいはPuma欲しい)

• appendとclose(rotate)とMR対象
  • ログをscribedからHDFSに追記していっても、rotateが行われないとMapReduce対象にできない
    • どうしても1時間ごととかの単位で処理する必要がある
  • rotateを待つとそれだけで実時間に対する遅延になる
• rotate単位を処理するMR(ã‚„Hive)はそれなりに重い処理になる
  • そこでHDFS上でも tail して処理にかけられる PTail
  • データ自体はもっと小さい単位でやってくるんだから、やってきた端から逐次処理すれば、そりゃ実世界でのイベントに対する遅延は小さいよね
  • しかしその計算モデルはもう既存のhadoop上にはない何かだな、分散処理だけど、HDFSベースのパイプライン
    • どのくらい shard/pipeline 本数を構成するかというのが自動制御なのか手動なのか、それは実際にはどこで動いているのか
    • というのを聞き忘れてた、と、いま思い出した……
  • あとバッチ処理に較べると処理あたりのコストは当然高くなる
    • が、許容できるレベルだと思う、多分
• シャッフルはhbaseのソートにお任せという理解でいいのかな？
  • バッチ的視点だと読み出しバリアは無い
  • インクリメンタルな、いつ読まれても破綻しないデータでないとダメ

hadoopの価値というかhdfsの価値

• とりあえずHDFSに書く
  • あとからMRかけたりする可能性も考えたりすると、HDFSにとりあえず書く、のはアリだよねえ
• PTailがあるなら、いったん小さめのHDFSに書いておいて、そこから逐次処理でデータを取り出して変換しつつデカいHDFSにたくわえる
  • 必要があれば小さいHDFSからMRでガッと取り出し直すこともできる
  • PTailがあれば、かな
• PTailがMapになり、HBaseに対するクエリがReduceになる
  • HBaseへの書き込みまでがほぼ実時間追従で行われるとすれば、実時間に対する集計結果データの遅延はHBaseに対するクエリ分のみになる
    • 多分これがPumaで言っていた10秒〜30秒の遅延の大部分
  • PTail的な何かは欲しいなあ
    • PTail公開！ 公開！ とりあえず正体を見てみないと
    • まあなんか自分達で書きたい気もするよねー、というのが懇親会でのお話

自分的まとめ

ログ((やメッセージ(Titan)や各種メトリクス(ODS)))を前処理して、その結果を集約処理用のデータとしてどこかに書き込んでおく、というパターン自体は既存のものと変わらなくて、以下のような対応。

• 前処理
  • Puma以前: 生ログに対するMapReduce
  • Puma以後: PTailによる逐次読み出しとデータ処理
• 集約処理用データストア
  • Puma以前: Hive用テーブルとしてのHDFSファイル
  • Puma以後: HTable on HBase

ただし以下のような違いがある。これにより、実世界で起きるイベント(ログ書き込み)が集計結果に反映されるまでの時間を大幅に短縮している。

• データ書き込みに対する逐次処理的なMap
  • PTailが順次ログの前処理を行うことで、Mapによるオーバーヘッドを実時間への遅延にカウントしなくてよくなった
  • HBaseが(データ書き込み時に)動的にソート処理を行うことで、集約処理時の以下の処理のオーバーヘッドがかからなくなった
    • 集計対象絞り込みのためのソート
    • およびソートのための全件探索
  • HBaseが値のアトミック・インクリメントをサポートしてるので集計処理でやることが大幅に減らせる
    • 例えばPage Viewsみたいな指標は、ページごとにカウンタをつくってインクリメントしていけばいいから、処理タイミングを前処理側に倒せて集計フェーズでやらなくてよくなる

そして、もちろん良いことずくめではなくて、以下のようなデメリットがある。

• HBase用クラスタが(おそらく)ほぼ必須
  • HBaseはデータのソートをメモリ上で行い、しかもメモリ上にデータを保持したままにするので、ものすごくメモリ食いそう
  • バッチ処理用のMapReduceを走らせるクラスタと同居させるのはたぶんものすごくリスク高い
  • そもそもかなりの台数がないと性能出なさそう
    • ノードの増減に対してshardの再配置を自動で行う、ということは、shard再配置のオーバーヘッドが問題にならないまでにノード数を増やさないと使いものにならない、ということ
• PTail用クラスタが(おそらく)ほぼ必須
  • PTail自体をどのように動作させているかよくわからないので断言はできないが、hadoop MapReduceと同じ基盤では動かないと思う
  • PTailの場合はMapReduceと違ってひとつの処理プロセスが長時間動き続けることになるので、その分のメモリとCPUを確保しないといけない
  • これもけっこうコスト高そう

さてさて。とりあえずPTailを数週間で公開してくれるらしいので、それを見てからかな！