なぜApache HBaseを選ぶのか？ #cwt2013
•
11 likes•10,275 views
#cwt2013 ClouderaのJonathan Hsieh @jmhsieh によるHBaseの最新情報のスライドを公開しました。CDH5のHBase 0.96では耐障害性が強化され、障害発生時も書き込みは数秒、読み込みは10秒以内に復旧します。
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (10)
Similar to なぜApache HBaseを選ぶのか？ #cwt2013
Similar to なぜApache HBaseを選ぶのか？ #cwt2013 (20)
More from Cloudera Japan
More from Cloudera Japan (20)
なぜApache HBaseを選ぶのか？ #cwt2013
- 1. DO NOT USE PUBLICLY PRIOR TO 10/23/12 なぜApache HBaseを選ぶのか? Headline Goes Here Jonathan Hsieh | @jmhsieh Speaker Name or Subhead Goes Here SoHware Engineer at Cloudera | HBase PMC Member November 7th, 2013, Cloudera World Japan 2013
- 2. 自己紹介 • Cloudera: • ソフトウェアエンジニア • Tech Lead HBase Team • Apache HBase commiRer / PMC • Apache Flume founder / PMC • ワシントン大学: • 分散システムの研究 2 11/7/13 Cloudera World Japan Jonathan Hsieh
- 3. Apache HBaseとは? Apache HBaseはApache Hadoop上で開発された オープンソースの, 分散型 非リレーショナルデータ ベース。低レイテンシで一 貫性の高い読み出し・書き 込み操作などランダムアク セスを実現する 3 11/7/13 Cloudera World Japan Jonathan Hsieh
- 4. HBaseはオープンソース • Apache 2.0ライセンス • さまざまな組織からのコミッターやコントリビューターで構成さ れたコミュニティプロジェクト • Facebook, Cloudera, Salesforce.com, Huawei, HortonWorks, Intel… • コードライセンスとは、誰もがコードの利用・改変できることを 意味する 4 11/7/13 Cloudera World Japan Jonathan Hsieh
- 5. オープンソース開発者コミュニティ • 活気がある 活動盛んな コミュニティ 5 11/7/13 Cloudera World Japan Jonathan Hsieh
- 6. HBaseは低レイテンシなランダムアクセスを実現 • 書き込み: • • 読み出し: • • • 1-‐3ms, 1k-‐10k writes/sec per node 0-‐3ms キャッシュ, 10-‐30msディスク 10k-‐40k reads / 秒 / node from cache セルサイズ: • 0000000000 4 1 2222222222 3333333333 5 4444444444 5555555555 0B-‐3MB 6666666666 • 読み出し, 書き込み, テーブルの 2 3 任意の箇所へのデータ挿入 6 1111111111 11/7/13 Cloudera World Japan Jonathan Hsieh 7777777777
- 7. Apache HBase アーキテクチャ 設計と開発 7 11/7/13 Cloudera World Japan Jonathan Hsieh
- 8. Google インフラストラクチャー (2006年ごろ) • OSDI 2006 paper • 目標:大量の準構造化データに対する迅速なランダムリード（読み込 み）/ライト（書き出し）アクセスの実現 • 8 Webやorkut、アナリティクス、Google Earth、ブロガーへのGoogleク ローラー用データストア 11/7/13 Cloudera World Japan Jonathan Hsieh
- 9. バックエンド フロントエンド Web アプリケーション アーキテクチャ 9 HTTP App DB フィルタ ログ 処理 App data アプリケーションおよび HTTPログ レポート 機械学習 11/7/13 Cloudera World Japan Jonathan Hsieh
- 10. バックエンド フロントエンド Web アプリケーション アーキテクチャ 10 HTTP HTTP App App DB アプリケーション データ HTTP App HTTP HTTP App App ログ フィルタ アプリケーションおよび HTTPのログ 11/7/13 Cloudera World Japan Jonathan Hsieh … HTTP App ログ処理 レポート、 機械学習
- 11. バックエンド フロントエンド Web アプリケーション アーキテクチャ 11 HTTP HTTP App App DB アプリケーション データ HTTP App HTTP HTTP App App HDFS アプリケーションおよび HTTPログ 11/7/13 Cloudera World Japan Jonathan Hsieh … HTTP App Hadoop MapReduce レポート、 機械学習
- 12. バックエンド フロントエンド Web アプリケーション アーキテクチャ 12 HTTP HTTP App App HTTP App HTTP HTTP App App HDFS アプリケーション データ アプリケーションおよび HTTPログ 11/7/13 Cloudera World Japan Jonathan Hsieh … HTTP App Hadoop MapReduce レポート、 機械学習
- 13. 今日のプレゼン: Apache HBase 0.96.0 • HBaseのフォールト・トレラント機能 Reliable Highly Available • HDFSで永続性実現 • データの遺失がない • HBaseの高度な高可用性 • 障害からの迅速な復旧 Predictability 13 • 予測可能なパフォーマンスに向けた改善 • 99％タイルを向上し、平均値は上々 11/7/13 Cloudera World Japan Jonathan Hsieh
- 14. 実際に利用中のApache HBase アプリケーション • Inbox • ストレージ • Web • Search • 分析 • モニタリング 14 さらに詳しいケーススタディ→ hRp://www.hbasecon.com/agenda/ 11/7/13 Cloudera World Japan Jonathan Hsieh
- 15. HBaseの依存関係 • Apache Hadoop HDFS による永続性と信頼性 の実現 (先行書き込みログ) • Apache ZooKeeperによる分散協調の実現 • Apache Hadoop MapReduce によるデータの抽 出・インポートを行うMapReduceジョブの実行 App MR ZK HDFS 15 11/7/13 Cloudera World Japan Jonathan Hsieh
- 16. クラスタ上のHBase HDFSネームノード HBaseマスター Rack 1 ZooKeeper Quorum Slave Boxes (DN + RS) Name node Rack 2 Name node 16 11/7/13 Cloudera World Japan Jonathan Hsieh
- 17. バージョンごとのサマリー 0.90 (CDH3) 0.92 /0.94 (CDH4) 0.96 (CDH5) 次期バージョン 新機能 安定性 信頼性 継続性 マルチテナンシー MTTR 数時間内の 復旧 数分以内の復旧 書き込みは数秒以内、 数秒以内の復旧 読み出しは10秒以内 (reads/writes両方) の復旧 Perf ベースライン スループットの改善 パフォーマンス 最適化 予測可能な パフォーマンス ユーザ ビリティ HBase 開発者 専門家 HBase 運用経験 分散システムの 管理経験 アプリケーションの 開発経験 平均復旧 時間 17 11/7/13 Cloudera World Japan Jonathan Hsieh
- 18. HBase データモデル Rows, Columns Families and Qualifiers 18 11/7/13 Cloudera World Japan Jonathan Hsieh
- 19. ソートマップデータストア (論理ビュー) Row key roles:hadoop cugng ‘9H’ ‘CA’ ‘Founder’ tlipcon 19 info: height info:state ‘5H7’ ‘CA’ ‘PMC’ @ts=2011 ‘CommiRer’ @ts=2010 11/7/13 Cloudera World Japan Jonathan Hsieh roles:hbase ‘CommiRer’
- 20. ソートマップデータストア(論理ビュー) RDBMS観点における 暗黙のプライマリーキー Row key roles:hadoop cugng ‘9H’ ‘CA’ ‘Founder’ tlipcon 20 info: height info:state ‘5H7’ ‘CA’ ‘PMC’ @ts=2011 ‘CommiRer’ @ts=2010 11/7/13 Cloudera World Japan Jonathan Hsieh roles:hbase ‘CommiRer’
- 21. ソートマップデータストア(論理ビュー) RDBMS観点における 暗黙のプライマリーキー HBaseではデータはすべて byte[] Row key roles:hadoop cugng ‘9H’ ‘CA’ ‘Founder’ tlipcon 21 info: height info:state ‘5H7’ ‘CA’ ‘PMC’ @ts=2011 ‘CommiRer’ @ts=2010 11/7/13 Cloudera World Japan Jonathan Hsieh roles:hbase ‘CommiRer’
- 22. ソートマップデータストア(論理ビュー) RDBMS観点における 暗黙のプライマリーキー HBaseではデータはすべて byte[] Row key info: height info:state roles:hadoop cugng ‘9H’ ‘CA’ ‘Founder’ tlipcon ‘5H7’ ‘CA’ ‘PMC’ @ts=2011 ‘CommiRer’ @ts=2010 単一のセルは、 異なるタイムスタ ンプで異なる値を 持つ場合がある 22 11/7/13 Cloudera World Japan Jonathan Hsieh roles:hbase ‘CommiRer’
- 23. ソートマップデータストア(論理ビュー) RDBMS観点における 暗黙のプライマリーキー HBaseではデータはすべて byte[] Row key info: height info:state roles:hadoop cugng ‘9H’ ‘CA’ ‘Founder’ tlipcon ‘5H7’ ‘CA’ ‘PMC’ @ts=2011 ‘CommiRer’ @ts=2010 単一のセルは、 異なるタイムスタ ンプで異なる値を 持つ場合がある 23 11/7/13 Cloudera World Japan Jonathan Hsieh roles:hbase ‘CommiRer’ 異なる行は 異なる列セットを 持つこともある （テーブルはま ばら）
- 24. ソートマップデータストア(論理ビュー) RDBMS観点における 暗黙のプライマリーキー カラムフォーマットファミリー:修飾子 Row key info: height info:state roles:hadoop cugng ‘9H’ ‘CA’ ‘Founder’ tlipcon ‘5H7’ ‘CA’ ‘PMC’ @ts=2011 ‘CommiRer’ @ts=2010 単一のセルは、 異なるタイムスタ ンプで異なる値を 持つ場合がある 24 HBaseではデータはすべて byte[] 11/7/13 Cloudera World Japan Jonathan Hsieh roles:hbase ‘CommiRer’ 異なる行は 異なる列セットを 持つこともある （テーブルはま ばら）
- 25. ソートマップデータストア(物理ビュー) info Column Family Row key Cell value info:height 1273516197868 9H cugng info:state 1043871824184 CA tlipcon info:height 1273878447049 5H7 tlipcon info:state 1273616297446 CA Row key 25 Timestamp cugng 行キー、 列キー、 降順タイムス タンプで ディスクに ソート Column key Column key Timestamp Cell value cugng roles:Hadoop 1183746289103 Founder tlipcon roles:Hadoop 1300062064923 PMC tlipcon roles:Hadoop 1293388212294 CommiRer tlipcon roles:HBase 128432513215 CommiRer roles Column Family UNIX時代からミリ秒 11/7/13 Cloudera World Japan Jonathan Hsieh
- 26. どうやってデータを配置するべきか? rowkeyを複合した Tall skinny Table • 同形のデータを表している！ rowkey 行修飾子を利用したShort Fat Table Rowkey d:col1 d:col2 d:col3 d:col4 bob aaaa bbbb cccc dddd jon eeee ffff gggg hhhhh 行修飾子を利用したShort Fat Table d: bob-‐col1 aaaa bob-‐col2 bbbb bob-‐col3 cccc bob-‐col4 dddd jon-‐col1 eeee Rowkey col2: col3: col4: jon-‐col2 ffff bob aaaa bbbb cccc dddd jon-‐col3 gggg jon 26 col1: eeee ffff gggg hhhhh jon-‐col4 hhhh 11/7/13 Cloudera World Japan Jonathan Hsieh
- 27. どうやってデータを配置するべきか? rowkeyを複合した Tall skinny Table • 同形のデータを表している！ は に rowkey d: 行修飾子を利用したShort Fat Table 力 きな が伴う! bob-‐col1 aaaa 大 d:col3 任 d:col4 Rowkey d:col1 d:col2 bob-‐col2 bbbb な責 dddd る? bob aaaa bbbb き cccc 大 bob-‐col3 hhhhh やすくな cccc jon eeee ffff gggg 使い bob-‐col4 dddd 行修飾子を利用したShort Fat Table ーに jon-‐col1 eeee ーザ col4: Rowkey col1: col2: ユ col3: ば jon-‐col2 ffff れbbbb cccc dddd す bob どう aaaa jon-‐col3 gggg jon 27 eeee ffff gggg hhhhh 11/7/13 Cloudera World Japan Jonathan Hsieh jon-‐col4 hhhh
- 28. Impala HDFS（とHBase！）に対してスケーラブルな低レイテンシSQL クエリを実行 • ODBC/JDBCドライバ インターフェース • 特長 • • • • • Open sourced by ClouderaClouderaによるオープンソース • 28 Hiveメタストアと、そのhbase-‐hbaseコネクタ設定を利用規則 ネイティブコードの実装では、クエリの実行最適化に際して JITを利用 Kerberosのサポートによる認証 hRps://github.com/cloudera/impala 11/7/13 Cloudera World Japan Jonathan Hsieh
- 29. Phoenix • • • 低レイテンシクエリ分野ではHBaseより優れたSQL JDBC SQLインターフェイス 特長 • • • • • Salesforce.comによるオープンソース • • 29 データ型の追加 複合行キーのエンコーディングを操作 開発中の二次インデックス プッシュダウン集計（コンプレッサー）を提供 James Taylor, Jesse Yatesその他の方々の成果 hRps://github.com/forcedotcom/phoenix 11/7/13 Cloudera World Japan Jonathan Hsieh
- 30. HBase とその他NoSqlとの比較 Cassandra, MongoDB とM7 Tablesとの比較 30 11/7/13 Cloudera World Japan Jonathan Hsieh
- 31. 支持されているNoSQLは？ • システムを考慮すると • HBase • MongoDB • Cassandra • M7 Tables 31 11/7/13 Cloudera World Japan Jonathan Hsieh
- 32. BrewerのCAP理論 • Consistency（一貫性）: • DBとACID特性の分離の保証 • Availability（可用性）: • データを返す前に障害から復旧する か？ • 復旧を待つ代わりに、古いデータを 返すか? Parrron tolerance • ParZZon Tolerance（パーティー ション・トレランス）: • 32 ノードが落ちても、システムは稼働 11/7/13 Cloudera World Japan Jonathan Hsieh Consistency 5 4 3 2 1 0 Availability
- 33. NoSQL との機能比較 HBase その他の選択肢 可用性を上回る強力な一貫性 • パフォーマンスを上回る安全性 • シンプルな障害セマンティック • 整備されたレンジパーティーション • 数千ノードにスケール • ばらつきのあるカラムストレージ • Apacheライセンス • • 33 強力な一貫性を上回る可用性 • 安全性を上回るパフォーマンス • 複雑な設定が必要なセマンティック • 分散ハッシュ • 数十ノードのスケール • Btrees • GPLもしくはプロプライエタリなライセ ンス 11/7/13 Cloudera World Japan Jonathan Hsieh
- 34. 何がHBaseの書き込みを保証するのか？ client R value RS 1 2 3 • HBaseは強力な一貫性を持つ Acked書き込みは3つの永続的なレプリカを持つ • Nacked 書き込みはロールバック可能 • マシン障害はセマンティックを変更しない • • 開発者やアーキテクトが望んでいたシンプルなセマンティック 34 11/7/13 Cloudera World Japan Jonathan Hsieh
- 35. 何がHBaseの書き込みを保証するのか？ client R value RS 1 2 3 • HBaseは強力な一貫性を持つ Acked書き込みは3つの永続的なレプリカを持つ • Nacked 書き込みはロールバック可能 • マシン障害はセマンティックを変更しない • • 開発者やアーキテクトが望んでいたシンプルなセマンティック 35 11/7/13 Cloudera World Japan Jonathan Hsieh
- 36. 何がHBaseの書き込みを保証するのか？ client R value RS 1 2 3 • HBaseは強力な一貫性を持つ Acked書き込みは3つの永続的なレプリカを持つ • Nacked 書き込みはロールバック可能 • マシン障害はセマンティックを変更しない • • 開発者やアーキテクトが望んでいたシンプルなセマンティック 36 11/7/13 Cloudera World Japan Jonathan Hsieh
- 37. Cassandraでは何が書き込みを保証するのか？ client R value W client Subtle: Write Write client success, acks on quorum; client received nack but read quorum Read client quorum reports green value. reports purple value!? Subtle: Write client received nack but Write client Gossip / read repair success, acks on quorum; ould report purple value!? read alue. Read client quorum reports blue vany c 1 2 3 • Cassandraは最後の書き込みがポリシーに勝っている限り、ほぼ一貫性を保持 • • • • 一貫性の調整が可能(ほとんどがAckを使用, または “Quorum”) Acked書き込みは多数の永続レプリカを必要とする Nacked書き込みは永続レプリカを必要としない (最終的には必要になる！) 書き込みのロールバックはなし “Cassandraにはクライアントへの書き込み操作障 害時にクライアントへのレポート機能があるが、実際にはレプリカへの書き込みを保 持し続ける）”* hRp://www.datastax.com/documentaron/cassandra/1.2/webhelp/cassandra/dml/dml_about_transacrons_c.html 37 11/7/13 Cloudera World Japan Jonathan Hsieh
- 38. Cassandraでは何が書き込みを保証するのか？ client R value W client Subtle: Write client received nack but read quorum reports purple value!? 1 2 3 • Subtle: Write client received nack but read any could report purple value!? Cassandraは最後の書き込みがポリシーに勝っている限り、ほぼ一貫性を保持 • • • • 一貫性の調整が可能(ほとんどがAckを使用, または “Quorum”) Acked書き込みは多数の永続レプリカを必要とする Nacked書き込みは永続レプリカを必要としない (最終的には必要になる！) 書き込みのロールバックはなし “Cassandraにはクライアントへの書き込み操作障 害時にクライアントへのレポート機能があるが、実際にはレプリカへの書き込みを保 持し続ける）”* hRp://www.datastax.com/documentaron/cassandra/1.2/webhelp/cassandra/dml/dml_about_transacrons_c.html 38 11/7/13 Cloudera World Japan Jonathan Hsieh
- 39. Cassandraでは何が書き込みを保証するのか？ client R value W client Subtle: Write client received nack but read quorum reports purple value!? 1 2 3 • Gossip / read repair Cassandraは最後の書き込みがポリシーに勝っている限り、ほぼ一貫性を保持 • • • • 一貫性の調整が可能(ほとんどがAckを使用, または “Quorum”) Acked書き込みは多数の永続レプリカを必要とする Nacked書き込みは永続レプリカを必要としない (最終的には必要になる！) 書き込みのロールバックはなし “Cassandraにはクライアントへの書き込み操作障 害時にクライアントへのレポート機能があるが、実際にはレプリカへの書き込みを保 持し続ける）”* hRp://www.datastax.com/documentaron/cassandra/1.2/webhelp/cassandra/dml/dml_about_transacrons_c.html 39 Subtle: Write client received nack but read any could report purple value!? 11/7/13 Cloudera World Japan Jonathan Hsieh
- 40. Cassandraでは何が書き込みを保証するのか？ client R value W client 1 2 3 • Gossip / read repair Cassandra is eventually consistent with a Last Write Wins policy • • • • Tunable consistency (most use One Ack, also has “Quorum”) Acked writes has required number of durable replicas Nacked writes does not have required durable replicas (but may eventually win!) No rollback the writes. “It is possible in Cassandra to have a write operaron report a failure to the client, but srll actually persist the write to a replica.”* hRp://www.datastax.com/documentaron/cassandra/1.2/webhelp/cassandra/dml/dml_about_transacrons_c.html 40 11/7/13 Cloudera World Japan Jonathan Hsieh
- 41. MongoDB はどうやって書き込みを保証するのか? Parrron! Split brain! client 2 Subtle: Replica with latest logs wins. Either yellow or orange data is revoked/lost! client 1 1 2 3 • promoted MongoDB (2.4.8+) はデフォルトでacksを利用するが、永続的なログの書き込みはない • • demoted マシン障害は必ずしもデータ破損ではない “Write concerns” for higher reliability • • • Acked のレプリカ: # ack前にリモートノードにレプリカ Journaledack前にログ先行書き込みバッファ（フラッシュ間に100ms） ただし、強力な設定のイベントではAcked書き込みはフェールオーバー時に失われる* * hRp://docs.mongodb.org/manual/core/replica-‐set-‐rollbacks/ 41 11/7/13 Cloudera World Japan Jonathan Hsieh
- 42. MongoDB はどうやって書き込みを保証するのか? Parrron! Split brain! client 2 Subtle: Replica with latest logs wins. Either yellow or orange d ay i ave Because of network split, we mata hs revoked/lost! to primaries at the same rme. client 1 1 2 3 • promoted MongoDB (2.4.8+) はデフォルトでacksを利用するが、永続的なログの書き込みはない • • demoted マシン障害は必ずしもデータ破損ではない “Write concerns” for higher reliability • • • Acked のレプリカ: # ack前にリモートノードにレプリカ Journaledack前にログ先行書き込みバッファ（フラッシュ間に100ms） ただし、強力な設定のイベントではAcked書き込みはフェールオーバー時に失われる* * hRp://docs.mongodb.org/manual/core/replica-‐set-‐rollbacks/ 42 11/7/13 Cloudera World Japan Jonathan Hsieh
- 43. MongoDB はどうやって書き込みを保証するのか? Parrron! Split brain! client 2 Subtle: Replica with latest logs wins. Either yellow or orange data is revoked/lost! client 1 1 2 3 • promoted MongoDB (2.4.8+) はデフォルトでacksを利用するが、永続的なログの書き込みはない • • demoted マシン障害は必ずしもデータ破損ではない “Write concerns” for higher reliability • • • Acked のレプリカ: # ack前にリモートノードにレプリカ Journaledack前にログ先行書き込みバッファ（フラッシュ間に100ms） ただし、強力な設定のイベントではAcked書き込みはフェールオーバー時に失われる* * hRp://docs.mongodb.org/manual/core/replica-‐set-‐rollbacks/ 43 11/7/13 Cloudera World Japan Jonathan Hsieh
- 44. まとめ 45 11/7/13 Cloudera World Japan Jonathan Hsieh
- 45. なぜApache HBaseを選ぶのか? ビジネス面から見た理由 技術面から見た理由 Apache ライセンス • 複数のベンダがサポート • 多様なコミュニティ • 多くの人の支持、増加中 • HBase多くの企業がHBaseを拡張し てビジネスを構築 • ディザスタ・リカバリ機能 • 強力なセキュリティ機能 • • 46 可用性を上回る強力な一貫性 • パフォーマンスを上回る安全性 • シンプルな障害セマンティック • 数千・数百ノードへのスケール • データを破損することなくリカバリ ー 11/7/13 Cloudera World Japan Jonathan Hsieh
- 46. Quesrons? @jmhsieh 47 明日11月８日18時半〜 HBase Meetupを開催します。 ぜひご参加ください！ 11/7/13 Cloudera World Japan Jonathan Hsieh