• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Hbase勉強会(第一回)メモ
 

Hbase勉強会(第一回)メモ

on

  • 5,368 views

 

Statistics

Views

Total Views
5,368
Views on SlideShare
5,354
Embed Views
14

Actions

Likes
10
Downloads
0
Comments
0

5 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

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Hbase勉強会(第一回)メモ Hbase勉強会(第一回)メモ Presentation Transcript

    • 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
          • ファイルブロックのキャッシュ