3つのApache Spark APIの話：RDD、DataFrame、Datasetの比較

開発者の皆様に喜ばれるAPIは、生産性を高め、使いやすく、直感的で表現力豊かなものです。 Apache Spark が開発者にアピールしてきた理由の一つは、大規模データセットを対象に、Scala、Java、Python、Rといった複数の言語で操作できる使いやすいAPIを提供していることです。

この記事では、Apache Spark 2.2 以降で利用可能な3つのAPIセット（RDD、DataFrame、Dataset）について、それぞれの使用目的と適切なタイミング、パフォーマンスと最適化のメリット、そしてRDDではなくDataFrameやDatasetを使用すべきシナリオを解説します。主にDataFrameとDatasetに焦点を当てます。なぜなら、Apache Spark 2.0 では、これら2つのAPIが統合されたからです。

この統合の主な動機は、学習すべき概念の数を減らし、構造化データの処理方法を提供することでSparkを簡素化するという目標にあります。そして、構造化を通じて、Sparkはドメイン固有の言語構造として、より高レベルな抽象化とAPIを提供できるようになります。

Resilient Distributed Dataset (RDD)

RDDは、Sparkの inception 以来、主要なユーザー向けAPIでした。本質的に、RDDは、クラスター内のノードに分散され、並列に操作できるデータの要素の不変の分散コレクションであり、低レベルのAPIで変換（transformations）とアクション（actions）を提供します。

RDDを使用するのはどのような場合ですか？

RDDを使用するシナリオや一般的なユースケースを以下に示します。

• データセットに対する低レベルな変換やアクション、および制御が必要な場合
• データがメディアストリームやテキストストリームのような非構造化データである場合
• ドメイン固有の式よりも関数型プログラミングの構造でデータを操作したい場合
• 処理中やデータ属性へのアクセス時に、列形式のようなスキーマを課すことを気にしない場合、または名前や列で属性にアクセスする場合
• 構造化データおよび半構造化データで利用可能な一部の最適化とパフォーマンスのメリットを、DataFrameとDatasetのために犠牲にできる場合

Apache Spark 2.0 で RDD はどうなりますか？

「RDDは二級市民になるのか？」「非推奨になるのか？」と疑問に思うかもしれません。

その答えは、いいえ！です。

さらに、以下で説明するように、簡単なAPIメソッド呼び出しで、DataFrameまたはDatasetとRDD間を自由に行き来できます。そして、DataFrameとDatasetはRDDの上に構築されています。

DataFrames

RDDと同様に、DataFrame はデータの不変の分散コレクションです。RDDとは異なり、データはリレーショナルデータベースのテーブルのように、名前付きの列に編成されています。DataFrameは、大規模データセットの処理をさらに容易にするように設計されており、開発者が分散データコレクションに構造を課すことを可能にし、より高レベルな抽象化を提供します。分散データを操作するためのドメイン固有言語APIを提供し、専門的なデータエンジニア以外にもSparkをより幅広い層に利用可能にします。

Apache Spark 2.0 のプレビューウェビナーやその後のブログで述べたように、Spark 2.0 では DataFrame API と Dataset API がマージされ、ライブラリ全体でデータ処理機能が統合されます。この統合により、開発者は学習または記憶すべき概念が少なくなり、Dataset という単一の高レベルで型安全なAPIを扱うことができるようになります。

Datasets

Spark 2.0 以降、Dataset は、以下の表に示すように、厳密に型付けされたAPIと型付けされていないAPIという2つの異なるAPI特性を持ちます。概念的には、DataFrame は汎用オブジェクトのコレクションであるDataset[Row] のエイリアスと考えることができます。ここでRow は汎用の型付けされていないJVMオブジェクトです。対照的に、Dataset は、Scala で定義したケースクラスまたは Java で定義したクラスによって指定される、厳密に型付けされたJVMオブジェクトのコレクションです。

型付けされたAPIと型付けされていないAPI

注: Python と R にはコンパイル時の型安全性がないため、型付けされていないAPI、すなわちDataFrameのみが存在します。

Dataset API のメリット

Spark開発者として、Spark 2.0 の DataFrame と Dataset の統合APIから多くのメリットを得られます。

1. 静的型付けと実行時型安全性

静的型付けと実行時安全性をスペクトラムとして考えます。SQLが最も制限が少なく、Datasetが最も制限が多いとします。例えば、Spark SQLの文字列クエリでは、構文エラーは実行時までわかりません（コストがかかる可能性があります）。一方、DataFrameとDatasetでは、コンパイル時にエラーを検出できます（開発時間とコストを節約できます）。つまり、DataFrameでAPIの一部ではない関数を呼び出した場合、コンパイラがそれを検出します。ただし、実行時まで存在しない列名は検出されません。

スペクトラムの最も制限が多い端にあるのがDatasetです。Dataset APIはすべてラムダ関数とJVM型オブジェクトとして表現されるため、型パラメータの不一致はコンパイル時に検出されます。また、Datasetを使用する場合、分析エラーもコンパイル時に検出できるため、開発時間とコストを節約できます。

これらすべては、Sparkコードにおける構文および分析エラーに関する型安全性のスペクトラムに変換され、Datasetは最も制限が多いものの、開発者にとっては最も生産的です。

2. 高レベルな抽象化と構造化・半構造化データへのカスタムビュー

Dataset[Row] のコレクションとしてのDataFrameは、半構造化データに対する構造化されたカスタムビューを提供します。例えば、JSONで表現された大量のIoTデバイスイベントデータセットがあるとします。JSONは半構造化フォーマットであるため、厳密に型付けされた特定のDataset[DeviceIoTData] のコレクションとしてDatasetを使用するのに適しています。

各JSONエントリを、Scalaのケースクラスで表されるカスタムオブジェクトDeviceIoTDataとして表現できます。

次に、JSONファイルからデータを読み込みます。

上記のコードでは、内部で次の3つのことが起こります。

1. SparkはJSONを読み込み、スキーマを推論し、DataFrameのコレクションを作成します。
2. この時点で、SparkはデータをDataFrame = Dataset[Row]、つまり汎用Rowオブジェクトのコレクションに変換します。なぜなら、正確な型を知らないからです。
3. 次に、SparkはDataset[Row] -> Dataset[DeviceIoTData]、つまりクラスDeviceIoTDataで指定された型固有のScala JVMオブジェクトに変換します。

構造化データで作業するほとんどの人は、データを列形式で表示および処理すること、またはオブジェクト内の特定の属性にアクセスすることに慣れています。Dataset[ElementType] 型オブジェクトのコレクションとしてのDatasetを使用すると、コンパイル時の安全性と、厳密に型付けされたJVMオブジェクトのカスタムビューをシームレスに取得できます。そして、上記のコードから得られる結果の厳密に型付けされたDataset[T] は、高レベルなメソッドで簡単に表示または処理できます。

3. 構造化されたAPIによる使いやすさ

構造化はSparkプログラムがデータに対してできることの制御を制限する可能性がありますが、リッチなセマンティクスと、高レベルの構成要素として表現できる使いやすいドメイン固有の操作セットを導入します。しかし、ほとんどの計算はDatasetの高レベルAPIで達成できます。例えば、RDDの行のデータフィールドを使用するよりも、Datasetの型指定されたオブジェクトのDeviceIoTDataにアクセスすることで、agg、select、sum、avg、map、filter、またはgroupBy操作を実行する方がはるかに簡単です。

ドメイン固有のAPIで計算を表現することは、リレーション代数型の式（RDDの場合）を使用する場合よりもはるかにシンプルで簡単です。例えば、以下のコードは、別の不変のDatasetを作成するためにfilter()と map()を実行します。

4. パフォーマンスと最適化

上記のすべての利点に加えて、2つの理由から、DataFrameとDataset APIを使用することによるスペース効率とパフォーマンスの向上を見過ごすことはできません。

第一に、DataFrameとDataset APIはSpark SQLエンジンの上に構築されているため、Catalystを使用して最適化された論理的および物理的なクエリプランを生成します。R、Java、Scala、またはPythonのDataFrame/Dataset API全体で、すべてのリレーション型クエリは同じコードオプティマイザを経由し、スペースと速度の効率を提供します。一方、Dataset[T]型APIはデータエンジニアリングタスクに最適化されていますが、型指定されていないDataset[Row]（DataFrameのエイリアス）はさらに高速で、インタラクティブな分析に適しています。

第二に、Spark as a compilerはDataset型のJVMオブジェクトを理解するため、Encoderを使用して、型固有のJVMオブジェクトをTungstenの内部メモリ表現にマッピングします。その結果、Tungsten Encoderは、JVMオブジェクトを効率的にシリアル化/デシリアル化できるだけでなく、優れた速度で実行できるコンパクトなバイトコードを生成できます。

DataFrameまたはDatasetはいつ使用すべきですか？

• リッチなセマンティクス、高レベルの抽象化、ドメイン固有のAPIが必要な場合は、DataFrameまたはDatasetを使用してください。
• 処理で高レベルの式、フィルタ、マップ、集計、平均、合計、SQLクエリ、列アクセス、および半構造化データに対するラムダ関数の使用が必要な場合は、DataFrameまたはDatasetを使用してください。
• コンパイル時に高いレベルの型安全性が必要で、型指定されたJVMオブジェクトを使用し、Catalystの最適化を活用し、Tungstenの効率的なコード生成の恩恵を受けたい場合は、Datasetを使用してください。
• Sparkライブラリ全体でのAPIの統合と簡素化が必要な場合は、DataFrameまたはDatasetを使用してください。
• Rユーザーの場合は、DataFrameを使用してください。
• Pythonユーザーの場合は、DataFrameを使用し、より詳細な制御が必要な場合はRDDに戻ってください。

簡単なメソッド呼び出し.rddで、DataFrameおよび/またはDatasetからRDDへのシームレスな相互運用または変換が常に可能であることに注意してください。例えば、

まとめ

要約すると、RDDまたはDataFrameと/またはDatasetを使用するタイミングの選択は明白です。前者は低レベルの機能と制御を提供しますが、後者はカスタムビューと構造を可能にし、高レベルでドメイン固有の操作を提供し、スペースを節約し、優れた速度で実行します。

Sparkの初期リリースから学んだ教訓、つまり開発者向けにSparkを簡素化する方法、パフォーマンスを最適化する方法を検討した結果、低レベルのRDD APIを高レベルの抽象化であるDataFrameとDatasetに引き上げ、この統一されたデータ抽象化をCatalyst optimizerとTungstenの上に構築することを決定しました。

ニーズとユースケースに合ったAPI（DataFrameと/またはDatasetまたはRDD API）のいずれかを選択してください。ただし、構造化データと半構造化データを扱うほとんどの開発者が属する陣営にあなたも入るとしても、私は驚かないでしょう。

次に何をすべきか？

Databricks上のApache Spark 2.2を試すことができます。

3つのApache Spark APIの物語：RDD vs DataFrameとDatasetに関するSpark Summitのプレゼンテーションを視聴することもできます。

まだサインアップしていない場合は、今すぐDatabricksを試してください。

来週は、Structured Streamingに関する一連のブログを公開します。お楽しみに。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事