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

スポンサー 5

会場の様子当日の参加者およそ600人！ 6

会場の様子 Tシャツもらいました 7

イベントの構成講演は4トラック構成 8

General Session 9

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

General Session(Christophe & Charles) Hadoopの典型的な利用領域 検索エンジン クリックストリーム処理 クラスタリング HBaseによりカバーできるようになるアプリケーション領域 メッセージング 位置ベースアプリケーション リアルタイムレコメンデーション 広告最適化 1

General Session(Christophe & Charles)HBaseを用いたアプリケーションに共通するテーマについて言及 1

General Session(Christophe & Charles) HBaseを用いたアプリケーションの3つの共通テーマ 扱うデータがWeb Scale • RDBMSがカバーできない領域のスケール リアルタイム(ニアリアルタイム)が求められる Evolving • データソースとアプリケーションの要求が日々変わりうる 1

General Session(Christophe & Charles) これから重要となるHBaseの開発テーマ 1

General Session(Christophe & Charles) これから重要となるHBaseの開発テーマ  スキーママネジメント/データモデリング  既存アプリケーションやシステムとの統合  各種言語サポート • REST, ORM, JDBC, Java, Python, Ruby, Scala, R • データサイエンティストがよく使うPythonやRubyのサポートを手厚くする 1

Wishlist 1

Wishlist HBase開発者への要望  ユーザビリティとオペラビリティ • ワーニングメッセージやエラーメッセージの改善 • 解析用のメトリクス • 管理ツール  M/Rジョブとの連携の改善 • バッチジョブ/GC/コンパクションの協調  自動チューニング • リージョンサイズ/フラッシュやコンパクションのストラテジ 1

General Session(Facebook) 2

Applications 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

Tumblr 3

Tumblr 4

Facebook 4

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 5

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

Facebook 5

Facebook Appserverのドメインモデル  非正規化されたスキーマ  エンティティ • メッセージ • スレッド • etc  エンティティ間のリレーションシップ • スレッドとメッセージ • メッセージIDとスレッドID • etc 5

Facebook 5

Facebook 6

Operations 6

Case Study of HBase Operations at Facebook 6

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

Case Study of HBase Operations at Facebook発表者: Ryan Thiessen, Technical Lead, Facebook 6

HBase Backup 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

Development 8

HBase Schema Design 8

HBase Schema DesignHBaseのスキーマ設計設計は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

HBase Performance Tuning and Optimizations- Facebookでの性能チューニングベストプラクティス - 行キー設計と事前スプリット - ブロックサイズ - コンパクション設定- HBase自体の性能改良について紹介 - HFile v2 - データブロックエンコーディング(HBASE-4218) - スキャナ改善 9

HBase Performance Tuning and Optimizations発表者: Mikhail Bautin, Software Engineer, Facebook 9

HBase Performance Tuning and OptimizationsFacebookでの性能チューニングベストプラクティス - テーブルの事前スプリット。 - 行キーの先頭にハッシュキーをつけて書き込みを散らす。 - 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

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

Ligntning Talk 9

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

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

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

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

NextBio患者データの相関を格納 1

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

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

Sushi 1

Chocolate(Any Question?) 1

http://d.hatena.ne.jp	186
https://twitter.com	23
https://si0.twimg.com	16
http://us-w1.rockmelt.com	2
http://webcache.googleusercontent.com	1

HBaseCon 2012 参加レポート

by System Platforms Sector / NTT Data Corp on Jun 25, 2012

Accessibility

Categories

Upload Details

Usage Rights

5 Embeds 228

Statistics

HBaseCon 2012 参加レポート Presentation Transcript