HBaseCon 2012 参加レポート

2012月6月25日
Hadoopソースコードリーディング第10回資料

HBaseCon 2012 参加レポート

岩崎正剛/猿田浩輔
（株式会社NTTデータ）

本資料は 2012年5月にサンフランシスコで開催された Cloudera 社主催のイベント
『HBaseCon 2012』の参加レポートです。各セッションの内容に基づき、作成したものです。
各セッションの概要および資料は http://www.hbasecon.com/agenda/ から確認できます。

お品書き

 イベントの様子
 General Session
 Applications
 Operations
 Development
 Lightning Talk

2

イベントの様子

3

イベント概要

主催
 Cloudera, Inc
開催日時
 2012/05/22
開催場所
 InterContinental San Francisco Hotel
(カリフォルニア州サンフランシスコ)
概要
 コミュニティの活性化などを目的とし、HBaseの利用事例紹介や運用ノウハウ/
技術トピックなど、知見の発表/情報共有が行われるイベント

4

会場の様子

当日の参加者およそ600人！

6

会場の様子

Tシャツもらいました

7

イベントの構成

講演は4トラック構成

8

General Session(Stack & Mike)

HBaseのコミッタでStumbleUponのStackとCloudera CEOのMike

HBaseの開発に積極的に参加してほしいと要請

1

General Session(Stack & Mike)

 特に貢献が求めらるもの
 レプリケーション
 セキュリティ
 セカンダリインデックス
 スナップショット
 バックアップ

その他、分散システムの専門家の知見が必要な領域多数

1

General Session(Christophe & Charles)

WibiData CEOのChristopheとCloudera VPのCharles

Hadoopの典型的な利用領域と
Hbaseでカバーできるようになる領域について言及
1


 Hadoopの典型的な利用領域
検索エンジン
クリックストリーム処理
クラスタリング

 HBaseによりカバーできるようになるアプリケーション領
域
メッセージング
位置ベースアプリケーション
リアルタイムレコメンデーション
広告最適化

1


HBaseを用いたアプリケーションに共通するテーマについて言及
1


 HBaseを用いたアプリケーションの3つの共通テーマ
扱うデータがWeb Scale
• RDBMSがカバーできない領域のスケール

リアルタイム(ニアリアルタイム)が求められる

Evolving
• データソースとアプリケーションの要求が日々変わりうる

1


これから重要となるHBaseの開発テーマ
1


 これから重要となるHBaseの開発テーマ

 スキーママネジメント/データモデリング

 既存アプリケーションやシステムとの統合

 各種言語サポート
• REST, ORM, JDBC, Java, Python, Ruby, Scala, R
• データサイエンティストがよく使うPythonやRubyのサポートを手厚くす
る

1

Wishlist

 HBase開発者への要望
 ユーザビリティとオペラビリティ
• ワーニングメッセージやエラーメッセージの改善
• 解析用のメトリクス
• 管理ツール

 M/Rジョブとの連携の改善
• バッチジョブ/GC/コンパクションの協調

 自動チューニング
• リージョンサイズ/フラッシュやコンパクションのストラテジ

1

General Session(Facebook)

2

GAP

HBaseを用いてWeb上のカタログデータを統合

 全てのブランド/マーケットを一元管理し、ブランドをまたがっ
た分析などを可能にした
 在庫管理のためデータストアをニアリアルタイムに更新

2

GAP

実現したいこと
 業務用件
• 全てのブランド/マーケットを一元管理したい
• ブランドをまたがった分析ができる

 システムの用件
• カタログのデータ量が増えても、スケール可能なアーキテクチャ
• データストアに直接アクセスできる
– ニアリアルタイムな在庫管理のため
• キャッシュは最適化のためなどのためだけに最小限利用する
– データの反映が遅延することを避ける
• 高い可用性を持つ

2

GAP

いくつかのソリューションを検討
 シェアード型RDBMS、MemCachedなど
• 目的を達成するためには多大な努力が必要(チューニングコストな
どが大きい)
• スケーラビリティの限界という課題が残る
 非RDBの利用

結果的にHBaseを導入
 一貫性を重視した設計である
 サーバサイドでフィルタ処理が実装可能である
 自動でシャーディング/データの分散配置/フェイルオー
バーを行う
 Hadoopとの親和性が高い
2

GAP

クラスタのトラフィックパターン
 ほとんどが読み込みリクエスト
 書き込みや削除は突発的に起こる
• カタログの掲載
• M/Rジョブの出力
 書き込みは継続的に実行される
• 在庫のアップデート

2

GAP

扱うデータモデル
 カタログデータをグラフ構造で保持
• SKU -> スタイルなど階層構造でデータを表現
• クロスブランド販売を可能にする(ブランド間を関係づける)

アクセスパターン
 いちどにすべての商品のグラフ構造を読み込む(全商品の
検索)
 商品グラフの中の特定のノードへのシングルパスをたどる
(特定商品検索)
 セカンダリインデックスを用いた商品の検索
 etc

3

GAP

階層構造にセカンダリインデックスを組み込んだ

3

GAP

クラスタ構成
 16 Slave (RS + TT + DN) Nodes
• 8 & 16 GB RAM

 3 Master (HM,ZK,JT, NN) Nodes
• 8 GB RAM

 NN Failover via NFS

3

GAP

 チューニング関連ノウハウ
 Block Cache
• Maximize Block Cache
• hfile.block.cache.size: 0.6
 Garbage Collection
• MSLAB enabled
• CMSInitiatingOccupancyFactor
 Quick Recovery on node failure
• Default timeouts too large
• zookeeper.session.timeout
 Region Server
• hbase.rpc.timeout
 Data Node
• dfs.heartbeat.recheck.interval
• heartbeat.recheck.interval
3

Tumblr

Motherboy(Dashboardなどバックエンドストレー
ジシステム)の構築から得られた知見

3

Facebook

 HBase最大のアプリケーションとして有名なメッセージング基盤
 書き込みサイズの縮小、ホットスポットの排除が最重要

 2PBのオンラインデータ
 ひと月あたり250TBのペースで増加
 150億メッセージ x 1024 bytes = 14TB
 1200億のチャットデータ x 100 bytes = 11TB

 750億ops/day
 ピーク時の負荷は150万ops/s
 readが55%、writesが45%
 1行の書き込みが平均16KeyValueで複数のCFにまたがる

 1クラスタ25～200ノードからなる
 48GBのメモリ
 12～36TBのSATAディスク
 RegionServerはDataNodeと同一ノード上に同居

4

Facebook

なぜHBaseか？
 低レイテンシ
 水平方向にスケールする
 自動的にフェイルオーバーする
 自動シャーディング
 強い一貫性
 圧縮して格納
 Read - Modify - Writeをサポートしている(例えばカウン
タ)
 MapReduceとの統合

5

Facebook

 Appserverのドメインモデル
 非正規化されたスキーマ

 エンティティ
• メッセージ
• スレッド
• etc

 エンティティ間のリレーションシップ
• スレッドとメッセージ
• メッセージIDとスレッドID
• etc

5

Case Study of HBase Operations at Facebook

6


- HBaseの運用苦労話。
HBaseがいかにCoolかという話は別セッションでやるのでここではCoolでない話を。
- 障害パターンごとに対応や「こうなっているべき」を紹介。
- NameNode障害
- ラックスイッチ/クラスタスイッチ障害
- メンテナンス
- テーブル分割と負荷の偏り
- コンパクション
- バグによるサーバ停止
- プロセスが停止しないプロセス障害
- 原因別の停止時間比較。
定期/不定期メンテナンスが最も多い。スイッチの故障が続く。
NameNode障害は相対的に少ない。
- リージョンの移動が、データのローカリティが低下として、NW転送量にあらわれる。
帯域に余裕がほしい。
- 「落ちるときは落ちる」。
それを前提としてアプリや運用を作れ。しぶといシステムを組め。というまとめ。
6


発表者: Ryan Thiessen, Technical Lead, Facebook

6


7

HBase Backup

- 現状利用できるバックアップ手段の比較

- DistCP
- exportツール
- copytableツール
- レプリケーション
- アプリケーションから複数クラスタへの書き込み

- Facebookにおけるユースケース

- MapReduceによるバックアップジョブ
- バックアップレベル
- 所要時間

- Hbaseコミュニティでのバックアップ向け機能の開発状況

7

HBase Backup

発表者:
Sunil Sitaula, Solutions Architect, Cloudera Inc.
Madhuwanti Vaidya, Software Engineer, Facebook Inc.

7

HBase Backup -現状のバックアップ選択肢

DistCP
- /hbaseディレクトリ下をまるまるコピー。
- 速くて簡単だが一貫性は保証されない。Memstoreのデータも考慮されない。
exportツール
- データをExportするMRジョブ起動。
- テーブル名、バージョン数、TimeRange指定でexport対象を指定可能。
- 1度に1つのテーブルしか処理できない。
copytableツール
- exportツールとは違い、データを別クラスタに保存。
- 長所短所はexportツールと同様。
レプリケーション
- Regionサーバ間のWALEditsの転送によるレプリケーション。
- 一時的にスレーブ側クラスタをオフラインにすることもできる。
- バグやオペミスによるデータ消去はレプリカ側にも波及する。
アプリケーションから複数クラスタへの書き込み。
- DRに対応できるが、整合性や原子性をAPが配慮しなければならない。

7

HBase Backup - Facebookでのユースケース

- HBASE-5509を利用したMRジョブによるバックアップ。
- 1マッパーが1リージョンを担当。
- regionをflushしてからHFileをコピー。
- データのローカリティが高いようにmapperを配置する。
- Trashを見に行く必要があるので、保持期間に注意。
- リストアは、ファイルを配置して、.META.に情報追加。
- バックアップには3つのレベルがある。
1. 同一クラスタ内。(1回/1日)
2. 同一DC内。(1回/10日)
3. DC間。(1回/10日)
- 各データブロックを各ノードローカルにコピーする「高速コピー」機能を実装。
- 40TBのテーブルを49mapperでバックアップする際の所要時間。
- 通常: 15時間
- 高速コピー: 1.5時間
- 将来的な課題として、HLogのバックアップとPIRT。
- HDFSのハードリンク(HDFS-3370)が前提。

7

HBase Backup - 絶賛開発中の機能

- HBASE-6055: スナップショット

- HBASE-4618: HFileとHLogにもとづくバックアップ

7

HBase Backup - 高速コピー

8

ランチボックス

8

HBase Schema Design

8

HBase Schema Design

HBaseのスキーマ設計設計はRDBMSの場合の非正規化に相当する。
「入れ子になったエンティティ」というRDBMSにはない概念がキーポイント。

- HBaseのデータ構造の復習

- HBaseには外部キー、ジョイン、テーブルをまたがるトランザクションは無い。
テーブル間の関係をどう表現するかについて、
自力でジョインを実装するか非正規化するかの2択だが、非正規化がおすすめ。

- 入れ子になったエンティティ
- 固定幅での表現、区切り文字、シリアライズによるバイト列の結合
- 行キーの一部、列名、タイムスタンプを属性の格納に利用。

- 「HBaseスキーマのデザインパターン」紹介。
データへのアクセスパスを考慮して設計すること。
RDBはアクセスパターンをユーザから隠ぺいするが、 HBaseはユーザに考えさせる。

8

HBase Schema Design

発表者:
Ian Varley, Principal Member of Technical Staff, Salesforce.com

8

HBase Performance Tuning and Optimizations

8

HBase Schema Design - デザインパターン

0. 行キーの設計がすべて。
(行キーというかKeyValueのKey全体を含むニュアンス)

1. Design for the questions, not the answers.

2. データサイズは2種類しかない。大きすぎるか、そうでないか。

3. コンパクトに詰め込め。
(OpenTSBDのタイムスタンプを差分で保存する例から。)

4. 行単位の原子性を活用する。

5. 属性は行キー内に移動することができる。
(Lars Georgeがfoldingと呼んでいる手法。)

6. エンティティをネストさせると、データを事前に集計できる。
(DWHのpre-aggregation。)
8


- Facebookでの性能チューニングベストプラクティス

- 行キー設計と事前スプリット
- ブロックサイズ
- コンパクション設定

- HBase自体の性能改良について紹介

- HFile v2
- データブロックエンコーディング(HBASE-4218)
- スキャナ改善

9


発表者:
Mikhail Bautin, Software Engineer, Facebook

9


Facebookでの性能チューニングベストプラクティス

- テーブルの事前スプリット。
- 行キーの先頭にハッシュキーをつけて書き込みを散らす。
- 1ブロック内のKVの数が多くなりすぎないようにブロックサイズを調節。
Facebookdでは64KBまたは128KBを利用。

- オフピーク時間を設定する。
- hbase.offpeak.{start,end}.hour
- hbase.hstore.compaction.ratio.offpeak

- コンパクション設定
- hbase.hstore.compactionThreshold = 3
- hbase.hstore.compaction.max = 12 (OOMを防ぐために上限を設定。)
- hbase.hstore.compaction.min.size = 4194304 (4MB以下は常に対象。)
- hbase.store.compaction.ratioを上げ、積極的にコンパクションする。

9


9


スキャナ改善

- HBASE-4433: next呼び出し時の不要なブロック読み込みの防止。
- HBASE-4434: next呼び出しでのプリフェッチをやめる
- HBASE-2794: 同一CF内の複数列のGetでBloomフィルタを利用可能にする
- HBASE-4465: StoreFileのスキャン効率改善
- HBASE-4469: Bloomフィルタ利用時の行シークの効率改善。
- HBASE-4532: 専用Bloomフィルタを利用した行シークの効率改善。
- HBASE-4585: 複数列読み込み時のnextでの不要な読み込みの防止。

9

StumbleUpon

HBaseをCAS(Content Addressable Storage)として利用

9

Photobucket

Solbase: Solr/Luceneを改造してHBaseをバックエンドとして利用

9

Yahoo!

トランザクション機能を拡張

1

NextBio

ゲノム情報を高速に閲覧するための構造でHBaseに格納

1

NextBio

患者データの相関を格納

1

AOL

メールデータのプロファイリング結果を格納

1

OCLC

図書館所蔵の書籍データを格納するシステム

1

Chocolate(Any Question?)

1

HBaseCon 2012 参加レポート

More Related Content

HBaseCon 2012 参加レポート