HBaseCon 2012 参加レポート

4,881 views

Published on

2012年6月25日のHadoopソースコードリーディング 第10回での『HBaseCon 2012 イベント参加レポート』の発表資料です。NTTデータの猿田と岩崎による発表です。

▼HBaseCon 2012
http://www.hbasecon.com/

▼NTTデータ BizXaaS Hadoop構築・運用ソリューション
http://oss.nttdata.co.jp/hadoop/

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

No Downloads
Views
Total views
4,881
On SlideShare
0
From Embeds
0
Number of Embeds
356
Actions
Shares
0
Downloads
0
Comments
0
Likes
16
Embeds 0
No embeds

No notes for slide

HBaseCon 2012 参加レポート

  1. 1. 2012月6月25日Hadoopソースコードリーディング 第10回 資料 HBaseCon 2012 参加レポート 岩崎正剛/猿田浩輔 (株式会社NTTデータ)本資料は 2012年5月にサンフランシスコで開催された Cloudera 社主催のイベント『HBaseCon 2012』 の参加レポートです。各セッションの内容に基づき、作成したものです。各セッションの概要および資料は http://www.hbasecon.com/agenda/ から確認できます。
  2. 2. お品書き イベントの様子 General Session Applications Operations Development Lightning Talk 2
  3. 3. イベントの様子 3
  4. 4. イベント概要主催  Cloudera, Inc開催日時  2012/05/22開催場所  InterContinental San Francisco Hotel (カリフォルニア州サンフランシスコ)概要  コミュニティの活性化などを目的とし、HBaseの利用事例紹介や運用ノウハウ/ 技術トピックなど、知見の発表/情報共有が行われるイベント 4
  5. 5. スポンサー 5
  6. 6. 会場の様子 当日の参加者およそ600人! 6
  7. 7. 会場の様子 Tシャツもらいました 7
  8. 8. イベントの構成 講演は4トラック構成 8
  9. 9. General Session 9
  10. 10. General Session(Stack & Mike)HBaseのコミッタでStumbleUponのStackとCloudera CEOのMike HBaseの開発に積極的に参加してほしいと要請 1
  11. 11. General Session(Stack & Mike) 特に貢献が求めらるもの  レプリケーション  セキュリティ  セカンダリインデックス  スナップショット  バックアップその他、分散システムの専門家の知見が必要な領域多数 1
  12. 12. General Session(Christophe & Charles) WibiData CEOのChristopheとCloudera VPのCharles Hadoopの典型的な利用領域と Hbaseでカバーできるようになる領域について言及 1
  13. 13. General Session(Christophe & Charles) Hadoopの典型的な利用領域 検索エンジン クリックストリーム処理 クラスタリング HBaseによりカバーできるようになるアプリケーション領 域 メッセージング 位置ベースアプリケーション リアルタイムレコメンデーション 広告最適化 1
  14. 14. General Session(Christophe & Charles)HBaseを用いたアプリケーションに共通するテーマについて言及 1
  15. 15. General Session(Christophe & Charles) HBaseを用いたアプリケーションの3つの共通テーマ 扱うデータがWeb Scale • RDBMSがカバーできない領域のスケール リアルタイム(ニアリアルタイム)が求められる Evolving • データソースとアプリケーションの要求が日々変わりうる 1
  16. 16. General Session(Christophe & Charles) これから重要となるHBaseの開発テーマ 1
  17. 17. General Session(Christophe & Charles) これから重要となるHBaseの開発テーマ  スキーママネジメント/データモデリング  既存アプリケーションやシステムとの統合  各種言語サポート • REST, ORM, JDBC, Java, Python, Ruby, Scala, R • データサイエンティストがよく使うPythonやRubyのサポートを手厚くす る 1
  18. 18. Wishlist 1
  19. 19. Wishlist HBase開発者への要望  ユーザビリティとオペラビリティ • ワーニングメッセージやエラーメッセージの改善 • 解析用のメトリクス • 管理ツール  M/Rジョブとの連携の改善 • バッチジョブ/GC/コンパクションの協調  自動チューニング • リージョンサイズ/フラッシュやコンパクションのストラテジ 1
  20. 20. General Session(Facebook) 2
  21. 21. General Session(Facebook) 2
  22. 22. General Session(Facebook) 2
  23. 23. Applications 2
  24. 24. GAPHBaseを用いてWeb上のカタログデータを統合  全てのブランド/マーケットを一元管理し、ブランドをまたがっ た分析などを可能にした  在庫管理のためデータストアをニアリアルタイムに更新 2
  25. 25. GAP 2
  26. 26. GAP実現したいこと  業務用件 • 全てのブランド/マーケットを一元管理したい • ブランドをまたがった分析ができる  システムの用件 • カタログのデータ量が増えても、スケール可能なアーキテクチャ • データストアに直接アクセスできる – ニアリアルタイムな在庫管理のため • キャッシュは最適化のためなどのためだけに最小限利用する – データの反映が遅延することを避ける • 高い可用性を持つ 2
  27. 27. GAPいくつかのソリューションを検討  シェアード型RDBMS、MemCachedなど • 目的を達成するためには多大な努力が必要(チューニングコストな どが大きい) • スケーラビリティの限界という課題が残る  非RDBの利用結果的にHBaseを導入  一貫性を重視した設計である  サーバサイドでフィルタ処理が実装可能である  自動でシャーディング/データの分散配置/フェイルオー バーを行う  Hadoopとの親和性が高い 2
  28. 28. GAP 2
  29. 29. GAPクラスタのトラフィックパターン  ほとんどが読み込みリクエスト  書き込みや削除は突発的に起こる • カタログの掲載 • M/Rジョブの出力  書き込みは継続的に実行される • 在庫のアップデート 2
  30. 30. GAP扱うデータモデル  カタログデータをグラフ構造で保持 • SKU -> スタイルなど階層構造でデータを表現 • クロスブランド販売を可能にする(ブランド間を関係づける)アクセスパターン  いちどにすべての商品のグラフ構造を読み込む(全商品の 検索)  商品グラフの中の特定のノードへのシングルパスをたどる (特定商品検索)  セカンダリインデックスを用いた商品の検索  etc 3
  31. 31. GAP 3
  32. 32. GAP 3
  33. 33. GAP階層構造にセカンダリインデックスを組み込んだ 3
  34. 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. 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
  36. 36. TumblrMotherboy(Dashboardなどバックエンドストレー ジシステム)の構築から得られた知見 3
  37. 37. Tumblr 3
  38. 38. Tumblr 3
  39. 39. Tumblr 3
  40. 40. Tumblr 4
  41. 41. Tumblr 4
  42. 42. Tumblr 4
  43. 43. Tumblr 4
  44. 44. Tumblr 4
  45. 45. Tumblr 4
  46. 46. Tumblr 4
  47. 47. Facebook 4
  48. 48. Facebook 4
  49. 49. 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
  50. 50. Facebook 5
  51. 51. Facebook 5
  52. 52. FacebookなぜHBaseか?  低レイテンシ  水平方向にスケールする  自動的にフェイルオーバーする  自動シャーディング  強い一貫性  圧縮して格納  Read - Modify - Writeをサポートしている(例えばカウン タ)  MapReduceとの統合 5
  53. 53. Facebook 5
  54. 54. Facebook Appserverのドメインモデル  非正規化されたスキーマ  エンティティ • メッセージ • スレッド • etc  エンティティ間のリレーションシップ • スレッドとメッセージ • メッセージIDとスレッドID • etc 5
  55. 55. Facebook 5
  56. 56. Facebook 5
  57. 57. Facebook 5
  58. 58. Facebook 5
  59. 59. Facebook 5
  60. 60. Facebook 6
  61. 61. Facebook 6
  62. 62. Facebook 6
  63. 63. Facebook 6
  64. 64. Facebook 6
  65. 65. Operations 6
  66. 66. Case Study of HBase Operations at Facebook 6
  67. 67. Case Study of HBase Operations at Facebook- HBaseの運用苦労話。 HBaseがいかにCoolかという話は別セッションでやるのでここではCoolでない話を。- 障害パターンごとに対応や「こうなっているべき」を紹介。 - NameNode障害 - ラックスイッチ/クラスタスイッチ障害 - メンテナンス - テーブル分割と負荷の偏り - コンパクション - バグによるサーバ停止 - プロセスが停止しないプロセス障害- 原因別の停止時間比較。 定期/不定期メンテナンスが最も多い。スイッチの故障が続く。 NameNode障害は相対的に少ない。- リージョンの移動が、データのローカリティが低下として、NW転送量にあらわれる。 帯域に余裕がほしい。- 「落ちるときは落ちる」。 それを前提としてアプリや運用を作れ。しぶといシステムを組め。というまとめ。 6
  68. 68. Case Study of HBase Operations at Facebook発表者: Ryan Thiessen, Technical Lead, Facebook 6
  69. 69. Case Study of HBase Operations at Facebook 6
  70. 70. Case Study of HBase Operations at Facebook 7
  71. 71. Case Study of HBase Operations at Facebook 7
  72. 72. Case Study of HBase Operations at Facebook 7
  73. 73. Case Study of HBase Operations at Facebook 7
  74. 74. HBase Backup 7
  75. 75. HBase Backup- 現状利用できるバックアップ手段の比較 - DistCP - exportツール - copytableツール - レプリケーション - アプリケーションから複数クラスタへの書き込み- Facebookにおけるユースケース- MapReduceによるバックアップジョブ- バックアップレベル- 所要時間- Hbaseコミュニティでのバックアップ向け機能の開発状況 7
  76. 76. HBase Backup発表者: Sunil Sitaula, Solutions Architect, Cloudera Inc. Madhuwanti Vaidya, Software Engineer, Facebook Inc. 7
  77. 77. HBase Backup -現状のバックアップ選択肢DistCP - /hbaseディレクトリ下をまるまるコピー。 - 速くて簡単だが一貫性は保証されない。Memstoreのデータも考慮されない。exportツール - データをExportするMRジョブ起動。 - テーブル名、バージョン数、TimeRange指定でexport対象を指定可能。 - 1度に1つのテーブルしか処理できない。copytableツール - exportツールとは違い、データを別クラスタに保存。 - 長所短所はexportツールと同様。レプリケーション - Regionサーバ間のWALEditsの転送によるレプリケーション。 - 一時的にスレーブ側クラスタをオフラインにすることもできる。 - バグやオペミスによるデータ消去はレプリカ側にも波及する。アプリケーションから複数クラスタへの書き込み。 - DRに対応できるが、整合性や原子性をAPが配慮しなければならない。 7
  78. 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. 79. HBase Backup - 絶賛開発中の機能- HBASE-6055: スナップショット- HBASE-4618: HFileとHLogにもとづくバックアップ 7
  80. 80. HBase Backup - 高速コピー 8
  81. 81. ランチボックス 8
  82. 82. Development 8
  83. 83. HBase Schema Design 8
  84. 84. HBase Schema DesignHBaseのスキーマ設計設計はRDBMSの場合の非正規化に相当する。「入れ子になったエンティティ」というRDBMSにはない概念がキーポイント。- HBaseのデータ構造の復習- HBaseには外部キー、ジョイン、テーブルをまたがるトランザクションは無い。 テーブル間の関係をどう表現するかについて、 自力でジョインを実装するか非正規化するかの2択だが、非正規化がおすすめ。- 入れ子になったエンティティ - 固定幅での表現、区切り文字、シリアライズによるバイト列の結合 - 行キーの一部、列名、タイムスタンプを属性の格納に利用。- 「HBaseスキーマのデザインパターン」紹介。 データへのアクセスパスを考慮して設計すること。 RDBはアクセスパターンをユーザから隠ぺいするが、 HBaseはユーザに考えさせる。 8
  85. 85. HBase Schema Design発表者: Ian Varley, Principal Member of Technical Staff, Salesforce.com 8
  86. 86. HBase Performance Tuning and Optimizations 8
  87. 87. HBase Performance Tuning and Optimizations 8
  88. 88. HBase Performance Tuning and Optimizations 8
  89. 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. 90. HBase Performance Tuning and Optimizations- Facebookでの性能チューニングベストプラクティス - 行キー設計と事前スプリット - ブロックサイズ - コンパクション設定- HBase自体の性能改良について紹介 - HFile v2 - データブロックエンコーディング(HBASE-4218) - スキャナ改善 9
  91. 91. HBase Performance Tuning and Optimizations発表者: Mikhail Bautin, Software Engineer, Facebook 9
  92. 92. 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
  93. 93. HBase Performance Tuning and Optimizations 9
  94. 94. HBase Performance Tuning and Optimizations 9
  95. 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
  96. 96. HBase Performance Tuning and Optimizations 9
  97. 97. Ligntning Talk 9
  98. 98. StumbleUponHBaseをCAS(Content Addressable Storage)として利用 9
  99. 99. PhotobucketSolbase: Solr/Luceneを改造してHBaseをバックエンドとして利用 9
  100. 100. Yahoo!トランザクション機能を拡張 1
  101. 101. NextBioゲノム情報を高速に閲覧するための構造でHBaseに格納 1
  102. 102. NextBio患者データの相関を格納 1
  103. 103. AOLメールデータのプロファイリング結果を格納 1
  104. 104. OCLC図書館所蔵の書籍データを格納するシステム 1
  105. 105. Sushi 1
  106. 106. Chocolate(Any Question?) 1

×