HBase 第一回のメモです。 2011/5/20 @okachimachiorz1
Hbase <ul><li>Hbase の用途についての検討資料 </li></ul><ul><ul><li>Hbase の基本的性質の整理 </li></ul></ul><ul><ul><ul><li>振る舞い </li></ul></ul>...
<ul><li>Hbase の基本的性質についての整理 </li></ul><ul><ul><li>振る舞い </li></ul></ul><ul><ul><ul><li>分散型 </li></ul></ul></ul><ul><ul><ul>...
<ul><li>基本的データモデル </li></ul><ul><ul><li>行キー </li></ul></ul><ul><ul><ul><li>まぁ PK みたいなもんか~ 100byte 以下の任意の文字列~ dictionary </...
ちょっと考える~データモデル <ul><li>KVS 的には </li></ul><ul><ul><li>ジャーナルをダダ漏れで入れておいて、あとでキーで引っ張る </li></ul></ul><ul><ul><ul><li>例として POS ...
ちょっと考える 2 <ul><li>結局ローカリティはユーザーが意識する必要があるのか? </li></ul><ul><ul><li>それは駄目っぽくない? </li></ul></ul><ul><ul><li>というか、それをアプリ側に意識さ...
とはいえ、実際のアプリ・レイヤーから検討してみる <ul><li>想定されるアプリ </li></ul><ul><ul><li>考慮すべき事項は </li></ul></ul><ul><ul><ul><li>キー </li></ul></ul>...
受発注 <ul><li>受発注データモデル </li></ul><ul><ul><li>例)受注データ </li></ul></ul>キー考察) 結局、 Nest したデータ構造でのキー付けがポイントになる 受発注では伝票番号自体はユニーク保証...
物流 <ul><li>物流データモデル </li></ul><ul><ul><li>例)出荷指示書 </li></ul></ul>キー考察) データ間のトレーサビリティを取っていくときに工夫が必要になる。 ER モデルについても同様な問題が発生...
決済 <ul><li>決済データモデル </li></ul><ul><ul><li>例)請求データ </li></ul></ul>キー考察) 決済データの基本はサマリー(束にする=締め処理)と明細トレースになる。 他の種類のデータと異なり一般に...
情報系 <ul><li>情報系データ </li></ul><ul><ul><li>例)正規化終了後(営業日報確定後) POS データ </li></ul></ul>考察)情報系のログは便宜的にタイムスタンプをキーにすることが多いが、 おそらくそ...
人事系 <ul><li>人事系 </li></ul><ul><ul><li>例)出退勤ログ </li></ul></ul>考察) そもそも Timestamp がキーではなくてデータだったら、どうするのか?という問題 採番問題は考え置かないとあ...
ちょっとした結論 <ul><li>業務系データをどう格納するか? </li></ul><ul><ul><li>TX 系は頑張ればいける気がする </li></ul></ul><ul><ul><ul><li>業務系のデータモデルをある程度 F/W...
うまく Hbase 用のデータモデルは考えられないのか? <ul><li>半構造データの特徴 </li></ul><ul><ul><li>取り回しを考えるのであれば・・・ </li></ul></ul><ul><ul><li>抽象データ型の導入...
補足 <ul><li>カラムファミリー </li></ul><ul><ul><li>圧縮 </li></ul></ul><ul><ul><ul><li>Gzip, LZO </li></ul></ul></ul><ul><ul><li>Vers...
Upcoming SlideShare
Loading in...5
×

Hbase勉強会(第一回)メモ

5,192

Published on

Published in: Technology
0 Comments
11 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
5,192
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
11
Embeds 0
No embeds

No notes for slide

Hbase勉強会(第一回)メモ

  1. 1. HBase 第一回のメモです。 2011/5/20 @okachimachiorz1
  2. 2. Hbase <ul><li>Hbase の用途についての検討資料 </li></ul><ul><ul><li>Hbase の基本的性質の整理 </li></ul></ul><ul><ul><ul><li>振る舞い </li></ul></ul></ul><ul><ul><ul><li>データモデル ~ 業務アプリから見てみる </li></ul></ul></ul><ul><ul><li>用途についてのレイヤー毎での検討 </li></ul></ul><ul><ul><ul><li>レイヤーの整理~アプリ・レイヤーから見てみる </li></ul></ul></ul><ul><ul><ul><li>検討 </li></ul></ul></ul>
  3. 3. <ul><li>Hbase の基本的性質についての整理 </li></ul><ul><ul><li>振る舞い </li></ul></ul><ul><ul><ul><li>分散型 </li></ul></ul></ul><ul><ul><ul><ul><li>一般に、理屈からいうと複雑さがますほど制御が困難になる。 </li></ul></ul></ul></ul><ul><ul><ul><ul><li>CAP 定理については、内容に疑義はあるが検討項目には値する。すなわち、 Consistency ・ Availability ・ Partition-Tolerance について留意する </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>一般に HBase は Consistency を重視していると言われる </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>そのため SPoF 問題が常に浮上する。 SPoF はよく Availability の点で指摘されるが、むしろ Consistency の点からも検討されるべきである(不整合な状態を作るくらいなら、とっとと死ね的) </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><li>これらは後述するそれぞれのレイヤーから検討されるべき </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>今回はちょっとパス </li></ul></ul></ul></ul></ul><ul><ul><ul><li>SortedMap </li></ul></ul></ul><ul><ul><ul><ul><li>行キー・列・タイムスタンプとしてキーを利用する </li></ul></ul></ul></ul><ul><ul><ul><ul><li>カラムファミリー </li></ul></ul></ul></ul><ul><ul><ul><ul><li>データモデルの側面から検討すべき->今日のお題 </li></ul></ul></ul></ul><ul><ul><ul><li>HadoopMapReduce との親和性 </li></ul></ul></ul><ul><ul><ul><ul><li>単なる KVS 実装であれば、他のプロダクツはいくらでもある </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Hbase の相対メリットを明確にすべき </li></ul></ul></ul></ul><ul><ul><ul><ul><li>これも後で真剣に検討する </li></ul></ul></ul></ul><ul><ul><ul><li>想定されている利用コンテクストの整理 </li></ul></ul></ul><ul><ul><ul><ul><li>大容量 GB ~ PB </li></ul></ul></ul></ul><ul><ul><ul><ul><li>高速 Write k クエリー /sec/node </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Cache 利用 拡張性~あと mem 要請が強い </li></ul></ul></ul></ul><ul><ul><ul><ul><li>データレイアウト キー検索と Sparse カラム </li></ul></ul></ul></ul>
  4. 4. <ul><li>基本的データモデル </li></ul><ul><ul><li>行キー </li></ul></ul><ul><ul><ul><li>まぁ PK みたいなもんか~ 100byte 以下の任意の文字列~ dictionary </li></ul></ul></ul><ul><ul><ul><ul><li>・・・なので、 1,10,2,3,4,5 とかになるのよ。 </li></ul></ul></ul></ul><ul><ul><ul><ul><li>頭に 0 入れるとか、 Hash 使うとかノウハウはある。 </li></ul></ul></ul></ul><ul><ul><ul><ul><li>逆順に格納するという方法はよく使う。 </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Long.MAX_VALUE -System.currentTimeMillis() </li></ul></ul></ul></ul></ul><ul><ul><li>各 Table には、一つ以上のカラムファミリー </li></ul></ul><ul><ul><ul><li>あまり多数にわたるものは想定はしていない </li></ul></ul></ul><ul><ul><ul><li>あまり変化しない前提がある </li></ul></ul></ul><ul><ul><ul><ul><li>追加変更は一度 disable させてから行う </li></ul></ul></ul></ul><ul><ul><li>各行単位でのタイムスタンプ </li></ul></ul><ul><ul><ul><li>versioning に利用する </li></ul></ul></ul><ul><ul><li>基本的な Table 構造 </li></ul></ul><ul><ul><ul><li>行キー + 列キー + タイムスタンプ  ->  値 </li></ul></ul></ul><ul><ul><ul><li>相当制限的を見るべき </li></ul></ul></ul><ul><ul><ul><ul><li>普通に考えると特にアプリレイヤーでは、用途は制限される </li></ul></ul></ul></ul><ul><ul><ul><ul><li>制限的なデータモデルが許容されるミドルレイヤーでは用途が高い </li></ul></ul></ul></ul>
  5. 5. ちょっと考える~データモデル <ul><li>KVS 的には </li></ul><ul><ul><li>ジャーナルをダダ漏れで入れておいて、あとでキーで引っ張る </li></ul></ul><ul><ul><ul><li>例として POS データの登録を考えてみる </li></ul></ul></ul><ul><ul><ul><li>journal-> 商品 ID-> 単品集計 </li></ul></ul></ul><ul><ul><li>本質的には、登録ポイントを複数にしてスケールするか?どうか </li></ul></ul><ul><ul><ul><li>ジャーナル自体の発生は 1000 箇所以上 </li></ul></ul></ul><ul><ul><ul><li>登録が N 箇所でできて、整合性がとれればよい </li></ul></ul></ul><ul><ul><ul><ul><li>多分問題ないはず </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Rowkey の Uniqueness は保証可能 </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>ローカリティが分散するようにしてあげることが必要 </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><li>カラムで一発でとれるとうれしい </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>うれしいこともあるが、あまりに直線的な使い方に見える </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>汎用性は確実に低い </li></ul></ul></ul></ul></ul><ul><ul><li>・・・やっぱり前提として、 prejoin はやっている気がする </li></ul></ul><ul><ul><ul><li>暗黙のうちの事前フォーマットを想定している </li></ul></ul></ul><ul><ul><li>ロー・キーのローカリティに注意することは必須 </li></ul></ul><ul><ul><ul><li>HBase では同じ場所になるから。 </li></ul></ul></ul><ul><ul><ul><li>カラム・ファミリーは同じファイルに入ることも留意すること </li></ul></ul></ul>
  6. 6. ちょっと考える 2 <ul><li>結局ローカリティはユーザーが意識する必要があるのか? </li></ul><ul><ul><li>それは駄目っぽくない? </li></ul></ul><ul><ul><li>というか、それをアプリ側に意識させないミドルがいるんじゃないの? </li></ul></ul><ul><ul><ul><li>論理的には意識しろ、物理的には意識するな。 </li></ul></ul></ul><ul><ul><li>単純に分散 KVS 的な処理としてはローレイヤーでかまわないが、これでは汎用性が低い気がする </li></ul></ul><ul><ul><ul><li>別に SQL がとか、「そういう話」ではない。それ以前の話。 </li></ul></ul></ul><ul><ul><li>物理的なローカリティと論理的ローカリティは微妙に一致しないので、混乱しないようにした方が良い </li></ul></ul><ul><ul><ul><li>特にデータに偏りがある場合 </li></ul></ul></ul><ul><ul><ul><li>論理的には均一に見えるけど、物理的には偏っているようなケース </li></ul></ul></ul><ul><ul><li>HBase のローカリティの管理は整理しておきたい </li></ul></ul><ul><ul><ul><li>Table->RS-> データ </li></ul></ul></ul>
  7. 7. とはいえ、実際のアプリ・レイヤーから検討してみる <ul><li>想定されるアプリ </li></ul><ul><ul><li>考慮すべき事項は </li></ul></ul><ul><ul><ul><li>キー </li></ul></ul></ul><ul><ul><ul><li>ローカリティ </li></ul></ul></ul><ul><ul><li>ローカリティは特に MR の観点から検討しておくことが望ましい </li></ul></ul><ul><ul><li>主要の業務アプリのセグメント </li></ul></ul><ul><ul><ul><li>受発注 </li></ul></ul></ul><ul><ul><ul><ul><li>TX の多い消費財系の受発注を想定 </li></ul></ul></ul></ul><ul><ul><ul><li>物流 </li></ul></ul></ul><ul><ul><ul><ul><li>マテハン直前のデータに絞る。出荷指示・ ASN </li></ul></ul></ul></ul><ul><ul><ul><li>決済 </li></ul></ul></ul><ul><ul><ul><ul><li>基本的にマッチング処理 </li></ul></ul></ul></ul><ul><ul><ul><li>情報系 </li></ul></ul></ul><ul><ul><ul><ul><li>BI 系 </li></ul></ul></ul></ul><ul><ul><ul><li>人事系 </li></ul></ul></ul><ul><ul><ul><ul><li>給与計算 </li></ul></ul></ul></ul>何が見えるか、ちょっと 考えてみよう・・・ 思考実験なので 割とイマイチなの 勘弁してね。
  8. 8. 受発注 <ul><li>受発注データモデル </li></ul><ul><ul><li>例)受注データ </li></ul></ul>キー考察) 結局、 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
  9. 9. 物流 <ul><li>物流データモデル </li></ul><ul><ul><li>例)出荷指示書 </li></ul></ul>キー考察) データ間のトレーサビリティを取っていくときに工夫が必要になる。 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
  10. 10. 決済 <ul><li>決済データモデル </li></ul><ul><ul><li>例)請求データ </li></ul></ul>キー考察) 決済データの基本はサマリー(束にする=締め処理)と明細トレースになる。 他の種類のデータと異なり一般にヘッダー的な部分のウェイトが大きい とはいえ、基本的に前述の受発注・物流系のデータが処理できれば、メタレベルで大きな差があるわけではない ロケーション考察) 鬼の偏りは間違いなしだね。全世界的に偏る。 多分セカンダリーソートまで意図的に考えないとまったく分散しないで悲鳴があがる。 ・・・む~、このキーで良いか ? 的なレベル。 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
  11. 11. 情報系 <ul><li>情報系データ </li></ul><ul><ul><li>例)正規化終了後(営業日報確定後) POS データ </li></ul></ul>考察)情報系のログは便宜的にタイムスタンプをキーにすることが多いが、 おそらくそれ一本では機能しないので、考えていくことが必要になる。 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
  12. 12. 人事系 <ul><li>人事系 </li></ul><ul><ul><li>例)出退勤ログ </li></ul></ul>考察) そもそも Timestamp がキーではなくてデータだったら、どうするのか?という問題 採番問題は考え置かないとあとあと禍根を残す可能性もある 現状では、わりと無条件に時系列の Index が中立的なので、キーとしてつかるでしょう、という発想だけど 時系列データそのものに「意味」が発生した場合は中立性がなくなるので、他を考慮する必要がある Row key Column family Column keys personnel_ID Metadata Name, IDs personnel_ID+action_id Actions Type, Timestamp
  13. 13. ちょっとした結論 <ul><li>業務系データをどう格納するか? </li></ul><ul><ul><li>TX 系は頑張ればいける気がする </li></ul></ul><ul><ul><ul><li>業務系のデータモデルをある程度 F/W 化する必要がある </li></ul></ul></ul><ul><ul><ul><ul><li>① キー付けの問題が業務ドメインに固有 </li></ul></ul></ul></ul><ul><ul><ul><ul><li>② ロケーション管理 </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>どの単位で引っ張るか?ということ </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>HBase の特徴が MR であるため、そこを意識する必要がある </li></ul></ul></ul></ul></ul><ul><ul><ul><li>デメリットは・・・ </li></ul></ul></ul><ul><ul><ul><ul><li>繰り返し使わないと、モデル練度が上がらない </li></ul></ul></ul></ul><ul><ul><ul><ul><li>なんか構築コストが高くつくような気がする。 </li></ul></ul></ul></ul><ul><ul><ul><ul><li>メンテ性も良くはない </li></ul></ul></ul></ul><ul><ul><li>Master 系 </li></ul></ul><ul><ul><ul><li>M と TX の境界定義は曖昧なので今回の考察では見送り </li></ul></ul></ul>
  14. 14. うまく Hbase 用のデータモデルは考えられないのか? <ul><li>半構造データの特徴 </li></ul><ul><ul><li>取り回しを考えるのであれば・・・ </li></ul></ul><ul><ul><li>抽象データ型の導入が必要 </li></ul></ul><ul><ul><ul><li>まぁ Dictionary なんで、これをベースに拡張することは可能のはず </li></ul></ul></ul><ul><ul><ul><li>辞書型だけでは、身もふたもないないので </li></ul></ul></ul><ul><ul><ul><ul><li>Stack </li></ul></ul></ul></ul><ul><ul><ul><ul><li>List </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Array </li></ul></ul></ul></ul><ul><ul><ul><ul><li>あたりかな・・・ </li></ul></ul></ul></ul><ul><ul><li>ふと思うのは </li></ul></ul><ul><ul><ul><li>TX->KVS でだらだら入れ込む </li></ul></ul></ul><ul><ul><ul><li>Ms-> 抽象データ型で取り回しを重視する </li></ul></ul></ul><ul><ul><ul><ul><li>ということはありかな、とは思う。 </li></ul></ul></ul></ul><ul><ul><ul><li>いずれにしろ、 Ms 系の join は KVS は苦手のはずなので、 MR の専業だと思う </li></ul></ul></ul>
  15. 15. 補足 <ul><li>カラムファミリー </li></ul><ul><ul><li>圧縮 </li></ul></ul><ul><ul><ul><li>Gzip, LZO </li></ul></ul></ul><ul><ul><li>Version </li></ul></ul><ul><ul><ul><li>初期値は 3 </li></ul></ul></ul><ul><ul><li>TTL </li></ul></ul><ul><ul><li>Blocksize </li></ul></ul><ul><ul><ul><li>リードリクエストに対する読み込み量 </li></ul></ul></ul><ul><ul><li>In_Memory </li></ul></ul><ul><ul><ul><li>行をメモリーに置くかどうか </li></ul></ul></ul><ul><ul><li>Blockcache </li></ul></ul><ul><ul><ul><li>ファイルブロックのキャッシュ </li></ul></ul></ul>

×