Hbase勉強会（第一回）メモ

HBase 第一回のメモです。 2011/5/20 @okachimachiorz1

Hbase Hbase の用途についての検討資料 Hbase の基本的性質の整理振る舞いデータモデル ~ 業務アプリから見てみる用途についてのレイヤー毎での検討レイヤーの整理～アプリ・レイヤーから見てみる検討

Hbase の基本的性質についての整理振る舞い分散型一般に、理屈からいうと複雑さがますほど制御が困難になる。 CAP 定理については、内容に疑義はあるが検討項目には値する。すなわち、 Consistency ・ Availability ・ Partition-Tolerance について留意する一般に HBase は Consistency を重視していると言われるそのため SPoF 問題が常に浮上する。 SPoF はよく Availability の点で指摘されるが、むしろ Consistency の点からも検討されるべきである（不整合な状態を作るくらいなら、とっとと死ね的）これらは後述するそれぞれのレイヤーから検討されるべき今回はちょっとパス SortedMap 行キー・列・タイムスタンプとしてキーを利用するカラムファミリーデータモデルの側面から検討すべき->今日のお題 HadoopMapReduce との親和性単なる KVS 実装であれば、他のプロダクツはいくらでもある Hbase の相対メリットを明確にすべきこれも後で真剣に検討する想定されている利用コンテクストの整理大容量 GB ～ PB 高速 Write k クエリー /sec/node Cache 利用拡張性～あと mem 要請が強いデータレイアウトキー検索と Sparse カラム

基本的データモデル行キーまぁ PK みたいなもんか～ 100byte 以下の任意の文字列～ dictionary ・・・なので、 1,10,2,3,4,5 とかになるのよ。頭に 0 入れるとか、 Hash 使うとかノウハウはある。逆順に格納するという方法はよく使う。 Long.MAX_VALUE -System.currentTimeMillis() 各 Table には、一つ以上のカラムファミリーあまり多数にわたるものは想定はしていないあまり変化しない前提がある追加変更は一度 disable させてから行う各行単位でのタイムスタンプ versioning に利用する基本的な Table 構造行キー + 列キー + タイムスタンプ　 -> 　値相当制限的を見るべき普通に考えると特にアプリレイヤーでは、用途は制限される制限的なデータモデルが許容されるミドルレイヤーでは用途が高い

ちょっと考える～データモデル KVS 的にはジャーナルをダダ漏れで入れておいて、あとでキーで引っ張る例として POS データの登録を考えてみる journal-> 商品 ID-> 単品集計本質的には、登録ポイントを複数にしてスケールするか？どうかジャーナル自体の発生は 1000 箇所以上登録が N 箇所でできて、整合性がとれればよい多分問題ないはず Rowkey の Uniqueness は保証可能ローカリティが分散するようにしてあげることが必要カラムで一発でとれるとうれしいうれしいこともあるが、あまりに直線的な使い方に見える汎用性は確実に低い・・・やっぱり前提として、 prejoin はやっている気がする暗黙のうちの事前フォーマットを想定しているロー・キーのローカリティに注意することは必須 HBase では同じ場所になるから。カラム・ファミリーは同じファイルに入ることも留意すること

ちょっと考える 2 結局ローカリティはユーザーが意識する必要があるのか？それは駄目っぽくない？というか、それをアプリ側に意識させないミドルがいるんじゃないの？論理的には意識しろ、物理的には意識するな。単純に分散 KVS 的な処理としてはローレイヤーでかまわないが、これでは汎用性が低い気がする別に SQL がとか、「そういう話」ではない。それ以前の話。物理的なローカリティと論理的ローカリティは微妙に一致しないので、混乱しないようにした方が良い特にデータに偏りがある場合論理的には均一に見えるけど、物理的には偏っているようなケース HBase のローカリティの管理は整理しておきたい Table->RS-> データ

とはいえ、実際のアプリ・レイヤーから検討してみる想定されるアプリ考慮すべき事項はキーローカリティローカリティは特に MR の観点から検討しておくことが望ましい主要の業務アプリのセグメント受発注 TX の多い消費財系の受発注を想定物流マテハン直前のデータに絞る。出荷指示・ ASN 決済基本的にマッチング処理情報系 BI 系人事系給与計算何が見えるか、ちょっと考えてみよう・・・思考実験なので割とイマイチなの勘弁してね。

受発注受発注データモデル例）受注データキー考察）結局、 Nest したデータ構造でのキー付けがポイントになる受発注では伝票番号自体はユニーク保証が必須だけど、その下位での繰り返し構造をどう表現するか？がポイント BMS だと N 行、 J 手順だと 6 行固定とか Metadata ＝ header 的な取り扱いがフィットすると思う body 以降を lineID を加えてキーとして処理するたしかに後からカラムを足せるは便利だけど、テストや連携とか考えるとメリットも半減するラッパーとしての F/W が必要だと思うローカリティ考察）間違いなく物理的には偏る。クレンジングや引当を考えるのであればキーには Hash を振った方が絶対よい。ただし、処理的にはバッチ処理の方が多いはず。なので、 MR 処理を意識したロケーションがよい。 Row key Column family Column keys Voucher_ID Metadata type,header, date,customer_id Voucher_ID+line_ID Transactions Price, qty, amount Voucher_ID+line_ID Status reserved, shipped

物流物流データモデル例）出荷指示書キー考察）データ間のトレーサビリティを取っていくときに工夫が必要になる。 ER モデルについても同様な問題が発生したように Dangling の問題は絶対発生する物流データのように、他のデータとのつなぎが重要なデータは、キー間の連携を検討する必要がある。ロケーション考察）種まきか刈り取りかで出し方は変わるので、その辺はちょっと考慮がいる順次処理やワークアロケーションを優先するのであれば、偏りはすくない。 in_charge あたりの処理は平準化するので、ロケーション管理は割と楽 Row key Column family Column keys Instruction_ID Metadata type,header, in_charge, referred_id Instruction_ID+line_ID Transactions merchadise_id, picked, Instruction_ID+line_ID+ Timestamp Adjustment adjust_qty, split

決済決済データモデル例）請求データキー考察）決済データの基本はサマリー（束にする＝締め処理）と明細トレースになる。他の種類のデータと異なり一般にヘッダー的な部分のウェイトが大きいとはいえ、基本的に前述の受発注・物流系のデータが処理できれば、メタレベルで大きな差があるわけではないロケーション考察）鬼の偏りは間違いなしだね。全世界的に偏る。多分セカンダリーソートまで意図的に考えないとまったく分散しないで悲鳴があがる。・・・む～、このキーで良いか ? 的なレベル。 Hash で振るのはセンスゼロ円なんで、論理キーはロケーションと論理集合を意識する上記の例は「これだけ」では無理だと思う。 Row key Column family Column keys Invoice_id Metadata type,header, total_amout, conditions Invoice_id+line_ID Transactions detail_id, date, amout, c-tax, Invoice_id+line_ID+ ref_id referred_tx not_reserved

情報系情報系データ例）正規化終了後（営業日報確定後） POS データ考察）情報系のログは便宜的にタイムスタンプをキーにすることが多いが、おそらくそれ一本では機能しないので、考えていくことが必要になる。 Web 系のログ解析であれば、とりあえず時系列データ的に扱う、ということを主眼して、一時的に timestamp で格納するということはあるとは思う（素人なので、この辺はよくわからんが、聞いているとそういうのが多い）ただし、なんというか「そのまま入れ込んで使う」という感覚があるので、気にくわない。データモデルが、実装に引っ張られているので、デザイン的には「失敗している Affrodance 」な感じがする・・・ ( 苦笑ロケーション） POS データの格納でいえば、例えば、店舗単位で Table をつくる感じかな。 -> RS でバランスしてくれるので、店舗規模での調整は不要というのは分散のメリット MR するにしても、確実に journal 単位で独立処理ができるので最適になる。まぁいけると思う。 Row key Column family Column keys journal_ID Metadata Name, IDs journal_ID Transactions Price, qty, amount journal_ID+ check_Timestamp Adjustment Name, IDs

人事系人事系例）出退勤ログ考察）そもそも Timestamp がキーではなくてデータだったら、どうするのか？という問題採番問題は考え置かないとあとあと禍根を残す可能性もある現状では、わりと無条件に時系列の Index が中立的なので、キーとしてつかるでしょう、という発想だけど時系列データそのものに「意味」が発生した場合は中立性がなくなるので、他を考慮する必要がある Row key Column family Column keys personnel_ID Metadata Name, IDs personnel_ID+action_id Actions Type, Timestamp

ちょっとした結論業務系データをどう格納するか？ TX 系は頑張ればいける気がする業務系のデータモデルをある程度 F/W 化する必要がある ① キー付けの問題が業務ドメインに固有 ② ロケーション管理どの単位で引っ張るか？ということ HBase の特徴が MR であるため、そこを意識する必要があるデメリットは・・・繰り返し使わないと、モデル練度が上がらないなんか構築コストが高くつくような気がする。メンテ性も良くはない Master 系 M と TX の境界定義は曖昧なので今回の考察では見送り

うまく Hbase 用のデータモデルは考えられないのか？半構造データの特徴取り回しを考えるのであれば・・・抽象データ型の導入が必要まぁ Dictionary なんで、これをベースに拡張することは可能のはず辞書型だけでは、身もふたもないないので Stack List Array あたりかな・・・ふと思うのは TX->KVS でだらだら入れ込む Ms-> 抽象データ型で取り回しを重視するということはありかな、とは思う。いずれにしろ、 Ms 系の join は KVS は苦手のはずなので、 MR の専業だと思う

補足カラムファミリー圧縮 Gzip, LZO Version 初期値は 3 TTL Blocksize リードリクエストに対する読み込み量 In_Memory 行をメモリーに置くかどうか Blockcache ファイルブロックのキャッシュ

Hbase勉強会（第一回）メモ

More Related Content

Viewers also liked (14)

Hbase勉強会（第一回）メモ