確認問題｜Associate ④ Lakeflow Jobs

教材 04-jobs.md の内容に基づく確認問題です（全10問）。 まず問題を解き、下の「解答・解説」で答え合わせをしてください。

問題

Q1. Lakeflow ジョブ（旧 Databricks Workflows / Jobs）のオーケストレーションにおける「主要な 3 概念」のうち、ジョブを実行するタイミング（起動条件）を定義するものはどれか。

• A. タスク（Task）
• B. 依存関係（Dependency）
• C. トリガー（Trigger）
• D. パラメータ（Parameter）

Q2. ジョブ内のタスク間の実行順序（依存関係）は、UI 上で何として視覚的に表現されるか。

• A. Quartz cron 構文
• B. 有向非巡回グラフ（DAG）
• C. マテリアライズドビュー
• D. イベントログ（event log）

Q3. 既存の Lakeflow 宣言型パイプライン（マテリアライズドビューやストリーミングテーブルを含む）を、ジョブの一部として実行したい。ジョブに追加すべきタスクの種類はどれか。

• A. ノートブックタスク（Notebook task）
• B. Python スクリプトタスク（Python script task）
• C. パイプラインタスク（Pipeline task）
• D. dbt タスク（dbt task）

Q4.（シナリオ）あるジョブを「毎日・絶対時間で毎時」実行したいが、運用地域が夏時間（DST）を採用しているため、実行のスキップや 1〜2 時間のずれが起きないようにしたい。教材が推奨する構成はどれか。

• A. 単純スケジュール（Simple）にして間隔を 12 時間ごとに設定する
• B. 詳細スケジュールで DST を監視するローカルタイムゾーンを選ぶ
• C. 詳細スケジュールでタイムゾーンに UTC を選ぶ
• D. トリガーを「継続的（Continuous）」に切り替える

Q5. スケジュール（cron）トリガーに関する説明として、教材の内容と一致するものはどれか。

• A. 詳細スケジュールでは Quartz cron 構文を使ってスケジュールを編集できる
• B. cron 式を工夫すれば、後続実行の間隔を 1 秒まで短くできる
• C. 単純スケジュールでは、最初の実行時刻を正確に指定できる
• D. ジョブスケジューラは低遅延（ミリ秒単位）の実行を保証している

Q6. 複数タスクを含むジョブで一部のタスクだけが失敗した。教材が説明する「リトライ（Repair run）」の挙動として正しいものはどれか。

• A. ジョブ全体を必ず最初のタスクからやり直す必要がある
• B. 失敗・スキップしたタスクのサブセットのみを再実行できる
• C. Repair run は継続的（Continuous）トリガーのジョブでのみ利用できる
• D. リトライすると、すでに成功したタスクも強制的に再実行される

Q7. ジョブの同時実行（concurrency）と通知（Notification）に関する記述として、教材の内容と一致するものはどれか。

• A. 既定では 1 度に 1 実行のみがアクティブで、上限を超えた実行はスキップされる
• B. 既定で 10 実行まで同時にアクティブにでき、超過分はキューに入り順番に実行される
• C. 通知はメールのみ対応で、Slack やカスタム Webhook は利用できない
• D. 通知はジョブが成功したときにのみ送信され、失敗時には送れない

Q8. Lakeflow 宣言型パイプライン（旧 DLT）の 2 大データセット型のうち、追加専用ソースを増分的（incremental）かつ冪等（idempotent）に取り込む、取り込みの主要データセット型はどれか。

• A. マテリアライズドビュー（Materialized view）
• B. 一時ビュー（Temporary view）
• C. ストリーミングテーブル（Streaming table）
• D. 外部テーブル（External table）

Q9.（シナリオ）Unity Catalog を有効化したパイプラインで、クラウドオブジェクトストレージに到着し続ける CSV ファイルを増分・冪等に取り込みたい。教材の推奨として正しい組み合わせはどれか。

• A. Auto Loader（cloudFiles）を使う。SQL では read_files() を STREAM と組み合わせ、外部の場所と READ FILES 権限が必要
• B. spark.read.format("json") でバッチ読み込みし、外部の場所は不要
• C. read_kafka を使い、メッセージバスとして読み込む
• D. マテリアライズドビューで spark.read.table() を使い、外部の場所と READ FILES 権限が必要

Q10.（シナリオ）顧客向けの重要テーブルで、count > 0 を満たさないレコードが 1 件でも混入したら、テーブル更新自体を失敗させ、トランザクションをアトミックにロールバックさせたい。使うべき Expectations のアクションと、その特徴として正しいものはどれか。

• A. ON VIOLATION DROP ROW を使う。無効行だけが削除され、更新自体は成功する
• B. 既定の EXPECT（warn）を使う。無効行は保持され、更新は成功する
• C. ON VIOLATION FAIL UPDATE を使う。更新が失敗し、再処理には手動介入が必要になる
• D. expect_all を使う。無効行は自動的に修正されて書き込まれる

解答・解説

Q1. 正解: C オーケストレーションの主要 3 概念は「ジョブ（Job）＝調整・スケジュール・実行の主リソース」「タスク（Task）＝個々の作業単位」「トリガー（Trigger）＝ジョブを実行するタイミングを定義する仕組み」。起動条件（タイミング）を定義するのはトリガー。パラメータは実行時にタスクへプッシュされる値であり、起動条件ではない。

Q2. 正解: B ジョブ内のタスク（およびパイプライン内のテーブル）の依存関係は、有向非巡回グラフ（DAG, Directed Acyclic Graph）として視覚的に表現される。Quartz cron 構文はスケジュール記法、イベントログはパイプラインのメトリック確認用であり、依存関係の可視化とは別物。

Q3. 正解: C パイプラインタスクは、マテリアライズドビューやストリーミングテーブルを含む既存の Lakeflow パイプラインを指定して実行するタスク種類。ノートブックタスクは Databricks ノートブック、Python スクリプトタスクは Python ファイルを実行するもので、パイプラインの実行用ではない。

Q4. 正解: C 教材は「絶対時間で毎時実行したい場合は UTC を選ぶ」と明記している。DST を監視するタイムゾーンを選ぶと、1 時間ごとのジョブがスキップされたり 1〜2 時間遅れて見えることがある。単純スケジュールの間隔変更や継続的トリガーでは、絶対時間の毎時実行という要件を満たせない。

Q5. 正解: A 詳細スケジュール（Advanced）では「Cron 構文の表示」にチェックを入れると Quartz cron 構文でスケジュールを表示・編集できる。B は誤りで、cron 式の構成に関わらず後続実行の間には最小 10 秒の間隔が強制される。単純スケジュールは最初の実行時刻を指定できず（スケジューラが選ぶ）、スケジューラは低遅延実行を想定していない。

Q6. 正解: B Repair run では、失敗・スキップしたタスクのサブセットのみを再実行でき、ジョブ全体をやり直す必要はない。成功済みタスクを強制的に再実行することもなく、継続的トリガー限定の機能でもない。

Q7. 正解: A 既定では 1 度にアクティブにできるジョブ実行は 1 つだけで、詳細設定で最大同時実行数を引き上げられる。構成した最大コンカレンシーを超えた実行はスキップされる（キュー待ちではない）。通知はメール・Slack・カスタム Webhook に対応し、ジョブ失敗時や実行が長すぎるときに送れる。

Q8. 正解: C ストリーミングテーブルは、追加専用ソースを増分的・冪等に取り込む、取り込み（インジェスト）の主要データセット型。マテリアライズドビューはクエリ結果を実体化して保持し、変換・集計結果の保存に使う。両者が宣言型パイプラインの 2 大データセット型。

Q9. 正解: A クラウドオブジェクトストレージへ到着し続けるファイルの増分・冪等な取り込みには Auto Loader（cloudFiles フォーマット）が推奨され、SQL では read_files() を STREAM と組み合わせて使う。Unity Catalog 有効パイプラインで Auto Loader を使うには外部の場所（external location）が必要で、実行ユーザーに READ FILES 権限を付与する。B のバッチ読み込みは静的データ向け、C の read_kafka はメッセージバス用。

Q10. 正解: CON VIOLATION FAIL UPDATE（Python では expect_or_fail）は、無効レコードがあると更新を失敗させ、テーブル更新の場合はトランザクションをアトミックにロールバックする。再処理にはコード修正など手動介入が必要。DROP ROW（drop）は無効行だけ削除して更新は成功、既定の EXPECT（warn）は無効行を保持して更新は成功するため、要件に合わない。