Más contenido relacionado
La actualidad más candente (20)
Similar a HBaseCon 2012 参加レポート (20)
Más de NTT DATA OSS Professional Services (20)
HBaseCon 2012 参加レポート
- 1. 2012月6月25日
Hadoopソースコードリーディング 第10回 資料
HBaseCon 2012 参加レポート
岩崎正剛/猿田浩輔
(株式会社NTTデータ)
本資料は 2012年5月にサンフランシスコで開催された Cloudera 社主催のイベント
『HBaseCon 2012』 の参加レポートです。各セッションの内容に基づき、作成したものです。
各セッションの概要および資料は http://www.hbasecon.com/agenda/ から確認できます。
- 4. イベント概要
主催
Cloudera, Inc
開催日時
2012/05/22
開催場所
InterContinental San Francisco Hotel
(カリフォルニア州サンフランシスコ)
概要
コミュニティの活性化などを目的とし、HBaseの利用事例紹介や運用ノウハウ/
技術トピックなど、知見の発表/情報共有が行われるイベント
4
- 6. 会場の様子
当日の参加者およそ600人!
6
- 11. General Session(Stack & Mike)
特に貢献が求めらるもの
レプリケーション
セキュリティ
セカンダリインデックス
スナップショット
バックアップ
その他、分散システムの専門家の知見が必要な領域多数
1
- 13. General Session(Christophe & Charles)
Hadoopの典型的な利用領域
検索エンジン
クリックストリーム処理
クラスタリング
HBaseによりカバーできるようになるアプリケーション領
域
メッセージング
位置ベースアプリケーション
リアルタイムレコメンデーション
広告最適化
1
- 15. General Session(Christophe & Charles)
HBaseを用いたアプリケーションの3つの共通テーマ
扱うデータがWeb Scale
• RDBMSがカバーできない領域のスケール
リアルタイム(ニアリアルタイム)が求められる
Evolving
• データソースとアプリケーションの要求が日々変わりうる
1
- 17. General Session(Christophe & Charles)
これから重要となるHBaseの開発テーマ
スキーママネジメント/データモデリング
既存アプリケーションやシステムとの統合
各種言語サポート
• REST, ORM, JDBC, Java, Python, Ruby, Scala, R
• データサイエンティストがよく使うPythonやRubyのサポートを手厚くす
る
1
- 19. Wishlist
HBase開発者への要望
ユーザビリティとオペラビリティ
• ワーニングメッセージやエラーメッセージの改善
• 解析用のメトリクス
• 管理ツール
M/Rジョブとの連携の改善
• バッチジョブ/GC/コンパクションの協調
自動チューニング
• リージョンサイズ/フラッシュやコンパクションのストラテジ
1
- 26. GAP
実現したいこと
業務用件
• 全てのブランド/マーケットを一元管理したい
• ブランドをまたがった分析ができる
システムの用件
• カタログのデータ量が増えても、スケール可能なアーキテクチャ
• データストアに直接アクセスできる
– ニアリアルタイムな在庫管理のため
• キャッシュは最適化のためなどのためだけに最小限利用する
– データの反映が遅延することを避ける
• 高い可用性を持つ
2
- 27. GAP
いくつかのソリューションを検討
シェアード型RDBMS、MemCachedなど
• 目的を達成するためには多大な努力が必要(チューニングコストな
どが大きい)
• スケーラビリティの限界という課題が残る
非RDBの利用
結果的にHBaseを導入
一貫性を重視した設計である
サーバサイドでフィルタ処理が実装可能である
自動でシャーディング/データの分散配置/フェイルオー
バーを行う
Hadoopとの親和性が高い
2
- 29. GAP
クラスタのトラフィックパターン
ほとんどが読み込みリクエスト
書き込みや削除は突発的に起こる
• カタログの掲載
• M/Rジョブの出力
書き込みは継続的に実行される
• 在庫のアップデート
2
- 30. GAP
扱うデータモデル
カタログデータをグラフ構造で保持
• SKU -> スタイルなど階層構造でデータを表現
• クロスブランド販売を可能にする(ブランド間を関係づける)
アクセスパターン
いちどにすべての商品のグラフ構造を読み込む(全商品の
検索)
商品グラフの中の特定のノードへのシングルパスをたどる
(特定商品検索)
セカンダリインデックスを用いた商品の検索
etc
3
- 34. 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
- 35. 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
- 52. Facebook
なぜHBaseか?
低レイテンシ
水平方向にスケールする
自動的にフェイルオーバーする
自動シャーディング
強い一貫性
圧縮して格納
Read - Modify - Writeをサポートしている(例えばカウン
タ)
MapReduceとの統合
5
- 67. Case Study of HBase Operations at Facebook
- HBaseの運用苦労話。
HBaseがいかにCoolかという話は別セッションでやるのでここではCoolでない話を。
- 障害パターンごとに対応や「こうなっているべき」を紹介。
- NameNode障害
- ラックスイッチ/クラスタスイッチ障害
- メンテナンス
- テーブル分割と負荷の偏り
- コンパクション
- バグによるサーバ停止
- プロセスが停止しないプロセス障害
- 原因別の停止時間比較。
定期/不定期メンテナンスが最も多い。スイッチの故障が続く。
NameNode障害は相対的に少ない。
- リージョンの移動が、データのローカリティが低下として、NW転送量にあらわれる。
帯域に余裕がほしい。
- 「落ちるときは落ちる」。
それを前提としてアプリや運用を作れ。しぶといシステムを組め。というまとめ。
6
- 68. Case Study of HBase Operations at Facebook
発表者: Ryan Thiessen, Technical Lead, Facebook
6
- 75. HBase Backup
- 現状利用できるバックアップ手段の比較
- DistCP
- exportツール
- copytableツール
- レプリケーション
- アプリケーションから複数クラスタへの書き込み
- Facebookにおけるユースケース
- MapReduceによるバックアップジョブ
- バックアップレベル
- 所要時間
- Hbaseコミュニティでのバックアップ向け機能の開発状況
7
- 76. HBase Backup
発表者:
Sunil Sitaula, Solutions Architect, Cloudera Inc.
Madhuwanti Vaidya, Software Engineer, Facebook Inc.
7
- 77. HBase Backup -現状のバックアップ選択肢
DistCP
- /hbaseディレクトリ下をまるまるコピー。
- 速くて簡単だが一貫性は保証されない。Memstoreのデータも考慮されない。
exportツール
- データをExportするMRジョブ起動。
- テーブル名、バージョン数、TimeRange指定でexport対象を指定可能。
- 1度に1つのテーブルしか処理できない。
copytableツール
- exportツールとは違い、データを別クラスタに保存。
- 長所短所はexportツールと同様。
レプリケーション
- Regionサーバ間のWALEditsの転送によるレプリケーション。
- 一時的にスレーブ側クラスタをオフラインにすることもできる。
- バグやオペミスによるデータ消去はレプリカ側にも波及する。
アプリケーションから複数クラスタへの書き込み。
- DRに対応できるが、整合性や原子性をAPが配慮しなければならない。
7
- 78. 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
- 79. HBase Backup - 絶賛開発中の機能
- HBASE-6055: スナップショット
- HBASE-4618: HFileとHLogにもとづくバックアップ
7
- 89. 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
- 90. HBase Performance Tuning and Optimizations
- Facebookでの性能チューニングベストプラクティス
- 行キー設計と事前スプリット
- ブロックサイズ
- コンパクション設定
- HBase自体の性能改良について紹介
- HFile v2
- データブロックエンコーディング(HBASE-4218)
- スキャナ改善
9
- 92. HBase Performance Tuning and Optimizations
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
- 95. HBase Performance Tuning and Optimizations
スキャナ改善
- HBASE-4433: next呼び出し時の不要なブロック読み込みの防止。
- HBASE-4434: next呼び出しでのプリフェッチをやめる
- HBASE-2794: 同一CF内の複数列のGetでBloomフィルタを利用可能にする
- HBASE-4465: StoreFileのスキャン効率改善
- HBASE-4469: Bloomフィルタ利用時の行シークの効率改善。
- HBASE-4532: 専用Bloomフィルタを利用した行シークの効率改善。
- HBASE-4585: 複数列読み込み時のnextでの不要な読み込みの防止。
9