apache hbase 入門 (第２回) ドラフト第１版

ドラフト版

Apache HBase 入門 (第２回）“Big Data”のための Hadoop データベース

by Tatsuya Kawano <http://twitter.com/tatsuya6502>Hadoop ソースコードリーディング東京, #3, 2010年6月28日

2010年6月27日日曜日

[ ]ドラフト版自己紹介 Twitter: @tatsuya6502

証券会社のグローバル IT部門に勤務シニア Java / Scala デベロッパー

個人研究として、2009年秋から HBase を評価中

グラフィックデザイナーでもあるニューヨークの美大 Pratt Institute を卒業し数年間、現地アメリカ企業に勤務

HBase エバンジェリスト！


[ ]ドラフト版内容

HBase の基本アーキテクチャ

HBase と Cassandra ̶ トレードオフを理解する

HBase 0.89　開発者向けリリース

スライドの置き場所

今回　第２回 http://　

前回　第１回 http://bit.ly/bvDcOa


[ ]ドラフト版復習：HBaseとは？

Hadoop データベース

ランダムアクセス、シーケンシャルアクセス共に低レイテンシで行えるデータストア

Hadoop 分散ファイルシステム（HDFS）上に構築

Google Bigtableを参考に設計された

柔軟なテーブル構造、カラムファミリー指向

Bigtable と HBase の主なターゲットは “big data”

リアルタイムのウェブと、Map Reduce (MR) 処理の両方に対応可能。HBase では、これらを同時に扱える


[ ]ドラフト版復習：HBaseの特徴

自動シャーディング

柔軟性のあるテーブル構造

インデックスを持たない。行(row) はキー順に格納される

単純化されたクエリ。SQLはサポートしない

Hadoop Map Reduce (MR) をネイティブにサポート

強い一貫性(strong consistency) と CAS操作

高可用性 (HA) ̶ 故障を優雅に扱う

クラスターのモニタリングと管理機能


[ ]ドラフト版

HBaseの基本アーキテクチャ


[ ]ドラフト版write性能と read性能のトレードオフ

MySQL： read 性能 > write 性能

HBase： read 性能 < write 性能


[ ]ドラフト版従来のRDB：read 性能を重視

更新頻度が低く、参照頻度が高いことを想定

insertでは、行を組み立ててから HDD に保存する

updeteでは、HDD上の該当部分を書き換えるか行全体を新しい領域にコピーする

read性能 > write性能

write（insert / update）では、HDDのランダム read とランダム write を何度も行う


[ ]ドラフト版HBase：write の動作

クライアントから write されたデータは RS のメモリー (MemStore) にバッファリングされる

MemStore が指定したサイズ (64MB～)に達したら HFile としてディスクへ書き出し (flush動作)

key: 行キー + カラム名 + タイムスタンプ

value: データ（byte配列）

key順にソートし、ブロックごと (64KB) に圧縮

ブロックインデックスと bloom filter も保存される

シーケンシャル write のため高速、しかも、非同期


[ ]ドラフト版HBase：コミットログ

flush前に障害が起こると、バッファリングされていたデータが失われてしまう

そこで、

コミットログ（別名 WAL）を HDFS の３つのノードに記録する

ログは HDFS Data Node のメモリーにバッファリングされるため、書き込みは高速

RS がダウンすると、コミットログから HFile を復元する


[ ]ドラフト版

flushするたびにファイル (HFile) の世代が増える

HBase：read の動作

C2

C1 C1 C1

C2 C2

MemStore HFiles ５世代

C2

MemStore から、行に関係する key-value を探し出す

一連の HFile 世代から、行に関係する key-value を探し出す見つかった key-value から行を再構築する

C1


[ ]ドラフト版HBase：write性能 > read性能

read では、HFile 各世代のランダム read が発生するため低速

ブロックインデックスと bloom filter をメモリーに読み込み、アクセスを効率化している

C1 C1 C1

C2 C2

MemStore HFiles

C2

↑この HFile をスキップ


[ ]ドラフト版なぜ write 性能優先なのか？従来の設計では write がボトルネックになりやすいwriteでは、HDDの read / write 両方のランダムアクセスが発生

Yahoo! Cloud Serving Benchmark Report v4.4 http://research.yahoo.com/node/32022010年6月27日日曜日

[ ]ドラフト版read 性能の改善

read 性能はクラスター環境ならチューニングしやすい

ランダムアクセスの高速化：高速 HDD x 台数（SSDも有効だが高価）LRU ブロックキャッシュの拡大：クラスター全体の RAM 容量を増やす Scanによる先読みを促す：キーを scan操作に合わせて設計する無駄なアクセスをなくす：bloom filter を設定する（0.89、0.90 で再実装）HFile をひとつにまとめる：メジャーコンパクション（ディフォルトで24時間に１回）


[ ]ドラフト版

HBaseとCassandra


[ ]ドラフト版設計上のトレードオフを理解する

Apache HBase と Apache Cassandra

共に Apache のトップレベルプロジェクト(TLP)

共にカラムファミリー指向

共に高いスケーラビリティと可用性を備えた分散データストア

しかし、二者の性格は大きく異なる

どちらが優れているということではない。トレードオフを理解する必要がある


[ ]ドラフト版設計上のトレードオフ

共通点

write性能 > read性能

違いが見られる点

一貫性(C) 対可用性(A)

ノード故障時の挙動：明示的対透過的

SPOFの有無、マスターの有無

Hadoop Map Reduce (MR)との親和性


[ ]ドラフト版Cassandraの基本設計

メモリー上にレプリカを持つ

Consistent Hashing

同一行に対する write / readを、複数ノードで平行処理

競合(一貫性の問題) は後で解決


[ ]ドラフト版HBaseの基本設計

RSのメモリー上にレプリカを持たずHDFS上にレプリカを格納

自動シャーディング

同一行に対する write / read を単一ノードで処理

そのリージョンを担当している RS が単独で行うので競合の解決自体が不要


[ ]ドラフト版Cassandra: C < A

ノード故障時

writes / reads が中断しない

ネットワーク障害でクラスターが２つの島に分断されると

それぞれの島がそのまま稼働できる

一方で、一貫性の強度が落ちる

低い強度でリトライ？ or ユーザーにエラーを返す？

競合(一貫性の問題) はネットワーク回復後に解決


[ ]ドラフト版HBase: C > A

ノード故障時

故障した RS に割り当てられていたリージョンは複数の RS にフェイルオーバーされる

該当リージョンへの write / read は待たされれる

ネットワーク障害でクラスターが２つの島に分断されると

一方の島が自動的にシャットダウンする

残りの島による処理能力も、通常時より低下する

分断のしかたによっては、全体がクラッシュする


[ ]ドラフト版ノード故障時の挙動：Cassandra

ノードの故障時の動作は、アプリケーションや運用担当者が選択する必要がある

ノード故障中の一貫性強度の扱いをどうするか？

ノードをすぐに復活させるか？そのままにするか？別のマシンで置き換えるか？

選択させることで、ノード故障だけでなくネットワーク分断に耐えられるようになる


[ ]ドラフト版Cassandra：ノードのリタイア

ノード故障は、早めに復旧させる必要がある

故障している間は、一貫性強度が制限される

既存データのレプリカ数も減ったままになる

故障したノードをリタイアさせる場合、データの引き継ぎ先は、隣接する単一のノードになる

単純にリタイアさせると、負荷のバランスが狂う

新しいノードを追加して、そちらに引っ越す、または、

残ったノード間でリバランスする


[ ]ドラフト版ノード故障時の挙動：HBase

ノードの故障を透過的に扱う

自動フェイルオーバー

クライアントでは故障は見えない

RSの故障時、担当していたリージョンは自動的に別の複数のノードに復元される

HDFS Data Node の故障時、データブロックは自動的に別の複数のノードに復元される

クライアントからの write / read 操作は復元が終わるまで待たされる


[ ]ドラフト版ノード故障時の挙動：HBase（続き）

RS、DNどちらの故障でも、復元先は複数のノードとなり負荷がクラスター全体に分散される

大規模クラスターではノード故障が日常的に起こる

故障を透過的に扱うことで、

アプリケーションのロジックの簡略化

運用担当者の負担の軽減につながる

故障した RS や DN は放っておいてかまわない


[ ]ドラフト版SPOFの有無、マスターの有無

SPOF（単一故障点）

Cassandra には、SPOF は存在しない

HBase では、HDFS Name Node が SPOF

マスターノード

Cassandra には、マスターノードは存在しない

HBase では、Master と HDFS Name Node がある

故障への耐性は Cassandra > HBase


[ ]ドラフト版Hadoop との親和性

Map Reduce サポート

HBase、Cassandra 共に API を提供

Pig、Hive サポート

HBaseでは、Pig、Hiveのビッグユーザーが直接開発

Pig: Twitter、Hive: Facebook

Cassandraでは、Pigのコントリビューションモジュールがある


[ ]ドラフト版Hadoop MRとの親和性（続き）

性能の最適化

HBase は MR の主要なアクセスパターンであるwrite とシーケンシャル read に最適化されている

Yahoo! Cloud Serving Benchmark Report v4.4 http://research.yahoo.com/node/3202


[ ]ドラフト版Hadoop MRとの親和性: HDFS

HBase では、データファイルが HDFS に格納されている

MR から、HFile を直接出力できる

HBase 0.89、0.90 以降は、オンライン中に差分を反映できる

原理上は、オンライン中の HFile の読み込みも可能

HFile の内容は不変なので、安全にアクセスできる

必要なら開発します


[ ]ドラフト版HBase の可用性について

現時点の HBase には、可用性を阻害する大きな問題がある

HDFS 0.20 の不具合による最新のコミットログの消失

HBase の最初のリリース（2008年）でバグ報告

Hadoop 0.21 に修正版がコミットされているがリリースが延期され続けている

Hadoop 0.20 に専用のブランチができたので今後はそちらが使用できる

branch-0.20-append

HBase 0.89、0.90 と一緒に配布される


[ ]ドラフト版HDFS Name Node の SPOF

OSSのクラスタリングソフトで回避は可能

DRBD + Heartbeat

将来、根本的に解決されるかははっきりしていない

個人的には、Ceph のような SPOF を持たない分散ファイルシステムに期待している


[ ]ドラフト版HBase クラスター間レプリケーション

Trend Microのコミッターが開発し、現在、テスト中

テーブル、カラムファミリー単位でレプリケーションする／しないを設定できる

非同期通信（eventual consistency）

クラスターをまたがった行ロックや CAS操作は行えない

Hadoop クラスター間の MR前後のデータ連携にも応用可能

支店 Hadoop クラスター → 本社 Hadoop クラスター

東京本社 ←→ 大阪本社クラスター間で相互バックアップ


[ ]ドラフト版商用サポートについて

Cassandra：米 Riptano社

2010年 4月サービス開始

Cassandra 開発リーダーが立ち上げた会社

HBase：米 Cloudera社（予定）

CDH3 がリリースされたらサポート対象になる

HBase コミッターが１名所属

どちらも高いレベルのサポートが期待できる

国内ベンダーによるサポートは？


[ ]ドラフト版Cassandra のまとめ

Cassandra は、ディフォルトでAを優先

データセンターをまたいだ柔軟なクラスター構成がとれるため、可用性が極めて高い

Eventual consistency でよい場合は、全てのメリットを享受できる

しかし、一貫性強度を上げようとすると、アプリケーションの負担は増える

CAS操作がない

ノードダウン時の動作を選択する必要がある


[ ]ドラフト版HBase のまとめ

HBase は、Cを優先

故障時も一貫性を維持

CAS操作がある：ユニーク値制約、カウンターなど

これらを基盤に、複数の行にまたがるトランザクションを実装できる

ノード故障は透過的にフェイルオーバーされる

Hadoop との親和性が高い：HFile の直接出力

一方で、SPOFが存在したり、ネットワーク分断に弱い


[ ]ドラフト版Twitterでの利用事例

（作成中）


[ ]ドラフト版

HBase 0.89 開発者向けリリース


[ ]ドラフト版

HBase 0.89.20100621、2010年6月26日に公開

（概要は会場で発表予定）

HBase 0.89 開発者向けリリース


[ ]ドラフト版HBase 0.90

（概要は会場で発表予定）


[ ]ドラフト版

リリース時期未定、2011年前半？

HBase Master の書き直しZooKeeperに、より多くの責務を移管

パフォーマンスや安定性の改善Get、Put、Delete操作のパラレル実行、Intra-rowスキャン、など

HBase 1.0


[ ]ドラフト版HBase コミッター

HBase コミッターは、所属する企業から給料をもらいHBase の開発に仕事として取り組んでいる

StumbleUpon：３名、San Francisco在住

Facebook １名、San Francisco在住

Trend Micro：　１名、Los Angeles在住

WorldLingo：　１名、ドイツ在住

Cloudera：　１名、San Francisco在住


[ ]ドラフト版困ったとき、質問は

HBase は、初期設定のままではうまく動かないのが普通？あきらめる前に質問してください

Hadoop ユーザー会　http://hugjp.org/

nosql-ja　http://groups.google.com/group/nosql-ja

エバンジェリスト氏に直接質問もOK（お気軽にどうぞ）

Twitter　 http://twitter.com/tatsuya6502

ブログ　　http://jp.hmaster.info/

回答内容をブログなどにまとめてもらえると嬉しいです！


apache hbase 入門 (第２回) ドラフト第１版

Technology