Communication of the ACM の1月号には MapReduce のはなしが載っていて、というのを steps to phantasien で知って、実際に読んでみた。私は去年の末から ACM 会員になったので、CACM は家に紙のやつが届くのです。
MapReduce and Parallel DBMSs: Friends or Foes?
ひとつは MR と並列 DBMS を比較し、実際に Hadoop と商用の DBMS でベンチマークもとったけど DBMS のほうが速かったよ、という Michael Stonebraker らによる "MapReduce and Parallel DBMSs: Friends or Foes?"。これは、同著者ら (ただし 1st author はちがう) による "A comparison of approaches to large-scale analysis" の続きというかまとめ的な感じ。
著者らはまず、MR は RDBMS というよりは ETL (extract-transform-load, 抽出-加工-書き出し) システムに似たものであって RDBMS とは補完しあう技術であるよ、と置きつつも
it is natural to ask whether MR systems should replace parallel database systems.
と、並列 DBMS との比較につなげる。並列 DBMS というのは、安価な (comodity な) 計算機をつないだクラスタ上で、ひとつのテーブルを複数のノードに分散させ、SQL を各々のノードで並列・分割に実行できるものらしい。水平な分散 (sharding) が SQL 上ではなく、その抽象化の下にあるってことですね。
次に、著者らは MR のプログラミングモデルはそれ特有のものでなく、並列 DBMS 上でも実現できるよ、と主張する。抽出や加工はふつうに SQL で書けるし、複雑な Map, Reduce にはユーザー定義関数 (UDF) を使えばよろしい。Map-Reduce 間の shuffle は GROUP BY でできる。また、並列 DBMS の線形なスケーラビリティにはここ20年の実績があり
There is no reason why scalability cannot be increased dramatically to the levels reported by Jeffery Dean and Sanjay Ghemawat, assuming there is customer demand.
という。すごい自信だ。
著者らはさらに、MR が使われがちな局面について、並列 DBMS での実現方法を考察していく。
- ETL: MR むきだけど並列 DBMS でもできる。でも ETL は DBMS にデータをいれる前段階に使われることが多い。
- 複雑な分析: マイニングやクラスタリングのような、SQL で書きづらく、かつ処理が複数段になっているものは MR に向いている。
- Semi-structured: 行ベースの DBMS には向かないけど Vertica のような列ベースのものなら向いている。
- 汚くてもいいのですぐ分析したい: 並列 DBMS はインストールと設定が難しい。その点、MR は簡単にスキーマもないしすぐ使いはじめられる。ただ並列 DBMS はちゃんと設定・設計すれば速いので、その分析が一時的なものでなければ、初期投資も見合う。
- 予算がない: 並列 DBMS は高いし、コミュニティベースのものは信頼性があんまり。MR は良いね。
わりと向き不向きがあるんですね、って平和なのはここまでなんですが。
ベンチマーク
ここで著者らは Hadoop と DBMS-X (名前は明かされないが、行ベースの並列 DBMS), Vertica (列ベースのDBMS) について100ノードのクラスタでベンチマークをとる。すべての結果と考察は "A comparison of approaches to large-scale analysis" にあり、今回の論文ではそのうちの3つについてふれている。
- MR の最初の論文にあった Grep: DBMS のソートやインデックスが使えないし、ファイルシステム上にレイヤをあまり重ねない MR のほうが有利だと思うけど、DBMS-X が Hadoop より1.5倍、Vertica が2.6倍速い
- Web のログファイルをあつかう: フルスキャンでインデックスも使えないのに DBMS-X が Hadoop より1.5倍、Vertica が4.3倍速い
- Join: DBMS-X が Hadoop より36.3倍、Vertica が21倍速い
結果の考察としては
- パース: Hadoop のデフォルト設定では、入力データと同じようなテキスト形式のフォーマットで HDFS にデータが置かれるため、パースが何度も必要になっている。SequenceFile という効率的なフォーマットも提供されているが、これも value に複数の属性をいれるとパースが必要になる。
- 圧縮: 並列 DBMS はデータを圧縮して IO のコストを減らしているので速い。Hadoop にも圧縮はあるけど、減らせる IO コストと増える CPU コストとのバランスが微妙で、使うと遅くなることもある。
- パイプライン: 並列 DBMS はデータを処理から処理へ push して流していく。MR は Map で出来た中間ファイルを Reduce 側で pull したり、耐障害性の反面、効率は悪い。
- スケジューリング: 並列 DBMS は実行前に全体でのスケジューリングと最適化を行うけど、MR は実行時にノード単位でやるだけなので遅い。
- 列ベース: ログファイルを扱う際にで Vertica が速かったのは、他ふたつが行ベースだったから。
という点をあげ、Hadoop の実装特有の (Google の実装では解決されているかもしれない) 問題も多いけど、パイプラインとスケジューリングのあたりは MR モデルの耐障害性に関連しているので、MR 一般の問題だろうと指摘する。また DBMS のトランザクション単位の耐障害性にも、途中の処理結果をディスクにおいて、より細かい耐障害性を実現するものもあるんだよ、という。
つづく
長くなったので一旦おわり。後編では Google のそもそもの MapReduce 論文の著者である Jeffery Dean, Sanjay Ghemawat の反論を紹介します。