Databricks Declarative Pipelines (Delta Live Tables) と Workflows の使い分け・設計判断

Databricksでデータパイプラインを構築する際、Lakeflow Declarative Pipelines（旧Delta Live Tables / DLT）とWorkflows（Jobs）のどちらを使うべきか、あるいは併用すべきかは頻出の設計判断です。 DLTは「何をしたいか」を宣言する方式で、データ品質や依存関係をフレームワークが自動管理します。 Workflowsは「どう実行するか」を命令する方式で、任意のタスクをDAGで組み合わせて柔軟にオーケストレーションします。

本記事では両者を実行モデル・エラー処理・データ品質・コストの4軸で比較し、併用パターンと選択判断フローを整理します。

DLT vs Workflows：主要観点の比較

DLTの基本構文：宣言的なテーブル定義

DLTでは「このテーブルはこのソースからこう変換して作る」と宣言するだけで、依存関係の解決・増分処理・スキーマ進化をフレームワークが管理します。

import dlt
from pyspark.sql.functions import col, current_timestamp

@dlt.table(comment="Bronzeレイヤー：生データ取り込み")
def bronze_orders():
    return (
        spark.readStream
        .format("cloudFiles")
        .option("cloudFiles.format", "json")
        .load("/mnt/landing/orders/")
    )

@dlt.table(comment="Silverレイヤー：クレンジング済み")
@dlt.expect_or_drop("valid_amount", "amount > 0")
def silver_orders():
    return (
        dlt.read_stream("bronze_orders")
        .select("order_id", "customer_id", "amount", "region",
                current_timestamp().alias("processed_at"))
        .filter(col("order_id").isNotNull())
    )

@dlt.table(comment="Goldレイヤー：集約")
def gold_revenue_by_region():
    return (
        dlt.read("silver_orders")
        .groupBy("region")
        .agg({"amount": "sum"})
        .withColumnRenamed("sum(amount)", "total_revenue")
    )

dlt.read_stream()でストリーミング読み取り、dlt.read()でバッチ読み取りを指定します。 テーブル間の依存はread/read_streamの参照先から自動的に解決されるため、実行順の指定は不要です。

Workflowsの基本構造：マルチタスクDAG

Workflowsはタスクの依存関係をDAG（有向非巡回グラフ）として定義します。 各タスクにはノートブック、Pythonスクリプト、JARファイル、DLTパイプライン、dbtプロジェクトなどを指定でき、 異なるコンピュートリソースを割り当てることも可能です。

# Workflows のDAG構造の概念
#
# [extract_task] ──→ [dlt_pipeline_task] ──→ [notify_task]
#       │                                         ↑
#       └──→ [validate_source_task] ──────────────┘
#
# - extract_task: 外部APIからデータ取得（Pythonノートブック）
# - dlt_pipeline_task: DLTパイプラインでETL（タスクタイプ: Pipeline）
# - validate_source_task: ソースデータの疎通確認
# - notify_task: Slack通知（成功/失敗を条件分岐で制御）

Workflowsの強みは、タスクごとにリトライ回数・タイムアウト・条件分岐（if/else/for_each）を設定できる柔軟性です。 MLモデルの学習、外部APIの呼び出し、通知といったデータ変換以外のタスクも統合管理できます。

併用パターン：Workflows × DLT

実務で最も多いのは、WorkflowsのDAG内の1タスクとしてDLTパイプラインを組み込む併用パターンです。 DLTにはETLの変換・品質管理を任せ、Workflowsには前後処理のオーケストレーションを担当させます。

この構成では、DLTパイプラインの成功/失敗がWorkflowsのタスクステータスとして伝搬するため、 後続タスクの条件分岐やリトライ設定と組み合わせた高度なエラーハンドリングが可能です。

選択判断フロー

DLTとWorkflowsの選択は、パイプラインの性質とチームのニーズに応じて判断します。

パイプラインの中心はテーブル変換（ETL/ELT）か？
├─ YES → データ品質管理（Expectations）が必要か？
│    ├─ YES → DLTを使う（Workflowsと併用も検討）
│    └─ NO  → シンプルならWorkflows単体、複雑ならDLTを検討
└─ NO  → MLトレーニング・外部API・通知など多様なタスクか？
     └─ YES → Workflowsを使う（ETL部分があればDLTを併用）

• テーブル変換中心 + 品質管理が必要 → DLT（単独 or Workflows併用）
• 多様なタスクのオーケストレーション → Workflows
• ETL + ML + 通知を統合 → Workflows + DLTパイプラインタスク
• 単純なノートブック1本の定期実行 → Workflowsで十分

コスト面の違い

DLTはDLT専用のDBU単価が適用され、通常のJobs Compute DBUより単価が高くなります。 ただしDLTはEnhanced Autoscalingによるクラスタ最適化やincremental処理の自動化を行うため、 手動で同等の機能を実装した場合の開発コスト・運用コストとの総合比較が必要です。

試験で問われるポイント

• DLTが「宣言型」でWorkflowsが「命令型」であることの具体的な違い
• データ品質管理はDLTのExpectationsが組み込みで提供し、Workflowsには組み込みの品質機能がないこと
• WorkflowsのタスクとしてDLTパイプラインを実行できること（併用パターン）
• DLTは依存関係を自動解決するがWorkflowsはDAGで明示的に定義すること
• DBU単価の違い（DLT ＞ Jobs Compute）

問題で確認

よくある質問