Databricks Certified Data Engineer Associate 教科書
第4章 Lakeflow Jobsによるオーケストレーション(Working with Lakeflow Jobs, 16%)
🎯 この節の学習目標
4-1・4-2 では「ジョブの中で何をどの順に動かすか」を学びました。本節のテーマは「ジョブそのものをいつ起動するか」、すなわちトリガーです。Lakeflow Jobs では、手動実行(Run now)のほかに、主に次の4種類のトリガーを設定できます。
| トリガータイプ | 起動のきっかけ | 一言でいうと |
|---|---|---|
| スケジュール(Scheduled) | 指定した時刻・周期の到来 | 時間ベース。「毎日6時に」 |
| ファイル到着(File arrival) | 監視場所への新ファイルの到着 | データ駆動。「ファイルが来たら」 |
| テーブル更新(Table update) | 対象テーブルの更新(コミット) | データ駆動。「テーブルが更新されたら」 |
| 継続(Continuous) | 常時。ジョブの実行が終わると即座に次の実行が始まる | 常時稼働。「途切れず動かし続ける」 |
最も基本的なトリガーで、簡易UI(「毎日」「毎時」などの選択)または cron 構文で実行タイミングを指定します。cron 構文では「平日の朝6時だけ」「15分ごと」のような細かい周期も表現できます。タイムゾーンの指定も可能で、日次バッチでは業務のタイムゾーンに合わせて設定します。
ファイル到着トリガーは、指定したストレージ上の場所(Unity Catalog の external location や volume)を監視し、新しいファイルが到着したらジョブを起動します。外部システムが不定期にファイルを置いていくパターンで、到着を待ち構える「ポーリング&起動」を Databricks 側が肩代わりしてくれます。
テーブル更新トリガーは、指定した Unity Catalog 管理下のテーブルが更新(新しいコミットが追加)されたらジョブを起動します。「上流のジョブやパイプラインがテーブルを書き終えたら、下流の変換をすぐ動かしたい」というジョブ間・パイプライン間の連携をテーブルを介して疎結合に実現できます。
継続(Continuous)は、ジョブの1回の実行が終了するとすぐに次の実行が開始されるモードです。常に動き続けるため準リアルタイムの処理に使えますが、計算資源が常時稼働するためコストは高くなります。ストリーミング処理そのものは構造化ストリーミングやパイプラインの継続モードが担うことが多く、試験対策としては「途切れない実行が必要なときの選択肢として存在する」ことと「常時稼働=高コスト」という性質を押さえれば十分です。
| トリガー | 起動条件 | 適する状況 | 主な注意点 |
|---|---|---|---|
| スケジュール | 時刻・周期(cron/簡易UI) | 定時レポート、到着時刻が安定した上流データの日次・時間次バッチ | データ未着でも起動する(空振り・失敗のリスク) |
| ファイル到着 | 監視場所への新ファイル到着 | 不定期に届くファイルの取り込み(Auto Loader と好相性) | UC管理の場所が対象。検知は約1分間隔で厳密なリアルタイムではない |
| テーブル更新 | UC管理テーブルへのコミット | 上流ジョブ/パイプラインの出力テーブル更新を受けた下流処理の即時起動 | UC管理テーブルが対象。細かい更新が続くと起動が頻発しうる(待機設定で緩和) |
| 継続 | 常時(終了後すぐ再実行) | 途切れない準リアルタイム処理 | 常時稼働のため高コスト |
ジョブには、開始・成功・失敗などのイベントに対する通知を設定できます。宛先はメールアドレスのほか、Slack や Webhook などのシステム宛先も指定できます。運用の基本は「失敗通知は必ず設定する」ことです。失敗に気づかず放置されたジョブは、下流のデータ鮮度問題として跳ね返ってきます。実行時間が長すぎる場合の通知(duration warning)も設定でき、異常な遅延の早期検知に役立ちます。
max concurrent runs は、そのジョブを同時に何実行まで走らせてよいかの上限です。既定は1で、前の実行がまだ走っている間に次のトリガー時刻が来た場合の挙動はキューイング(queueing)の設定で変わります。現在 UI で新規作成したジョブはキューイングが既定で有効になっており、上限を超えた実行は最大48時間キューに入って順番を待ちます。キューイングを無効にしている場合は、上限超過分の新しい実行はスキップされます。
💡 具体例:15分周期ジョブの実行時間が延びたら
15分ごとのスケジュールで動くジョブの処理時間が、データ増加で20分に延びたとします。max concurrent runs が1(既定)なら、実行中に到来した次回分は並走せず、キューイング有効ならキューで前の実行の終了を待ち、無効ならスキップされます。いずれの場合も並走による二重処理は起きません。一方、実行同士が独立で並走しても安全な設計(例:パラメータで対象期間が分かれている)であれば、上限を増やして並走を許すこともできます。同じテーブルに同じ処理を書き込むジョブの並走は、二重書き込みの危険があるため、既定の1のままにするのが安全です。
📝 試験のポイント
トリガー名と起動条件の対応は確実に押さえましょう:scheduled=時刻、file arrival=監視場所への新ファイル、table update=UC テーブルの更新、continuous=常時。さらに「前回の実行が終わらないうちに次が始まって二重処理になるのを防ぎたい」→ max concurrent runs を1にする(既定)、という運用設定も問われる可能性があります。
✅ この節のまとめ
問1. 取引先が不定期に(週に数回、時刻は予測不能)CSVファイルをクラウドストレージの所定の場所に置いていく。ファイルが届いたら、できるだけ早く取り込みジョブを実行したい。最も適切なトリガーはどれか。
正解:B
「不定期に届くファイルを契機に起動」はファイル到着トリガーの設計目的そのものです。Aでは到着から取り込みまで最大丸1日待たされ、届かない日は空振り実行になります。Cは常時稼働のためコストが過大で、週に数回の処理には見合いません。Dは即時性・確実性とも人手に依存し、自動化の要件を満たしません。
問2. 別チームが管理する上流ジョブが Unity Catalog のテーブル silver.orders を更新する。その更新を受けて、自チームの集計ジョブを即時に実行したい。上流ジョブの構成は変更できない。最も適切な方法はどれか。
正解:B
テーブル更新トリガーなら、上流ジョブに手を入れずに「テーブルが更新された」という事実だけで下流を起動でき、疎結合な連携になります。Aは上流の遅延・前倒しに追従できず、未着実行や無駄な待ち時間が生じます。Cは更新を待つためだけに計算資源を常時稼働させることになり不経済です。Dは人手依存で即時性・確実性に欠けます。
問3. 15分ごとのスケジュールで実行されるジョブがある。データ量の増加で処理が15分を超える日があり、前の実行が終わらないうちに次の実行が重なって同じデータを二重処理することを防ぎたい。最も適切な設定はどれか。
正解:A
max concurrent runs が1なら、実行中に次のトリガー時刻が来ても新しい実行は並走せず(キューイング有効なら前の実行の終了までキューで待機、無効ならスキップ)、並走による二重処理を防げます。Bは並走を積極的に許す設定で、要件と正反対です。Cの継続モードでも実行が途切れずに続くだけで、二重処理の懸念に対する直接の解決にはなりません(かつ常時稼働でコスト増)。Dのリトライは失敗時の再試行の仕組みで、実行の重なりとは無関係です。
問4. トリガータイプと起動条件の組み合わせとして誤っているものはどれか。
正解:D
継続(continuous)トリガーは「実行が終了すると即座に次の実行が始まる常時稼働モード」であり、行数のしきい値で起動する仕組みではありません(そのような行数条件のトリガーは存在しません)。A・B・Cはそれぞれ正しい対応です。名称と起動条件の対応関係は、シナリオ問題を解く前提知識として確実に覚えておきましょう。