HBase勉強会（第二回）の感想

第2回HBase勉強会に参加しましたので、例によって感想など書いてみます。
Togetter - 第2回HBase勉強会 #hbaseworkshop

ちなみに第1回は不参加…実務でHBase使ってるわけじゃないので資格外かなーと思ったのと、18:30からだと微妙に間に合わない。今回は19:00からだった（ことにぎりぎり気付いた）のでラッキー♪
しかし京浜東北線が人身事故で山手線まで止まってて間に合わないかと思った＾＾； 品川駅なんかすごい混雑で、ホームから人が落ちて新たな事故にならないのが不思議なくらい(汗) 電車内が混んでるのは何度も経験してるけど、駅で人混みに押されるなんて初めて(苦笑)

---

今回はtatsuya6502さんが体調不良でお休みということで、残念。お大事に。

代わりにueshinさんの発表からスタート。→資料
いきなり自宅サーバーはインパクトあるなぁ(笑)　しかしスペックとか構成とか、こういう実例は嬉しい。
特にZooKeeperをDataNode等とは別にした方が良いとか。同居させると負荷が高いとき（MapReduce実行時とか＾＾；）に反応が遅くなって落ちちゃうらしい。ZooKeeper1台構成もすぐ落ちちゃうし2台は元々非推奨なので、3台で。
3台構成なら、1台が落ちて2台になっても稼動する。
ZooKeeperがROOTテーブルの位置を保持しているので、ZooKeeperが機能しなくなったらZooKeeperへアクセスしようとリトライし続けるのではないかとのこと。

HBaseの仕組みは、物理的にはカラムファミリー毎に保存される。
リージョンはROWキー（の範囲）によって分割される。一定サイズ（デフォルトは128MB）を超えると自動的に分割される。リージョン分割中はそのリージョンへのアクセスは一時停止となる。
ここで、カラムファミリー内にデータをいっぱい入れたり、カラムファミリーそのものがいっぱい作られたらどうなるの？という質問が。たぶんコンパクションが無限に起きてしまうんじゃないかとのこと。要するにカラムファミリーはたくさん作るものじゃない、と。まぁカラムファミリーを追加するにはテーブルを使用不可にしないといけないしねぇ。
（ちなみに以前上限を聞いたと思ったが、行数10億とカラム数100万で、カラムファミリーは載ってなかった＾＾；）

あと、ACID特性に関連して、ROW内はatomicだが、複数ROWにまたがるatomicは無理。複数をやりたかったら、分散トランザクションを作るか、ZooKeeperでロックするか。いずれにしてもあまりやらない方が良さげ＾＾；

---

続いてokachimachiorzさんから、アーキテクチャ要件について。

MapReduce実行時とかコンパクション（リバランス）時とか、HBaseはまだ不安定に感じる、HBaseはある程度の規模を想定しているのだろうとのこと。
（そういえばHBaseとCassandraの討論会でもHBaseは5台以上欲しいという話だった）

そして、HDFSとHBaseのデータロケーションを分けるべきかもしれないという衝撃発言！
HDFSと分けるというのは、別クラスターを作る（MapReduce実行用のクラスターとHBase用クラスターを分ける）という意味だろうか。
HBaseに書き込んで出来たファイルに対して直接MapReduce出来るのが他のKVSとは違う利点だと思うので、別クラスターにデータコピーしてMapReduceするとしたら、あまり意味が無いような＾＾；
（実験環境はどうしても低スペック（サーバー数も少ない）になるだろうから、そこで「使えない」と誤解されてしまったら寂しいっすねぇ）

それはそれとして、okachimachiさんが考える適用業務について。
（このうちの一分野も分からないとなると、SIerとしては失格だよなぁ＞＜　自分は全然ダメだ）

●マスター管理
マスターの同期処理が必要。やはりフロントはRDBということで、RDBMS→HBase→HDFS

●受発注
伝票検索：特定キーと日付による検索。一括検索はHDFSでよいが、微妙なサイズ・タイミング（障害が起きた場合に一部だけ実行したい（サブバッチ）とか）はHBase。

●在庫管理
教科書はＡＣＩＤで書かれているが、普通はACIDではない。フラグを立てて非同期で実行する。
指定された在庫だけ処理したい→HBase（HBaseをフロントに置く前提）
読み込みはしたい→更新時にロックしたい（更新は3時間毎で参照はリアルタイムとか）
→でもフラグを立てるだけならロック不要、すなわちHBaseでなくてもよいのでは？というツッコミが＾＾；
基幹バッチ処理としては一部を別の場所にコピーしてそれを処理するというのは王道だが、HBaseとHadoopのロケーションを分けてコピーすると負荷がかかるし…という感じらしい。

●原価計算
確定処理とシミュレーション（同期は不要）→結果を保存して参照するのにHBase

●物流管理
リレーショナルデータ（在庫マスターや顧客マスター）との結合あり。
Planing（計画）系とExcecution（実行）系
マテハン（マテリアルハンドリング・組込み系）への受け渡しあり。

●製造管理
計画のプランニングはHadoopで実施できる。分散MRPとしてHBaseでやれたらすごいらしい。

●生産管理
歴史的推移：昔は実行系のみ→実行系と計画系（SCM）→結合していく→ERP（ロックイン、メンテ不能）
・スケールアウトしない
・非同期処理の高速化→HBaseが使えそう。
・素結合による簡素化→レイテンシーは上がる。（人は、3秒かかると死んだと判断する）

●原子力発電管理（ネタ）
シミュレーション、センサーデータ収集分析、リアルタイム、組み込みの直接制御
リアルタイムというのは、例えば薬品を一定量入れたいとき、センサーで監視しつつ、予定の場所まで来たらすぐ止める必要がある。ミリ秒以下。
→メジャーコンパクションが起きたらアウト！　したがって、HBaseでは原発管理できないｗ（原発を想定したNoSQLがあったら面白い…って＾＾；）

●販売管理
集配信→HBase（分散書込）→HDFS→HBase（分散書出）→RDB
想定件数は、多いときで1億件。HDFSでの非同期処理は15分間隔。
集信でバッファリングが要るかもしれない。
ツッコミ1：書き出しのHBaseは不要で、直接RDBへ入れれば？
ツッコミ2：データ追記型なら、書き込みのHBaseは不要で、ファイル（HDFS）でよいのでは？（ログ収集ならファイルを直接HDFSに入れる。それと同じイメージでいけるのでは？）
書き出しに関しては、同じROW（の別カラムファミリー）にデータを追加する形なら、HBaseが有効かもという考察。
HBaseは分断すると落ちる（第10回Cassandra勉強会参照）ので、Cassandraの方がいいかも。ただしデータの整合性は弱い？

※下手に継続するよりも、落ちるなら落ちた方が良い
※システムが落ちたらまず言う事は、「まず落ち着け」「落ち着いて説明しろ」ｗ

---

続いてashigeruさんから、（今度は業務ではなく仕組み寄りで）HBaseの用途について。

HBaseの特徴は、
・細かいデータの多数書き込みに強い
・キー順にソート済（「隣のレコード」という概念が存在する）
・バーストリードは一応早い
・テーブルとROWが同じなら、リージョンも同じ
・カラムファミリーの追加は停止しないと出来ない
・暇なときにリバランス（リージョン分割）する⇔忙しいときはリージョン分割しない

したがって
・OLTP+インクリメンタル
・オンライン性能をあまり劣化させずにバックグラウンド処理
・バックグラウンド処理同士の干渉が少ない
・分散memtableは、バッチ処理ではあまり恩恵を得られない

これを元に、やりたい事は「締め処理を速くしたい」
締め処理の特徴
・BigDataまではいかない
・小さなマスターが多い
・大きなマスターもある
・トランザクションとの全件結合なんてことも(汗)

小さなマスターだと、そこにアクセスすると負荷が集中する可能性がある。
（そもそもHadoopではSequenceFileとかにして配布する機能があったと思うけど、大きさ次第なのかな？）

MapReduceのReduceサイドJOINだと、マスターが大きい場合は、一部しか使われないと無駄（同期はされる（ReduceタスクはMapタスクが終わるのを待つ）ので、遅くなる）。
↓逆の発想
マスターをHBaseで分散しておいて、（キーで分散しているから）その場所にトランザクションデータを配置して処理
↓
ただし、出力先も同じリージョンになるとは限らない（キーが異なるから）
↓
ハッシュをROWキーにして、同じ場所を強制する？（←さすがに無理があると思う(苦笑)）

---

最後に、frsyukiさん。

ログ収集ツール（まだ未公開）の紹介。（Facebookのscribeを参考にしたそう）
先ほどの販売管理の集配信に似た仕組みということかな？

ログ→fluent→HDFS
fluent（フルーエント）でバッファリングおよびスプリット（MessagePack File）し、定期的にHDFSに保存。たまにマージジョブを実行する。
バッファリングの際にコンバイナーのような演算も出来る。
キューのような使い方も出来るが、入力は1件ずつだけど出力はチャンク単位という制限がある。

もうひとつ、MessagePack＋Hadoop。
MessagePackのIDLで構造を定義し、MapReduceやHiveで指定できる。
MessagePackInputFormat・MessagePackWritableにはちょっと燃えた(笑)　いいなぁ、これ！

それと、Columnar File。カラム指向ファイルということかな。
[id:1, a:11, b:202][id:2, a:13, b:204]というデータがあったら、id:[1,2],a[11,13],b[202,204]という形で保存することによって、キー名を毎回書かなくても済む分、データ量が減らせる。
また、特定キーのデータをスキップすることも簡単になる。
さすがMessagePackを作っているだけあって、そういう部分は詳しそう。

最後に非構造化データに関する質問があって、クレンジングについて話題が。クレンジングには2種類あって、
・データフォーマットが壊れている→実際には少ない。バリデーションで弾く
・セマンティクス（意味）がおかしい→必要がデータが入っていないとか値が変とか
現実には前者は少なく、後者の方が多いとのこと。

---

ふう、今回も盛りだくさんでした。

HBaseでどうテーブル（カラム）を持たせればいいかというのは思考実験で考えていたつもりだけど、実際の特性は知らないので、やっぱりそういう所も気にしないと駄目ですね。

ありがとうございました。