"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
セッションの内容と自分が考えたことと人としゃべったことをいっしょくたにここに書いておく。分けるのがめんどい。
データ量と書き込みスループットの問題
処理モデルと実時間追従の話 (あるいはPuma欲しい)
- appendとclose(rotate)とMR対象
- rotate単位を処理するMR(やHive)はそれなりに重い処理になる
- シャッフルはhbaseのソートにお任せという理解でいいのかな?
- バッチ的視点だと読み出しバリアは無い
- インクリメンタルな、いつ読まれても破綻しないデータでないとダメ
hadoopの価値というかhdfsの価値
- とりあえずHDFSに書く
- あとからMRかけたりする可能性も考えたりすると、HDFSにとりあえず書く、のはアリだよねえ
- PTailがあるなら、いったん小さめのHDFSに書いておいて、そこから逐次処理でデータを取り出して変換しつつデカいHDFSにたくわえる
- 必要があれば小さいHDFSからMRでガッと取り出し直すこともできる
- PTailがあれば、かな
- PTailがMapになり、HBaseに対するクエリがReduceになる
- HBaseへの書き込みまでがほぼ実時間追従で行われるとすれば、実時間に対する集計結果データの遅延はHBaseに対するクエリ分のみになる
- 多分これがPumaで言っていた10秒〜30秒の遅延の大部分
- PTail的な何かは欲しいなあ
- PTail公開! 公開! とりあえず正体を見てみないと
- まあなんか自分達で書きたい気もするよねー、というのが懇親会でのお話
- HBaseへの書き込みまでがほぼ実時間追従で行われるとすれば、実時間に対する集計結果データの遅延はHBaseに対するクエリ分のみになる
自分的まとめ
ログ((やメッセージ(Titan)や各種メトリクス(ODS)))を前処理して、その結果を集約処理用のデータとしてどこかに書き込んでおく、というパターン自体は既存のものと変わらなくて、以下のような対応。
- 前処理
- 集約処理用データストア
- Puma以前: Hive用テーブルとしてのHDFSファイル
- Puma以後: HTable on HBase
ただし以下のような違いがある。これにより、実世界で起きるイベント(ログ書き込み)が集計結果に反映されるまでの時間を大幅に短縮している。
- データ書き込みに対する逐次処理的なMap
- PTailが順次ログの前処理を行うことで、Mapによるオーバーヘッドを実時間への遅延にカウントしなくてよくなった
- HBaseが(データ書き込み時に)動的にソート処理を行うことで、集約処理時の以下の処理のオーバーヘッドがかからなくなった
- 集計対象絞り込みのためのソート
- およびソートのための全件探索
- HBaseが値のアトミック・インクリメントをサポートしてるので集計処理でやることが大幅に減らせる
- 例えばPage Viewsみたいな指標は、ページごとにカウンタをつくってインクリメントしていけばいいから、処理タイミングを前処理側に倒せて集計フェーズでやらなくてよくなる
そして、もちろん良いことずくめではなくて、以下のようなデメリットがある。
さてさて。とりあえずPTailを数週間で公開してくれるらしいので、それを見てからかな!