Apache Spark™ に「宣言的パイプライン」がついに登場！

Apache Spark™ は、今やビッグデータ処理における事実上の標準エンジンとなっており、世界中の大手企業のワークロードを支えています。過去10年間で、Apache Spark は汎用コンピューティングエンジンから、オープンレイクハウスアーキテクチャにおける中核レイヤーへと進化してきました。Spark SQL、Structured Streaming、オープンテーブル形式、統合ガバナンスといった機能は、現代のデータプラットフォームにおける重要な柱となっています。

そしてこの進化は、最新版の Apache Spark 4.0 のリリースによってさらに加速しています。ストリーミング、Python、SQL、セミ構造化データの分野で大きな進歩がありました。詳しい内容はこちらをご覧ください。

この堅牢な Apache Spark の基盤の上に、私たちはオープンソースへの新たな貢献を発表します：

信頼性とスケーラビリティを兼ね備えた Declarative Pipelines（宣言型パイプライン） を Apache Spark に寄贈

宣言型パイプライン は、堅牢かつスケーラブルなデータパイプラインを構築するための実績ある標準であり、これを Apache Spark プロジェクトへ寄贈します。

この貢献により、Apache Spark の宣言的アプローチは、単一のクエリだけでなくパイプライン全体へと拡張されます。つまり、ユーザーは「パイプラインが何をすべきか」を記述するだけで、「どのように実行するか」は Spark が自動的に判断してくれるという設計です。

この API は、長年にわたる実際の Apache Spark ワークロードの観察をもとに設計されており、バッチ処理とストリーミング処理の両方を含む、よくあるユースケースをカバーしています。私たちが培ってきた知見を、宣言的 API として形にしました。

宣言的APIでETLがもっとシンプルに、もっと保守しやすく

私たちは、長年にわたり実際のSparkユーザーと取り組んできた中で、プロダクション向けパイプライン構築に共通する課題を数多く見てきました：

• インクリメンタル取り込みやデータセットのマテリアライズのタイミングを判断するための“つなぎコード”に多くの時間がかかっている
  　このような作業はどのチームでも発生しますが、差別化にはつながらず、肝心のビジネスロジックに集中できません。

• 同じようなパターンがチーム間で何度も再実装されてしまい、非効率かつ一貫性がない
  　結果として運用負荷が増大します。

• テストやデータの流れ（リネージ）、CI/CD、モニタリングを一貫して管理できる標準的なフレームワークが存在しない

こうした課題に対し、Databricksでは「DLT（Delta Live Tables）」という製品を通じて、よくあるエンジニアリングのベストプラクティスを宣言的アプローチでプロダクトに落とし込んできました。

DLTでは、処理の全てを自分で組み立てる必要はありません。テーブルの最終状態を定義するだけで、依存関係のマッピング、エラーハンドリング、チェックポイント、障害時のリトライなどはエンジンが自動で処理してくれます。

その結果、生産性・信頼性・保守性は大きく向上し、特に複雑なパイプラインを運用するチームにとっては大きなブレイクスルーとなりました。

学びを活かし、次のステージへ

DLTのローンチ以降、私たちは多くのことを学びました。

• 宣言的アプローチが非常に効果を発揮する領域

• 逆に、柔軟性や細かな制御が求められるケース

• 複雑なロジックやストリーミングのオーケストレーションを自動化することの価値

• 開発者の自由と移植性を担保するためには、オープンなSpark APIの上に構築することが不可欠であるということ

こうした知見をもとに、私たちは新たな方向性に踏み出しました：

それが、「宣言的パイプライン開発のための、オープンソースかつSparkネイティブなフレームワーク」です。

クエリからエンドツーエンドのパイプラインへ：Sparkの宣言的進化の次なるステージ

Apache Spark SQL によって、クエリ実行は「宣言的」に進化しました。開発者は、低レベルな RDD コードでジョインや集計処理を書く代わりに、「求める結果をSQLで記述」するだけでよくなり、残りは Spark が自動で処理してくれるようになりました。

そして今回、Spark Declarative Pipelines により、この宣言的アプローチがクエリ単体から複数テーブルにまたがるパイプライン全体へと拡張されます。
開発者は「どのようなデータセットが必要で、どのように生成されるか」を定義するだけで、Spark が最適な実行計画を自動で導出し、依存関係の管理やインクリメンタル処理を行ってくれます。

Spark 宣言型パイプライン の特徴

オープン性と再利用性（コンポーザビリティ）を重視して設計された Spark Declarative Pipelines は、以下の機能を備えています：

• テーブルや変換処理を定義するための宣言的API

• バッチ処理とストリーミング処理の両方をネイティブにサポート

• データ依存を自動で追跡し、実行順序やバックフィルも自動管理する、データに気づいたオーケストレーション

• ストリーミング処理のための自動チェックポイント、リトライ、インクリメンタル実行

• SQLとPythonの両方に対応

• Sparkの実行プランに完全アクセスできるため、実行の透明性を確保

そして何よりも重要なのは、このフレームワークが「Apache Sparkそのもの」だということです。
ラッパーやブラックボックス的な仕組みは一切なく、Sparkのオープンな構造の上で動作します。

オープンソースで実現する、新たな標準

今回の貢献は、Apache Spark、Delta Lake、そしてオープンデータコミュニティ全体にわたる長年の取り組みの集大成です。DLTで得た知見をもとにしながら、より柔軟に、より拡張可能に、そして完全にオープンソースとして設計されています。

そしてこれは始まりにすぎません。私たちはこのフレームワークを、Apache Spark エコシステム全体が共通基盤として活用できるよう提供します。独自のパイプラインを構築する場合も、業界特化の抽象化を行う場合も、Spark本体に貢献する場合も、このフレームワークがあなたを支援します。

「宣言的なパイプラインは、現代のデータエンジニアリングの複雑さをシンプルで直感的なプログラミングモデルの下に隠します。エンジニアリングマネージャーとして、私のエンジニアがビジネスに最も重要なことに集中できることが大好きです。このレベルのイノベーションが今、オープンソース化されていることを見るのは興奮しています-これにより、さらに多くのチームがアクセスできるようになります。” — Jian (Miracle) Zhou, Senior Engineering Manager, Navy Federal Credit Union

「84.51では、データパイプラインを構築しやすく、維持しやすくする方法を常に探しています。特に、よりオープンで柔軟なツールに移行するにつれて。宣言的なアプローチは、管理するコードの量を減らすのに大いに役立ち、バッチとストリーミングの両方をサポートするのが容易になり、別々のシステムを縫い合わせる必要がなくなりました。このフレームワークをSpark Declarative Pipelinesとしてオープンソース化することは、Sparkコミュニティにとって大きなステップです。” — Brad Turnbaugh, Sr. Data Engineer, 84.51°

今後の展望

詳細は今後、Apache Sparkのドキュメンテーションで随時公開される予定です。
それまでの間は、提案に関するJiraとコミュニティディスカッションをご覧いただけます。

もし今 Apache Spark でパイプラインを構築しているなら、ぜひこの宣言的モデルを試してみてください。
私たちの目標は、すべての人にとってパイプライン開発をもっとシンプルに、信頼性高く、そして協調的なものにすることです。

Lakehouse の本質は、単なるオープンなストレージではありません。
オープンなフォーマット、オープンなエンジン、そしてそれらの上に構築するためのオープンなパターンが揃って初めて、真のLakehouseが実現します。

私たちは、宣言的パイプラインが Apache Spark 開発における新たな標準となると信じています。
そしてその未来を、オープンに、コミュニティと共に築いていけることを楽しみにしています。