なぜ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 Qualiﬁers 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

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

なぜApache HBaseを選ぶのか？ #cwt2013

Cloudera Japan

なぜApache HBaseを選ぶのか？ #cwt2013