Databricks Certified Data Engineer Associate 教科書
第4章 Lakeflow Jobsによるオーケストレーション(Working with Lakeflow Jobs, 16%)
🎯 この節の学習目標
Lakeflow Jobs(旧 Databricks Workflows / Jobs)は、Databricks に組み込まれたマネージドなオーケストレーションサービスです。データの取り込み・変換・集計・可視化といった一連の処理を「いつ・どの順序で・どの計算資源で実行するか」を定義し、自動実行してくれます。外部のオーケストレーションツールを別途構築・運用しなくても、Databricks 内で完結したパイプライン運用ができる点が特長です。
試験問題では旧称の Databricks Workflows や単に Jobs という名称で出題される可能性があります。「Workflows でジョブを作成する」「Jobs UI でタスクを追加する」といった表現が出てきても、本章で学ぶ Lakeflow Jobs と同じものを指しています。ジョブ・タスク・依存関係などの概念はそのまま対応します。
現在の正式名称は Lakeflow Jobs で、Lakeflow というデータエンジニアリング製品群(Lakeflow Connect / Lakeflow Spark Declarative Pipelines / Lakeflow Jobs)の一角に位置づけられています。UI 上は「ジョブとパイプライン(Jobs & Pipelines)」という画面から作成・管理します。機能面は旧 Workflows を引き継ぎつつ、制御フローやトリガーの種類が拡充されています。
Lakeflow Jobs の基本の単位は次の2つです。
| 概念 | 役割 |
|---|---|
| ジョブ(Job) | 実行の最上位単位。トリガー(スケジュール等)、通知、同時実行数などの設定を持ち、1つ以上のタスクを束ねる |
| タスク(Task) | ジョブの中の個々の処理ステップ。ノートブック実行、SQL実行などの「タスクタイプ」と、実行に使う計算資源、依存関係(depends_on)を持つ |
つまり「ジョブ=複数タスクを依存関係で結んだ実行単位」です。タスク同士の依存関係が全体としてDAG(Directed Acyclic Graph:有向非巡回グラフ)を形成します。「非巡回」なので、タスクAがタスクBに依存し、同時にタスクBがタスクAに依存する、といった循環は定義できません。
1つのジョブの中で、性質の異なる処理を組み合わせられるのが Lakeflow Jobs の強みです。試験で押さえておきたい主要タスクタイプは次のとおりです。
| タスクタイプ | 実行内容 | 典型的な用途 |
|---|---|---|
| ノートブック | ワークスペースまたは Git 上のノートブックを実行する | データ取り込み、前処理、アドホックなロジックの定期実行 |
| SQL | 保存済みの SQL クエリやファイルを SQLウェアハウスで実行する | ゴールド層の集計、品質チェッククエリの実行 |
| パイプライン | Lakeflow Spark Declarative Pipelines(第3章)のパイプラインを起動する | ブロンズ〜シルバーの宣言的な変換処理をジョブの一部として実行 |
| ダッシュボード更新 | AI/BI ダッシュボードのデータを最新化する | 集計完了後にダッシュボードを更新して閲覧者に最新値を見せる |
| その他 | Python スクリプト、Python wheel、dbt、JAR、別ジョブの実行(Run Job)、条件分岐(If/else)、繰り返し(For each)など | 既存資産の再利用や制御フロー(4-2 で詳述) |
📝 試験のポイント
「宣言的なパイプライン(Lakeflow Spark Declarative Pipelines)を、他の処理と組み合わせて定期実行したい」という要件では、ジョブの中にパイプラインタスクを組み込むのが正解の方向です。パイプライン自体にもスケジュール実行の仕組みはありますが、「ノートブックでの後処理」「SQL集計」「ダッシュボード更新」などと依存関係で結んで一連の流れとして実行するには、Lakeflow Jobs がオーケストレーターの役割を担います。
タスクには depends_on(依存先タスク)を指定できます。依存先のタスクがすべて完了してから、そのタスクが開始されます。逆に、互いに依存関係のないタスクは並列に実行されます。これにより「直列にしか流せないパイプライン」ではなく、「依存のない部分は同時に走る効率的なグラフ」を構成できます。
💡 具体例:日次売上パイプラインのタスクグラフ
ある小売業のデータチームが、毎日の売上データを処理するジョブを考えます。(1)取り込みノートブックで生データをブロンズ層へ、(2)変換パイプラインでシルバー層まで整形、(3)その後は「SQLでのゴールド集計」と「データ品質チェック」を並列に実行し、(4)両方が終わったらダッシュボードを更新します。
図:依存関係(depends_on)で構成した DAG。③と④は依存関係がないため並列に実行される
この図のポイントは次の3つです。
タスク間では、task values という仕組みで小さな値を受け渡せます。上流のノートブックタスクで dbutils.jobs.taskValues.set(key="processed_date", value="2026-08-19") のように値をセットし、下流タスクで dbutils.jobs.taskValues.get(taskKey="ingest", key="processed_date") のように取得します。処理対象日やレコード件数のようなメタ情報の受け渡しに使うもので、大量データの受け渡しはテーブル経由で行うのが原則です。task values は 4-2 で学ぶ条件分岐(If/else)の判定材料にもなります。
1-3 で学んだとおり、計算資源にはAll-purpose クラスタ(対話的開発用)とJob クラスタ(ジョブ実行用)がありました。Lakeflow Jobs のタスクを実行する際の推奨は Job クラスタです。
📝 試験のポイント
「本番の定期ジョブを最もコスト効率よく実行する計算資源は?」という問いには、Job クラスタが正解の軸になります。All-purpose クラスタでジョブを回すのは、単価が高く、消し忘れによる無駄な課金も起きやすいため、本番運用では避けるべき構成として誤答選択肢に登場します。
✅ この節のまとめ
depends_on で依存関係を定義する。依存のないタスク同士は並列実行され、複数タスクに依存するタスクは全依存先の完了を待つ。問1. Lakeflow Jobs における「ジョブ」と「タスク」の関係の説明として正しいものはどれか。
正解:B
ジョブが上位、タスクが下位の概念で、ジョブは複数タスクを depends_on で結んだ DAG として構成されます。Aは両者の区別ができておらず、Cは「複数タスクを1ジョブに束ねられる」という Lakeflow Jobs の中核機能を否定しています。Dは上下関係が逆です。
問2. あるジョブで、タスクCがタスクAとタスクBの両方に依存している(AとBの間に依存関係はない)。このジョブの実行順序として正しいものはどれか。
正解:B
依存関係のないAとBは並列に実行され、Cはすべての依存先(AとB)の完了を待って開始されます。Aは「依存がなければ並列に走る」という DAG 実行の利点を見落としています。Cのような「どちらか一方の完了で開始」は既定の動作ではありません。Dは依存の向きが逆です。
問3. Lakeflow Spark Declarative Pipelines のパイプラインを、前処理ノートブックの完了後に実行し、その後 SQL 集計とダッシュボード更新まで一連の流れとして自動実行したい。最も適切な構成はどれか。
正解:B
種類の異なる処理を依存関係で結んで自動実行するのは、まさに Lakeflow Jobs の役割です。パイプラインは「パイプラインタスク」としてジョブに組み込めます。Aは手動運用で自動化の要件を満たしません。Cはパイプラインが担うのは宣言的なテーブル変換であり、ダッシュボード更新などのオーケストレーションはジョブの守備範囲です。Dは失敗時の部分再実行や並列化ができず、保守性も低い構成です。
問4. 本番の日次ジョブを実行する計算資源として最も適切なものはどれか。
正解:B
Job クラスタはジョブの実行時のみ存在するため待機コストがなく、単価も All-purpose クラスタより低いため、本番の定期実行に適しています。Aは待機時間の課金と高い単価の両面で不経済です。Cは自動化の趣旨に反し、運用ミスの原因にもなります。Dのような構成は存在せず、クラスタにはドライバーノードが必要です。