PR

 米国サンフランシスコで2014年6月30日から7月2日まで開催されたSpark Summit 2014では、筆者の一人であるNTTデータの土橋昌が、エンタープライズ環境で「Hadoop」を扱ってきたNTTデータの立場から見た「Spark」の評価について講演した。第2回となる今回はこの内容を元に、200台ほどの実サーバーを用いて実施したSparkの検証結果などについて解説しよう。

写真1●NTTデータの土橋昌によるSpark Summit 2014での講演風景
写真1●NTTデータの土橋昌によるSpark Summit 2014での講演風景
[画像のクリックで拡大表示]

 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(アプリケーション・プログラミング・インターフェース)を備えているため分析用途に使いやすいと考えた。

図1●従来のHadoop(MapReduce)とSparkの処理方式の違い
図1●従来のHadoop(MapReduce)とSparkの処理方式の違い
[画像のクリックで拡大表示]

 実際のSparkの検証では、分散処理環境におけるリソース管理基盤として近年活発に開発が進んでいるHadoopの新しいリソース管理機構「YARN」を使用。MapReduceとSparkの両方を利用できる分散処理フレームワーク上で、データの整形や回帰計算などを実行した。