によって ビラル・アスラム, Ray Zhu 、 Matei Zaharia による投稿
データエンジニアリングチームは、より高品質なデータをより速く提供するというプレッシャーにさらされていますが、パイプラインの構築と運用の作業は、容易になるどころか、ますます困難になっています。私たちは何百人ものデータエンジニアにインタビューし、何百万もの実際のワークロードを調査した結果、驚くべき事実を発見しました。データエンジニアは、その時間の大部分をコードの記述ではなく、ツールをつなぎ合わせることで生じる運用の負担に費やしているのです。理由は単純です。既存のデータエンジニアリングフレームワークでは、オーケストレーション、増分データ処理、データ品質、バックフィルといった、本番運用パイプラインにおける一般的なタスクをデータエンジニアが手動で処理する必要があるからです。データ量とユースケースが増加するにつれて、この運用の負担は増大し、データエンジニアリングはビジネスを加速させるどころか、ボトルネックになってしまいます。
業界がこの壁にぶつかったのは、今回が初めてではありません。初期のデータ処理では、あらゆる問いに対して新しいプログラムを作成する必要があり、これはスケールしませんでした。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行で実現しています。次のような強力なメリットも得られます。
@dp.expect_or_drop デコレーターは、不正なレコードを自動的に隔離します。PySparkでは、正常なレコードと不正なレコードを手動で分割し、別々のテーブルに書き込んでいました。dbtでは、別のモデルと手動での処理が必要でした。weekly_sales が raw_sales に依存していることを検出し、実行順序を自動的に調整します。外部のオーケストレーターは不要です。Apache Spark 4.1 の SDP は、データパイプラインにとって優れた選択肢となる以下の 機能 を備えています：
私たちは、Sparkコミュニティと共にオープンに開発されているSDPのロードマップに期待しています。今後のSparkリリースでは、この基盤の上に、継続的な実行とより効率的な増分処理のサポートが構築されていきます。また、実 際のユースケースやコミュニティからのフィードバックを反映させながら、チェンジデータキャプチャ (CDC) などのコア機能をSDPに導入することも計画しています。私たちの目標は、SDPを、Sparkエコシステム全体で信頼性の高いバッチおよびストリーミングパイプラインを構築するための、共有可能で拡張性のある基盤にすることです。
(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事
ブログを購読して、最新の投稿を受信トレイにお届けします。