Hadoop loves H2

Copyright (c) Bitforest Co., Ltd.

　

　

Hadoopは RDBMSをスケールアウト可能にする

08/12/131

金床株式会社ビットフォレスト CTO

@kinyukahttp://www.jumperz.net/

https://github.com/Kanatoko

https://twitter.com/kinyuka

http://www.jumperz.net/

https://github.com/Kanatoko


　

　

• Hadoopについて、もっとも有名なメリット– I/O性能をスケールアウト可能にする– HDFSがキモ– データを持ってくる（ Hadoop以前）のではなく、データがある場所に処理を行うアプリケーションを移動させるというアプローチ

• Hadoop上で稼働するソフトウェアの種類は爆発的に増えており、「 Hadoopエコシステム」などと呼ばれる– 特によく使われているのが、 SQLっぽくやりたい処理を記述する Hiveや Pig– Hive/Pigでは、もっとも低レベルな Hadoop処理の記述方法であるMap/Reduceを書かずに済む

Hadoop一般論

08/12/132


　

　

Javaプログラマから見た Hadoop

• Hadoopを Javaプログラマとしての視点から見る

– Hadoopは Javaで書かれている– I/Oボトルネックな処理以外（例： CPU）もスケールアウト可能– Mapと Reduceだけ書けば、インフラのコードを書かずに、 10倍、 100倍というレベルで処理をスケールアウトさせることができる

– Hadoopは非常によくテストされたフレームワーク（世界中で実績あり）

– 統率のとれたコンピュータ群を率いるイメージ– Amazon Elastic MapReduceの存在

• クラスタを自分で用意したり、サーバを管理したりする必要がなく、 Javaのコードだけに集中できる

08/12/133


　

　

Javaプログラマから見た Hadoop（２）

• 「分散 JVM環境」としての Hadoop

08/12/134


　

　

Hadoop vs RDBMS ??

• Hadoopと RDBMSは比べるものではない？

– 「 No！」　用途によっては RDBMSと完全に競合するので、どちらがよいか比較する必要がある

– 例：集約処理– Hadoopの HelloWorldとして有名なWordCount– RDBMSならば group byや sum、 countを使えば SQL一発で終わる– 必然的に RDBMSに慣れた人からは「MapReduceは原始的」という反応

– しかし「テラバイト規模のデータ処理を、今すぐにあなたの手元の RDBMS …で出来ますか？」と言われたら

– Partitioning/Shardingが有効だが、実装も管理も非常にめんどうくさい

08/12/135


　

　

Hadoop vs RDBMS ??（２）

• Hadoopと RDBMSが競合しない用途

– ACIDが必要な場面は RDBMS圧勝– 低レイテンシが必要な場面も RDBMS– 構造化されていないデータに対するバッチ処理はやや Hadoopが勝ち• （パーサを書けば RDBMSでもいける）

– データサイズが大きすぎる場合（いわゆるビッグデータ）にはHadoopが圧勝

08/12/136


　

　

RDBMSとスケールアウトの関係

• RDBMSをスケールアウトさせる場合、 ACIDはあきらめる必要がある

• しかし、 RDBMSの魅力は ACIDだけではない• SQL

– 現時点で唯一広く使われている Declarative Language– 「おいコンピュータ！この文書 (データ )に含まれる単語を数えて、多い順に 5つ報告しろ！」

– 高い生産性– 背景に Set Theory– 関数型言語の流行から、 SQLはその価値を見直されている

• インデックスが可能にする高速な処理– 単にソートするだけの用途にも使える

• スケールアウトさせる場合、 Partitioning/Shardingが用いられる

08/12/137


　

　

MapReduceと Partitioning/Sharding

• MapReduceと Partitioning/Shardingは凄く相性がいい• キーごとにデータを分割するのは Hadoopの主要な仕事• http://serverfault.com/questions/351072/rdbms-is-it-possible-to-scale-out-a-rdb

– より引用– 「 Horizontal partitioning aka Sharding — Distributing data from each

table evenly among all servers. Location of data is determined by sharding key. Scales for reads and writes, however accessing data via criteria other then the sharding key requires querying all the servers, in extreme cases requires map-reduce kind of infrastructure.」

08/12/138

http://serverfault.com/questions/351072/rdbms-is-it-possible-to-scale-out-a-rdb


　

　

Hadoopで RDBMS（ H2）をスケールアウトさせる

• Hadoopは JVM上で出来る処理ならスケールアウトできる• ならば RDBMSは？• H2/HSQLDB/Derbyなど、 Pure Javaな組み込みデータベースは Hadoop上でスケールアウトできる

• キーによるデータの分割は Hadoopが自動的に担当• 分割されたデータをMapあるいは Reduceフェーズで JVM上の RDBMSに格納

• 処理は SQLで書くことができ、分散されて実行される• ただし、複数のキーにまたがる処理は、それぞれのデータが別の JVM上に位置してしまうため、このアプローチでは不可（後述）

08/12/139


　

　

Hadoopで RDBMS（ H2）をスケールアウトさせる

08/12/1310


　

　

Hadoopで RDBMS（ H2）をスケールアウトさせる（３）

• 実例１： Reduceフェーズの入力値をソートする– Hadoopでは、 Reduceに渡されるデータについて、値はソートされない

– 値をソートするためにはセカンダリソートと呼ばれるテクニックを使う必要がある• セカンダリソートは明らかにアンチパターン• 直観に反する実装（キーに値が含まれる！）• 冗長で変更に弱いコード (典型的な Javaの嫌なコード。 Comparator）

– Reduceフェーズにおいて、まず値をすべてイテレートし、 H2に格納する。テーブル定義の際に当然インデックスを作成しておく。データをすべて格納した後に、 order byでデータを取り出す（ソートされたデータを取得）• コードの量　↓• コードのわかりやすさ（単純なたったひとつの SQL文）　↑• 変更への耐性　↑• パフォーマンス　↑

– (セカンダリソート : 2時間 15 分 H2でソート : 1時間 52分 )

08/12/1311


　

　

Hadoopで RDBMS（ H2）をスケールアウトさせる（４）

• 実例 2：キーごとに分けられたデータに対する集約処理をSQLで記述する– 例 1と同じく、 Reduceフェーズにおいて、まず値をすべてイテレートし、 H2に格納する。

– その後、Min/Max/Sum/Countなどを使って集約処理を簡単に記述– SQLが使える

• コードの量　↓• コードのわかりやすさ（単純な SQL文）　↑• 変更への耐性　↑• パフォーマンスはケースバイケース。インデックスが効く場合、 Javaで処理をゴリゴリ記述するより H2に SQLを投げる方が高速になる可能性が高い

– データに対する複数回の問い合わせ・アクセスが可能になる• MapReduceでは、値に対するイテレートを一週する間に処理を行わなければならない– 多段MapReduceは面倒かつ非効率

08/12/1312


　

　

H2 on Hadoopの実例　 Dunkhead

08/12/1313

•タイムスタンプ付きのデータ（アクセスログなど）を手軽に可視化し、解析のヒントを得るためのソフトウェア•ビッグデータ解析の初日に使う•オープンソース•Hadoop上で稼働する Pure Javaなアプリケーション•H2を内部で使用•近日リリース予定


　

　

H2 on Hadoopの実例　 Dunkhead（２）

08/12/1314

•Combinerと Reducerで H2oHを利用•Combinerで積極的に集約し、 Reducerに渡るデータのレコード数を減らすようにする（Map/Reduceではよくあるパターン）•Combinerでは一度に処理するデータ量が少ないので、 H2をインメモリで動作させることも可能

•パフォーマンスの大幅向上•当初 Javaで集約処理を書いていたが、 SQLにしてコードが簡潔に•当初セカンダリソートを使っていたが、 SQLに変更してパフォーマンスもアップ


　

　

H2 on Hadoopと Hive/Pigの比較

• H2oHでは本物の SQLが使える (Not SQL-Like)• H2oHではインデックスも使える

– (Hive/Pigでもサポートされているかも。未確認 )

• 動く、あるいは処理を記述するレイヤーが違う– Ｈ２は最もレベルが低い、生のMap/Reduceと同じレイヤー– Hive/Pigはそれよりひとつ上のレイヤー– それぞれの善し悪しがある– カリカリにパフォーマンスを求める場合はMap/Reduceレイヤーで処理を実装することになるが、その際でも H2oHは SQLでの楽な記述を可能にする

08/12/1315


　

　

H2 on Hadoopと Hive/Pigの比較（２）

• H2oHでは SQLは Javaコード内に記述し、コンパイルする必要がある– Adhocなクエリを投げて対話的にデータ解析したい場合 (SQLを書くのがプログラマでない場合など）は Hive/Pigがよさそう

• 複数のキーにまたがるクエリは H2oHでは処理できない– データはキー毎にそれぞれ別の JVM上の H2に分割されているため

– Hive/Pigなら集約可能

• H2は単なる Javaライブラリであるため、 Hadoopが動作する環境であれば簡単に動作させることができる– Amazon ElasticMapReduceで、もっとも基本的な JARアプリケーションとして動作可能

08/12/1316


　

　

H2 on Hadoopと通常の RDBMSとの比較

• AmazonEMR上で通常の RDBMS(PostgreSQLやMySQL)を使用することも可能か？– 未検証– スレーブノード上で自動的にインストールし、起動させる– ユーザ権限などいろいろと面倒がありそう– Hadoopがキー毎に分割したデータを Javaアプリケーションから

RDBMSに JDBCドライバ経由で insert– その後は H2と同じ– H2は充分高速なので、パフォーマンスに大きな差はなさそう– Java内で閉じているので H2が有利な可能性もあり– 管理コストは H2だとゼロなので、その部分は H2の勝ちか– H2の場合、スタンドアロンモードで簡単にテストでき、そのままのコードを EMRに載せられるのは大きい

08/12/1317


　

　

その他、 H2 on Hadoopが使えそうな場面

• （それほど大きくない）マスタテーブル等を H2データベースの形で各ノードに配布する– マスタテーブルを CSVファイルの形で配布し、ループしながら

Joinを行うという原始的なコーディングを避ける。 H2の場合、データベース全体が 1ファイルにおさまるため、配布しやすい。 Joinの際にはインデックスが利用できるし、コードも SQLで書けるのでよい。

• メモリに載りきらない量のデータを処理する場合– Hadoopに限らず、 Javaアプリケーション内でメモリ（ Listや

Map）に載りきらない量のデータを処理する場合、 H2は活躍してくれる。ただし、もちろんディスクのサイズを超えるデータは扱えない

08/12/1318


　

　

まとめ

• H2 on Hadoopは低レベルのMap/Reduceでカリカリに速度を追求しながら SQLが使える非常に優れたテクニック

• 単にセカンダリソートが嫌というだけの理由でも使える• Map/Reduceで自動的に Partitioning/Shardingが行われ、 H2は簡単にスケールアウトする

• Hive/Pigとはレイヤーが異なる

　　　 Hadoop loves H2

08/12/1319

Documents

Hadoop loves H2