Sparkの2016年は，1月4日にバージョン1.6.0のリリースからスタートしましたが，なんといっても今年の目玉はバージョン2.0.0のリリースでした。2016年7月26日にリリースされ，この開発には2,000以上のパッチが投稿され，世界中から280人もの開発貢献者の参画があったと言われています。

バージョン2.0ではアーキテクチャが抜本的に見直され，さらなる性能向上，さらなる使いやすさが実現しました。両バージョンについては現在もメンテナンスが続けられており，本稿執筆時点では1.6.3，2.0.2が最新リリースです。そして，12月28日にバージョン2.1がリリースされました。本稿では，2016年後半の中心だったバージョン2.0の特徴について，バージョン1.6以前も振り返りつつおさらいし，2017年にどのような取り組みがなされるかについてお伝えします。

Sparkの特徴のおさらい

2016年のSparkの話に入る前に，Sparkのおさらいをしておきましょう。Sparkの特徴を「性能向上」と「使いやすさ」の2軸で簡単に確認します。

まず「性能向上」についてですが，もともとHadoopでも利用されているMapReduceでは非効率になる処理の改善がSparkの開発の元々の目的でした。具体的には多段のMapReduceジョブを実行する際の効率化やキャッシュの利用により，余計なI/Oを減らすことで高速化を目指しました。これには，コモディティあるいはモダンなハードウェアの能力を「使い切る」ことで高速な処理をリーズナブルに実現したいというオープンソースソフトウェアの哲学が源流にあるといえます。

もう一点が「使いやすさ」です。MapReduceではまだ利用の敷居が高いと言われてきた並列分散処理のハードルを下げる仕掛けがSparkにはあります。大きく以下の4点があります。

1. RDDと呼ばれるデータ構造の導入によるデータの抽象化と，データ処理を記述するのに理解しやすいAPIの整備
2. 開発言語のサポート，特にデータ分析界隈で利用者が多いPython対応の開発が進む
3. 用途別ライブラリの導入：SQL（Spark SQL）⁠，ストリーム処理（Spark Streaming）⁠，機械学習（MLlib）⁠，グラフ処理（GraphX）
4. インタラクティブシェルの導入：データ分析の現場でニーズが高い試行錯誤をしやすく

Sparkが単に性能向上を目指す以外に，使いやすさも追求しているあたりが利用者の目線に立った開発が行われている大事なポイントだといえます。

2016年のApache Spark

Sparkがもつ「性能向上」「⁠使いやすさ」という2つの特徴それぞれからSparkの進化を見てみます。

「性能向上」の面ではProject Tungstenと呼ばれる性能向上の取り組みがなされており，コモディティあるいはモダンなハードウェアの能力を使い切る活動がさらに推し進められています。

「使いやすさ」の面では，DataFrame/Datasetと呼ばれるデータ構造の導入により，並列分散処理利用時のハードルを下げる取り組みが行われています。以下，それぞれについて見ていきます。

Project Tungsten

Project Tungstenと呼ばれる「性能向上」の取り組みの背景には，ハードウェアの進化があります。2010年から2015年にかけてメモリの大容量化，SSDや10Gbpsネットワークのコモディティ化によりハードウェアの性能が向上し実質的に10倍程度向上したといえます。この結果，Spark開発当初はI/Oが性能面でのボトルネックになりがちでしたが，それがCPUに移りつつあります。これを，メモリの利用効率改善やモダンなCPU機能の活用によりCPUネックの解消を行っている活動がProject Tungstenです。

また，MPPデータベースに代表されるようなモダンな処理エンジンの良い点を見習い，そこで利用されている高速化のための取り組みをSparkで利用されるワークロードに適するよう導入が進められています。

バージョン1.6以前でもProject Tungstenの取り組みは行われていました。大きく3点あり，Java JVM利用によるGCの影響緩和のための独自のメモリ管理機構の導入，データがキャッシュに乗ることを意識したデータ構造やアルゴリズムの導入，Codegen（実行時コード生成）と呼ばれる，Spark SQLでクエリ記述した際のクエリ解析時に式を高速に評価するためのカスタムコードをコンパイル時に生成，といったものです。

バージョン2.0のProject Tungstenではバージョン1.6での活動を下地として，さらに2つの取り組みを行いました。

1つはWhole Stage Codegenと呼ばれるCodegenの後続となる取り組みです。入力データをスキャンし，フィルタし，射影をとって集約した結果を出力するといった処理を行うことはよくあると思いますが，このような複数のオペレータが存在する処理を行う際の高速化です。1レコード取り出すたびにオペレータの数分だけ都度メソッド呼び出しが発生していたのを，複数オペレータに対してまとめてカスタムコードを生成し，オペレータ間のレコード受け渡しに伴うメソッド呼び出しを減らしました。余分な処理を除去することでCPU利用効率のさらなる改善が期待できます。

もう1つはVectorizationです。Spark SQLにおいて入力ファイルフォーマットのParquetというカラム指向ファイルフォーマットを利用する際の高速化です。JVMのJITによる最適化を促すことで，ループ展開やSIMD命令によって，複数のレコードをまとめて処理する際の高速化を実現します。

DataFrame/Dataset

バージョン2.0のDataFrame/Datasetの話に入る前に，DataFrameの導入の背景についておさらいしておきます。DataFrameはスキーマを備えた，RDBMSにおけるテーブルのようなデータ構造です。DataFrameはいくつかの課題の解決を目的として導入されました。たとえば，もともとSparkで導入されていたRDDと呼ばれる配列のようなデータ構造に対して処理を記述した場合の見通しの悪さを改善するといった点が挙げられます。

さらに使いやすさの改善だけでなく，性能改善もあわせて行われており，DataFrameベースの処理は，オプティマイザにより最適化されるようになりました。また，アプリケーション開発言語間で存在していた処理の性能差をなくすように開発が進められたことで，DataFrameの利用が主流となるような礎を築きました。

バージョン1.6では，このDataFrameを発展させる形でDatasetと呼ばれるデータ構造を導入しました。Datasetもまたテーブルのようなデータ構造なのですが，データを直接Spark SQLの内部表現（UnsafeRow）に変換し，シリアライズ効率の改善を実現しています。ただ，バージョン1.6ではDataFrameとDatasetが似たようなデータ構造で併存する形となっており，アルファリリース扱いのままでした。

バージョン2.0のDataFrame/Datasetは，Datasetの開発をさらに推し進め，併存する形となっていた両者の内部アーキテクチャをDatasetベースに整理することで，利用側から見たときのSpark全体としてのAPIの統一を図りました。これにより，Scala言語ではDataFrameはDatasetの型付き表現という扱いになりました。また，バージョン1.6のDataFrameではできなかった列名や型の誤りをコンパイル時に検出できるようになったことで，利用者にとっての利便性が高まりました。