![© 2025 NTT DATA Japan Corporation 15
Spark の進化の軌跡
rdd.mapValues(lambda sales: (sales, 1))
.reduceByKey(lambda a, b: (a[0] + b[0], a[1] + b[1]))
.mapValues(lambda x: x[0] / x[1])
RDD → Spark SQL → Structured Streaming → Delta Lake(Transactional Storage) と
Sparkは処理を宣言的に書くことができ、パイプライン全体を簡潔に記述できるようになっていった
新しいデータが来たときに適宜更新したいなぁ
データパイプラインを作りたいなぁ
Structured Streaming
SELECT date, avg(sales)
FROM STREAM sales_data
GROUP BY date
クラウド上で
整合性を保ちつつ安全にデータを保存したいなぁ
SELECT date, avg(sales)
FROM sales_data
GROUP BY date
Spark SQL
処理をSQLで記載したいなぁ
手続き的ではなく、構造的に書きたいなぁ
data.groupBy(“date”) “region”)
.agg(avg(“sales”))
.writeStream
.mode(“append”)
.format(“delta”)
.table(“daily_sales”)
Delta Lake
Spark RDD](https://image.slidesharecdn.com/spark-declarative-pipeline-jedai-dais-recap-nttdata-250808064511-f03cb3d6/85/Spark-Declarative-Pipeline-JEDAI-DAIS-Recap-2-15-320.jpg)
開発中の新機能 Spark Declarative Pipeline に飛びついてみたが難しかった(JEDAI DAIS Recap#2 講演資料)
- 1. © 2025 NTT DATA Japan Corporation © 2025 NTT DATA Japan Corporation Data + AI Summit 2025を みんなで振り返ろう！#2 開発中の Spark Declarative Pipeline に飛びついてみたが 難しかった 2025年8月6日 NTTデータ OSSソリューション統括部 北波 紘子
- 2. © 2025 NTT DATA Japan Corporation 2 自己紹介 北波 紘子(キタバ ヒロコ) NTTデータ OSSソリューション統括部 業務： Databricks、Apache Spark、Hadoop を使用したプロジェクト支援、 最近は KVM 周りを触っている(主に UI ) 2023年にDatabricks Championを取得しました
- 3. © 2025 NTT DATA Japan Corporation 3 なぜ Data+AI Summit 2025 (DAIS 2025) に参加したのか？ Databricks、Apache Spark やデータ分析基盤にかかわる最新技術動向を得るため 昨年に引き続き、今年も現地参加した。 メイン会場：Moscone center Keynote (Moscone center 内) 昼食会場：Yerba Buena Gardens パーティ(Yerba Buena Gardens 内) セッション会場
- 4. © 2025 NTT DATA Japan Corporation 4 Question1. DAIS 2025 は何セッションあったでしょうか？
- 5. © 2025 NTT DATA Japan Corporation 5 Answer1. 715セッション 0 100 200 300 400 Technologies セッションのジャンル ※重複あり AI/BI Apache Iceberg Apache Spark DLT DSPy Databricks Apps Databricks SQL Databricks Workflows Delta Lake Lake Flow MLFlow Mosaic AI Unity Catalog AI/BI は昨年度に引き続き注目されている。 Apache Spark と Unity catalog が多くなった印象(自分の所感)
- 6. © 2025 NTT DATA Japan Corporation 6 聴講したセッション一覧 6/10(Tue) 6/11(Wed) 6/12(Thu) Open Source Unity Catalog Getting Started, Best Practices and Governance at Scale Keynote by Databricks Keynote by Databricks Breaking Silos: Enabling Databricks-Snowflake Interoperability With Iceberg and Unity Catalog What’s New in PySpark: TVFs, Subqueries, Plots, and Profilers What’s New in Apache Spark 4.0? Building Real-Time Sport Model Insights with Spark Structured Streaming The Upcoming Apache Spark 4.1: The Next Chapter in Unified Analytics Japan Closing Session Apache Iceberg with Unity Catalog at HelloFresh Lessons Leaned: Building a Scalable Game Analytics Platform at Netflix A Unified Solution for Data Management and Model Training With Apache Iceberg and Mosaic Streaming No More Fragile Pipelines: Kafka and Iceberg the Declarative Way Delta Kernel for Rust and Java Declarative Pipelines: What’s Next for the Apache Spark Ecosystem The Future of DSv2 in Apache Spark Incremental Iceberg Table Replication at Scale Spark メイン Unity Catalog と Iceberg メイン OSSチーム所属のため、 Apache Spark と Unity catalog・Apache Iceberg をメインで聞いた
- 7. © 2025 NTT DATA Japan Corporation 7 Question2. そもそも Apache Spark とはなにものでしょうか？
- 8. © 2025 NTT DATA Japan Corporation 8 Apache Spark とは • 大規模データのための並列分散処理フレームワーク • AMPLab ( UC Berkeley ) で開発スタート (2009年) • 処理機能を提供する • Spark そのものにデータをためておく機能はなく、処理するだけ • Spark は処理するサーバ台数を増やすことで性能向上を図る (スケールアウト) • 耐障害性を提供する • 障害発生時に自動的にリトライされ、処理を継続できる • ユーザが耐障害性を意識せずに処理を記述できる Answer2. Apache Spark は並列分散処理フレームワーク 分散ストレージ ( HDFS など) ① 基となる データを入力する ② 分散ストレージから データを読み込んで処理する ③ 処理した結果を 分散ストレージに保存する ④ 処理された データを利用する HDFS：Hadoop で利用される分散ストレージ 分散処理エンジン (データを処理するところ)
- 9. © 2025 NTT DATA Japan Corporation 9 処理の高速化・効率化 • データに対する反復処理や変換処理を高速化するために、 大規模なデータに対する複雑な処理を、高スループットかつ効率的に処理を実行する並列分散処理基盤を持つ • データに対してコレクション操作ができる (参考：処理モデルは RDD ( Resilient Distributed Dataset ) という部分故障への耐性を考慮した分散コレクション データ処理を繰り返して目的の結果が得られるように処理できる) • 現在はユーザがより使いやすい Spark SQL という データを疑似的にテーブル操作できる API を使ってのデータ処理が多い Apache Spark の特徴
- 10. © 2025 NTT DATA Japan Corporation 10 アプリケーション開発者目線の代表的な利点は3つである • DataFrame に対して SQL 操作のように記述できる( Spark SQL ) • Scala / Python / Java / SQL / HiveQL / R をサポートする。 Python の API として PySpark がある (特定の言語だけサポートするAPIもある) • 一台のマシンでは収まらないような大きなデータセットに対して試行錯誤できる環境が提供されている( Spark Shell ) コマンドラインを利用して試行錯誤を繰り返して開発できる Apache Spark の特徴 (アプリケーション開発者視点の利点) df.select(...).replace(...).groupBy(...).write.csv(...) フィルタして 加工して 集計して 結果を保存
- 11. © 2025 NTT DATA Japan Corporation 11 Spark 今までの経緯 参考：https://spark.apache.org/news/index.html 2012/1 Spark プロジェクトがスタート 2013/7 Spark が Apache に移行 2014/5 Spark 1.0 リリース 2016/10 Spark 2.0 リリース 2020/6 Spark 3.0 リリース 2025/5/29 Spark 4.0 リリース RDD の導入 API の提供 DataFrame API の導入 Spark SQL の強化 ストリーミング処理ができるように AQE が導入され クエリが動的に最適化できるように Pandas API の導入
- 12. © 2025 NTT DATA Japan Corporation 12 Spark4.0 のリリース概要 ジャンル 変更点 新機能 Spark Connect, ANSI Mode, Arbitrary Stateful Processiong V2, Collation Support, Variant Data Types, Pandas 2.x Support 拡張機能 Python Data Source APIs XML/Databricks Connectors and DSV2 Extension Delta 4.0 カスタム関数とプロシージャ SQL UDFs SQL Scripting Python UDTF Arrow optimized Python UDF PySpark UDF Unified Profiler 使いやすさ 構造化ログフレームワークなど
- 13. © 2025 NTT DATA Japan Corporation 13 Spark4.0 のリリース概要 ジャンル 変更点 新機能 Spark Connect, ANSI Mode, Arbitrary Stateful Processiong V2, Collation Support, Variant Data Types, Pandas 2.x Support 拡張機能 Python Data Source APIs XML/Databricks Connectors and DSV2 Extension Delta 4.0 カスタム関数とプロシージャ SQL UDFs SQL Scripting Python UDTF Arrow optimized Python UDF PySpark UDF Unified Profiler 使いやすさ 構造化ログフレームワークなど
- 14. © 2025 NTT DATA Japan Corporation 14 今年特に面白かった講演について 今年初めて発表！Spark4.1 の展望についての講演たち リリース時期は2026年頃といわれている 特に Spark Declarative Pipeline に興味を持った 世に情報があまりない機能が気になった 6つの大きなアップデート！ 1. Declarative Pipelines: バッチ・ストリーミング両対応 2. Real Time Streaming: Structured Streamingのリアル タイムモードの強化、長時間稼働でもログ容量を減らす改善 3. Gen AI: 自動コード生成、実行時インサイト取得、 機能展開の素早さ 4. Data Source APIs: 外部データソースとの入出力を担うAPIを 統一インタフェースで使用できるDSv2がSpark4.1の標準仕様になる 5. Foundation: 地理空間データ型のサポート基盤の整備 6. SQL Lang: 再帰 CTE や ANSI標準のSQL/PSMに準拠した SQLスクリプト機能と Stored Procedures をサポート
- 15. © 2025 NTT DATA Japan Corporation 15 Spark の進化の軌跡 rdd.mapValues(lambda sales: (sales, 1)) .reduceByKey(lambda a, b: (a[0] + b[0], a[1] + b[1])) .mapValues(lambda x: x[0] / x[1]) RDD → Spark SQL → Structured Streaming → Delta Lake(Transactional Storage) と Sparkは処理を宣言的に書くことができ、パイプライン全体を簡潔に記述できるようになっていった 新しいデータが来たときに適宜更新したいなぁ データパイプラインを作りたいなぁ Structured Streaming SELECT date, avg(sales) FROM STREAM sales_data GROUP BY date クラウド上で 整合性を保ちつつ安全にデータを保存したいなぁ SELECT date, avg(sales) FROM sales_data GROUP BY date Spark SQL 処理をSQLで記載したいなぁ 手続き的ではなく、構造的に書きたいなぁ data.groupBy(“date”) “region”) .agg(avg(“sales”)) .writeStream .mode(“append”) .format(“delta”) .table(“daily_sales”) Delta Lake Spark RDD
- 16. © 2025 NTT DATA Japan Corporation 16 sum_orders_df = spark.readStream.table(“customers_orders”) .from_json(…) .select(“…”) .filter(col(“price”) > 100) .join(spark.table(“sales”, on=“store_id”, how=“inner”)) sum_orders_df.writeStream .format(“delta”) .option(“…”, “…”) .table(“sum_orders”) .trigger(availableNow=True) .start() データパイプライン データパイプラインとは、一連の Dataset を作成し更新していくもの。 クエリ化 → Dataset にする…を繰り返して処理している sales_df = spark.read.csv(“sales.csv”) .filter(“id” > 100) sales_df.write.mode(“overwrite”) .saveAsTable(“sales”) customers_df = spark.readStream.format(“kafka”) .option(“…”, “…”) .load() customers_df.writeStream .format(“delta”) .option(“…”, “…”) .table(“customers_orders”) .trigger(availableNow=True) .start() クエリ クエリ sales customer_ord ers クエリ sum_orders Dataset Dataset Dataset イメージ図
- 17. © 2025 NTT DATA Japan Corporation 17 データパイプラインでバッチとストリーミングを簡単に組み合わせたい リアルタイム分析と過去データ分析を組み合わせてより精度の高い予測や異常検知などを行うため バッチでのクエリ実行とストリーミングでのクエリ実行を組み合わせたい要望も出てきた バッチで クエリ実行 ストリーミングで クエリ実行 Dataset Dataset ストリーミングで クエリ実行 バッチで クエリ実行 Dataset Dataset バッチで クエリ実行 ストリーミングで クエリ実行 Dataset Dataset 5分おきに実行 継続的に実行 30分おきに実行 継続的に実行 1時間おきに実行 継続的に実行 今まで OSS のワークフローオーケストレーションツールの Airflow によってスケジュール管理されてきたが、 スキーマ変更によるエラーなど課題があり容易にデータパイプラインを作成できない… ・・・
- 18. © 2025 NTT DATA Japan Corporation 18 また、もっとシンプルに書きたい 今までのデータパイプラインの実行方法 order_df = spark.readStream.format(“kafka”) .option(“…”,”…”) .load() .from_json(…) .select(…) .filter(…) order_df.writeStream .format(“delta”) .option(“…”, “…”) .outputMode(“…”) .table(“”) .trigger() .start() start によって宣言的な計画を実行 (この実行によってテーブルが作られる) 最終的にまとめた実行の命令を書かないとデータ検証できない。 コード上で逐次 start を呼ぶ実装と外部ツールでの二重管理になりがち・・・
- 19. © 2025 NTT DATA Japan Corporation 19 これらの問題を解決する Lakeflow Declarative Pipeline (LDP) の技術が Spark に導入！ Databricks のエンジニアが Spark に新機能 Declarative Pipeline を導入することで Spark で単一のコードでバッチ＆ストリーミング混在パイプラインを宣言的に扱える • SQL 形式でストリーミングテーブルの作成から、集計ビューの作成まで完結することが可能 • パイプラインの実行は spark-pipelines run というコマンドで開始可能 CREATE STREAMING TABLE sales AS SELECT * FROM STREAM json.`./sales` CREATE MATERIALIZED VIEW daily_sales AS SELECT date, sum(sales) FROM sales_table GROUP BY date こんな書き方で可能 Materialized view が SQL で定義することも可能になった！ Datasetの種類の補足 STREAMING TABLE : データの増分処理をサポートするテーブル MATERIALIZED VIEW : テーブルに事前計算されたビュー TEMP VIEW : パイプライン内にスコープが限定されたビュー
- 20. © 2025 NTT DATA Japan Corporation 20 Databricksや他のサービスとSpark Declarative Pipeline(SDP)の比較 vs Databricks の Lakeflow Declarative Pipeline (LDP) LDP も Keynote で発表されていました！ • SDP で書かれたコードは LDP でも動くので移植性あり • SDP は全ての LDP の API に対応できていない (が、今後範囲は拡大する) • LDP はパイプラインのマネージメントサポートがある vs data build tool (dbt) SDP dbt 実行場所 Apache Spark SQLウェアハウス 言語 Python/SQL/Scala/Java SQL 処理形式 バッチ、ストリーミング バッチ 対象者 データエンジニア データサイエンティスト 参考：https://www.databricks.com/product/data-engineering/lakeflow-declarative-pipelines
- 21. © 2025 NTT DATA Japan Corporation 21 実際にどんな改修がされているのか確認してみた 実際の開発状況は https://issues.apache.org/jira/browse/SPARK-51727 で確認可能
- 22. © 2025 NTT DATA Japan Corporation 22 実際にどんな改修がされているのか確認してみた 現在 master ブランチにマージされているものは以下 宣言的パイプラインのための API • Python APIs・・・ PySpark でパイプライン構築が可能に • SQL 構文サポート(https://github.com/apache/spark/pull/50875) • (今後対応) Scala/Java APIs • Theoretically any language (※Spark Connect) パイプラインランナー • コマンドラインインタフェース • グラフ実行トリガ CREATE MATERIALIZED VIEW mv1 AS SELECT …; CREATE STREAMING TABLE st1 (…) AS SELECT …; CREATE FLOW flow1 AS INSERT INTO …; という宣言的パイプライン定義ができ、spark-pipelines runで実行可能に
- 23. © 2025 NTT DATA Japan Corporation 23 Spark Declarative Pipeline の概念 パイプライン ストリーミングクエリ バッチクエリ Dataset Streaming table: データの増分処理をサポートするテーブル Materialized view: テーブルに事前計算されたビュー Temp view: パイプライン内にスコープが限定されたビュー Dataset Dataset Dataset バッチクエリ Dataset バッチクエリ 矢印: Flow データ処理概念 ストリーミングとバッチの両方をサポート Flow はソースからデータを読み取り、 ユーザ定義の処理ロジックを適用し、結果を Dataset に書き込む 開発と実行の主要な単位 実行順序と並列化が自動的に調整される パイプラインを定義するのが、パイプラインプロジェクト パイプラインを構成するデータセットとフローを定義するコード を含むソースファイルのセットのこと
- 24. © 2025 NTT DATA Japan Corporation 24 Spark Declarative Pipeline の利用手順 Spark Declarative Pipeline を実行するためのソースコードの設計の流れの例・概要( Python を想定) Spark 環境をビルドする Spark ディストリビューションを 作成する 手順参考：https://github.com/apache/spark/blob/v4.1.0-preview1-rc1/docs/building-spark.md パイプラインをyamlファイル で定義 パイプラインに組み込む ***.pyファイルの作成 パイプラインに組み込む ***.sqlファイルの作成 spark-pipelines init <パイプライン名> コマンドで パイプラインプロジェクトを作成する spark-pipelines runコマンドで パイプラインを実行する 実行結果を確認する 出力先を指定しない際は デフォルトでパイプラインプロジェクト直下の spark-warehouse フォルダに Materialized view 含め実行結果が格納される ユーザ側の手順 デコレータなどで Materialized view などを定義 読み込む対象のファイルを定義
- 25. © 2025 NTT DATA Japan Corporation 25 Spark Declarative Pipeline の内部構造 デコレータで定義 → モデルオブジェクト生成 → レジストリ登録 → パイプライン実行 → CLI が一気通貫で構成されている。 api.py type_error_utils.pyや source_code_location.py block_connect_access.py flow.pyやdataset.py graph_element_registry.pyや spark_connect_graph_element_registry.py spark_connect_pipeline.py cli.py init_cli.py Models Utilities Registry @table, @materialized_view などの ユーザ向けデコレータや関数群が 定義されている デコレータが呼ばれるたびに登録された パイプラインのデータフローグラフを サーバに作成・実行し、 イベントをハンドリングする 実行コマンドのエントリポイント spark-pipelines run/init を定義している デコレータが呼ばれたタイミングで Dataset の型定義をしたり、 各ステップの名称やロジックを定義する Dataset/Flow を受け取ったり、 gRPC で Spark Connect サーバに 宣言的定義を連携する ユーザの実行や実装に責務 がある範囲
- 26. © 2025 NTT DATA Japan Corporation 26 実際に動かしてみる ローカルでビルドして、Spark Declarative Pipeline を試してみた。 対象： 4.1.0-rc1 https://github.com/apache/spark/tree/v4.1.0-preview1-rc1 環境：Java 21、maven 3.9.9、Python3.13 言語：Python デモしたかったがビルドに 30-40分かかるため割愛
- 27. © 2025 NTT DATA Japan Corporation 27 試してみた① (ビルド～パイプラインプロジェクト作成まで) ./build/mvn -DskipTests -Denforcer.skip=true -Phadoop-3 -Dhadoop.version=3.4.0 clean package ビルド Spark のホームディレクトリ配下 ./dev/make-distribution.sh --name custom-spark(任意) --pip --tgz ディストリビューション作成 Spark のホームディレクトリ配下 ./bin/spark-pipelines init --name my_pipeline(任意) パイプラインプロジェクト作成 Spark のホームディレクトリ配下 spark ディレクトリ直下に spark-4.1.0-preview1-bin-custom-spark.tgz が生成される。 Spark のホームディレクトリにコピーして解凍する ※ライブラリインストール手順については割愛 以下の構成のフォルダ・ファイルが作成される。 パイプライン実行のための Python/SQLのサンプルファイル パイプライン定義ファイル pipe_line.ymlの中身:
- 28. © 2025 NTT DATA Japan Corporation 28 試してみた① (パイプラインの中身確認～サンプルパイプライン実行まで) transformations フォルダとその配下にパイプライン実行のためのサンプルファイルが作成される example_python_materialized_view.py example_sql_materialized_view.sql パイプラインで実行する対象のサンプルファイル サンプルパイプラインの概要: Python 側で作成した Materialized view を、 SQL 側が参照して id が偶数のレコードのみ抽出するパイプライン ./bin/spark-pipelines run パイプライン実行 Spark のホームディレクトリ配下 my_pipeline配下に、spark-warehouse フォルダが作成され、Materialized view や出力結果が保存される 次のページ ※注意：再度実行時に過去に作成された Pipeline との不整合でエラーが出た場合は spark-warehouse を rm –r でリセットすること example_python_m aterialized_view example_sql_ma terialized_view パイプラインの構成 SELECT クエリ
- 29. © 2025 NTT DATA Japan Corporation 29 試してみた① (実行結果確認) • 出力結果 • Materialized view の中身 python 側： sql 側： 期待通り、 偶数のレコードのみ抽出されている
- 30. © 2025 NTT DATA Japan Corporation 30 試してみた② (自分でパイプラインファイルを作成) ストリーム処理の効果について確認したかったため、自分でパイプラインファイルを作成した パイプラインの概要: ソケット(port 9999)を利用してcsv形式の データをテーブルとして登録する 作成したパイプラインファイル 1_source.py 2_agg.sql 3_sink.py vehicle_count_mate rialized_view パイプラインの構成 SELECT クエリ vehicle_result vehicle_info SELECT クエリ ストリーム
- 31. © 2025 NTT DATA Japan Corporation 31 試してみた② (パイプライン実行) ※別のウィンドウで nc -lk 9999 でソケットを待ち受ける必要がある ./bin/spark-pipelines run パイプライン実行 Spark のホームディレクトリ配下 問題：エラーなく動作は完了するが、連続で走行せずにそのまま終了してしまう 以下のように出力結果のファイルは作成される (中身は空): 疑問と今後の調査ポイント： Structured Streaming では awaitTermination をコールして起動し続けられるが、 それに相当するオプションをオンにする必要がある？ Spark Declarative Pipelineでは何がそのオプションにあたるか調査が必要
- 32. © 2025 NTT DATA Japan Corporation 32 試してみた感想 Spark Declarative Pipeline に飛びつくのが早すぎた。以下理由： • まだ開発中のため、未実装の機能や動作方法が不明なものがある • dry-runは（少なくともCLIにおいては）実装されていないが、ドキュメントには dry run が紹介されている 動かしてみて良かったなと思った点： • collect(), count(), save(), start() といった Action 系の処理はパイプラインに組み込まなくてもよくなったこと。 今までは Action 系の処理を入れないとデータ検証できなかったが、意味のない count が削除できそうなこと (入れなくてもデータ検証できる) cli.py: error: argument command: invalid choice: 'dry-run' (choose from run, init)
- 33. © 2025 NTT DATA Japan Corporation 33 今後の Spark Declarative Pipeline のロードマップについて • 大きなデータセットやクエリのなかから、一部分を切り出して実行できるようにする • 永続的なビュー対応 • ジョブやワークフローの継続実行 • 外部の出力先に対応する • マテリアライズドビューをカタログ API 経由で管理できるようにする
- 34. © 2025 NTT DATA Japan Corporation 34 まとめ DAIS での発表や今回の調査について： • DAIS では開発者の講演を直接聞くことができ、さらに質問の機会も多くあり、非常に貴重で学びが多かった • Databricks や Spark は開発が活発！今年の発表を受けて特に気になった機能については、Spark コミュニティの活 動状況を継続的に追いかけるきっかけになった。この点でも、大変有意義な機会だった • ただまだ開発中の機能も多いため、今後のアップデートは随時確認が必要 DAIS 現地で感じたこと： • 昨年に比べて「オープン化」が大きく注目されており、特に Iceberg や Spark に多くのスポットライトが当たっていたのが印象 的だった。（昨年度の Keynote ではほとんど言及されていなかった点からも、今年は潮流の変化が感じられた） • 特定のベンダーへの依存を避けたいというニーズがあり、それに対応できる柔軟性が今後ますます求められていくのではないかと 感じた • Databricks も、オープン性の重要さを強調しており、今後の方向性として「オープンであること」がますます鍵になっていくと予 想される
- 35. © 2025 NTT DATA Japan Corporation 35 さいごに なにか質問があれば、 JEDAI の Discord の Hiroko Kitaba ( @hirokokitaba_82269 ) に連絡をお願いします！ 日々の励みになります！