米国サンフランシスコで2014年6月30日から7月2日まで開催されたSpark Summit 2014では、筆者の一人であるNTTデータの土橋昌が、エンタープライズ環境で「Hadoop」を扱ってきたNTTデータの立場から見た「Spark」の評価について講演した。第2回となる今回はこの内容を元に、200台ほどの実サーバーを用いて実施したSparkの検証結果などについて解説しよう。
NTTデータ 基盤システム事業本部OSSプロフェッショナルサービスに所属する土橋が登壇したセッションのタイトルは「Spark on large Hadoop cluster and evaluation from the view point of enterprise Hadoop and developer」というものだ（写真1）。NTTデータは6年前からHadoopに関連するシステム構築ビジネスを手がけており、Hadoopを用いた商用システムの構築・運用実績がある。そのような経験に基づいて「Sparkに対してどのような期待を抱いているか」「200台ほどの実サーバーを用いて、現実のシナリオに近い検証を実施し、そこからSparkのどんな特徴が分かったか」といった内容を解説した。
Sparkによる「繰り返し処理」の高速化に期待
NTTデータがSparkに興味を持った最大の理由は、「繰り返し処理」と「多段処理」の高速化であった。従来のHadoopの標準的な処理方式であるMapReduceは、仕組みは単純だがデータ量に比例して処理能力をスケール（拡張）できることが強みだった。
しかしMapReduceには不得意な処理もあった。統計処理や機械学習のような「繰り返し計算」や「多段処理」が必要な複雑な処理である。Map処理とReduce処理の一対を単位とし、処理単位のたびに中間データをディスクに書き出すMapReduceは、繰り返し計算や多段処理を苦手としていた。
そこで、処理の流れをDAG（無閉路有向グラフ）で表し、繰り返し計算や多段処理を一括りのジョブとして効率的に扱えるSparkに着目した（図1）。さらにSparkは高度で便利なAPI（アプリケーション・プログラミング・インターフェース）を備えているため分析用途に使いやすいと考えた。
実際のSparkの検証では、分散処理環境におけるリソース管理基盤として近年活発に開発が進んでいるHadoopの新しいリソース管理機構「YARN」を使用。MapReduceとSparkの両方を利用できる分散処理フレームワーク上で、データの整形や回帰計算などを実行した。
