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

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

[ ]自己紹介 Twitter: @tatsuya6502

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

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

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

HBase エバンジェリスト！

[ ]内容

HBaseの特徴

ユースケース（ユーザー事例）

次回以降【６月】HBase と Cassandra ̶ トレードオフを理解する【７月】はまりやすい落とし穴【７月】ロードマップ

[ ]HBaseとは？Hadoop データベース

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

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

Google Bigtableを参考に設計された

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

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

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

[ ]Big Dataへの道のり

あなたは、MySQLを使いこなして、1,000万件のウェブテーブルを提供することに成功しました

もちろん、ビジネスは大成功！

ウェブAPサーバーを数台追加したところreadとwriteがもの凄いペースで行われるようになった

テーブルはどんどん膨れ上がり、やがて1億件に（10倍）

[ ]10倍 ‒ 便利な機能を切り捨てる大量 read ̶ memcached を採用。データの一貫性を失った

大量 write ̶ 二次インデックスを廃止した

クエリプランの改善を試みるが、いうことを聞かず

テーブルの結合(join) に負荷が集中。非正規化を行いリレーションを廃止した

何とか乗り切ることができた！しかし、もし、10億件（元の100倍）に達したら？

[ ]100倍 ‒ シャーディング

データベースサーバーを増やして対応する

テーブルを N個に分割（例、N = 10）

N x 2 ノード（20ノード）の MySQL クラスターを構築。個々のパーティションを、それぞれのノードに割り当てる

これにより、ACID属性が失われた

そして最後は、５倍の大きさ（元の500倍）に達した

[ ]500倍 ‒ 【再】シャーディング！10 x 5 x 2 = 100 ノードの新しい MySQL クラスターを構築

50億レコードを再移行

ダウンタイム？ ̶ どのくらいの時間、停止するか？

[ ]もう、お手上げかも...

50億件のテーブルで、カラムの追加・削除・変更をしたい？ダウンタイム？

100ノードあると、故障の頻度は？

[ ]HBaseの出番自動シャーディング

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

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

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

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

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

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

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

[ ]自動シャーディングテーブルは、リージョンという単位に自動的に分割される

リージョンは、リージョンサーバー(RS) と呼ばれるワーカーノードにランダムに割り当てられる

１台のRSに、数十～数百のリージョンが載る

リージョンが大きくなると、自動的に再分割される

RSを何台か追加することで、より高い負荷に対応できる。 HBaseは、数千台のRSでもリニアにスケールする(Bigtableで 1000 TB 超の実績あり)

[ ]自動シャーディング (続き)

[ ]柔軟性のあるテーブル構造行(row) を書き込むとき、自由にカラムを追加できる

不在のカラム (値が NULL のカラム) はディスクスペースを消費しない

カラムのデータ型は Byte配列

Avro、Protobuf、MessagePackなどを使えば１つのカラムに複数の値を格納できる

非正規化したテーブルの格納に最適

本当の意味のインデックスを持たない。行はキー順に格納

DIY: 追加テーブルで、二次インデックスが実現できる

[ ]単純化されたクエリHBase は SQL に対応していない

Put: 行の追加または更新

Get: 行の取得

Scanner + サーバー側 Filter: 指定した範囲の一連の行を取得

Delete: 行の削除

結合(join) や group by は用意されていない

DIY: テーブルの非正規化で対応できる。MR と Cascading で事前に非正規化

[ ]強い一貫性 (strong consistency)行に関する操作はアトミック

更新前の古いデータが見えることはない

CAS (Check and Save) 操作

checkAndPut(row, cf, qual, oldValue, newValues)ユニーク値制約（例、emailの重複不可）

楽観的ロック（optimistic locking）

incrementColumnValue(row, cf, qual, incr)カウンターや連番

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

HBase Region Server と HDFS Data Node の統計情報をモニタリング可能：Ganglia、JMX、ウェブコンソール

hbase shell 経由で様々なメンテナンス操作が可能

[ ]HBase クライアントAPIネイティブ Java API

もちろん他の JVM 言語も利用可能 Closure、Scala、JRuby など

ゲートウェイアクセス

Thrift　PHP、Python、C++ など

REST　JSON, XML, Protbuf、　　　　バイナリーエンコーディングなどをサポート

ゲートウェイアクセスでは、大きなレイテンシは見られないが、大量の write / read ではおすすめしない

[ ]パフォーマンス特性Random Write: 驚異的！Sequential Read: 優秀！HTable#setScannerCaching(n) を大きくする

Sequential Write: いまいち負荷を分散する代わりに、１台のRSに負荷を集中させている状態レコードの順序をシャッフルするか、行キーにランダムな要素を加える（例、後半にハッシュ値を付ける）

Random Read: 悪い (特にベンチマーク)ディスクドライブを追加するLRU ブロックキャッシュのサイズを大きくする

[ ]ユースケース

[ ]巨大データベースでオンラインアクセスとMRバッチを同時処理数十億を超える行を格納

無数のクライアントからのオンラインCURD操作

MRバッチ処理を継続的に実行し、データのインポートや分析を実施

[ ]Big Dataに対するMRバッチMRバッチを実行してキーワードインデックスや全文検索用インデックスを作成リコメンデーションを算出様々なレポートや、OLAP Cubeなどを生成

[ ]Big Dataに対するMRバッチ (続き)MRバッチの実行時、ウェブクライアントのレスポンスを悪化させる心配をあまりしなくてよい夜間バッチに制限しなくてよい。頻度を増やして、ほぼリアルタイムな処理も可能ただし、十分な台数のディスクが必要 (１ノード 4～12台)I/Oが非常にヘビーな MRバッチでは、ウェブクライアントのレスポンスに影響を与えることもある

[ ]StumbleUpon “Su.pr”Su.pr はコンテンツのリコメンデーションエンジンを備えた唯一の短縮 URL サービス

リアルタイムの分析処理はウェブからのデータ更新時に実行

さらに深い分析では Cascading と MR バッチを使用

[ ]Su.pr ウェブアクセスThriftゲートウェイを使用し、PHPコードから HBaseにアクセス

HBaseの組み込みキャッシュのみで運用

これにより、強い一貫性(strong consistency) が保てる

memcachedなどを使うと、キャッシュした値の無効化に気を遣う必要がある

[ ]Su.pr ‒ 巨大なデータを格納90億行、1.3 TB のデータを HBase に格納

700 GBのテーブルを、約20分で MR できる

毎秒 600万行

[ ]Socorro では 週250万件の Firefox クラッシュレポートを受信

１日あたり 350 GB のデータが登録される

現行システムでは、そのうちの 15%しか処理できない

NSF: 単一ノードであることがボトルネックになり、バッチ処理がスケールしない

RDB: この規模のデータを格納することは非現実的

Socorro: Mozillaクラッシュレポート

[ ]Socorro: HBase ＆ MRへ移行現在、HBase と MR による新しいシステムへ移行中

全てのクラッシュレポートは、すでに HBase にも格納されている

2010年の第２四半期（6月の終わり）までにクラッシュレポートの MRによる分析処理を開始

これにより、全てのクラッシュが分析可能に

将来はさらに複雑な分析をする方向で検討中

全文検索、faceted search (多面的・横断検索)、“クラッシュの爆発的増加” の発見など

[ ]MRバッチの能力を拡張するHBaseをデータソースに設定し、HDFSでは不可能な処理を実現HDFSファイルでは書き込みは１度きり。ファイルの一部を書き換えたりできないインデックスがないので、キーによるランダムなルックアップができない

[ ]MRバッチの能力を拡張する (続き)

HBaseで解決できるTwitterでは、People Searchの下準備としてHBase上のデータソースのカウンター値を更新しながらMRを実行Yahoo! では、文書の重複検出を行うためにHBase と MRを活用。ほぼリアルタイムで処理

[ ] Pig や Hive との統合HBaseを直接使うのではなく、Pig や Hiveの性能を向上させるため、縁の下の力持ちとして活用Twitter ̶ Pig と HBaseの統合を開発中１日に 7 TB のデータが発生１日あたり20,000ジョブを実行ちなみに、全データでツィートが占める割合は 0.5%すでに、MR から HBase を使っているが、現在、Pig から使えるよう開発中

[ ] Pig や Hive との統合 (続き)Facebook ̶ Hive と HBaseの統合を開発中現状は、2,000台の Hadoop MR/HDFSクラスタで運用2009年の終わりには、１日に12 TB のデータが発生１日あたり7,500ジョブを実行200人を超えるユーザー。最新データですぐ結果がほしい

Hive + HBase の統合機能を、20ノードクラスター6 TB のデータでテスト中

低レイテンシなウェアハウスの実現へ！

[ ]その他のユーザーAdobe Systems

Meetup

Ning, SNS SaaS

Karooga, Photo Album Discovery

HBase PoweredByページhttp://wiki.apache.org/hadoop/Hbase/PoweredBy

[ ]なぜ Big Dataなのか？Twitter、Facebook、Yahoo! が大量データを扱うのは当然。私たちの業務には大げさでは？

いままで、コストの面から保存できず、捨てていたデータはないだろうか？

例：過去10年の小売り情報

Hadoopの登場によって、データを保管したり、Pig や Hiveによるアドホックな分析が実現できる時代になった

まず、データを貯めることから始めてみる

MRで分析し、その結果を HBase で社内提供してもよい

[ ]困ったとき、質問は

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

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

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

エバンジェリスト氏に直接質問もOK（お気軽にどうぞ）http://twitter.com/tatsuya6502

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