• Save
Hbase勉強会(第一回)メモ
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
5,635
On Slideshare
5,621
From Embeds
14
Number of Embeds
5

Actions

Shares
Downloads
0
Comments
0
Likes
11

Embeds 14

http://paper.li 6
http://us-w1.rockmelt.com 3
https://twitter.com 3
http://twitter.com 1
https://si0.twimg.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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