Apache Airflow®からDatabricks Lakeflow Jobsへの移行方法

In the previous post, From Apache Airflow® to Lakeflow: Data-First Orchestration, orchestration was reframed around data and the lakehouse instead of external schedulers. This post builds on that foundation and focuses on execution details for teams already running Airflow in production and wishing to move to Databricks’ native orchestrator, Lakeflow Jobs.

This guide is written both for practitioners migrating from Airflow and for programming agents generating Lakeflow Jobs workflows. The goal is to show how those same workflows can be expressed naturally when orchestration is part of the lakehouse itself within Databricks.

Airflow to Lakeflow Jobs migration map

The table below summarizes how common Airflow orchestration patterns translate to Lakeflow Jobs, and whether the migration is a direct translation or a conceptual refactor.

Migration strategy: incremental, not all at once

Most teams migrate incrementally rather than replacing Airflow wholesale. Common approaches include:

• Starting with self-contained or event-driven workflows
• Migrating file arrival and data-driven triggers early
• Keeping stable Airflow pipelines unchanged initially
• Avoiding rewrites of mature, low-risk jobs

Lakeflow Jobs is designed to coexist during migration and to take over orchestration responsibilities where it adds the most value.

Checklist

• XComs with small metadata → task values; XComs with data → Unity Catalog tables or volumes.

• File sensors/assets → file arrival or table update triggers where data is in UC.

• Execution‑date macros (ds, etc.) → explicit parameters + backfill runs.

• Branching (@task.branch) → condition tasks.

• Dynamic task mapping → for‑each tasks where fan‑out is data‑driven.

• (Optional) Jobs and schemas managed via Python Asset Bundles for consistent environments.

Lakeflow Jobs overview

When migrating from Airflow, it is useful to internalize a few core assumptions that shape how Lakeflow Jobs works:

Control plane vs data plane 

Operations in the data plane (queries, reads, writes, and transformations) drive compute usage. Control-plane operations such as triggers, task values, and parameters do not.

Jobs are the unit of orchestration

• Jobs encapsulate tasks and dependencies; coordination across jobs typically uses data (tables, files), not cross‑DAG signals
• This shifts designs from “DAG talking to DAG” to “producer writes a table, consumer job triggers when that table changes.”
• A Run Job task exists for cases where job-to-job invocation is intentional, but it complements rather than replaces the data-driven coordination model.

Triggers are first-class

• File arrival and table update triggers are built-in features, not implemented via long-running sensors.
• This shifts orchestration from polling-based to event-driven by default.

These assumptions explain why some Airflow patterns translate directly, while others are intentionally simplified or replaced.

Migration steps

1. XComs to task values for control, tables for data

Airflow: XComs for small control metadata

In Apache Airflow, XComs are used to pass small pieces of metadata between tasks within a DAG run. A minimal Airflow example that passes a small value between tasks:

This works well for small IDs, values, flags, and counts but becomes hard to reason about when many tasks rely on XComs or when large payloads are pushed.

Lakeflow: task values for control, tables for data

In Lakeflow Jobs, task values play the XCom role for control metadata. Jobs and tasks are typically defined via asset bundles, and their implementations live in notebooks or Python files. Bundle snippet (Python) defining two tasks and a dependency:

Producer notebook:

Consumer notebook:

タスクの値は、実行ごとのLakeflow Jobs UIで確認でき、小さなペイロードに限定されるため、フラグ、カウンター、IDに最適です。より大きなオブジェクトや再利用可能な出力については、タスクは Unity Catalogテーブルまたはビューに書き込む必要があります。

💡 経験則: タスクの値は制御メタデータにのみ使用し、データのように見えるものはすべてテーブル、ビュー、またはボリュームに格納してください。

移行のヒント

• シンプルなXCom → タスクの値。
• データフレームや大きなJSONを渡すXCom → 代わりにUnity Catalogへの読み書きを行います。
• XComを多用するDAGの再現は避け、レイクハウスを共有状態として活用してください。

2. センサーとアセットからファイルおよびテーブルトリガーへ

Airflow: ファイルセンサーとアセット

ファイル駆動型パイプラインの典型的なAirflowパターン:

これにより、ワーカーのスロットがポーリングに専有され、複数のコンシューマーが同じデータに依存する場合、カスタムアセット追跡と組み合わされることがよくあります。

Lakeflow: ファイル到着トリガー

ファイル到着トリガーを示すスニペット

ノートブックの実装

プラットフォームはトリガーの状態、デバウンス、クールダウンを処理するため、ファイル監視のための長時間実行センサーや外部スケジューラは不要になります。

Lakeflow: テーブル更新トリガー（アセットスタイルのスケジューリング）

プロデューサーがUnity Catalogテーブルに書き込むと、コンシューマーは時間ベースのスケジュールではなく、テーブルの更新をトリガーできます。

💡経験則:可能な限りファイル到着またはテーブル更新でジョブをトリガーし、スケジュールは本当に必要な場合にのみ使用してください。

移行のヒント

• ファイルセンサー → UCの場所またはボリュームでのファイル到着トリガー。
• アセットレジストリ → テーブル更新トリガーを持つUnity Catalogテーブル。
• 非データイベント → 明示的な外部トリガーまたはパラメータ。

3. 実行日からパラメータとバックフィル実行へ

Airflow: 実行日と ds

Airflowは実行日によるテンプレートロジックを推奨しています:

バックフィルはAirflowのスケジューラと実行日によって駆動され、ロジックは暗黙的に時間のスケジューラ概念に依存します。

Lakeflow: 明示的なパラメータとバックフィル

Lakeflow Jobsでは、「論理実行日」はパラメータとしてモデル化されるべきです。パラメータを持つジョブ定義（バンドル）:

注:  Airflowスタイルの {{ds}} または {{ execution_date }} を例のハードコードされたデータではなく使用したい場合は、 {{ job.trigger.time.iso_date }} を使用することもできます。

SQLはパラメータを使用します:

バックフィルするには、パラメータ値のセットを定義し、UIまたはAPI経由でそれらをバックフィル実行しますが、暗黙的なスケジューラキャッチアップに依存するのではなく、パラメータは一度定義され、バックフィル実行をトリガーする際に実行時にオーバーライドされます。

💡経験則:時間をデータとして扱い、パラメータとしてモデル化し、タスクに明示的に渡し、パラメータ範囲でバックフィルを駆動してください。

移行のヒント

• パラメータ（例: :run_date）で {{ ds }}および関連マクロを置き換えます。
• 特定のパラメータセットに対してタスクを冪等にし、バックフィルを安全に保ちます。
• スケジューラ駆動のキャッチアップロジックを再作成するのではなく、Lakeflowバックフィル実行を使用します。

4. 分岐と動的マッピングから条件付きおよびfor-eachタスクへ

Airflow: 分岐と動的タスクマッピング

@task.branchによる分岐:

expand()を使用した実行時のファンアウトのための動的タスクマッピング:

Lakeflow: condition tasks

Lakeflow Jobsは、データに基づいた分岐のために条件タスクを使用します

check_quality notebookはタスク値をエクスポートします:

グラフは分岐を明示的に示しており、決定ロジックは、埋め込まれたPython制御フローではなく、データ（タスク値）を介して表現されます。

💡目安: パラメータまたはタスク値に対するブール式がパスを決定する場合、条件タスクを使用します。

Lakeflow: ランタイムのファンアウトのためのfor-eachタスク

For-eachタスクは、タスクカウントがランタイムデータに依存する場合にファンアウトを実装します。

generate_items notebook:

process_item notebookは現在のアイテムを次のように認識します:{{input}}（言語ラッパーによっては同等のランタイム変数）。

💡目安: ファンアウトがランタイムデータによって駆動される場合はfor-eachを使用します。ファンアウトが設計時に固定されている場合はタスクを静的に保ちます。

移行のヒント

• @task.branch → タスク値またはパラメータを使用した条件タスク。
• 動的なタスクマッピング → タスク値またはテーブルによって駆動されるfor-eachタスク。
• 大規模なイテレーションメタデータ → テーブル/ボリューム。小規模なID/インデックス → タスク値。

5. (オプション) Pythonアセットバンドルを使用したプログラムによる生成

多くのAirflowデプロイメントでは、DAGを動的に生成し（テーブルまたはSQLファイルごとに1つのDAG）、規約とスクリプトを通じて環境の違いを管理しています。Pythonアセットバンドルは、ジョブと関連リソースをプログラムで生成するための構造化された方法を提供します。

例: SQLファイルごとのジョブ:

これをミューテータと組み合わせることで、環境ごとに通知、実行ID、または再試行を調整し、ジョブ定義をPythonに保ちながら標準を一元化できます。

💡目安: プログラムによる生成は、プラットフォームの規約をコード化するために使用し、場当たり的なハックを隠すために使用しないでください。

次のステップ

現在Airflowを実行している場合は、センサー、XCom、または動的なタスクマッピングに依存するDAGを1つ選び、トリガー、for-eachタスク、および明示的なパラメータを使用して再実装してください。これにより、通常はLakeflow Jobsのメンタルモデルを内部化するのに十分です。

• このガイドで使用されている完全な動作例をクローンして実行します

• データファーストオーケストレーションについてさらに学ぶ

• Lakeflow Jobsドキュメントを探索する

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