Apache HBase 入門 (第２回)

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

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

2010年6月28日月曜日

[ ]自己紹介 Twitter: @tatsuya6502

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

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

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

HBase エバンジェリスト！


[ ]内容HBase の基本動作 ̶ write と read

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

HBase 0.89　開発者向けリリース

スライドの置き場所

今回　第２回 http://bit.ly/9lKtYM

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


[ ]復習：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


[ ]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 されたデータは Region Server (RS) のメモリー (MemStore) にバッファリングされる

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

key: 行キー + カラム名 + タイムスタンプvalue: データ（byte配列）key順にソートし、ブロックごと (64KB) に圧縮ブロックインデックスと bloom filter も保存される

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


[ ]HBase：コミットログRS が故障すると、MemStore に入っていた flush 前のデータが失われてしまう

そこで、

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

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

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


[ ]MemStore を flush するたびに HFile の世代が増える

HBase：read の動作

C2

R1:C1 R1:C1 R1:C1

R1:C2 R1:C2

MemStore HFile ５世代

R1:C2

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

C1R1


[ ]HBase：write性能 > read性能

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

ブロックインデックスと bloom filter をあらかじめメモリーに読み込んでおき、アクセスを効率化している

↑bloom filter の働きにより　この HFile をスキップできる

R1:C1 R1:C1 R1:C1

R1:C2 R1:C2

MemStore HFile ５世代

R1:C2


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

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

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

ノード故障時

write / read が中断しない

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

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

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

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

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


[ ]HBase: C > A

ノード故障時

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

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

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

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

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

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


[ ]SPOFの有無、マスターの有無SPOF（単一故障点）

Cassandra には、SPOF は存在しない

HBase では、HDFS Name Node が SPOF

マスターノード

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

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

故障への耐性は Cassandra > HBase


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

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

状況に応じた、最短のリカバリー手順が求められる

ring にアサインされた token の扱い。ノードをすぐに復活させるか？そのままリタイアするか？別のマシンで置き換えるか？

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


[ ]Cassandra：故障したノードの扱いノード故障の時は、早めに復旧させる必要がある

故障している間は、一貫性強度が制限される既存データのレプリカ数が減ったままになる

故障したノード60 をリタイアさせる場合、区間Aのデータの引き継ぎ先は、隣接するノード80 になる単純に removetoken すると負荷のバランスが狂う新しいノードを token フリーで追加してそちらに引っ越す、または、

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

80

2040

00

60

A

B


[ ]ノード故障時の挙動：HBaseノードの故障を透過的に扱う

自動フェイルオーバー

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

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

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

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


[ ]ノード故障時の挙動：HBase（続き）RS、DNどちらの故障でも、復元先は複数のノードとなり負荷がクラスター全体に分配されるこれらの復元の動作は、マスター（HBase Master または HDFS Name Node）が制御する

[00 - 05)

[00 - 05)

[25 - 30)

[60 - 65)

[90 - 95)

[90 - 95)

[25 - 30)

[60 - 65)

RS1 故障 RS2 RS4 RS5RS3


[ ]ノード故障時の挙動：HBase（続き）大規模クラスターではノード故障が日常的に起こる

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

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

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

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


[ ]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での利用事例つぶやき本文（タイムライン）

大量の write。絶対的な可用性

MySQL から Cassandra に移行中


[ ]Twitterでの利用事例(続き)分析プラットフォーム。大量のデータ(7TB/日) の分析

つぶやき本文は全体の 0.5%

残りの 99.5% は

数千台のサーバーのログHTTPD、Rails W3C, JSON, Protobufs

DBテーブルユーザー情報、位置情報、トレンド、モバイル端末

現状、Hadoop MR と Pig。一部の MR で HBase 使用

今後、Pigのデータストアとして、HBase を活用予定


[ ]HBase 0.89 開発者向けリリース


[ ]HBase 0.89.20100621 が 2010年6月26日に公開された

0.89 開発者向けリリースとは？

今年リリース予定の HBase 0.90 を事前に検証するためのリリース

今後、定期的にリリースされる

バグを含んでいる可能性がある。リリース前に簡単なテストはしているので、検証目的には十分使えるレベル

変更点については、配布物に含まれる CHANGES.txt

既知のバグについては、 KNOWN-BUGS.txt

HBase 0.89 開発者向けリリース


[ ]Hadoop 0.20 と 0.21 に対応

HDFSの性能改善のための様々なパッチ

コミットログの完全性サポート

クラスター間レプリケーションの事前お試し版

大幅に増強された hbase shell

HBase 0.89 のハイライト


[ ]新機能、改良点（主なもの）

HBASE-2294 ACID属性の整理

HBASE-1200 Bloom filters の再実装

HBASE-1923 既存テーブルへの MRバルクインポート

HBASE-1901 MRインポート用の汎用パーティショナ

HBASE-1537 行の内部スキャン

HBASE-2579 アトミックな checkAndDelete

HBASE-2438 ページング・フィルタ

HBase 0.89 のハイライト（続き）


[ ]新機能、改良点（主なもの）

HBASE-2473 create table 操作で、任意の数のリージョンを作成

HBASE-2400 Avro RPC アクセス用の新コネクター

バグ修正（主なもの）

HBASE-2774 YCSB実行時、リージョンの初回 flush に異常に時間がかかる（ReadWriteConsistencyControl から抜け出せない）

その他、たくさんのバグ修正

HBase 0.89 のハイライト（続き）


[ ]HBase 0.90今年リリース予定

いままで、HBase 0.21 と呼んでいた trunk コードのこと

HBase のビッグユーザー４社（社名は非公開）は、すでに、このバージョンをターゲットに開発・テスト中

HBase 0.89.20100621 ＋おそらく以下の機能

Masterの再実装。より多くの責務を ZooKeeper へhttp://wiki.apache.org/hadoop/Hbase/MasterRewrite

クラスター間レプリケーションの最終版


http://wiki.apache.org/hadoop/Hbase/MasterRewrite

http://wiki.apache.org/hadoop/Hbase/MasterRewrite

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

新機能についてはまだ未定

HBASE-1697 アクセス制御？

HBASE-1002 簡易クエリ言語？独自言語？ or JavaScript (Rhino) .filter？

パフォーマンスや安定性の改善

Get、Put、Delete操作のパラレル実行など

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/

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


Technology

Apache HBase 入門 (第２回)