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