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

Headline Goes Here Speaker Name or Subhead Goes Here

DO NOT USE PUBLICLY PRIOR TO 10/23/12 なぜApache HBaseを選ぶのか?

Jonathan Hsieh | @jmhsieh SoHware Engineer at Cloudera | HBase PMC Member November 7th, 2013, Cloudera World Japan 2013

自己紹介

•  Cloudera: •  ソフトウェアエンジニア •  Tech Lead HBase Team •  Apache HBase commiRer / PMC •  Apache Flume founder / PMC

• ワシントン大学: •  分散システムの研究

11/7/13 Cloudera World Japan Jonathan Hsieh 2

Apache HBaseとは? Apache HBaseはApache Hadoop上で開発された

オープンソースの, 分散型非リレーショナルデータ

ベース。低レイテンシで一貫性の高い読み出し・書き込み操作などランダムアク

セスを実現する 11/7/13 Cloudera World Japan

Jonathan Hsieh 3

HBaseはオープンソース

• Apache 2.0ライセンス • さまざまな組織からのコミッターやコントリビューターで構成されたコミュニティプロジェクト

•  Facebook, Cloudera, Salesforce.com, Huawei, HortonWorks, Intel…

• コードライセンスとは、誰もがコードの利用・改変できることを意味する


オープンソース開発者コミュニティ

• 活気がある活動盛んなコミュニティ


HBaseは低レイテンシなランダムアクセスを実現

•  書き込み: •  1-‐3ms, 1k-‐10k writes/sec per node

•  読み出し: •  0-‐3ms キャッシュ, 10-‐30msディスク •  10k-‐40k reads / 秒 / node from cache

•  セルサイズ: •  0B-‐3MB

• 読み出し, 書き込み, テーブルの任意の箇所へのデータ挿入

11/7/13 Cloudera World Japan Jonathan Hsieh

0000000000

1111111111

2222222222

3333333333

4444444444

5555555555

6666666666

7777777777

1

2 3

4

5

6

Apache HBase アーキテクチャ設計と開発


Google インフラストラクチャー (2006年ごろ)

•  OSDI 2006 paper

•  目標:大量の準構造化データに対する迅速なランダムリード（読み込み）/ライト（書き出し）アクセスの実現

•  Webやorkut、アナリティクス、Google Earth、ブロガーへのGoogleクローラー用データストア


Web アプリケーションアーキテクチャ


App HTTP

フィルタ DB

フロ

ント

エン

ド

バッ

クエ

ンド

ログ処理

アプリケーションおよび HTTPログ

App data レポート機械学習

9



App HTTP

ログフィルタ DB

フロ

ント

エン

ド

バッ

クエ

ンド

アプリケーションおよび HTTPのログ

アプリケーションデータ

ログ処理

App HTTP

App HTTP

App HTTP

App HTTP

App HTTP

…

レポート、機械学習

10



App HTTP

フロ

ント

エン

ド

バッ

クエ

ンド



App HTTP

App HTTP

App HTTP

App HTTP

App HTTP

…

Hadoop MapReduce レポート、機械学習

DB

11

HDFS



App HTTP

フロ

ント

エン

ド

バッ

クエ

ンド

App HTTP

App HTTP

App HTTP

App HTTP

App HTTP

…

12

HDFS Hadoop

MapReduce レポート、機械学習



今日のプレゼン: Apache HBase 0.96.0


• HBaseのフォールト・トレラント機能 •  HDFSで永続性実現 •  データの遺失がない

• HBaseの高度な高可用性 •  障害からの迅速な復旧

• 予測可能なパフォーマンスに向けた改善 •  99％タイルを向上し、平均値は上々

Reliable

Highly Available

Predictability

13

実際に利用中のApache HBase アプリケーション

•  Inbox • ストレージ • Web •  Search • 分析 • モニタリング

さらに詳しいケーススタディ→ hRp://www.hbasecon.com/agenda/ 11/7/13 Cloudera World Japan

Jonathan Hsieh 14

HBaseの依存関係

• Apache Hadoop HDFS による永続性と信頼性の実現 (先行書き込みログ)

• Apache ZooKeeperによる分散協調の実現

• Apache Hadoop MapReduce によるデータの抽出・インポートを行うMapReduceジョブの実行

ZK HDFS

App MR


クラスタ上のHBase

Name node

Name node

Rack 1

Rack 2


HDFSネームノード HBaseマスター

ZooKeeper Quorum

Slave Boxes (DN + RS)

16

バージョンごとのサマリー 0.90 (CDH3) 0.92 /0.94 (CDH4) 0.96 (CDH5) 次期バージョン

新機能安定性信頼性

継続性マルチテナンシー

MTTR 平均復旧時間

数時間内の復旧

数分以内の復旧書き込みは数秒以内、読み出しは10秒以内の復旧

数秒以内の復旧(reads/writes両方)

Perf ベースラインスループットの改善パフォーマンス最適化

予測可能なパフォーマンス

ユーザビリティ

HBase 開発者専門家

HBase 運用経験分散システムの管理経験

アプリケーションの開発経験


Rows, Columns Families and Qualifiers

HBase データモデル


ソートマップデータストア (論理ビュー)

Row key info: height info:state roles:hadoop roles:hbase

cugng ‘9H’ ‘CA’ ‘Founder’

tlipcon ‘5H7’ ‘CA’ ‘PMC’ @ts=2011 ‘CommiRer’ @ts=2010

‘CommiRer’


ソートマップデータストア(論理ビュー)




‘CommiRer’

RDBMS観点における暗黙のプライマリーキー





‘CommiRer’

HBaseではデータはすべてbyte[]


ソートマップデータストア(論理ビュー) RDBMS観点における

暗黙のプライマリーキー




‘CommiRer’

単一のセルは、異なるタイムスタンプで異なる値を持つ場合がある


RDBMS観点における暗黙のプライマリーキー

HBaseではデータはすべてbyte[]

ソートマップデータストア(論理ビュー)




‘CommiRer’

異なる行は異なる列セットを

持つこともある（テーブルはま

ばら）



暗黙のプライマリーキー HBaseではデータはすべて

byte[]





‘CommiRer’

カラムフォーマットファミリー:修飾子



暗黙のプライマリーキー HBaseではデータはすべて

byte[]


異なる行は異なる列セットを

持つこともある（テーブルはま

ばら）

ソートマップデータストア(物理ビュー)

Row 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

行キー、列キー、

降順タイムスタンプで

ディスクにソート UNIX時代からミリ秒

Row key Column key Timestamp Cell value

cugng info:height 1273516197868 9H

cugng info:state 1043871824184 CA

tlipcon info:height 1273878447049 5H7

tlipcon info:state 1273616297446 CA

info Column Family

roles Column Family


どうやってデータを配置するべきか?

• 同形のデータを表している！


rowkey d:

bob-‐col1 aaaa

bob-‐col2 bbbb

bob-‐col3 cccc

bob-‐col4 dddd

jon-‐col1 eeee

jon-‐col2 ffff

jon-‐col3 gggg

jon-‐col4 hhhh

Rowkey d:col1 d:col2 d:col3 d:col4

bob aaaa bbbb cccc dddd

jon eeee ffff gggg hhhhh

Rowkey col1: col2: col3: col4:



行修飾子を利用したShort Fat Table


rowkeyを複合した Tall skinny Table

26

どうやってデータを配置するべきか?

• 同形のデータを表している！


rowkey d:

bob-‐col1 aaaa

bob-‐col2 bbbb

bob-‐col3 cccc

bob-‐col4 dddd

jon-‐col1 eeee

jon-‐col2 ffff

jon-‐col3 gggg

jon-‐col4 hhhh

Rowkey d:col1 d:col2 d:col3 d:col4



Rowkey col1: col2: col3: col4:





rowkeyを複合した Tall skinny Table

27

大きな力には

大きな責任が

伴う!

どうすればユーザーに使いやすくなる?

Impala

•  HDFS（とHBase！）に対してスケーラブルな低レイテンシSQLクエリを実行

•  ODBC/JDBCドライバインターフェース •  特長

•  Hiveメタストアと、そのhbase-‐hbaseコネクタ設定を利用規則 •  ネイティブコードの実装では、クエリの実行最適化に際してJITを利用

•  Kerberosのサポートによる認証

•  Open sourced by ClouderaClouderaによるオープンソース •  hRps://github.com/cloudera/impala


Phoenix

•  低レイテンシクエリ分野ではHBaseより優れたSQL •  JDBC SQLインターフェイス •  特長

•  データ型の追加 •  複合行キーのエンコーディングを操作 •  開発中の二次インデックス •  プッシュダウン集計（コンプレッサー）を提供

•  Salesforce.comによるオープンソース •  James Taylor, Jesse Yatesその他の方々の成果 •  hRps://github.com/forcedotcom/phoenix


Cassandra, MongoDB とM7 Tablesとの比較

HBase とその他NoSqlとの比較


支持されているNoSQLは？

• システムを考慮すると •  HBase • MongoDB •  Cassandra • M7 Tables


BrewerのCAP理論

•  Consistency（一貫性）: •  DBとACID特性の分離の保証

• Availability（可用性）: •  データを返す前に障害から復旧する

か？ •  復旧を待つ代わりに、古いデータを

返すか? •  ParZZon Tolerance（パーティーション・トレランス）:

•  ノードが落ちても、システムは稼働


0

1

2

3

4

5 Consistency

Availability Parrron tolerance

32

NoSQL との機能比較

HBase •  可用性を上回る強力な一貫性 •  パフォーマンスを上回る安全性 •  シンプルな障害セマンティック •  整備されたレンジパーティーション •  数千ノードにスケール •  ばらつきのあるカラムストレージ •  Apacheライセンス

その他の選択肢 •  強力な一貫性を上回る可用性 •  安全性を上回るパフォーマンス •  複雑な設定が必要なセマンティック •  分散ハッシュ •  数十ノードのスケール •  Btrees •  GPLもしくはプロプライエタリなライセ

ンス


何がHBaseの書き込みを保証するのか？

•  HBaseは強力な一貫性を持つ •  Acked書き込みは3つの永続的なレプリカを持つ •  Nacked 書き込みはロールバック可能 •  マシン障害はセマンティックを変更しない

•  開発者やアーキテクトが望んでいたシンプルなセマンティック


RS

1 2 3

34

client R value


RS

1 2 3

35

client R value





RS

1 2 3

36

client R value




Cassandraでは何が書き込みを保証するのか？

•  Cassandraは最後の書き込みがポリシーに勝っている限り、ほぼ一貫性を保持 •  一貫性の調整が可能(ほとんどがAckを使用, または “Quorum”) •  Acked書き込みは多数の永続レプリカを必要とする •  Nacked書き込みは永続レプリカを必要としない (最終的には必要になる！) •  書き込みのロールバックはなし “Cassandraにはクライアントへの書き込み操作障

害時にクライアントへのレポート機能があるが、実際にはレプリカへの書き込みを保持し続ける）”*


hRp://www.datastax.com/documentaron/cassandra/1.2/webhelp/cassandra/dml/dml_about_transacrons_c.html

W client

1 2 3

37

Gossip / read repair

Subtle: Write client received nack but read quorum reports purple value!?

client R value

Subtle: Write client received nack but read any could report purple value!?

Write client success, acks on quorum; Read client quorum reports green value. Write client success, acks on quorum; Read client quorum reports blue value.



W client

1 2 3

38

Subtle: Write client received nack but read quorum reports purple value!?

client R value

Subtle: Write client received nack but read any could report purple value!?






W client

1 2 3

39


client R value

Subtle: Write client received nack but read quorum reports purple value!? Subtle: Write client received nack but read any could report purple value!?




•  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.”*



W client

1 2 3

40


client R value


MongoDB はどうやって書き込みを保証するのか?

•  MongoDB (2.4.8+) はデフォルトでacksを利用するが、永続的なログの書き込みはない •  マシン障害は必ずしもデータ破損ではない

•  “Write concerns” for higher reliability •  Acked のレプリカ: # ack前にリモートノードにレプリカ •  Journaledack前にログ先行書き込みバッファ（フラッシュ間に100ms） •  ただし、強力な設定のイベントではAcked書き込みはフェールオーバー時に失われる*


client 1

1 2 3

Parrron! Split brain!

* hRp://docs.mongodb.org/manual/core/replica-‐set-‐rollbacks/

41

demoted

promoted

client 2 Subtle: Replica with latest logs wins.

Either yellow or orange data is revoked/lost!


client 1

1 2 3



42

demoted

promoted



Because of network split, we may have to primaries at the same rme.





client 1

1 2 3



43

demoted

promoted






まとめ


なぜApache HBaseを選ぶのか?

ビジネス面から見た理由 •  Apache ライセンス •  複数のベンダがサポート •  多様なコミュニティ •  多くの人の支持、増加中 •  HBase多くの企業がHBaseを拡張し

てビジネスを構築 •  ディザスタ・リカバリ機能 •  強力なセキュリティ機能

技術面から見た理由 •  可用性を上回る強力な一貫性 •  パフォーマンスを上回る安全性 •  シンプルな障害セマンティック •  数千・数百ノードへのスケール •  データを破損することなくリカバリ

ー


Quesrons? @jmhsieh


明日11月８日18時半〜 HBase　Meetupを開催します。ぜひご参加ください！

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

Technology

latest logs wins

higher reliability acked

row key roles

row key info

rdbms hbase byte

report purple

apache hbase

acked nacked