本記事は、株式会社ギックスの運営していた分析情報サイト graffe/グラーフ より移設されました（2019/7/1）
目次
SparkはHadoopの後発として期待されるビッグデータ処理基盤
今日は「Apache Spark」という言葉について説明します。先日「Hadoop(ハドゥープ)」についての掲載をさせていただきましたが、その中でHadoopとは、
- 巨大データの取り扱いを目的とした分散処理のフレームワークである
- 分散処理によってビッグデータを高速に処理することができる
- Hadoopの利用者は自作したデータ処理のプログラムや他者が開発したツールプログラムをHadoop内に組み込んでビッグデータ処理を行う
と説明させていただきました。またその他関連記事の中で、
- Hadoop上で稼動するデータベースマネージメントシステム(DBMS)としてHive・Impalaがあり、
- 同じくHadoop上で稼動するスクリプト環境としてPigがある
- これらHadoop連携ソフトウェアの存在がビックデータ処理環境をより便利なものにしている
とも説明させていただきました。
SparkもHadoopと同じく分散処理のフレームワークです。Sparkはカリフォルニア大学バークレー校で開発が開始され、2014年にApache Software Foundationに寄贈されました。HadoopがJava言語で作られているのに対してSparkはJavaの派生言語であるScalaで作られています。
Sparkの特徴を以下に簡単に説明します。
インメモリ処理による高速化
Hadoop内部で主に用いられているMapReduceと呼ばれる処理方法は、入出力処理の際にハードディスクやSSD等ストレージへのアクセスを比較的頻繁に行う処理方法でありました。これに対してSparkの内部処理方式にはデータをメモリに保存することで入出力の高速化を図り処理全体の実行速度を向上させようとする取り組みがなされています(もちろん利用可能メモリが枯渇した場合にはデータをストレージに保存するケースも勘案されています)。この処理方式は、例えば機械学習の計算処理に効果を発揮する事が考えられており、実際特定のアプリケーションに関する実行性能は、HadoopのMapReduce処理と比べた場合の100倍にも達するといわれています。
「データの格納場所」に関する選択肢の広さ
Sparkで処理を行うデータは「いろいろな種類のデータ置き場」に格納することができます。言い換えれば「Sparkは様々なデータ格納場所からのデータ入出力に対応している」と言えるでしょう。 Hadoopがデータの格納場所として基本的には「Hadoop Distributed File System (HDFS)」という独自のファイル格納場所を必要とする事と比べて、これは非常に特徴的です。現在Sparkには
- Hadoop Distributed File System (HDFS)
- Cassandra
- OpenStack Swift
- Amazon S3
などが対応可能ストレージとして挙げられています。
プログラム手法に関する選択肢の広さ(SQLもサポート)
HadoopそのものはJavaでプログラムされていますが、ここで「Hadoopを用いて処理を行う際に用いられるプログラミング手法」としては以下のパターンが代表的です。
- Java(直接Hadoopを制御する事からこの方法を生Hadoopと呼んだりします)
- HiveQL(Hadoop+Hive)
- Pig(Hadoop+Pig)
- Hadoop Streamingを使用することで標準入出力を介してPythonなどから制御
このようにHadoopでは「Javaを用いた生Hadoop」を除いては「Hadoopとは別のソフトウェア」を介してプログラミングを行う事が一般的です。これは元々HadoopがJavaのソフトウェアであり、その広がりとともに周辺の便利なソフトウェアが後付けで開発されてきた事を物語っています。
これに対してSparkはSpark自身はScalaでプログラムされているものの、他のプログラム言語に対してより緊密なアプローチが採用されています。すなわち、Sparkを制御するための機能が、Scalaだけではなく
- Java
- Python
- R言語
といった昨今広く用いられている各プログラム言語用のAPIとして提供されています。具体的にはSparkと通信を行う部分がラッパーとして各言語ごとに作成・配布されているのです。
また、データの操作を行ううえでもっとも一般的な言語のひとつであるSQLもSparkは「Spark SQL」として利用する事が可能です。
このように「Sparkを用いて処理を行う際に用いられるプログラミング手法」が手広くサポートされていることはSparkを利用するユーザにとってありがたいことであるといえるでしょう。
Note:
しかしながら現時点で問題が皆無であるわけではないのが実情で、上記API(ラッパー)を介在させた場合のオーバーヘッドによる処理速度の低下がネット上で報告されているようです。
SparkとHadoopの関係は競合というよりは共存。ユーザには広い選択肢が与えられている
現時点でのSparkとHadoopの関係は競合関係・駆逐関係というには早急であると考えられます。なによりも
- 「Hadoop+Spark」の構成も現実的である(Hadoop内のYarn制御下でSparkを利用する)
- Sparkはデータの入出力場所としてHDFSにも対応している
という事からも「現段階ではSparkとHadoopは共存関係にある」という表現がふさわしいでしょう。とくにSparkがHDFS上のデータをその制御の対象としていることは、既存データの再利用性も含めて二者の親和性の高さをより緊密なものにしています。競合関係という意味では「Spark式処理方法とMapReduce式処理方法の競合」という表現が適切なのかもしれません。
いずれにしても、利用者にとっては大規模データに対する処理方法の選択肢が広がることは喜ばしい事だと考えられます。そこで必要なのは大規模データから求める成果を導くシステムを構築するために必要な要件を見定める俯瞰的な視野なのではないでしょうか。
現実的に想定される適応ケースとしては
後発プロダクトであるSparkへの注目が集まっている事からも、従来Hadoopでの処理が想定されていたケースでSparkが選択されるケースは今後増えていくことが予想されますが、当面は「インタラクティブなリアルタイム処理」や「機械学習等のSparkが得意分野であると評価されている処理」の要件に対してSparkの適用を期待しつつ、実際のデータサイズの観点からHadoopとSparkの実績評価を天秤にかけていくのではないかと考えられます。
データ分析用語：索引
