HBase勉強会（第三回）に参加させていただきましたので、そのメモです。
Togetter： Hbase勉強会（第三回） #hbaseworkshop
今回のテーマはOS・ハードウェア・ネットワーク。自分の苦手分野ばっかりですな（得意分野を聞かれても答えに窮するが）(爆)
最初に軽く@tatsuya6502さんからHBase本が公開レビュー中という話とHBaseブックの日本語訳が2011/5/2にあしたのオープンソース研究所で公開されたというお話。
まずはClouderaの@shiumachiさんからHBase向けハードウェアのポイントについて。
どこがボトルネックになるか？という点について、HadoopがI/Oインテンシブ（ディスク・ネットワークが重要）で、HDFS上で動くHBaseも当然それが重要だが、CPUインテンシブでもあるからCPUも重要とのこと。（全部じゃんｗ）
メモリーを大量に使うからOSは64bitが当然とか、ネットワークも高性能なものが必要（ラック間でも10Gbit）とか。
HBase Master（HDFSのNameNodeと共有）用にQuadCore（コモディティ＝手に入りやすいという意味では、今なら6コアもあり？）で24GBが目安とか。
マスターなのでRAID10またはRAID01にする。
ディスクは4TBもあれば充分。
データノードはRAID不要。8コアとかで1つずつのコアにディスクが割り当てられるようにする。安いからSATAでよい。
メモリーはあるに越したことは無いということで、16～24GB。
RegionServerはメモリーが最低でも24GBは欲しい(!) 32GBとか。
ヒープは最低でも4GB割り当てる。ただし現時点では16GB以上割り当てたら駄目。HBaseのGCが動いて止まるから。これはJavaVMのGCではなく、memchachedと同様にHBase内のアロケータがあるという話らしい。
HBaseを使うには高性能なマシンが必要とはよく聞くけれど、さすがClouderaさんが相手にしている世界はすごいな＾＾；
次いで@kzk_moverさん。
「HBase＋運用」でGoogle検索するとトップに出てくる(笑)分散データベース「HBase」の安定運用を目指しての説明。
これまたかなり色々多岐にわたってOSやHadoop・ZooKeeper・HBaseの設定が書いてあり、素晴らしい。
そりゃOSも色々設定ポイントがあるよなぁ。いつもデフォルト状態で使うようにしてるからあまり気にしたこと無いけど＾＾；
途中で紹介されていたTsuna's blogは、e1000eというNIC（ネットワークドライバー）を使うようにしたらパケットのドロップ率が激減したという話。
あと、FacebookのHadoopクラスターの設定ファイルの内容が公開されているらしい。
Facebook has the world's largest Hadoop cluster!というページの「Facebook's Hadoop warehouse configurations」をクリックするとconf.tar.gzというアーカイブがダウンロードできる。
これも色々カスタマイズしていて参考になるそうです。
そして@ueshinさんから、Chef（シェフ）という構成管理ツールについて。
ueshinさんの自宅HBaseクラスターの管理をChefで行っていて、そのレシピ（Chef cookbooks）を公開しているという話。“レシピ”というのはChefの用語で、要するに設定内容のことらしい。
（これはRubyが使われているっぽい）
Chef Serverに対象ノード毎にレシピ（設定）を登録しておき、そのノードからChefのクライアントコマンドを実行すると、サーバーから設定を取り込んできて更新されるようだ。
最初に“ロール”としてHadoop用設定とかHBase用設定とかを登録しておき、どのノードがどのロールをインストールするかも設定しておく。この辺りはGUIでドラッグ&ドロップで指定できるのだそうだ。
ueshinさんは手動でクライアントコマンドを実行しているそうだが、デーモンで定期的に更新させることも出来るっぽい。
ちなみにこのHBaseクラスターもけっこうな量になっていて、全件カウントを実行したら3～4時間かかったらしい(笑)
休憩をはさんで、再び@tatsuya6502さん。
2011/7/1に行われたHbase at FaceBookのプレゼン資料から、p.39「典型的なセル構成」の話。
確かこれはUstで見たけど、英語が分からないからさっぱりだったんだよな…(爆)
今回tatsuyaさんの説明を聞いてようやく理解できた。ラック1つにつきZooKeeperを1つずつ入れて、それぞれNameNodeとかHBaseMasterとかJobTrackerとか異なる機能を同居させている。
で、ラック内の残りの19台がデータノード。ノード1台につき2Uでディスク12個だとか？
あと、リージョン分割が起きるとその間機能が停止するので、最初から分割しておくとかしているらしい。
それと、Puma（プーマ）について。
p.41「Puma以前」（つまり現在？）では、Hadoop（Hive）を使ってレポートへの反映に15分～24時間かかっていたものが、p.42「Puma」を使うことで10～30秒で処理できるようになった。
でもPumaって何するもの？という辺り、参加者の人達も記憶が断片化しているようで＾＾；
Ptailがストリーミング的にデータを取得してMapみたいな処理を行い、HBaseのカウンターを更新（Reduce的な処理）することで、擬似的に（リアルタイムな）MapReduceを実現したということらしい。
で、結局Pumaって何よ？ということだが、みんな忘れててよく分からない(爆)→結論：早くソース公開しろよ→7月公開予定という話もあったそうだが(爆)
PumaQL（PQL）という言語を使うが、現在オープンソース用に書き直し中らしい。（HiveのHiveQLみたいなネーミング。まぁどちらもFacebookかｗ）
もうひとつ別の話題として、@hisayoshさんの単一行のread&write連続試行の図を見ながら、HBaseの特性について。
読み込み性能を犠牲にして、書き込み性能を上げている（書き込みのスループットは一定だが読み込みにはムラがある）という話。
読み込み・書き込みを繰り返すと、読み込み性能がだんだん悪くなってきて、メジャーコンパクションが実行されると性能が回復する。
HBaseが書き込み性能を上げる為の2つのポイントがあって、
１．ディスクがランダムアクセスすると遅くなるので、ヘッドが固定できるようシーケンシャルな書き込みを行う。HBaseのPutのタイミングに関わらず、非同期に実施する。
２．HBase本の第8章に書かれている内容。RDBは一般的にB+Treeインデックスを使う。これは書き込み時に更新する。アクセス時間が一定となるようにバランスするので（メモリー上にデータが入り切れば）高速だが、メモリーに乗らなくなるとパフォーマンスが落ちる。
一方、HBaseはLSMツリー（Log Structured Merge）という仕組みを使っている。これは更新を受けた順に書き込んでゆき、後でソートする。MemStore内ではキー順でデータが並んでいるが、複数のStoreが順不同で書き込まれる為、読み込み時にそれらのStoreを全部見る必要があるので遅くなるという理屈。メジャーコンパクションが実行されるとStore内のデータも含めてキー順にマージされるので、読み込み性能が回復する。
LSMツリーって初めて聞いたけど、納得！
ログ（更新データ）をどんどん追加していって後からマージするというニュアンスだろうか。
キー順にデータが並んでると思ってたけどそうでもないと言われてちょっと疑問だったんだけど、こういう理由だったのか。
あと諸々の話題。
Avroってどうなの？→Hadoopエコシステムの一部として進められるはず。単なるシリアライズを超える。
Hortonworksの修正をClouderaは取り込むか？→Hadoop本体に含まれれば当然取り入れるはず。
最後に発表者の人達から宣伝(笑) 9月にもHadoop・HBase関連の集まりが色々。
『Hadoopカンファレンス・秋』が2011/9/26にある。1000人入れるってｗ
Cloudera vs MapR vs Hortonworksとか、熱いぜ！(笑)
