スケーラブルなシステムのためのHBaseスキーマ設計 #hcj13w

13,479 views

Published on

Cloudera HBase トレーニング: http://tiny.cloudera.com/jptraininghbase
Hadoop Conference Japan 2013 Winter で発表した、HBaseのスキーマ設計に関する資料です。
Cloudera の HBase サポート、Cloudera Enterprise RTD
http://tiny.cloudera.com/jpcertd

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

No Downloads
Views
Total views
13,479
On SlideShare
0
From Embeds
0
Number of Embeds
202
Actions
Shares
0
Downloads
257
Comments
0
Likes
56
Embeds 0
No embeds

No notes for slide

スケーラブルなシステムのためのHBaseスキーマ設計 #hcj13w

  1. 1. スケーラブルなシステムのための   HBaseスキーマ設計   Cloudera株式会社  カスタマーオペレーションズエンジニア   嶋内  翔   2013年1月21日  1
  2. 2. 自己紹介   •  嶋内 翔(しまうち しょう)   •  2011年4月にClouderaの最初の日本人社員として入 社   •  カスタマーオペレーションズエンジニアとしてテクニ カルサポート業務を担当   •  email:  sho@cloudera.com   •  twi=er:  @shiumachi  2
  3. 3. Agenda   •  Apache  HBase  とは   •  スキーマ設計の話の前に   •  HBase  ストレージアーキテクチャ   •  スキーマ設計のポイント  3
  4. 4. セッション概要   •  Hadoop  上で動作する分散ストレージシステム HBase  を活用するためのスキーマ設計のポイントに ついて紹介します   •  ゴール   •  性能が出る、正しいHBaseのスキーマ設計ができるように なること   •  アンチパターンを知り、誤ったスキーマ設計を避けるよう になること  4
  5. 5. 対象者・レベル   •  対象者   •  HBase  の構築・運用担当者   •  HBase  アプリケーションの開発者   •  対象レベル:  中級   •  Hadoop  (特に  HDFS)  について、アーキテクチャをある程度 理解している  5
  6. 6. 本セッションで取り扱わない内容   (1)  HDFSの信頼性   •  HBaseはデータの信頼性をファイルシステムに依存 しています   •  HDFSは十分信頼性が高いです   •  数年以上の稼動実績   •  HDFS  HA  によるSPOFの排除   •  詳細は下記スライドを参照してください   •  Cloudera  Manager4.0とNameNode-­‐HAセミナー資料   •  h=p://www.slideshare.net/Cloudera_jp/cloudera-­‐ manager4namenodeha   •  CDH4.1オーバービュー(HA機能についての説明がありま す)   •  h=p://www.slideshare.net/Cloudera_jp/cdh41  6
  7. 7. 本セッションで取り扱わない内容   (2)  Hadoop/HBaseの運用・チューニング   Cloudera  Managerを使えば1時間でCDHクラスタの構 築ができ、管理も非常に簡単です   HBaseを使うなら   Cloudera  Enterprise   (CDH  +  Cloudera  Manager)   を選びましょう   ダウンロードはこちら   h=p://www.cloudera.com/downloads/  7
  8. 8. Apache  HBase  とは  8
  9. 9. HBase  •  HDFS  上で動作する NoSQL  •  Google  の開発した NoSQL  BigTable  に基づいて作成され ている  •   HDFS  が苦手とする低レイテンシのアクセスや小さいファ イルの操作を得意とする   h=p://ja.fotopedia.com/items/flickr-­‐1999559141  
  10. 10. なぜHBaseを使うのか  •  シャーディングをサポートしてる   •  自動シャーディング   •  コマンド一発で手動シャーディング  •  書き込みが高速で、しかもスケールアウト可能  •  データの耐障害性も確保されてる   •  これはHadoopのファイルシステムHDFSの機能  
  11. 11. HBaseのデータ構造  キーバリューがソートされて並んでいる   タイム  行キー   列ファミリ   列   値   スタンプ   r1   cf1   c1   1000   ‘python’   r1   cf1   c2   1000   ‘php’   r1   cf2   c1   1000   ‘ruby’   r2   cf1   c2   1000   ‘java’  
  12. 12. HBaseのテーブル構造(概要)  •  行キーの一定範囲ごとに別ファイルに分割   •  この範囲のことをリージョンという  •  1リージョンには列ファミリの数以上のストアファイルが存在  •  ここではかなり簡略化して説明している。詳細は後述   列ファミリ1   列ファミリ2   リージョン   ストアファイル   ストアファイル   a  -­‐  c   リージョン   ストアファイル   ストアファイル   d  -­‐  f   リージョン   ストアファイル   ストアファイル   h  -­‐  j  
  13. 13. HBaseの構成図   ※マスタサーバは存在するが、   クライアント   データ通信には使わない   リージョンサーバ   リージョンサーバ   リージョンサーバ   リージョンa   リージョンb   リージョンc   データノード       データノード   データノード   データノード       データノード   データノード       データノード   データノード   データノード   ブロック1   ブロック1   ブロック1   ブロック2   ブロック2   ブロック2   ブロック3   ブロック3   ブロック3  
  14. 14. HBaseの動作概要   クライアント   HDFSと同様、クライアントはマスタを介さず 直接リージョンサーバと通信する   リージョンサーバ   リージョンサーバ   リージョンサーバ   リージョンサーバはHDFSのクライアントとして   データノードと通信する   リージョンa   リージョンb   リージョンc   データノード       データノード   データノード   データノード       データノード   データノード       データノード   データノード   データノード   ブロック1   ブロック1   ブロック1   ブロック2   ブロック2   ブロック2   ブロック3   ブロック3   ブロック3  
  15. 15. スキーマ設計の話の前に  15
  16. 16. 究極のベストプラクティス、それは……  16  
  17. 17. h=p://ja.fotopedia.com/items/flickr-­‐1999559141  17  
  18. 18. HBaseを使わない   (必要がない限り)   h=p://ja.fotopedia.com/items/flickr-­‐1999559141  18  
  19. 19. HBase  にはない機能がいっぱい   •  JOINがない   •  セカンダリインデックスも当然ない   •  テーブル間トランザクションがない   •  etc.   RDBMSは超優秀だし最近はハードウェアも安いので   必要ない限りはRDBMS使いましょう  19
  20. 20. じゃあどんなときにHBaseを使えばいいの?  20
  21. 21. じゃあどんなときにHBaseを使えばいいの?   大量のデータがあるとき!  21
  22. 22. じゃあどんなときにHBaseを使えばいいの?   大量のデータがあるとき!   •  サーバ1台のメモリに載りきらない   •  サーバ1台のディスクに入りきらない   •  etc.   •  最近のサーバだとメモリ100GB、ディスク10TB(RAID5)ぐ らいなら余裕のはず   •  Hadoopを既に使っている人は大量データがあるはずな ので利用の検討はあり  22
  23. 23. HBaseとRDBの比較   RDB   HBase   •  RDBMSが高機能   •  非正規化前提   •  きちんとDB設計すればほ •  特定のクエリに特化して ぼどんなクエリにも対応 設計   可能   •  用途を絞ってしまえば、 •  スケールしない   容量や読み書きがスケー •  ストレージ容量   ルするので非常に強力   •  書き込み   •  Hadoop  との連携がしや すい  23  
  24. 24. RDBとHBaseにおけるスキーマ設計の違い  24
  25. 25. RDBとHBaseにおけるスキーマ設計の違い   論理設計まではほぼ同じ   •  論理データモデルが間違ってたらこの先の議論は 無意味   •  RDBとHBaseの違いは物理表現レベルの話  25
  26. 26. しかし、設計段階でも物理表現を知ることは   重要   •  HBaseはユースケースやアクセスパターンに基づい て自動的に最適化したりしない   •  HBaseの実装を知らないと正しいスキーマ設計がで きない   •  このセッションではまずHBaseのストレージアーキテ クチャを理解し、その上でスキーマ設計の話に移る  26
  27. 27. HBase  ストレージアーキテクチャ  27
  28. 28. HBaseテーブル   列ファミリA   列ファミリB   列a   列b   列c   列a   列b   行   r1   リージョン1   行   r2   行   (r3,  A:b)   r3   ver.1   行   リージョン2   r4   行   r5  28  
  29. 29. HBaseテーブル   •  行と列によるテーブル構造   •  行は一定範囲ごとに「リージョン」という単位で区切られて いる   •  列は「列ファミリ」という単位でグループ化されている   •  セル  =  行と列の交点   •  セルはタイムスタンプを持っている   •  バージョンとタイムスタンプはほぼ同じ意味  29
  30. 30. HBaseテーブル   列ファミリA   列ファミリB   列a   列b   列c   列a   列b   行   r1   リージョン1   行   r2   行   (r3,  A:b)   r3   ver.1   行   リージョン2   r4   行   r5  30  
  31. 31. HBaseテーブル   列ファミリA   列ファミリB   列a   列b   列c   列a   列b   行   テーブルに対する行、列、そして行と列の交差する部分 r1   のセル   リージョン1   論理的なテーブル構造は基本的にRDBと変わらない   行   r2   行   (r3,  A:b)   r3   ver.1   行   リージョン2   r4   行   r5  31  
  32. 32. HBaseテーブル   列ファミリA   列ファミリB   列a   列b   列c   列a   列b   行   r1   リージョン1   行   r2   行   (r3,  A:b)   (r3,  A:b)   r3   ver.2   ver.1   行   リージョン2   r4   行   r5  32  
  33. 33. HBaseテーブル   列ファミリA   列ファミリB   列a   列b   列c   列a   列b   行   r1   リージョン1   行   r2   行   (r3,  AA:b)   (r3,   :b)   (r3,  A:b)   r3   ver.3   ver.2   ver.1   行   リージョン2   r4   行   r5  33  
  34. 34. HBaseテーブル   列ファミリA   列ファミリB   列a   列b   列c   列a   列b   行   セルには複数のバージョンを格 r1   納することができる   リージョン1   行   r2   行   (r3,  AA:b)   (r3,   :b)   (r3,  A:b)   r3   ver.3   ver.2   ver.1   行   リージョン2   r4   行   r5  34  
  35. 35. リージョンと列ファミリ   •  テーブルは複数のリージョンで構成されている   •  リージョン =  一定範囲の行キーの集合   •  リージョンは行キーのスタートキーとエンドキーで区分け される   •  それぞれのリージョンは別々のリージョンサーバに割り当 てられている   •  列(カラム)は、列ファミリと列が存在する   •  列ファミリごとに別々の物理ファイルが作成される   •  「列ファミリ:列」の記述を列修飾子というが、これで単に列 ということも多い  35
  36. 36. リージョンと列ファミリ   列ファミリA   列ファミリB   列a   列b   列c   列a   列b   行   r1   リージョン1   行   r2   行   (r3,  A:b)   r3   ver.1   行   リージョン2   r4   行   r5  36  
  37. 37. リージョンと列ファミリ   列ファミリA   列ファミリB   列a   列b   テーブルは複数のリージョンで   列c   列a   列b   行   構成されている   r1   リージョン1   行   r2   行   (r3,  A:b)   r3   ver.1   行   リージョン2   r4   行   r5  37  
  38. 38. リージョンと列ファミリ   列ファミリA   列ファミリB   列a   列b   列c   列a   列b   行   r1   リージョン1   行   r2   行   (r3,  A:b)   r3   ver.1   行   列ファミリごとに別々の物理ファ リージョン2   r4   イルに格納される   行   r5  38  
  39. 39. リージョンと列ファミリ   列ファミリA   列ファミリB   列a   列b   列c   列a   列b   行   r1   リージョン1   行   リージョン1   r2   [r1,  r4)   行   (r3,  A:b)   r3   ver.1   行   リージョン2   r4   リージョン2   行   [r4,  r6)   r5  39  
  40. 40. リージョンと列ファミリ   リージョンはスタートキーとエンド 列ファミリA   列ファミリB   列a   列b   列c   キーで範囲を決定する   列a   列b   エンドキーは含まないので注意   行   r1   リージョン1   行   リージョン1   r2   [r1,  r4)   行   (r3,  A:b)   r3   ver.1   行   リージョン2   r4   リージョン2   行   [r4,  r6)   r5  40  
  41. 41. リージョンと列ファミリ   リージョンサーバA   リージョンサーバB   リージョン1   リージョン2   リージョン1   [r1,  r4)   リージョン2   [r4,  r6)  41  
  42. 42. リージョンと列ファミリ   リージョンサーバA   リージョンサーバB   リージョン1   リージョン2   リージョン1   [r1,  r4)   リージョン2   リージョンはスレーブノード(リージョ [r4,  r6)   ンサーバ)に別々に配置される  42  
  43. 43. リージョンと列ファミリ   リージョンサーバA   リージョンサーバB   リージョン1   リージョン2   リージョン1   MemStore1   MemStore2   MemStore3   MemStore4   [r1,  r4)   リージョン2   [r4,  r6)  43  
  44. 44. リージョンと列ファミリ   リージョンサーバA   リージョンサーバB   列ファミリごとにメモリストア(MemStore)   リージョン1   が作られる   リージョン2   リージョン1   MemStore1   MemStore2   MemStore3   MemStore4   [r1,  r4)   書き込みを行う場合、先行書き込みログ(WAL)に書き込ん だあとはこのMemStoreに書き込まれる   リージョン2   [r4,  r6)   MemStoreはメモリ上にしか存在しない   メモリストアはリージョン☓列ファミリごとに存在する  44  
  45. 45. リージョンと列ファミリ   リージョンサーバA   リージョンサーバB   リージョン1   リージョン2   リージョン1   MemStore1   MemStore2   MemStore3   MemStore4   [r1,  r4)   HDFS   HFile  1   HFile  1 HFile  1     HFile  1   HFile  2 HFile  1     リージョン2   [r4,  r6)   HFile  1   HFile  3 HFile  1   HFile  4 HFile  1     HFile  1    45  
  46. 46. リージョンと列ファミリ   MemStoreに対し複数のHFileが存在する   リージョンサーバA   リージョンサーバB   Memstoreからフラッシュされるたびに作成され、   リージョン1   リージョン2   コンパクションによってまとめられる   リージョン1   MemStore1   MemStore2   MemStore3   MemStore4   [r1,  r4)   HDFS   HFile  1   HFile  1 HFile  1     HFile  1   HFile  2 HFile  1     リージョン2   [r4,  rHFileは  HDFS  上に格納される   1     6)   HFile   3 HFile   HFile  1   HFile  4 データブロックの複製や配置は   HFile  1   HFile  1     全てHDFS側で管理   (図ではHDFSのレプリカは省略)  46  
  47. 47. 論理テーブルから物理ファイルへ   列ファミリA   列ファミリB   列a   列b   列c   列a   列b   行   r1   リージョン1   行   リージョン1   r2   [r1,  r4)   行   (r3,  A:b)   r3   ver.1   行   リージョン2   r4   リージョン2   行   [r4,  r6)   r5  47  
  48. 48. 論理テーブルから物理ファイルへ   列ファミリA   列ファミリB   列a   列b   列c   列a   列b   行   r1   リージョン1   行   r2   MemStore  1   MemStore  2   行   (r3,  A:b)   r3   ver.1   行   リージョン2   r4   行   MemStore  3   MemStore  4   r5  48  
  49. 49. 論理テーブルから物理ファイルへ   列ファミリA   列ファミリB   列a   列b   列c   列a   列b   行   r1   リージョン1   行   r2   HFile  1-­‐3   HFile  2-­‐2   行   (r3,  A:b)   r3   ver.1   行   HFile  4-­‐5   リージョン2   r4   行   HFile  3-­‐1   r5  49  
  50. 50. HBase  テーブルと物理レイアウト   •  テーブルでは、辞書順に行をソートしている   •  全ての値は行キー、列ファミリ、列修飾子、タイムス タンプと一緒に保存される   •  テーブルのスキーマは列ファミリのみ定義している   •  それぞれの列ファミリは任意の数の列を格納可能   •  列ファミリと異なり、スキーマ定義は不要   •  それぞれのセル(行と列の交点)は任意の数のバージョン を格納可能   •  セルは挿入されたときにしか作成されないのでNULLはコ ストゼロ   •  テーブル名以外はすべて  byte[]  として格納される  50
  51. 51. HBase  テーブルと物理レイアウト   以下のようなテーブルを例に考える   cf1:c1   cf1:c2   cf2:c1   cf1:c2   ‘python’   ‘php’   ‘ruby’   r1   ts  =  100   ts  =  100   ts  =  100   r2   ‘scala’   ‘java’   ts  =  100   ‘scala’   ts  =  100   ‘java’   ts  =  90  51
  52. 52. HBase  テーブルと物理レイアウト   ストアファイルにはこのように保存されている   ストアファイル  cf1   ストアファイル  cf2   r1:cf1:c1:100:‘python’   r1:cf2:c1:100:‘ruby’   r1:cf1:c2:100:‘php’   r2:cf1:c1:100:‘scala’   r2:cf1:c1:90:‘java’  52
  53. 53. HBase  テーブルと物理レイアウト   ストアファイル  cf1   ストアファイル  cf2   r1:cf1:c1:100:‘python’   r1:cf2:c1:100:‘ruby’   r1:cf1:c2:100:‘php’   r2:cf1:c1:100:‘scala’   r2:cf1:c1:90:‘java’   ストアファイルはリージョン☓列ファミリで作る   列ファミリはスキーマ定義時に一緒に定義する  53
  54. 54. HBase  テーブルと物理レイアウト   行キー:列ファミリ:列:タイムスタンプ:値   これらが全て1つのデータで格納されている   ストアファイル  cf1   ストアファイル  cf2   r1:cf1:c1:100:‘python’   r1:cf2:c1:100:‘ruby’   r1:cf1:c2:100:‘php’   r2:cf1:c1:100:‘scala’   値   r2:cf1:c1:90:‘java’   タイムスタンプ   列   行キー   列ファミリ  54
  55. 55. スキーマ設計のポイント  55
  56. 56. スキーマ設計   •  最高のパフォーマンスを得るのに正しいスキーマ設 計は不可欠   •  HBaseでの正しいスキーマ設計にはストレージアー キテクチャの知識が不可欠   •  これまでのアーキテクチャの説明を踏まえて、ス キーマ設計のポイントを説明します  56
  57. 57. スキーマ設計の前に(再)   •  論理設計までは同じです   •  設計する前に、「どういう問い合わせをしたいか」を きちんと考えましょう   •  ユーザ同士のソーシャルグラフを見たい   •  ユーザ単位のメッセージを一括取得したい   •  etc.  57
  58. 58. DDI(でぃーでぃーあい)   •  Denormalizajon(非正規化)   •  複数のエンティティのリレーションを一つのテーブルで表現する   •  一回の読み込みでそのリレーションに関するデータ取得が可能   •  Duplicajon(複製)   •  Intelligent  Keys(インテリジェントキー)   •  属性の組み合わせを行キーとすることで検索を容易にする   •  RDBにおける複合キーのようなもの   •  の略   •  詳細は 「Cloud  Data  Structure  Diagramming  Techniques  and   Design  Pa=erns」を参照   •  h=ps://www.data-­‐tacjcs-­‐corp.com/index.php/component/ jdownloads/finish/22-­‐white-­‐papers/68-­‐cloud-­‐data-­‐structure-­‐ diagramming  58
  59. 59. 非正規化   •  HBaseにはJOINがない   •  JOINなしでエンティティ間のリレーションを表現する 方法は2つ   •  自力でJOINを実装する   •  極めて困難。ていうか無理   •  データを非正規化する   •  非正規化  =  2つの論理エンティティで1つの物理表現 を共有すること  59
  60. 60. 非正規化の例   Order   Item   id   id   amount   name   customer_id   price   item_id   Customer   普通のリレーショナルモデルの設計   id   これを……   name  60  
  61. 61. 全部くっつける!   Order   Item   id   id   amount   Order   name   customer_id   price   item_id   order_id   order_amount   customer_id   Customer   customer_name   id   item_id   name   item_name   item_price  61  
  62. 62. 非正規化のメリットとデメリット   •  メリット   •  あらかじめ非正規化しておいたリレーションに関するクエ リは、たとえ大量のデータであっても超高速に結果が返っ てくる   •  デメリット   •  更新が大変   •  非正規化していないエンティティ同士のリレーションに関 するクエリは、JOINがないので結局できない   •  ユースケースの絞り込みが重要  62
  63. 63. パフォーマンスとカーディナリティ   行単位でのスキップが可能   タイム   行キー   列ファミリ   列   値   スタンプ   ストアファイル単位でのスキップが可能   パフォーマンスが高い   カーディナリティが高い  63
  64. 64. パフォーマンスとカーディナリティ   •  行キーを使うときが一番パフォーマンスが高い   •  列ファミリの選択はスキャン対象のデータの数を減 らす   •  値だけのフィルタはフルスキャンと同じ   •  要するに重い(ネットワーク負荷は減るかもしれないが)  64
  65. 65. 値のシフト   r1:cf1:c1:100:‘python’¥x00   r1:cf1:c1‘python’:100:¥x00   r1‘python’:cf1:c1:100:¥x00   •  一つのキーと値は、列ファミリー・列の名前も込みで格 納されている   •  だから値を列や行キーにシフトしてもデータサイズは変 わらない   •  値を空にして、意味のある情報を列や行キーに含めると いう手法もある  65
  66. 66. Tall  vs.  Wide   Tall   Wide  66
  67. 67. Tall  vs.  Wide   •  Tall:  行が多く、列が少ない   •  Wide:  行が少なく、列が多い   •  Tall  の特長   •  Scan  に向いている   •  Wide  の特長   •  Get  (特定の行のみ取得)に向いている   •  HBaseは行単位ならアトミックに処理可能なので、アトミッ クな処理をしたい場合に有効  67
  68. 68. キー設計   シーケンシャルキー   Saltedキー   フィールド昇格キー   ランダムキー   シーケンシャルリードのパフォーマンスが高い   書き込みパフォーマンスが高い  68
  69. 69. キー設計   •  アクセスパターンに基づき、シーケンシャルキーかラ ンダムキーのいずれかを選択   •  両方使う場合もある   •  アーキテクチャの限界を乗り越える   •  どちらも使いどころを間違えなければ有用   •  シーケンシャルキーにはバルクインポートを使う   •  ランダムアクセスをしたい場合にはランダムキーを使う  69
  70. 70. 具体的なキー設計の手法   •  リバースドメイン   •  com.cloudera.www,  com.cloudera.blog,  etc.   •  サイトごとの行キーが近くなる、つまりレンジスキャンがしやすくなる   •  ハッシュ付与   •  データをばらつかせるのに有効   •  例:  MD5(逆ドメイン)  +  逆ドメイン   •  ソルト   •  単にハッシュをとるのではなく、リージョンサーバの数で割ってmodを とる   •  リージョンサーバ単位で正確に均等にしたい場合に便利   •  リバースタイムスタンプ   •  LONG_MAX  -­‐  タイムスタンプ   •  降順にすることで、一番最近のデータが一番上に来るようにする  70
  71. 71. 具体的なキー設計の手法   元データ   リバースドメイン   ハッシュ付与   ソルト   (ドメイン名)   www.cloudera.com   com.cloudera.www   276e_com.cloudera.ww 4_com.cloudera.www   w   blog.cloudera.com   com.cloudera.blog   c75d_com.cloudera.blog   1_com.cloudera.blog   元データ   リバースタイムスタン (タイムスタンプ)   プ   1358736114   2936231182   1358736150   2936231146  71
  72. 72. 具体的なキー設計の手法   元データ   リバースドメイン   ハッシュ付与   ソルト   (ドメイン名)   www.cloudera.com   com.cloudera.www   276e_com.cloudera.ww 4_com.cloudera.www   w   blog.cloudera.com   com.cloudera.blog   c75d_com.cloudera.blog   1_com.cloudera.blog   元データ   リバースタイムスタン (タイムスタンプ)   プ   1358736114   2936231182   1358736150   ハッシュを付与することで配置を分散させる   2936231146   ソルトを使うことでリージョンサーバ間でより均等になる ように分散させることも可能  72
  73. 73. 具体的なキー設計の手法   元データ   これは未ソートの状態   リバースドメイン   ハッシュ付与   ソルト   (ドメイン名)   www.cloudera.com   実際にはソートされ、元データと逆になる   com.cloudera.www   276e_com.cloudera.ww 4_com.cloudera.www   (新しいタイムスタンプが一番上に来る)   w   blog.cloudera.com   com.cloudera.blog   c75d_com.cloudera.blog   1_com.cloudera.blog   元データ   リバースタイムスタン (タイムスタンプ)   プ   1358736114   2936231182   1358736150   2936231146  73
  74. 74. キー設計の例:  カウンタ   •  ドメイン毎、URL毎のカウンタを保存する   •  HBase  のインクリメント(アトミックな  read-­‐modify-­‐write  )機 能を使う   •  それぞれの行は一つのドメインあるいはURL   •  列は特定のメトリクスのカウンタ   •  列ファミリは時間範囲のグループカウンタとして使う   •  列ファミリレベルでTTL(生存期間)を設定して、一定期間経過後に メトリクスが削除されるようにしてストレージ領域を節約   •  例:  “Daily  Counters”  (日次カウンタ)  列ファミリには2週間のTTLを 設定  74
  75. 75. キー設計の例:  カウンタ   •  ドメインの行キー  =  MD5(リバースドメイン)  +  リバー スドメイン   •  行キーを分散させ、バラバラのリージョンに配置されるよ うにする   •  ロードバランシングの方法として有効   •  URLの行キー  =  MD5(リバースドメイン)  +  リバースド メイン  +  URL  ID   •  行キーのサイズ節約のため、URL  ID  を作っておいてそれ を使った方がいい  75
  76. 76. 列修飾子設計  (1)  列ファミリ   •  データは複数のストレージファイルに保存されることを考 慮する   •  列ファミリは少なめにする   •  HFileの数  =  リージョン  *  列ファミリ  *  (3〜6ぐらい)   •  HBase  は全ての HFile  をオープンする   •  つまり列ファミリが多いと必要なファイルディスクリプタの数が 増大する   •  多くても3つぐらい。1つだけで運用する場合もあり   •  アクセスパターンが全く異なるデータがあるときに使うの が◯   •  例1:  メタデータ  +  実データ   •  例2:  日次データ  +  週次データ  +  月次データ  76
  77. 77. 列修飾子設計 (2)  名前   •  列ファミリ・列の名前は短い方がいい   •  列修飾子全体が1行ごとに保存されるため、ここが長いと データ量が大幅に増加する  77
  78. 78. 列修飾子設計の例:  カウンタ   •  列ファミリ   •  1時間毎のカウンタ     •  日次カウンタ   •  総計カウンタ   •  列名は分かりやすく日本語にしているのでそのまま使わないよう に   時間毎   日次   総計   実際にはこんな感じでいい   h  (hourlyの略)   d  (dailyの略)   t  (totalの略)  78
  79. 79. 列修飾子設計の例:  カウンタ   •  単位時間のメトリックのカウンタを配置   •  <時間><メトリック>   時間毎   18時合計   18時東京   18時大阪   19時合計   19時東京   ……   日次   1/1合計   1/1東京   1/1大阪   1/2合計   1/2東京   ……  79
  80. 80. ホットスポット   •  HBaseは1リージョンは1リージョンサーバが担当する   •  だから特定のリージョンだけにアクセスが集中する ということがありうる(ホットスポット)   •  シーケンシャルキーだとホットスポットができるかも しれない   •  午前中のキーノートでもNHN  Japanの中村さんが LINEでホットスポットが発生していたという事例を紹 介していた   •  h=p://www.slideshare.net/naverjapan/storage-­‐ infrastructure-­‐using-­‐hbase-­‐behind-­‐line-­‐messages    80
  81. 81. ホットスポットの例:タイムスタンプを使う   •  <タイムスタンプ><他のキー>:  {  列ファミリ:  {  列修飾 子:  {  タイムスタンプ  :  値  }}}   •  これはダメな例   •  ホットスポットが発生する   cf1   行キーの頭がほとんど同じ   cf1:c1   cf1:c2   これだと、ある時間帯に1つのRSだけが   1358682406_metricA   処理をすることになる   1358682406_metricB   1358682407_metricA   1358682410_metricA  81
  82. 82. ホットスポットの例:タイムスタンプを使う   解決策1:  タイムスタンプをソルトする   (事前にリージョンを分割して別々のRSに割り当てておく)   cf1   cf1:c1   cf1:c2   0_1358682406_metricA   1_1358682200_metricA   4_1358672200_metricB   9_1358662211_metricA  82
  83. 83. ホットスポットの例:タイムスタンプを使う   解決策2:  <他のキー>を前に持ってくる   cf1   cf1:c1   cf1:c2   metricA_1358682406   metricA_1358682407   metricA_1358682410   metricB_1358682406  83
  84. 84. 例:  OpenTSDB   •  OpenTSDB  は、メトリクスを保存するための時系列データ ベース   •  h=p://opentsdb.net/   •  スキーマは以下のようになっている   •  メトリックの種類とタグは行キーに保存されている   •  新しいタイムスタンプによる行キーは定期的に作成   •  ホットスポットの解決策2の典型例   メトリクス(列ファミリ)   <時間差分><フラグ>   <時間差分><フラグ>   <メトリック><タイムスタンプ><タグ>   値   値  84
  85. 85. 例:  OpenTSDB   時間の差分を列にとる   例)  1358600000  +  1  =  1358600001   +1   +2   +4   metricA_1358600000   10   12   15   metricA_1358600600   11   17   metricB_1358600000   100   105   一定時間ごとに新しい行を作成   詳細は h=p://opentsdb.net/misc/opentsdb-­‐hbasecon.pdf    85
  86. 86. まとめ  86
  87. 87. まとめ   •  HBaseにおける正しいスキーマ設計には、ユース ケースやアクセスパターンと、HBaseの内部構造を 知ることが不可欠です   •  非正規化・インテリジェントキーなど、RDBと異なるテ クニックを駆使することで、性能をスケールさせるこ とができます   •  正しくスキーマを設計して、快適なHBaseライフを満 喫しましょう!  87
  88. 88. HBase  本日本語訳出ました   •  Cloudera  の  Lars  George  が 書いた HBase  のバイブル   •  訳は安心の玉川さん   •  レビュー手伝ってました  
  89. 89. Cloudera  の HBase  トレーニング   HBase  トレーニングではスキーマ設計もあります   今日の話だけでは物足りないという方は今すぐ登録 を!   次回は3/25  -­‐  26  開催です     申し込みはこちら   h=p://www.cloudera.co.jp/university/hbase.html      
  90. 90. CDHコミュニティ・MLの紹介   CDH  ユーザ メーリングリスト(日本語)   cdh-­‐user-­‐jp@cloudera.org   CDH  の質問についてはこちら     Cloudera  ニュースレター   h=p://www.cloudera.co.jp/newsle=er   Cloudera  に関するニュースをお届けします   CDHの最新情報・使い方なども紹介します      90
  91. 91. 宣伝   Cloudera  Managerを使えば1時間でCDHクラスタの構 築ができ、管理も非常に簡単です   HBaseを使うなら   Cloudera  Enterprise   (CDH  +  Cloudera  Manager)   を選びましょう   ダウンロードはこちら   h=p://www.cloudera.com/downloads/  91
  92. 92. 92

×