MapR M7 技術概要
•
6 likes•3,064 views
MapR Technologies CTO の M.C. Srivas による、MapR M7 技術概要。
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to MapR M7 技術概要
Similar to MapR M7 技術概要 (20)
More from MapR Technologies Japan
More from MapR Technologies Japan (11)
Recently uploaded
Recently uploaded (11)
MapR M7 技術概要
- 1. 1 ©MapR Technologies MapR M7 技術概要 M. C. Srivas CTO/Founder, MapR
- 2. 2 ©MapR Technologies MapR: データセンターの完全自動化へ • 自動フェールオーバー • 自動再レプリケーション • ハードウェアおよびソフトウェア障 害からの自律回復 • 負荷分散 • ローリングアップグレード • ジョブやデータの損失なし • 99.999% の稼働時間 高信頼処理 高信頼ストレージ • スナップショットおよびミラーによる 事業継続 • ポイントインタイムの復旧 • エンドツーエンドチェックサム • 強い一貫性 • ビルトイン圧縮 • RTO ポリシーに基づく拠点間ミラー
- 3. 3 ©MapR Technologies MapR の MapReduce 性能 (速い) TeraSort 記録 1 TB を 54 秒 1003 ノード MinuteSort 記録 1.5 TB を 59 秒 2103 ノード
- 4. 4 ©MapR Technologies MapR の MapReduce 性能 (より速い) TeraSort 記録 1 TB を 54 秒 1003 ノード MinuteSort 記録 1.5 TB を 59 秒 2103 ノード 1.65 300
- 5. 5 ©MapR Technologies Dynamo DB ZopeDB Shoal CloudKit Vertex DB FlockD B NoSQL
- 6. 6 ©MapR Technologies HBase テーブルアーキテクチャ § テーブルは Key 範囲で分割される (Region) § Region は各ノードが管理 (RegionServer) § カラムはアクセスグループに分割される (カラムファミリー) CF1 CF2 CF3 CF4 CF5 R1 R2 R3 R4
- 7. 7 ©MapR Technologies HBase アーキテクチャが優れている点 § 強い一貫性モデル – 書き込み完了後、すべての読み出しは同じ値になることを保証 – 他のNoSQLの「Eventually Consistent」は、実際にはときどき 「Eventually Inconsistent」に § 効率の良いスキャン – ブロードキャストを行わない – Ring ベースの NoSQL データベース (例: Cassandra, Riak) はスキャン が大変 § 自動的にスケール – Regionが大きくなると自動で分割される – データ分散や格納スペースの管理に HDFS を利用 § Hadoop との連携 – HBase のデータを MapReduce で直接処理できる
- 8. 8 ©MapR Technologies MapR M7 非構造化データおよび構造化データ のための統合システム
- 9. 9 ©MapR Technologies MapR M7 テーブル § Apache HBase とバイナリ互換 – M7 テーブルへのアクセスには再コンパイル不要 – CLASSPATH を設定するだけ – HBase コマンドラインインターフェースを含む § パス名の指定で M7 テーブルにアクセス – openTable( “hello”) … HBase を使用 – openTable( “/hello”) … M7 を使用 – openTable( “/user/srivas/hello”) … M7 を使用
- 10. 10 ©MapR Technologies バイナリ互換 § 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
- 11. 11 ©MapR Technologies 特徴 § テーブル数の制限なし – HBase は一般的に 10〜20 程度 (最大でも 100) § コンパクションなし § 即時起動 – 復旧時間ゼロ § 8倍の挿入/更新性能 § 10倍のランダムスキャン性能 § Flash の活用で10倍の性能 -‐ Flash の特別サポート
- 12. 12 ©MapR Technologies M7: レイヤーを削除してシンプルに MapR M7
- 13. 13 ©MapR Technologies MapR クラスタ内の M7 テーブル § M7 テーブルはストレージに統合されている – いつでも、どのノードでも利用可能 – 別のプロセスを起動・監視する必要なし – 管理不要 – チューニングパラメータなし … そのまま動く § M7 テーブルは 「期待通りに」動く – 一つ目のコピーは書き込みクライアント自身の場所に – スナップショットやミラーを適用可能 – クォータ、レプリケーション数、データ配置の指定が可能
- 14. 14 ©MapR Technologies ファイルとテーブルの名前空間の統合 $ 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
- 15. 15 ©MapR Technologies M7 – 統合されたシステム
- 16. 16 ©MapR Technologies エンドユーザーから見たテーブル § ユーザーは自分のテーブルを作成・管理できる – テーブル数の制限がないから – 一つ目のコピーは自分の場所に § テーブルはどのディレクトリにも作成できる – テーブルはボリュームの管理下になり、ユーザークォータの計算 対象になる § 管理者の介在は不要 – 処理は即時に行われ、サーバの停止・再開は不要 § 自動データ保護とディザスタリカバリ – ユーザーは自分のスナップショット/ミラーから復旧可能
- 17. 17 ©MapR Technologies M7 は LSM と BTree の良い部分を結合 § LSM Tree はインデックス更新を後に引き延ばしてまとめて行うことで挿 入コストを削減 – コンパクションの頻度が低いと Read 性能に影響 – コンパクションの頻度が高いと Write 性能に影響 § B-‐Trees は Read に最適 – ただしリアルタイムでの更新の負荷が大きい Index Log Index Memory Disk Write Read 両方のアイデアを結合できないか? Write は W = 2.5倍 より改善できない ログ書き出し + データの書き出し + メタデータ更新
- 18. 18 ©MapR Technologies MapR M7 § 改良 BTree – リーフは可変サイズ (8KB〜8MB もしくはそれ以上) – 長期間アンバランスである事を許容 • 挿入の繰り返しにより最終的にバランスが取れる • 内部 BTree ノードに対する更新を自動的に調整 – M7 はデータが格納されるべき「おおよその」場所に挿入される § Read – BTree 構造を利用して「近くまで」非常に高速に到達 • 非常に高いブランチングとKey プリフィックス圧縮 – 別の低いレベルのインデックスを利用して正確な場所を確定 • Get には「直接更新される」Bloom フィルタ, Scan にはRange Map § オーバーヘッド – 1KB レコードの Read では、logN 回のシークで約 32KB のディスクか らの転送が行われる
- 19. 19 ©MapR Technologies M7 Apache HBase, Level-‐DB, BTree の比較分析
- 20. 20 ©MapR Technologies Apache HBase HFile の構造 64Kバイトブロック が圧縮される 圧縮ブロックに対するイ ンデックスが btree として 構築される Key-‐Value ペアが昇順 で並ぶ 各セルは個別の Key + Value -‐ 行の中では各カラム毎に Key が繰り返し現れる
- 21. 21 ©MapR Technologies HBase Region オペレーション § 典型的な Region サイズは数 GB、ときどき 10GB〜20GB § RS はフルになるまでデータをメモリに保持し、新しい HFile に書き出す – HFileの階層で構成されるデータベースの論理ビュー （新しいものが一番上） この Region が格納する Key の範囲 新しい 古い
- 22. 22 ©MapR Technologies HBase Read アンプリフィケーション § Get/Scan を行う際、すべてのファイルを調べる必要がある – スキーマレスなので、どこにカラムがあるのか? – インメモリで行われ、ディスク上のデータへの変更はない • Bloom フィルタは Scan には役立たない 新しい 古い 7 つのファイルでは、 1KB レコードの get () で約 30 回のシークと 7 ブロックの展開、 HDFS から合計約 130KB のデータ転送が行われる計算
- 23. 23 ©MapR Technologies HBase Write アンプリフィケーション § Read アンプリフィケーションを減らすため、HBase は HFile を定期的にマージする – いわゆるコンパクション処理 – ファイルの数が大きくなると自動的に処理が起動 – I/O ストームの原因となるため通常はオフにするケースが多い – 週末に手動で走らせておく コンパクションはすべてのファイルを読み 単一の HFile にマージする
- 24. 24 ©MapR Technologies 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)
- 25. 25 ©MapR Technologies 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
- 26. 26 ©MapR Technologies BTree の分析 § Read は直接データを発見、最速であることは証明済み – 内部ノードは Key のみを保持 – 非常に大きなブランチングファクター – Value はリーフのみに存在 – このためキャッシュが有効に機能する – キャッシュがない場合、R = logN シーク – 1KB レコードの Read で logN ブロックのディスクからの転送 § Write は挿入処理を伴い、遅い – 即時に正しい位置に挿入される – さもなければ Read で発見できないため – BTree の継続的なリバランスが要求される – 挿入パスにおいて激しいランダム I/O を引き起こす – キャッシュがない場合、W = 2.5倍 + logN シーク
- 27. 27 ©MapR Technologies 1KB レコード -‐ Read アンプリ フィケーション コンパクション リカバリ 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 未満の復旧 まとめ
- 29. 29 ©MapR Technologies M7 vs. CDH: 50-‐50 Mix (Read)
- 30. 30 ©MapR Technologies M7 vs. CDH: 50-‐50 Mix (Read レイテンシ)
- 31. 31 ©MapR Technologies M7 vs. CDH: 50-‐50 Mix (Update)
- 32. 32 ©MapR Technologies M7 vs. CDH: 50-‐50 Mix (Update レイテンシ)
- 33. 33 ©MapR Technologies 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) ベンチマーク MapR 3.0.1 (M7) CDH 4.3.0 (HBase) MapR 性能比 50% Read, 50% Update 21328 2547 8.4倍 95% Read, 5% update 13455 2660 5倍 Read 18206 1605 11.3倍 スキャン (50 行) 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 倍
- 34. 34 ©MapR Technologies M7: Fileserver が Region を管理 § Region は全体がコンテナ内部に格納される – ZooKeeper によるコーディネーションは行われない § コンテナが分散トランザクションをサポート – レプリケーションも行われる § システム内で行われるコーディネーションは分割のみ – Region マップとデータコンテナ間での調整 – ファイルとデータチャンクの扱いにおいて既にこの課題は解決済 み
- 35. 35 ©MapR Technologies サーバーの再起動 § コンテナレポートは全部合わせてもごくわずか – 1,000 ノードのクラスタで CLDB が必要とする DRAM は 2GB § ボリュームはすぐにオンラインになる – 各ボリュームは他ボリュームから独立に管理 – コンテナの最小レプリカ数を満たせばすぐにオンラインに
- 36. 36 ©MapR Technologies サーバーの再起動 § コンテナレポートは全部合わせてもごくわずか – 1,000 ノードのクラスタで CLDB が必要とする DRAM は 2GB § ボリュームはすぐにオンラインになる – 各ボリュームは他ボリュームから独立に管理 – コンテナの最小レプリカ数を満たせばすぐにオンラインに – クラスタ全体を待たない (例: HDFS は 99.9% のブロックレポートが上がるのを待つ)
- 37. 37 ©MapR Technologies サーバーの再起動 § コンテナレポートは全部合わせてもごくわずか – 1,000 ノードのクラスタで CLDB が必要とする DRAM は 2GB § ボリュームはすぐにオンラインになる – 各ボリュームは他ボリュームから独立に管理 – コンテナの最小レプリカ数を満たせばすぐにオンラインに – クラスタ全体を待たない (例: HDFS は 99.9% のブロックレポートが上がるのを待つ) § 1,000 ノードのクラスタは 5 分以内に再起動
- 38. 38 ©MapR Technologies M7 の即時復旧 § Region 毎に 0〜40 個の microWAL – アイドル状態の WAL はすぐにゼロになるため、ほとんどは空 – すべての microWAL の復旧を待たずに Region が起動 – Region の復旧はバックグラウンドで並列処理 – Key へのアクセスがあると、対象の microWAL はインラインで復旧 される – 1000〜10000倍の速さで復旧
- 39. 39 ©MapR Technologies M7 の即時復旧 § Region 毎に 0〜40 個の microWAL – アイドル状態の WAL はすぐにゼロになるため、ほとんどは空 – すべての microWAL の復旧を待たずに Region が起動 – Region の復旧はバックグラウンドで並列処理 – Key へのアクセスがあると、対象の microWAL はインラインで復旧 される – 1000〜10000倍の速さで復旧 § なぜ HBase ではできなくて、M7ではできるのか？ – M7 はMapR ファイルシステムのユニークな機能を活用しており、 HDFS の様々な制約の影響を受けない – ディスク上のファイル数の上限がない – オープンできるファイル数の上限がない – I/O パスがランダム Write をディスクに対するシーケンシャル Write に変換する
- 40. 40 ©MapR Technologies 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) ベンチマーク MapR 3.0.1 (M7) CDH 4.3.0 (HBase) MapR 性能比 50% Read, 50% Update 21328 2547 8.4倍 95% Read, 5% update 13455 2660 5倍 Read 18206 1605 11.3倍 スキャン (50 行) 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 倍