Spark 宣言型パイプライン: データエンジニアリングがエンドツーエンドの宣言型になるべき理由

データエンジニアリングチームは、より高品質なデータをより速く提供するというプレッシャーにさらされていますが、パイプラインの構築と運用の作業は、容易になるどころか、ますます困難になっています。私たちは何百人ものデータエンジニアにインタビューし、何百万もの実際のワークロードを調査した結果、驚くべき事実を発見しました。データエンジニアは、その時間の大部分をコードの記述ではなく、ツールをつなぎ合わせることで生じる運用の負担に費やしているのです。理由は単純です。既存のデータエンジニアリングフレームワークでは、オーケストレーション、増分データ処理、データ品質、バックフィルといった、本番運用パイプラインにおける一般的なタスクをデータエンジニアが手動で処理する必要があるからです。データ量とユースケースが増加するにつれて、この運用の負担は増大し、データエンジニアリングはビジネスを加速させるどころか、ボトルネックになってしまいます。

業界がこの壁にぶつかったのは、今回が初めてではありません。初期のデータ処理では、あらゆる問いに対して新しいプログラムを作成する必要があり、これはスケールしませんでした。SQLは、個々のクエリーを 宣言的 にすることで、この状況を変えました。つまり、望む結果が 何か を指定すれば、エンジンがそのコンピュート方法を判断してくれるのです。現在、SQL データベースはあらゆるビジネスを支えています。

しかし、データ エンジニアリングは単一のクエリを実行することではありません。パイプラインは、時間の経過とともに相互に依存する複数のデータセットを繰り返し更新します。SQLエンジンはクエリの境界で停止するため、増分処理、依存関係の管理、バックフィル、データ品質、再試行など、それ以降のすべては依然として手作業で組み立てる必要があります。大規模になると、実行順序、並列処理、障害モードについての推論が、すぐに複雑さの主な原因となります。

欠けているのは、パイプライン全体を宣言する方法です。Spark宣言型パイプライン (SDP) は、宣言的なデータ処理を個々のクエリーからパイプライン全体に拡張し、Apache Sparkがエンドツーエンドで計画および実行できるようにします。ステップ間で手動でデータを移動させる代わりに、存在させたいデータセットが何かを宣言すると、SDPが時間の経過とともにそれらを正しく維持する方法を担います。例えば、週ごとの売上を計算するパイプラインでは、SDPがデータセット間の依存関係を推論し、単一の実行計画を構築して、正しい順序で結果を更新します。新規または変更されたデータのみを自動的に処理し、データ品質ルールをインラインで表現し、手動での介入なしにバックフィルや遅延到着データを処理します。SDPはクエリーのセマンティクスを理解しているため、パイプラインの事前検証、安全な並列実行、障害からの正しい復旧が可能です。これらは、Apache Sparkに直接組み込まれたファーストクラスの、パイプラインを認識する宣言的なAPIsを必要とする機能です。

SDPにおけるエンドツーエンドの宣言的なデータエンジニアリングは、強力なメリットをもたらします。

• 生産性の向上： データエンジニアは、グルーコードの代わりにビジネスロジックの記述に集中できます。
• コスト削減：このフレームワークはオーケストレーションと増分データ処理を自動的に処理するため、手作業で作成されたパイプラインよりもコスト効率が高くなります。
• 運用上の負担を軽減: バックフィル、データ品質、再試行などの一般的なユースケースが統合され、自動化されています。

エンドツーエンドの宣言的なデータエンジニアリングの利点を説明するために、まずはPySparkで記述された週次の売上パイプラインから始めましょう。PySparkはエンドツーエンドの宣言型ではないため、実行順序、増分処理、データ品質ロジックを手動でエンコードし、再試行、アラート、モニタリングについてはAirflowなどの外部オーケストレーターに依存する必要があります（ここでは簡潔にするために省略しています）。

SQL dbt プロジェクトとして表現されたこのパイプラインは、多くの同様の制限に悩まされています。増分データ処理は手動でのコーディングが依然として必要で、データ品質は別途処理され、リトライや障害処理は Airflow などのオーケストレーターに頼らざるを得ません：

このパイプラインをSDPで書き換えて、そのメリットを探ってみましょう。まず、SDPをインストールして、新しいパイプラインを作成しましょう:

次に、以下のコードでパイプラインを定義します。なお、expect_or_drop データ品質期待値 API は、コミュニティと協力してオープンソース化に取り組んでいるため、コメントアウトしています:

パイプラインを実行するには、ターミナルで次のコマンドを入力してください:

このコマンドを使用すると、パイプラインを最初に実行することなく事前に検証でき、構文エラーやスキーマの不一致を検出するのに便利です。

バックフィルがはるかに簡単になります - raw_salesテーブルをバックフィルするには、このコマンドをランします。

コードははるかにシンプルです。PySpark版やdbt版では外部ツールを必要とするすべての機能を、わずか20行で実現しています。次のような強力なメリットも得られます。

• 増分データ処理の自動化。このフレームワークは処理済みのデータを追跡し、新規または変更されたレコードのみを読み取ります。MAXクエリー、チェックポイントファイル、条件ロジックは必要ありません。
• 統合されたデータ品質。@dp.expect_or_drop デコレーターは、不正なレコードを自動的に隔離します。PySparkでは、正常なレコードと不正なレコードを手動で分割し、別々のテーブルに書き込んでいました。dbtでは、別のモデルと手動での処理が必要でした。
• 依存関係の自動追跡。フレームワークは、weekly_sales が raw_sales に依存していることを検出し、実行順序を自動的に調整します。外部のオーケストレーターは不要です。
• 統合されたリトライとモニタリング。このフレームワークは障害に対応し、組み込みのUIを通じて可観測性を提供します。外部ツールは不要です。

Apache Spark 4.1 の SDP は、データパイプラインにとって優れた選択肢となる以下の 機能 を備えています：

• データセットを定義するためのPythonおよびSQL API
• バッチクエリーとストリーミングクエリーに対応
• データセット間の依存関係の自動追跡と、効率的な並列更新
• パイプラインのスキャフォールド、検証、そしてローカルまたは本番運用での実行を行うためのCLI

私たちは、Sparkコミュニティと共にオープンに開発されているSDPのロードマップに期待しています。今後のSparkリリースでは、この基盤の上に、継続的な実行とより効率的な増分処理のサポートが構築されていきます。また、実際のユースケースやコミュニティからのフィードバックを反映させながら、チェンジデータキャプチャ (CDC) などのコア機能をSDPに導入することも計画しています。私たちの目標は、SDPを、Sparkエコシステム全体で信頼性の高いバッチおよびストリーミングパイプラインを構築するための、共有可能で拡張性のある基盤にすることです。

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