メモや理解が理解がおいつかなかったところは追々公開されるはずのスライドでカバーしたいと思っています。
事前には裏のセッションに出ようとしていたのですが、 A会場に居座っていてよかったと思ったセッションでした。
15:40 (7F 国際会議場) スケーラブルなシステムのためのHBaseスキーマ設計 嶋内 翔（Cloudera）
Apache HBaseは、Apache Hadoop上で動作するスケーラブルな分散ストレージシステムです。HBaseを使うことで、RDBMSのようなスキーマを持つことができ、Hadoop単体では実現できないランダムアクセスや低レイテンシのデータアクセスを実現することができます。しかし、HBaseのパフォーマンスを最大限に発揮するには、正しいスキーマ設計が不可欠です。
本セッションでは、HBaseのストレージアーキテクチャを説明した上で、HBaseの性能を引き出すためのスキーマを設計する方法を紹介します。
➤ 自己紹介
- @shiumachi
- セッションの説明
- HDFSの信頼性の話はしない
- Hadoop、HBaseの運用
→CDH、 Cloudera Manager 使ってください
➤ Apache HBase とは？
- HDFS 上で動作する NoSQL
- Google BigTable
＊
- 何がいいのか？
- 一番いいのは Sharding を自動的にやってくれること
- 書き込みがスケーラブルなこと
- データの耐障害性
＊
- HBase のデータの構造
- 基本的には KVS
- それがソートされてならんでいる
＊
- 物理ファイルとの関連づけ✔
＊
- HBase の構成図✔
- Client はHMasterとほとんど通信しない
➤ スキーマ設計のまえに
- 先に考えないといけないことを説明
- HBaseの究極のベストプラクティス
→使わないこと - よっぽど必要がなければ使わないでください
- ない機能がいっぱいある✔
- どんなときに使ったらいいのか？
→大量のデータがあるとき✔ - Hadoop をすでにつかっているのであれば、利用の検討はできるかも。
- RDBMS でハンドルできることは今は広い
＊
- RDBMS との比較
- RDBはきちんと設計すればどんなクエリも対応可能
- ただしスケールはしない
→HBaseは真逆
＊
- RDBとHBaseにおけるスキーマ設計の違い
- 論理設計は一緒！✔
↓ - HBase との違いは物理設計が大きくちがう
- 設計段階で物理表現を知ることはとても重要✔
➤ HBase アーキテクチャ
- HBase のテーブル
- 行と列によるテーブル構造
- 行は一定範囲ごとにリージョン
＊
- RDBと違うのは同じセルに対して複数のバージョンを格納できること（実際はタイムスタンプだが）
＊
- リージョンと列ファミリ✔
- 列と列ファミリ
- 列ファミリごとに別々の物理ファイルに格納される
- テーブルは複数のリージョンで構成されている
＊
- 物理レイアとどのようにマッピングされるのか
- 列ファミリごとに Memstore （書き込みを行う時は先に WAL ）
- さらに HDFS のレイアではどうなっているか
- MemStore にたいして複数の HFile、 Hfile はHDFS 上に格納される
＊
- 論理テーブルから物理ファイルへの対応がスキーマ設計にも重要になって行く
＊
- HBase テーブルと物理レイアウト
- テーブルは辞書順にソートしている
- 列は固定ではない、いくらでも追加できる
- ひとつのセルの中に複数のデータが格納される可能性がある
- セルは挿入された時にしか作成されないのでNULLはコストゼロ
ー
- ストアファイル
ー
- 行キー、列ファミリ、列、タイムスタンプ、値
→ここもポイント
➤ では、スキーマ設計
- 最高のパフォーマンスを得るのには正しいスキーマ設計が必要
＊
- 論理設計までは同じ、がんばってやって。
＊
- DDI
- Denormalization, Duplication, Inteligent Keys
- ✔ Cloud data structure diagramming techniques and design pattern
＊
- 非正規化
- HBase にはジョインがない
- 自力でJOINをする→ほとんど無理
- もしくは、
- データを非正規化する
→RDBのエキスパートからしてみたら、発狂する（まさにそう思う）
ー
- メリットとデメリット✔
→ユースケースの絞り込みが重要、どのように使うのかを最初に考えることなしに手をだすなかれ。
＊
- パフォーマンスとカーディナリティ
- 行キーでのスキャンがもっとも効率的
（行基ーとどうしても変換されるのに納得…） - 列ファミリの選択はスキャン対象のデータ数を減らす
- 値だけのフィルタはフルスキャンと同じ
＊
- 値のシフト
- 行キーのなかにデータをさしこむという方法もある
- どこの位置にシフトさせると有効なのかというのがユースケースによって変わる
＊
- Tall vs Wide ✔
- Tall と Wide の特徴
- メリットとデメリット、トレードオフ
＊
- キー設計✔
- シーケンシャルキー、Saltedキー、フィールド昇格キー、ランダムキー
- アクセスパターンに応じて選択する
ー
- 具体的なキー設計の手法
- リバースドメイン
- ハッシュ付与
- ソルト→リージョンサーバー単位で正確に均等したい場合
- リバースタイムスタンプ
↓ - その具体的な図解
＊
- キー設計の例：カウンタ
- ドメインごと
＊
- 列修飾子設計の例：カウンタ
- 列ファミリ、列の名前は短い方がいい
＊
- ホットスポット✔
- シーケンシャルキーだとホットスポットができるかもしれない
- ダメなパターン、頭にタイムスタンプをつけている
→タイムスタンプにソルトをつける、他のキーを前にもってくる
↓ - OpenTSDB が内部的にそういうことをしている
- opentsdb.net
- 一定時間ごとに新しい行、差分を列に追加して行く
➤ まとめ
- HBase の内部構造を知ることが前提
- 馬本の第一章にこの話がよくまとめられているので、読みのがしているなら、再読をおすすめ
- 最後は Cloudera の紹介
- Cloudera Manager を使えば、 HBase の運用も楽になるよ、と
➤ QA
- 列ファミリの数
- 少なめにする
- HFile の数が増えていく
- 多くても3つくらい
- 列ファミリが多いと必要なファイルディスクリプタの数が多くなりすぎる
＊
- ソルトの欠点
- 同じソルトの中でリージョン分割などが起こってしまうと、さらにごちゃごちゃになってしまう
✔ #hcj13w わたしのとった他のメモへのリンク
- #hcj13w Hadoop Conference Japan 2013 Winter 午前中 Keynote のメモ
- #hcj13w A会場 午後 (1) ”Hadoop’s Power to Transform Business Ted Dunning（MapR Technologies）” のメモ
- #hcj13w A会場 午後 (2) ”Introduction to Impala 〜Hadoop用のSQLエンジン〜” のメモ
- #hcj13w A会場 午後 (3) ”Hadoop上の多種多様な処理でPigの活きる道” のメモ
- #hcj13w A会場 午後 (5) ”いかにしてHadoopにデータを集めるか” のメモ
- #hcj13w A会場 午後 (6) ”トラブルシューティングのために欲しかった、Hadoopがまるっと分かる可視化ツール” のメモ
