HBase at Facebook に行ってきました
FacebookでのHbase利用について、
アーキテクトのJonathan Grayさんに来てもらって、プレゼンしてもらうという
素晴らしい会に参加しました。
http://www.zusaar.com/event/agZ6dXNhYXJyDQsSBUV2ZW50GOuRAgw
@tatsuya6502 さんによるJonathanのプレゼン資料の日本語訳
(英語資料は未公開)
- 感想
- FacebookでHiveで15-24hoursかかってた処理がPUMA(+PTail)というので10-30 secになった。衝撃的。PTailは数週間(a couple of weeks)で公開されるとのこと。
- FacebookはHBaseにかなり力を入れている。
- おそらくMySQLをやめて代わりにHBase+CacheにしてWebもバックエンドもリアルタイム化しようとしている。
- 「バッチスタイルのアプローチだったが、ストリーミングなアプローチにした」というのが印象的だった。
- 彼らの中ではHadoopはもう古いんだと思う。これからはストリーミング。日本は数年遅れてると思った。
- もしかしたらCassandraでもと思われる方が多いかもしれないが、僕はそうは思わない。おそらく全てのサービスでconsistency(一貫性)は非常に重要なので、HBaseが合う。実際にCassandraを作ったFacebookで、もうCassandraは使われてないという事実が全てを示している。
- Facebookは広告の効果測定をリアルタイム化していた。
- オープンソース化する文化って本当に素晴らしい。日本にはないものだと思った。日本も恩恵を受けてるんだから返さないとだめだと思う。
- @tatsuya6502 さんとアンケートのユースケースにもあった某CT○の翻訳が素晴らしかった。
- 普通に二次会予約しておけばよかった。
- FacebookとJonathanかっこいい!
- Jonathan Grayさんが言ってたこと
- Q&A覚書き(長いです)
Q: Scribeあたりのバッファの消失の問題をどうしているか(古橋さん[twitter@frsyuki])
A: オフセットを保持して、そこまで書けたら次のオフセットまでという方式。
Transactionの話
scribeがこけたらどうのという話題も。
Q: なぜCassandraやMySQLシャーディングじゃなかったのか?
A: consistency(一貫性)が欲しかった。
ひとつのサーバーに複数のシャードを割り当てたい。
社内にHDFSに詳しい人がたくさんいた。
Q: Pumaのボトルネックはどこでどう改善したのか?
A: Hiveでは24時間のデータを処理するのに24時間以上かかっていた。
バッチスタイルのアプローチだったが、ストリーミングなアプローチに変えたということ。
Q: MySQLをスケーラブルにっていうのはどういう風に?
A: 単純なシャーディング
レンジがどうとか(よくわからん)
Joinはアプリケーションサイド
Q: ネットワークの苦労話は?
A: DC内でネットワークパーティションがおきないこと。
Redundancy(冗長性)の確保。
上層のネットワークを10GBにした。
下は1G。
物理的に近いところにある。階をまたがない。
Q: rainbirdやverticaをなぜ使わないのか?
A: 自分で作りたいし(笑)
Q: スケーラブルなスキーマの例がなかったが
A: rowがユーザーひとりで、メッセージとか全部そこにつまってるよ
Q: どんな見積もり方法をしましたか?
A: Darkloanchと呼ばれる方法(Facebookの詳しい資料にちょっと書いてありました)。
Q: FacebookでCassandraは使われてるのですか?
CassandraのコミッターはFacebookにたくさんいますが・・・(西澤無我さん)
A: 使ってません。(ざわざわざわ・・・)
僕らが欲しかったのは
Availability
Consistency
まあ、違う用途には使えるだろう。
Q: PUMAはオープンソース?どうしても欲しいです。
A: PUMAはサービスよりの技術(的な事を言ってた)。こんな構成要素からなる。
scribe
ptail
HBase
(Caribe FS?(カリブと聞こえた))
昨日なにか発表があったよ。そこで新しい発表があったかもしれない。
ptailは数週間以内にオープンソース化されるだろう。(歓声!そして質問者握手!w)
Q: HBaseのバックアップは?(将さん)
A: 実は開発中です。
今までは2箇所に書いてた。
今は違うアプローチを取ろうとしてる。
HBaseでスナップショットを取るような
インメモリはディスクに書き出す。
HLOGを書き出すような。
Q: メジャーコンパクションのレイテンシはどう保つか
A: スプリットやコンパクション自体を少なくすればいい。
ブルームフィルターみたいので解決できる(よくわからず)。
あらかじめスプリットしておく。
TITANは自動スプリットはしてない?
Q: もしJonathanがスタートアップにいて、それでも使う?
A: 会社によると思う。
僕が起こした会社はものすごい量のデータを扱っていたので必要があると思う。
NoSQLとかの新しい技術はいいこともあるけど悪いこともある。
新しいことはできるけど、成熟してない。
Q: PUMAを使えるようになってよかった例は?
A: さまざまな効果測定がリアルタイムに。
広告のUU数とか。
ユーザーの動きがリアルタイムにわかるようになった。
- HBase & Facebookリンク集
- 「Facebookが新サービスの基盤にしたのは、MySQLでもCassandraでもなく、HBaseだった − Publickey」 http://www.publickey1.jp/blog/10/facebookmysqlcassandrahbase.html
-
- 「HBase at Facebook: The Underlying Technology of Messages :: myNoSQL」 http://nosql.mypopescu.com/post/2668434779/hbase-at-facebook-the-underlying-technology-of
-
- 「HBase « Agile Cat ― in the cloud with openness」 http://agilecat.wordpress.com/tag/hbase/
-
- 「RealtimeHadoopSigmod2011.pdf (PDF)」 http://borthakur.com/ftp/RealtimeHadoopSigmod2011.pdf
-
- 「How Facebook Is Powering Real-Time Analytics ― Cloud Computing News」 http://gigaom.com/cloud/how-facebook-is-powering-real-time-analytics/
-
- 「Facebook - Jonthan Gray - Hadoop World 2010」 http://www.slideshare.net/cloudera/h-base-in-production-at-facebook-jonthan-grayfacebookfinal
-
- 「Togetter - 「Hbase at FaceBookのまとめ」」 http://togetter.com/li/156588
-
- 「FacebookがHBaseを大規模リアルタイム処理に利用している理由(前編) − Publickey」 http://www.publickey1.jp/blog/11/facebookhbase.html