Databricks. 2025.『データエンジニアリングのためのコンパクトガイド』では次のように述べられています。
パイプラインを宣言的に定義し、構築・運用ができるETLフレームワーク。
ストリーミングとバッチ処理における ETL の簡素化、コスト効率化を可能にする。
データに対して実行する変換を定義するだけで、 DLT パイプラインが自動的にタスクオーケストレーション、クラスタ管理、モニタリング、データ品質／エラー管理を行います。エンジニアはデータをコードとして扱い、テスト、エラー処理、モニタリング、ドキュメンテーションなどのソフトウェアエンジニアリングの最新のベストプラクティスを適用し、大規模な高信頼性データパイプラインを構築できます。
DLT は、 Python と SQL をサポートし、ストリーミングとバッチのいずれのワークロードにも効果的に対応します。
ただ、上記説明だと私には理解できなかったため、私なりに噛み砕いたことを下に書きました。Delta Live Tables = DLT として書いてます。
宣言型だとDLTにとって何がいいの？
下記は、ざっくりとした私の理解です。
DLTは「宣言型」がキーワードとなります。
宣言型に対して命令型というワードがよく出ます。下記のコードを読んだりしましたが、どうも宣言型と命令型の違い・宣言型であるDLTの何がいいのかが分かるようで腑に落ちない感じが続いていました。
改めて考え直したところ、以下のように具体例上げて噛み砕くと腑に落ちました。
命令型と宣言型を「業務での上司から部下への指示の出し方」に例えると、
- 命令型
- 一つ一つの手順を詳細に説明する指示
- 宣言型
- やってほしいことやプロジェクトの目的を伝えるだけ
この例えで考えると、宣言型で業務を遂行する部下の方が優秀でありがたいと捉えられました。
例えを踏まえて話をDLTに戻すと、ETLパイプラインを宣言的に書けるDLTの特徴を一言で表すと、抽象化であり、命令型で記述するような細かい処理はDLTがよしなにやってくれる、と言えると思います。
そのためデータエンジニアは何をしたいかに集中できます。
これを踏まえて、もう一度冒頭の引用文を読むと頭に入ってくるようになりました。
命令型プログラミングとDLTを用いた宣言型プログラミング比較
本内容はPDF｜ストリーミングをシンプルに！Delta Live Tables（Databricks Japan, 2025）を参考にしています。
Spark命令型プログラム
date = current_date()
spark.read.table("orders")
.where(s"date = $date")
.select("sum(sales)")
.write
.mode("overwrite")
.replaceWhere(s"date = $date")
.table("sales")
※ちなみに、この操作はDelta Lakeのような[[トランザクション]]対応のデータレイクに対して行われている。
ちなみに、処理としては以下の3つ。
- 今日の注文データを取得
- 売上合計を計算
salesテーブルの「今日の分だけ」置き換えて書き込む
つまり、
「最新の売上合計を計算して、salesテーブルの該当日付パーティションだけを更新するETL処理」
DLT宣言型プログラム
create materialized view sales
as select date, sum(sales)
from orders
group by date
orders テーブルから日付ごとの売上合計を計算し、sales という[[マテリアライズ・ドビュー]]を作るという処理
create materialized viewはDatabricksで使えるクエリ。（参考：https://docs.databricks.com/aws/en/sql/language-manual/sql-ref-syntax-ddl-create-materialized-view）
命令型（Imperative）と宣言型（Declarative）の違いまとめ
ChatGPTにまとめてもらった表です。
| 観点 | 命令型（Spark） | 宣言型（DLT） |
|---|---|---|
| 書き方 | 「どう処理するか」をコードで指定（for文・write操作など） | 「何をしたいか」だけをSQLまたはデコレーターで宣言 |
| 処理責任 | 開発者が処理順序・依存関係・再試行・チェックポイントを管理 | DLTが自動的に依存関係を解決し、再試行や品質検証も実行 |
| 更新方法 | 自分で .write や .replaceWhere などを制御 |
DLTランタイムが最適な方法（インクリメンタル or フル）を自動選択 |
| 規模拡張 | スクリプト管理が増えると複雑化 | テーブル同士の依存関係グラフ（[[DAG]]）で自動管理される |
ワークフローとDLTの棲み分け
本内容はPDF｜ストリーミングをシンプルに！Delta Live Tables（Databricks Japan, 2025）を参考にしています。
DLTはワークフローの一部。
- ワークフローの役割
- スケジューリング
- オーケストレーション
- DLT
- データフロー管理
- デルタテーブルの作成・更新
- 構造化ストリーミングの実行
- cloudFiles