宣言型パイプラインを 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 がそれをどのように実行するかを判断できるようになります。この設計は、実際の Apache Spark ワークロードを長年観察した結果に基づいており、バッチフローとストリーミングフローの両方を含む最も一般的なパターンをカバーする宣言型 API に、私たちが学んだことを体系化しています。

宣言型 API により、ETL がよりシンプルで保守しやすくなります

長年にわたる実際の Spark ユーザーとの連携を通じて、本番環境パイプラインの構築時に共通の課題が発生することがわかりました。

• 増分インジェストを処理したり、データセットを具体化するタイミングを決定したりするために、「グルーコード」を使用してパイプラインを接続するのに時間がかかりすぎています。これは、すべてのチームがコアビジネスロジックに集中する代わりに維持することになる、差別化されていない重労働です。
• チーム間で同じパターンを再実装すると、一貫性のない状態になり、運用上のオーバーヘッドが発生します。
• 大規模なテスト、リネージ、CI/CD、およびモニタリングのための標準化されたフレームワークがありません。

Databricks では、一般的なエンジニアリングのベストプラクティスを DLT と呼ばれる製品に体系化することで、これらの課題への取り組みを開始しました。DLT は宣言的なアプローチを取りました。すべてのロジックを自分で接続する代わりに、テーブルの最終的な状態を指定すると、エンジンが依存関係のマッピング、エラー処理、チェックポイント、障害、および再試行などを処理します。

その結果、特に複雑な本番環境パイプラインを管理するチームにとって、生産性、信頼性、および保守性が大幅に向上しました。

DLT のリリース以来、多くのことを学びました。

宣言的なアプローチが大きな影響を与える可能性がある場所、およびチームがより柔軟性と制御を必要とする場所を確認しました。複雑なロジックとストリーミングオーケストレーションを自動化することの価値、および移植性と開発者の自由を確保するために、オープンな Spark API を基盤とすることの重要性を確認しました。

その経験から、宣言型パイプライン開発のためのファーストクラスのオープンソースの Spark ネイティブフレームワークという新しい方向性が生まれました。

クエリからエンドツーエンドのパイプラインへ: Spark の宣言的進化における次のステップ

Apache Spark SQL により、クエリの実行が宣言的になりました。開発者は、低レベルの RDD コードで結合と集計を実装する代わりに、SQL を記述して必要な結果を記述するだけで、残りは Spark が処理します。

Spark Declarative Pipelines は、その基盤の上に構築され、それをさらに一歩進めて、宣言型モデルを個々のクエリから複数のテーブルにまたがる完全なパイプラインに拡張します。これで、開発者はデータセットが存在する必要があるものと、それらがどのように派生するかを定義でき、Spark は最適な実行計画を決定し、依存関係を管理し、増分処理を自動的に処理します。

オープン性と構成可能性を念頭に置いて構築された Spark Declarative Pipelines は、以下を提供します。

• テーブルと変換を定義するための宣言型 API
• バッチデータフローとストリーミングデータフローの両方のネイティブサポート
• 自動依存関係追跡、実行順序、およびバックフィル処理によるデータ対応オーケストレーション
• ストリーミングデータ用の自動チェックポイント、再試行、および増分処理
• SQL と Python の両方のサポート
• 基盤となる Spark プランへのフルアクセスによる実行の透明性

そして最も重要なことは、完全に Apache Spark であり、ラッパーやブラックボックスはありません。

オープンな新しい標準

この貢献は、Apache Spark、Delta Lake、およびより広範なオープンデータコミュニティ全体での長年の作業を表しています。DLT の構築から学んだことに触発されていますが、より柔軟で、より拡張可能で、完全にオープンソースになるように設計されています。

そして、私たちはまだ始まったばかりです。これを、独自のプラットフォームでパイプラインをオーケストレーションしている場合でも、ドメイン固有の抽象化を構築している場合でも、Spark 自体に直接貢献している場合でも、Apache 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 は、単なるオープンストレージ以上のものです。オープンフォーマット、オープンエンジン、そして今では、それらを基盤とするオープンパターンに関するものです。

宣言型パイプラインが Apache Spark 開発の新しい標準になると信じています。そして、コミュニティとともに、オープンな場で、その未来を共に築いていくことを楽しみにしています。

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