電車で読む、
試験前の一枚。

schemaLocation と checkpoint は別物

schemaLocation は推論スキーマと進化履歴、checkpointLocation はストリームの処理進捗と状態を保存する。

罠 役割は別だが同じディレクトリも指定可能。入力パスとは分離し、クエリごとに固有の checkpoint を使う。

救出列は _rescued_data

救出列名を変えるオプションは rescuedDataColumn。既定列名は _rescued_data で、_rescue_data ではない。

定期稼働か、追いついて停止か

processingTime はクエリを動かし続けて周期実行。availableNow は開始時点までの未処理データを複数バッチで処理して停止。

Jobs のトリガーは現在6系統

Scheduled / Table update / File arrival / Model update（Beta） / Continuous / None（手動・外部起動）。

注意 古い問題は Model update を含めず5種類としている。

File arrival は「毎分・ベストエフォート」

新規ファイルの有無を約1分ごとに確認する。ミリ秒保証ではなく、通常は既存ファイルの上書きでは起動しない。

cooldown と debounce を分ける

min_time_between_triggers_seconds は実行間隔の下限。wait_after_last_change_seconds は最後の変更後に静まるまで待つ。

時刻はジョブ、Run if は依存結果

平日09:00はジョブの Scheduled トリガーで Quartz cron と timezone を指定する。タスクの Run if は成功・失敗など依存タスクの結果条件で、曜日や時刻条件ではない。

重要 過去問題の「AとD」は不適切。実質的に必要なのはジョブ側の schedule。

変数値は「外から強い」

--var → BUNDLE_VAR_* → variable-overrides.json → target の variables → top-level default。

既存ジョブは generate と bind を分けて考える

対応する既存ジョブは databricks bundle generate job --existing-job-id <id> で定義を生成。現行CLIは notebook task のジョブのみ対応し、既存ジョブを管理するなら --bind も使う。

罠 generate しただけで deploy すると、既存ジョブではなく新しいリソースを作る。

テーブル権限だけでは読めない

基本は USE CATALOG + USE SCHEMA + 対象の SELECT。権限継承があっても親階層を利用する権限は必要。

UC には account group

workspace-local group には Unity Catalog の権限を付与できない。アカウントレベルで管理される account group を使う。

VACUUM の既定は7日 = 168時間

短縮には retention safety check の無効化が必要だが危険。VACUUM は現行テーブルから参照されない古いデータファイルを物理削除し、タイムトラベル可能期間を縮める。