MapR M7 技術概要

1 ©MapR Technologies

MapR M7 技術概要 M. C. Srivas

CTO/Founder, MapR


MapR: データセンターの完全自動化へ

•  自動フェールオーバー

•  自動再レプリケーション

•  ハードウェアおよびソフトウェア障害からの自律回復

•  負荷分散

•  ローリングアップグレード

•  ジョブやデータの損失なし

•  99.999% の稼働時間

高信頼処理高信頼ストレージ

•  スナップショットおよびミラーによる事業継続

•  ポイントインタイムの復旧 •  エンドツーエンドチェックサム •  強い一貫性 •  ビルトイン圧縮 •  RTO ポリシーに基づく拠点間ミラー


MapR の MapReduce 性能 (速い)

TeraSort 記録 1 TB を 54 秒

1003 ノード

MinuteSort 記録 1.5 TB を 59 秒

2103 ノード


MapR の MapReduce 性能 (より速い)

TeraSort 記録 1 TB を 54 秒

1003 ノード

MinuteSort 記録 1.5 TB を 59 秒

2103 ノード 1.65

300


Dynamo DB

ZopeDB

Shoal

CloudKit

Vertex DB

FlockDB

NoSQL


HBase テーブルアーキテクチャ §  テーブルは Key 範囲で分割される (Region) §  Region は各ノードが管理 (RegionServer) §  カラムはアクセスグループに分割される (カラムファミリー)

CF1 CF2 CF3 CF4 CF5

R1

R2

R3

R4


HBase アーキテクチャが優れている点

§  強い一貫性モデル – 書き込み完了後、すべての読み出しは同じ値になることを保証 – 他のNoSQLの「Eventually Consistent」は、実際にはときどき

「Eventually Inconsistent」に

§  効率の良いスキャン – ブロードキャストを行わない –  Ring ベースの NoSQL データベース (例: Cassandra, Riak) はスキャン

が大変

§  自動的にスケール –  Regionが大きくなると自動で分割される – データ分散や格納スペースの管理に HDFS を利用

§  Hadoop との連携 –  HBase のデータを MapReduce で直接処理できる


MapR M7 非構造化データおよび構造化データ

のための統合システム


MapR M7 テーブル

§  Apache HBase とバイナリ互換 – M7 テーブルへのアクセスには再コンパイル不要 –  CLASSPATH を設定するだけ –  HBase コマンドラインインターフェースを含む

§  パス名の指定で M7 テーブルにアクセス –  openTable( “hello”) … HBase を使用 –  openTable( “/hello”) … M7 を使用 –  openTable( “/user/srivas/hello”) … M7 を使用


バイナリ互換

§  HBase アプリケーションは M7 でも「変更なしで」動作 – 再コンパイル不要、CLASSPATH を設定するだけ

§  M7 と HBase を単一クラスタで同時に稼働できる – 例: 移行期間中 – 同じプログラムで M7 テーブルと HBase テーブルの両方にアクセス可

能

§  標準の Apache HBase CopyTable ツールを使用して、HBase から M7 にテーブルをコピー（逆も可） % hbase org.apache.hadoop.hbase.mapreduce.CopyTable -‐-‐new.name=/user/srivas/mytable oldtable


特徴

§  テーブル数の制限なし –  HBase は一般的に 10〜20 程度 (最大でも 100)

§  コンパクションなし §  即時起動 – 復旧時間ゼロ

§  8倍の挿入/更新性能 §  10倍のランダムスキャン性能 §  Flash の活用で10倍の性能 -‐ Flash の特別サポート


M7: レイヤーを削除してシンプルに

MapR M7


MapR クラスタ内の M7 テーブル

§  M7 テーブルはストレージに統合されている – いつでも、どのノードでも利用可能 – 別のプロセスを起動・監視する必要なし – 管理不要 – チューニングパラメータなし … そのまま動く

§  M7 テーブルは「期待通りに」動く – 一つ目のコピーは書き込みクライアント自身の場所に – スナップショットやミラーを適用可能 – クォータ、レプリケーション数、データ配置の指定が可能


ファイルとテーブルの名前空間の統合

$ pwd /mapr/default/user/dave $ ls file1 file2 table1 table2 $ hbase shell hbase(main):003:0> create '/user/dave/table3', 'cf1', 'cf2', 'cf3' 0 row(s) in 0.1570 seconds $ ls file1 file2 table1 table2 table3 $ hadoop fs -‐ls /user/dave Found 5 items -‐rw-‐r-‐-‐r-‐-‐ 3 mapr mapr 16 2012-‐09-‐28 08:34 /user/dave/file1 -‐rw-‐r-‐-‐r-‐-‐ 3 mapr mapr 22 2012-‐09-‐28 08:34 /user/dave/file2 trwxr-‐xr-‐x 3 mapr mapr 2 2012-‐09-‐28 08:32 /user/dave/table1 trwxr-‐xr-‐x 3 mapr mapr 2 2012-‐09-‐28 08:33 /user/dave/table2 trwxr-‐xr-‐x 3 mapr mapr 2 2012-‐09-‐28 08:38 /user/dave/table3


M7 – 統合されたシステム


エンドユーザーから見たテーブル

§  ユーザーは自分のテーブルを作成・管理できる – テーブル数の制限がないから – 一つ目のコピーは自分の場所に

§  テーブルはどのディレクトリにも作成できる – テーブルはボリュームの管理下になり、ユーザークォータの計算

対象になる

§  管理者の介在は不要 – 処理は即時に行われ、サーバの停止・再開は不要

§  自動データ保護とディザスタリカバリ – ユーザーは自分のスナップショット/ミラーから復旧可能


M7 は LSM と BTree の良い部分を結合 §  LSM Tree はインデックス更新を後に引き延ばしてまとめて行うことで挿

入コストを削減 –  コンパクションの頻度が低いと Read 性能に影響 –  コンパクションの頻度が高いと Write 性能に影響

§  B-‐Trees は Read に最適 –  ただしリアルタイムでの更新の負荷が大きい

Index Log

Index

Memory Disk

Write

Read

両方のアイデアを結合できないか? Write は W = 2.5倍より改善できない

ログ書き出し + データの書き出し + メタデータ更新


MapR M7 §  改良 BTree – リーフは可変サイズ (8KB〜8MB もしくはそれ以上) – 長期間アンバランスである事を許容 •  挿入の繰り返しにより最終的にバランスが取れる •  内部 BTree ノードに対する更新を自動的に調整

– M7 はデータが格納されるべき「おおよその」場所に挿入される

§  Read –  BTree 構造を利用して「近くまで」非常に高速に到達 •  非常に高いブランチングとKey プリフィックス圧縮

– 別の低いレベルのインデックスを利用して正確な場所を確定 •  Get には「直接更新される」Bloom フィルタ, Scan にはRange Map

§  オーバーヘッド –  1KB レコードの Read では、logN 回のシークで約 32KB のディスクか

らの転送が行われる


M7 Apache HBase, Level-‐DB, BTree

の比較分析


Apache HBase HFile の構造

64Kバイトブロックが圧縮される

圧縮ブロックに対するインデックスが btree として構築される

Key-‐Value ペアが昇順で並ぶ

各セルは個別の Key + Value -‐ 行の中では各カラム毎に Key が繰り返し現れる


HBase Region オペレーション

§  典型的な Region サイズは数 GB、ときどき 10GB〜20GB §  RS はフルになるまでデータをメモリに保持し、新しい HFile

に書き出す –  HFileの階層で構成されるデータベースの論理ビュー

（新しいものが一番上）

この Region が格納する Key の範囲

新しい

古い


HBase Read アンプリフィケーション §  Get/Scan を行う際、すべてのファイルを調べる必要がある – スキーマレスなので、どこにカラムがあるのか? – インメモリで行われ、ディスク上のデータへの変更はない •  Bloom フィルタは Scan には役立たない

新しい

古い

7 つのファイルでは、 1KB レコードの get () で約 30 回のシークと 7 ブロックの展開、 HDFS から合計約 130KB のデータ転送が行われる計算


HBase Write アンプリフィケーション

§  Read アンプリフィケーションを減らすため、HBase は HFile を定期的にマージする – いわゆるコンパクション処理 – ファイルの数が大きくなると自動的に処理が起動 –  I/O ストームの原因となるため通常はオフにするケースが多い – 週末に手動で走らせておく

コンパクションはすべてのファイルを読み単一の HFile にマージする


HBase コンパクションの分析

§  Region あたり 10GB、1日で10%を更新、1週間で10%増加、を仮定 –  1GB の Write –  7日後、1GB のファイルが 7 つと 10GB のファイルが 1 つ

§  コンパクション –  Read 合計: 17GB (= 7 x 1GB + 1 x 10GB) – Write 合計: 25GB (= 7GB WAL + 7GB 書き出し + 11GB 新しい HFile へ

の Write)

§  500 Region では –  8.5TB の Read、12.5TB の Write è ノードの長時間の停止 –  HFile の数が少なくなれば、より状況は悪化

§  ベストプラクティスは、ノードあたり 500GB 未満にすること (50 Region)


Level-‐DB

§  階層化され、対数的に増加 –  L1: 2 x 1MB ファイル –  L2: 10 x 1MB –  L3: 100 x 1MB –  L4: 1,000 x 1MB, など

§  コンパクションのオーバーヘッド –  I/O ストームの回避 (10MB 未満の細かい単位で I/O 処理) – しかし、HBase と比較して非常に大きな帯域を必要とする

§  Read オーバーヘッドは依然大きい –  10〜15 シーク、最下層のサイズが非常に大きい場合はそれ以上 –  1KB レコードを取得するために 40KB〜60KB のディスクからの Read


BTree の分析 §  Read は直接データを発見、最速であることは証明済み – 内部ノードは Key のみを保持 – 非常に大きなブランチングファクター –  Value はリーフのみに存在 – このためキャッシュが有効に機能する – キャッシュがない場合、R = logN シーク –  1KB レコードの Read で logN ブロックのディスクからの転送

§  Write は挿入処理を伴い、遅い – 即時に正しい位置に挿入される – さもなければ Read で発見できないため –  BTree の継続的なリバランスが要求される – 挿入パスにおいて激しいランダム I/O を引き起こす – キャッシュがない場合、W = 2.5倍 + logN シーク


1K レコード -‐read amplificaKon

コンパクションリカバリ

HBase (7 つの hfile) 30 シーク 130KB 転送

I/O ストームある程度の帯域使用

巨大な WAL の復旧

HBase (3 つの hfile) 15 シーク 70KB 転送

I/O ストーム大きな帯域使用

巨大な WAL の復旧

LevelDB (5 レベル) 13 シーク 48KB 転送

I/O ストームなし非常に大きな帯域使用

非常に小さい WAL

BTree logN シーク logN 転送

I/O ストームなしただし 100% ランダム

WAL は同時実行数 + キャッシュに比例

MapR M7 logN シーク 32KB 転送

I/O ストームなし小さな帯域使用

microWAL により 100ms 未満の復旧

まとめ

確認のためにいくつかの性能値を見てみる


M7 vs. CDH: 50-‐50 Mix (Read)


M7 vs. CDH: 50-‐50 Mix (Read レイテンシ)


M7 vs. CDH: 50-‐50 Mix (Update)


M7 vs. CDH: 50-‐50 Mix (Update レイテンシ)


MapR M7によるHBaseアプリケーションの高速化

ベンチマーク MapR 3.0.1 (M7)

CDH 4.3.0 (HBase)

MapR 性能比

50% Read, 50% Update

8000 1695 5.5倍

95% Read, 5% Update

3716 602 6倍

Read 5520 764 7.2倍

スキャン (50 行)

1080 156 6.9倍

CPU: 2 x Intel Xeon CPU E5645 2.40GHz 12 コア RAM: 48GB ディスク: 12 x 3TB (7200 RPM) レコードサイズ: 1KB データサイズ: 2TB OS: CentOS Release 6.2 (Final)


CDH 4.3.0 (HBase)

MapR 性能比


21328 2547 8.4倍

95% Read, 5% update

13455 2660 5倍

Read 18206 1605 11.3倍


1298 116 11.2倍

CPU: 2 x Intel Xeon CPU E5620 2.40GHz 8 コア RAM: 24GB ディスク: 1 x 1.2TB Fusion I/O ioDrive2 レコードサイズ: 1KB データサイズ: 600GB OS: CentOS Release 6.3 (Final)

HDD 使用時の MapR の性能: 5-‐7 倍 SSD 使用時の MapR の性能: 5-‐11.3 倍


M7: Fileserver が Region を管理

§  Region は全体がコンテナ内部に格納される –  ZooKeeper によるコーディネーションは行われない

§  コンテナが分散トランザクションをサポート – レプリケーションも行われる

§  システム内で行われるコーディネーションは分割のみ –  Region マップとデータコンテナ間での調整 – ファイルとデータチャンクの扱いにおいて既にこの課題は解決済

み


サーバーの再起動

§  コンテナレポートは全部合わせてもごくわずか – 1,000 ノードのクラスタで CLDB が必要とする DRAM は 2GB

§  ボリュームはすぐにオンラインになる – 各ボリュームは他ボリュームから独立に管理 – コンテナの最小レプリカ数を満たせばすぐにオンラインに




§  ボリュームはすぐにオンラインになる – 各ボリュームは他ボリュームから独立に管理 – コンテナの最小レプリカ数を満たせばすぐにオンラインに – クラスタ全体を待たない (例: HDFS は 99.9% のブロックレポートが上がるのを待つ)




§  ボリュームはすぐにオンラインになる – 各ボリュームは他ボリュームから独立に管理 – コンテナの最小レプリカ数を満たせばすぐにオンラインに – クラスタ全体を待たない (例: HDFS は 99.9% のブロックレポートが上がるのを待つ)

§  1,000 ノードのクラスタは 5 分以内に再起動


M7 の即時復旧

§  Region 毎に 0〜40 個の microWAL – アイドル状態の WAL はすぐにゼロになるため、ほとんどは空 – すべての microWAL の復旧を待たずに Region が起動 –  Region の復旧はバックグラウンドで並列処理 –  Key へのアクセスがあると、対象の microWAL はインラインで復旧

される –  1000〜10000倍の速さで復旧


M7 の即時復旧

§  Region 毎に 0〜40 個の microWAL – アイドル状態の WAL はすぐにゼロになるため、ほとんどは空 – すべての microWAL の復旧を待たずに Region が起動 –  Region の復旧はバックグラウンドで並列処理 –  Key へのアクセスがあると、対象の microWAL はインラインで復旧

される –  1000〜10000倍の速さで復旧

§  なぜ HBase ではできなくて、M7ではできるのか？ – M7 はMapR ファイルシステムのユニークな機能を活用しており、HDFS の様々な制約の影響を受けない

– ディスク上のファイル数の上限がない – オープンできるファイル数の上限がない –  I/O パスがランダム Write をディスクに対するシーケンシャル Write に変換する


MapR M7によるHBaseアプリケーションの高速化


CDH 4.3.0 (HBase)

MapR 性能比


8000 1695 5.5倍

95% Read, 5% Update

3716 602 6倍

Read 5520 764 7.2倍


1080 156 6.9倍

CPU: 2 x Intel Xeon CPU E5645 2.40GHz 12 コア RAM: 48GB ディスク: 12 x 3TB (7200 RPM) レコードサイズ: 1KB データサイズ: 2TB OS: CentOS Release 6.2 (Final)


CDH 4.3.0 (HBase)

MapR 性能比


21328 2547 8.4倍

95% Read, 5% update

13455 2660 5倍

Read 18206 1605 11.3倍


1298 116 11.2倍

CPU: 2 x Intel Xeon CPU E5620 2.40GHz 8 コア RAM: 24GB ディスク: 1 x 1.2TB Fusion I/O ioDrive2 レコードサイズ: 1KB データサイズ: 600GB OS: CentOS Release 6.3 (Final)

HDD 使用時の MapR の性能: 5-‐7 倍 SSD 使用時の MapR の性能: 5-‐11.3 倍

Technology

MapR M7 技術概要