HbaseとHadoopMR
Hbase勉強会のまとめの延長として
今後の考え方をまとめておきます。
まずは前提として
<一般論>
Hbaseにかぎらず、NoSQL系一般に言えることではあるが
Usecaseを意識して利用する事が必要だ、ということだと思う。
最近の傾向としては、Googleでも顕著だけど、
一定の用途をターゲットにして
特定のミドルを開発するという方法が結構多い。
Hbaseもその流れはあるので、
そのあたりは意識する必要はあるかもしれない。
Hbaseついては、注目するとすればFacebookになるかな。
http://www.cloudera.com/resource/hw10_hbase_in_production_at_facebook
いずれにしても、割とうまくいっているUsecaseの情報の有用性は
他の技術よりも高いと思う。
基本的に単純に分散KVSを使いたいならHbaseにこだわる必要はない。
他に実績のある分散KVSはいくらである。
敢えてHBaseを使うのであれば、やはりそれなりの理由付けが必要だ
Hbaseの他のKVSとは違う加点ポイントをあげてみる。
1:一貫性が強い
自分としては基本的に業務アプリをメインで考えているので
一貫性が相対的に強く求められる。
これはlog収集ということではなくて
トランザクションデータやマスターデータの更新を
念頭においているためです。ここは理由として大きい。
2:データがソートされていること。
論理階層がソートされているのは、データの一定の塊を
処理する場合には非常に有利だ。分散処理ではキーの管理が
設計のポイントになるが、その際にソートが前提になっているのは
なにかと都合がよい。
たとえば、一定のキー・レンジで処理がしたいような場合
HFileの形で処理ができるようなことができるとうれしい（気がする）
http://lanyrd.com/2010/huguk7/sxbw/
3:HadoopMRとの相性の問題。
後述するように原理的な課題はあるが、やはり
基本にあるフォーマット互換やAPIの親和性は
最終的には品質や安定性に影響する。
課題があるとはいえ、他のKVS系よりも障害時の対策案は
練りやすいのは当然といえる。
これは割と大きなポイントだと思う。
とはいえ、まずはHbaseを利用する前提はHadoopMRなわけだ。
やりたいことは明確で、HadoopMapReduceの弱点を埋めることである。
ということで、まずは現状のHadoopMapReduceの課題を
整理しておく必要がある。
HadoopMRはCoreとMRとHDFSが一体なので、それぞれの問題点も
HadoopMRの課題ということにしよう
1:データの追加処理に弱い
これはまぁどうしようもない。
ある意味ファイルのバースト・リードに特化したものがHDFSなので、
その分appendに弱いのはトレードオフと見なした方がいいと思う。
勿論、appendの実装はされつつあるが、
直接HDFSに追加書き込みはコストがかかるのは原理的なものだと思う。
つまりHDFSの拡張では見込み薄い。
2:それほど巨大ではないデータに弱い
これは弱い、というよりも効率が悪いということにつきる。
これは非同期分散処理のメリットの裏返しともいえる。
分散処理のオーバーヘッドを吸収するに
十分な現状課題のデメリットがないと、採用のうまみはない。
とはいえ、データ量が少なくても、かなりタコなSQLバッチは
やたら散見されるので、
まぁできればHadoopMRのコンテキストで処理したいところではある。
3:バリアー処理のコストが高い
MRの連鎖がかならず、形式的とは言え、M-R-M-R-M・・・の流れになる
効率的でないのは普通に考えればわかる。
例えばフラグを一個セットしますってのでもM-Rですか？ってのはある。
AsakusaはAshigelコンパイラが他の処理と併せて圧縮してくれるので
あまりオーバーヘッドはないけど、にしても無駄は無駄。
4:値の取り出しに弱い
これは特にできあがったデータを外部に保存する場合に顕在化する。
デフォルトのHadoopではデータ入出力のIOがタコ過ぎるので
AsakusaではThunderGateを作っている。
この辺りは、どこもかしこも苦労しているのはわかる。
自分のところの実装はRDBMSなんだけど、
本当はHadoopNativeにしたいところ。
1と4の対策案としてのHbaseを検討するべき、というのが基本線になる。
細かい理屈はともかく、大きくはデータの入出力に
今のHadoopは弱いので、Hbaseでカバーしましょう、つーことに尽きる。
（あくまで現状と1＋4の解決案として）
従って、基本の路線は以上の問題点をカバーするために、
外部システム（RDBMS）＋Hbase＋Hadoopのフローになる。
順に見ていく。
まず、入力フロー。
外部→Hbase→Hadoopという流れだが、これは対応する業務による。
仮にログの取込ということだけであれば、Hbaseは必要ないのでは？
というのが勉強会の結論になったと思う。
実際に、BI系の処理では、ログは直接HDFSに
収集されているケースも多い
例えば、MessagePackでも対応はできるだろう。
2011-06-18
しかし、取込時に何らかのフックが必要だったり、
取り込んだデータをバッファリングして、
差分のみ処理するということや、
一部取り込んだデータの更新を行う、ということであれば
間にHbaseを挟んだ方がよいと思われる。
特に、いわゆるオンラインバッチ系の処理で、
処理中のデータを参照したり、
処理フラグが設定されていないデータのみを、
バッチ処理中に追加的に処理したいようなことがあるのであれば、
Hbaseを挟む形になる。
次に内部での処理。
HbaseとHDFSでデータのキャッチボールをする必要があるのか？
ということになる。
これは現状のHadoopMRのみで問題を処理するのであれば、
多少議論になる。
joinの使い勝手の向上を目的とした利用方法にはなるだろう。
そうでなければ本当にいるのか？という結論もでるだろう。
ただしこれは、後述するようにHadoopMRとHbaseの
より具体的な同居の仕方に依存する。
自分の意見は、むしろ、前述の3のコンテキストで、
HadoopMR自体の問題点を解決する手段として
利用するという側面での検討がされると思う。
最後に出力。
Hadoop→Hbase→外部システムの流れ。
これはある意味結論が出ていて、Hbaseは有効だろう、
という風に見えている。
というか、現状のHbaseの使い方の大半はこういう使い方になっている。
HadoopMRで処理したアウトプットを自由に利用したり、
追加的にデータを修正したりするようなケースだ。
これはまぁ取り回しを考えても、妥当な選択になる。
ただし、最初の述べたように、この場合は他のKVS
（いや普通にRDBMSでもよい）でも十分に利用可能である。
よってHbaseの特性を生かせるケース、
例えば、ソートの有利性を生かせるusecaseということが
要件になると思う。
入出力としてはこんなところがまず論点かな、と。
それでHbaseを投入する場合の問題は、
データローカリティをどうするのか？キーの配置をどうするのか？
ということが問題になる。現在のここでの課題は・・・
そもそもHadoopMapReduce自体が、他の仕組みとの共存がしにくい。
プラクティスとして、
「MapReduceをHbaseのノードで実行してはいけない」
という話もちらほら聞く。
それじゃー意味ないだろう、という意見はおいておいて
冷静に考えてみれば、MapReduce自体はCPUとN/Wを割と
帯域一杯まで使うわけで、ある意味当然の結果ではある。
すべてのコアを一斉にめいっぱいまで、使うミドルは、そうそうない。
（ないことはないが、普通は専用にアプライアンス化される）
他方、KVSを始めとする分散系の処理系は
基本的にアプリレイヤーに動作を意識させない。
普通はアプリレイヤーにローレベルの分散処理を意識させた時点で
仕組み的には破綻している。
だから、HadoopMRがコアをめいっぱいまで使っている最中に
それとは異なる何らかの分散処理が裏で走る可能性があるわけで、
これはどう考えても分が悪い。
その意味では、分散KVS系の処理とHadoopMRはなんの手当もしない場合は
相性は決してよくない。分散KVS系の明示的な動作はともかく、
大抵は黙示で動くのでそこがつらい。
どんな処理であろうとMRしている最中に何か走る、というのは
一般にパフォーマンスは挙動不審になる。
するとどんな風にHbaseとHadoopを共存させていくか？
ということになる。
基本線はHbase上になんか工夫をするということになると思う。
または直裁にいうと、ノードの切り分けと
N/Wのトポロジーをどうするか？ということにもなる。
この辺が今後の焦点。
（これは個人的な仮説だけど、一般にHadoopMRは「どんな分散KVS」とも
同一ノードクラスターで処理を行う場合は相性が悪い、
という気がする。
他のKVSはよくしらんので、なんともいえないけど、
少なくともKVS側で、HadoopMRのような
「極端なリソースの利用の仕方をする他のミドル」
がノード上走るということは想定しているのかな？と思う。
あと経験的に分散系はリソース逼迫時のエラーは、
なんか意味不明なケースが多い。
・・ので、原因追跡が困難で、実装も困難。
なので「後付けMR実装」はちょっと不安に見える。
まぁ確かめてないので、なんともいえませんが。
誰か確かめるといいとは思いますが。）
・・・ここまでしてもHbaseは来るのか？
という話はあるにはあるのですが。
多分来ます。理由は簡単で「HadoopのHbase」だからですね。
HadoopのE/Uさんへの名前の浸透は、かなり異常な状態で、
それに引っ張られてHbaseの知名度も上がっています。
HadoopコアなメンバーではHbaseは
Casssandra、MongoDBと並ぶ位の位置づけだと思うけど
E/UサイドではHbaseに分がある。
というわけでこの辺はまじめに検討しないとどうしようもねーだろ
的な感じです。
それから追加的にいうと・・・
3はそもそもHadoopMRなのか、という部分もあるので
補完的に別のパラダイムの導入を検討した方がよい
PFIさんのブログもまぁ参考になります。
MapReduce以外の分散処理基盤BSP, Piccolo, Sparkの紹介 | Preferred Research
この辺はまたあとでまとめる予定、というか検討する。
2については、現在別の手法を検討しているので
また別のところで議論すべき。
これも検討中というか、実装中。
まぁ、こんな感じ。
