HBase勉強会（第三回）のメモ

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とか、熱いぜ！(笑)

AsakusaFWでフローの描画

AsakusaフレームワークのドキュメントにGraphvizを使ってジョブフローの描画が出来ると書いてあったので、試してみた。

Cascadingでも同じくGraphvizを使ってフローの描画が出来たが、AsakusaFWの方が綺麗。
stop演算子へ出力した箇所（@Convertのoriginal）が単なる“点”になっていたりして芸が細かい(笑)

AsakusaFWのデータをHive・Pigで読む

「“Asakusaフレームワークで作ったアプリケーションが出力するシーケンスファイル”をHiveやPigから読む為のSerDe・Storage」を生成するデータモデルドライバーを作ったよ。

---

…えーと、順を追って説明していくと。

AsakusaFWで作ったアプリケーションは、実行するとシーケンスファイルを出力する。
これは普通のHadoopのシーケンスファイルであり、キーはNullWritableでデータ部はAsakusaFWのDMDLから生成したモデル（Writable）クラスとなっている。

そして、HiveやPigでは独自のSerDeやStorageを作れば個別のWritableを格納したシーケンスファイルを読むことが出来る。

なので、AsakusaFW用のStorageを手で作ってPigからファイルを読めるか試してみたら、出来た。
同様にAsakusaFW用のSerDeを作ってHiveからテーブルとして参照することも出来た。

ここまで来たら、次にDMDLからSerDe・Storageクラスを自動生成したい。
AsakusaFWではSPIの機能を使ってプラグインとして拡張できるという話を以前聞いていたから、SPIのファイルを探してみた。そしたらそれっぽいクラス（データモデルドライバー）を見つけたので試してみた。

で、SPIの機能を使って自分のクラスを呼ばせるのは、驚くほどすんなり出来た(笑)
で、既存のクラスを参考に実際のSerDeやStorageを生成するドライバーを書いてみたのだが、これがえらく大変。とっても大変。何度も強調したくなるくらい大変(爆)
最初はPigのStorage用のドライバーを試行錯誤しながら作ったので、1日（たぶん16時間）くらい。
次にHiveのSerDe用のドライバーを書いてみたが、ある程度慣れたとは思うんだけど、Pigよりステップ数が多いので（というかちょっと複雑なので）、同じく1日（16時間）くらいかかったと思う。（Eclipseが遅いせいでもあるのだが）
少なくとも丸2日間は完全にこれにかかりきりだったねorz
最終的にはちゃんと出来上がったけど、保守（修正）できる気がしない(苦笑)

このJavaソース生成用のクラス群だが、実によく出来ている。ここまでJavaの構文を網羅したクラス群を用意するのも大変だろう。自分で作れと言われたら絶対嫌だし(笑)、ここまで網羅できない。
でもこれは手でコーディングするときに使うものじゃないなー。

昔SQL文を同じような感じで構築していくフレームワークを使ったことがあるが、あれですら大変だった。
WHERE句を表すオブジェクトにANDやORのオブジェクトを登録し、そこに条件・演算オブジェクトを生成して追加していく…という感じ。
で、SQLですらちょっと複雑なものになると手で構文解析して記述していくのは大変なのに、Javaの構文全部なんて、とてもやってられないっす(苦笑) ちょっとした一文を書きたいだけなのに、やたら長くなって…。
（実はJavaソースを読み込んでこれらのクラスを使った形式で出力するツールがあったりするのかな？）

---

簡単にプラグインが追加できて、DMDLの情報を元に独自のクラスを生成できるのはとても便利だと思う。

でも、DMDL情報を保持するオブジェクトやファイルをオープンする機能を提供する程度に留めて、本文の出力はWriterやPrintStreamを使った単なる文字列出力でいいんじゃないかなぁ。
ちょうどHttpServletそのものを使ってHTMLを出力するような感じ。
もっと言えばJSPに相当するものがあると便利かもしれないけど、さすがにそこまで需要があるかどうかは不明だし＾＾；（ScalaやGroovyなら文字列内に変数を埋め込んだりして便利に構築できそうな気はする）

PigのStorage（LoadFunc/StoreFunc）

Pigで独自のファイルを読み書きするStorageクラスを作ってみた。

題材はHiveのSerDeと同じく、WordCountのWritableをデータに持つシーケンスファイルの読み書き。

HiveのSerDeはデータの読み書きの実装方法がけっこう独自な感じだったが、PigのStoreFunc・LoadFuncは素のHadoopのOutputFormat・InputFormatがそのまま出てきている感じ。MapReduceを直に書いたことがある人だったら理解は早そう。

Pigのユーザー定義関数

Pigでユーザー定義関数を作ってみた。

UDF用のクラスを継承して専用のメソッドをオーバーライドする、正統なJavaプログラムだなぁｗ
場合によってはデータ型を返すメソッドをオーバーライドする必要がある辺り、Hiveの方が裏で頑張ってくれる感じ。