Databricks Certified Data Engineer Associate 教科書
第4章 Lakeflow Jobsによるオーケストレーション(Working with Lakeflow Jobs, 16%)
🎯 この節の学習目標
4-3 で学んだトリガーは、大きく2つの発想に分けられます。時間ベース(time-based)は「時計」を基準に動かす発想で、スケジュールトリガーが該当します。データ駆動(data-driven / event-driven)は「データが来た・変わった」という事実を基準に動かす発想で、ファイル到着トリガーとテーブル更新トリガーが該当します。どちらが常に優れているというものではなく、データの性質と業務要件に合わせて選ぶ設計判断が本節のテーマです。試験でも「このシナリオに最適なトリガーは?」という形式で問われることを想定して読み進めてください。
時間ベースの強みは予測可能性です。実行時刻が確定しているため、「毎朝6時のダッシュボードには前日分が反映されている」といった定時の約束(締切)を業務側と結びやすいのが特長です。
| 観点 | 時間ベース(スケジュール)の性質 |
|---|---|
| 得意 | 上流データの到着時刻が安定している場合/「毎朝9時までに」など定時報告が必要な場合/実行時刻を揃えて運用を単純にしたい場合 |
| 不得意 | データ到着が不規則な場合。早すぎればデータ未着のまま実行(空振り・失敗)、余裕を持たせすぎれば到着から処理までの無駄な待ち時間が生じる |
| コスト | データがなくても定刻に起動するため、処理対象ゼロの無駄な実行にもクラスタ起動コストがかかる |
時間ベース設計の典型的な失敗は「上流が遅れた日にジョブが失敗または空のデータで完走し、誰も気づかないままダッシュボードが古い値を表示し続ける」というものです。時間ベースを選ぶ場合は、失敗通知(4-3)や品質チェック(3-6)を組み合わせて「未着に気づける」仕掛けをセットで用意します。
データ駆動の強みは無駄と待ち時間の排除です。データが来たときだけ、来たらすぐに動くため、空振り実行がなく、到着から処理完了までの遅延(レイテンシ)も最小化できます。
| 観点 | データ駆動(file arrival / table update)の性質 |
|---|---|
| 得意 | 到着が不規則・予測不能な場合/到着後できるだけ早く処理したい場合/来ない日は動かさずコストを抑えたい場合 |
| 不得意 | 「毎朝9時に必ず最新のレポートを出す」のような定時の締切そのものは表現できない(データが来なければ動かないため)。また、細かい更新が頻発すると起動が多発しうる(待機時間の設定で緩和) |
| コスト | 実行はデータがあるときだけなので計算コストの無駄は少ない |
トリガー選択は、次の4観点を順に確認すると整理できます。
| 観点 | 問い | 判断の方向 |
|---|---|---|
| ① データの到着パターン | 上流データはいつ届くか? | 定時に安定して届く→時間ベースで十分/不規則・予測不能→データ駆動 |
| ② 下流のSLA(鮮度要件) | 下流はどれだけ新しいデータを求めるか? | 「定時までにあればよい」→時間ベース/「到着後すみやかに反映」→データ駆動 |
| ③ コスト | 空振り実行や常時稼働をどこまで許容するか? | 来ない日が多いデータに定時実行は無駄→データ駆動/高頻度スケジュールで到着を追いかけるくらいならファイル到着トリガーへ |
| ④ 依存関係 | 起点は外部ファイルか、上流ジョブ/テーブルか? | 外部からのファイル→file arrival/上流の出力テーブル→table update。同一ジョブ内で完結できる依存は、そもそもトリガーではなくタスクの depends_on(4-1)で表現する |
📝 試験のポイント
観点④は特に重要です。「同じチームが管理する一連の処理」ならば1つのジョブのタスク依存(depends_on)にまとめるのが第一候補で、トリガーの出番はありません。ジョブをまたぐ連携が必要なときに初めて、Run Job タスクによるジョブ間連携や、上流の出力テーブルを監視する table update トリガーが選択肢になります。「なんでもトリガーで解決」ではなく、「まず depends_on、次にトリガー」という優先順位で考えましょう。
💡 シナリオ①:「毎晩23時までに日次集計が必要」
経営会議用の日次売上集計は毎晩23時までに完成している必要があります。上流の販売システムは毎晩21時までに当日分のデータ連携を完了させる運用が確立しており、到着時刻は安定しています。
判断:到着が安定(①)し、要件が「定時までに」という締切型(②)なので、時間ベースのスケジュールトリガー(例:21時30分に起動)が適切です。上流遅延の日に備え、失敗通知と品質チェックを組み合わせて未着を検知できるようにします。
💡 シナリオ②:「不定期にファイルが届く」
提携先から精算ファイルが不定期に(週に1〜3回、時刻もばらばら)ストレージに置かれます。届いたら数分以内に取り込みを始めたい一方、届かない日にジョブを動かすだけ無駄です。
判断:到着が不規則(①)、即時性の要求あり(②)、空振りコストを避けたい(③)ので、ファイル到着トリガーが適切です。「1時間ごとのスケジュールでポーリングする」案は、最悪1時間近い待ちと大量の空振り実行を生むため劣ります。
💡 シナリオ③:「上流テーブルが更新されたら即時変換」
別チームのパイプラインが Unity Catalog のテーブルを1日に数回、不定期なタイミングで更新します。自チームはその更新を受けて変換処理をすみやかに実行したいのですが、上流ジョブの設定を変更する権限はありません。
判断:起点が「上流の出力テーブル」(④)で、上流に手を入れられない以上、テーブル更新トリガーが適切です。もし両方のジョブを自チームが管理しているなら、1つのジョブに統合して depends_on で結ぶ、あるいは上流ジョブの最終タスクとして Run Job タスクで下流ジョブを呼ぶ構成も選択肢になります。
図:トリガー選択の思考順序。まず depends_on で足りるかを確認し、次に締切型か到着駆動型かで分ける
✅ この節のまとめ
問1. 上流システムが毎晩20時までに必ずデータ連携を完了する。経営レポートは毎朝7時のダッシュボード閲覧に間に合えばよい。この日次集計ジョブのトリガーとして最も適切なものはどれか。
正解:B
到着時刻が安定しており(20時まで)、要件も「朝7時までに」という締切型なので、時間ベースのスケジュール(例:20時30分)で十分です。Aは夜間に1回動けばよい処理に常時稼働の資源を割く過剰構成です。Cは実質的なポーリングで、無駄な実行が大量に発生します。Dは自動化の要件を満たさず、実行忘れのリスクがあります。
問2. 提携先からのファイルが月に数回、予測できないタイミングでストレージに置かれる。届いたらすみやかに取り込みたい。「毎時0分のスケジュールトリガー」と比べたときの「ファイル到着トリガー」の利点として最も適切なものはどれか。
正解:A
データ駆動の本質的な利点は「来たときだけ・来たらすぐ」動くことによる、無駄な実行の排除と遅延の最小化です。毎時スケジュールでは、月に数回のファイルのために毎時空振りし、到着後も最大1時間近く待たされます。Bはトリガーが変わっても処理自体は必要です。Cは副次的な違いにすぎず本質ではありません。Dのデータ品質はトリガーの種類とは無関係で、品質チェック(3-6)の役割です。
問3. 別チームが管理するジョブが Unity Catalog テーブル silver.shipments を1日に数回不定期に更新する。自チームはこの更新のたびに変換ジョブをすみやかに実行したい。上流ジョブの設定変更は依頼できない。最も適切な構成はどれか。
正解:B
上流に手を入れずに「テーブル更新」を起点に下流を起動できるのが table update トリガーで、この要件に合致します。Aは不定期な更新に追従できず、無駄な実行と反映遅延の両方が生じます。Cは「上流ジョブの設定変更は依頼できない」という制約に反します。Dのファイル到着トリガーが監視するのはストレージ上の場所(ファイルの到着)であり、テーブルの更新を監視する用途には table update トリガーを使います。
問4. データ未着リスクに関する記述として最も適切なものはどれか。
正解:A
時間ベースの弱点はまさに「データが来ていなくても時計どおりに動く」ことで、上流遅延時の空振り・失敗リスクへの備え(通知・品質チェック)が必要です。Bのような到着検知はスケジュールトリガーにはありません(それを担うのがデータ駆動トリガーです)。Cはファイル到着トリガーの動作と逆で、ファイルが来なければ実行されません。Dはトリガーを変えても監視や品質確認の必要性はなくならないため誤りです。