Databricks 認定学習資料

テーマ切替

Professional 学習教材 ⑥ デバッグ・デプロイ（配点 10%） ​

本教材は Databricks 認定データエンジニア Professional（上位資格） 試験のドメイン⑥「デバッグ・デプロイ」向けの自習用まとめです。Spark UI を使ったパフォーマンス／コスト診断、構造化ストリーミングの本番運用、CI/CD と宣言型オートメーション バンドル（旧称 Databricks Asset Bundles）、Git フォルダー（旧称 Repos）連携、Databricks CLI・サービスプリンシパルによる自動化を、この md 単体で学習が完結するようにまとめています。

参照した公式ページ（すべて Microsoft Learn 日本語版を WebFetch で実読）:

1. このドメインの概要 ​

「デバッグ・デプロイ」は、開発したデータパイプラインを 本番環境で確実に動かし、問題を診断・回復し、繰り返しデプロイできるようにする ための領域です。Professional 試験では、Associate よりも一段深く、次の 3 本柱が問われます。

  1. Spark UI による診断（デバッグ）

    • ジョブ（Job）／ステージ（Stage）／タスク（Task）の階層、DAG、シャッフル（Shuffle）、スキュー（Skew）、スピル（Spill）、メモリ不足（OOM）を Spark UI から読み解き、原因を特定して対処する。
    • 「まず最も時間のかかっているステージを見つけ、スピル→スキュー→I/O→その他 の順に切り分ける」という体系的な診断手順を理解する。

  2. 構造化ストリーミング（Structured Streaming）の本番運用

    • Lakeflow ジョブ（旧称 Databricks Jobs）としてスケジュールし、障害からの自動再起動、正確に1回（exactly-once）／少なくとも1回（at-least-once）保証、チェックポイント、StreamingQueryListener によるモニタリングを設計する。

  3. CI/CD とデプロイ

    • 宣言型オートメーション バンドル（Declarative Automation Bundles、旧称 Databricks Asset Bundles / DAB）で、ジョブやパイプラインを YAML で宣言し、開発（dev）→ステージング→本番（prod）へプロモーションする。
    • Git フォルダー（旧称 Repos）でバージョン管理し、Databricks CLI・サービスプリンシパル（Service Principal）・GitHub Actions / Azure DevOps などで自動化する。

キーとなる考え方: 本番デプロイは「コードとしてのインフラストラクチャ（IaC）」で行う。人手の操作を排し、バージョン管理・テスト・環境分離・自動ロールバックをパイプライン化することが、Professional レベルで一貫して求められる価値観です。

2. 重要用語集 ​

用語（日本語）English説明
Spark UISpark UIクラスターの [Spark UI] から開く、Spark アプリケーションの実行状況・コスト・パフォーマンスを診断する Web UI。ジョブ／ステージ／タスク／SQL／Executors／ストリーミング等のタブを持つ。
ジョブJobSpark のアクション（count, write 等）1 回に対応する実行単位。複数のステージから成る。
ステージStageシャッフル境界で区切られるジョブの部分。複数のタスクに分割されて並列実行される。
タスクTaskステージ内の 1 パーティションを処理する最小実行単位。Executor 上で実行される。
DAG（有向非巡回グラフ）DAG (Directed Acyclic Graph)クエリの物理実行計画を可視化したグラフ。SQL タブから開き、各ノードに費やされた累積時間・ステージ ID を確認できる。
ドライバーDriverSpark アプリを統括するプロセス。ジョブのスケジューリング・調整を行う。ここがボトルネックだとタイムラインにギャップが出る。
ワーカー／ExecutorWorker / Executor実際にタスクを実行する計算プロセス。Executor が削除／失敗するとジョブ全体に影響する。
ジョブ タイムライン（イベント タイムライン）Jobs / Event Timeline何がいつ実行され、Executor がいつ追加・削除されたかを時系列で示す図。診断の出発点。
シャッフルShuffle集約・結合・再パーティション時にノード間でデータを再配置する処理。スピルやスキューの主要因。
シャッフル読み取り／書き込みShuffle Read / Shuffle Writeステージが読み書きしたシャッフルデータ量。ステージ一覧の列で確認する。
入力／出力Input / Outputステージがストレージ（Delta / Parquet / CSV 等）から読み取った／書き込んだデータ量。
スキュー（データの偏り）Skew / Data Skewness1 つまたは少数のタスクだけが他より極端に長くかかる状態。クラスター使用率が下がり全体が遅くなる。
スピル（あふれ）Spillメモリ不足時にデータをディスクへ退避する処理。非常に高コスト。シャッフル中に最も発生しやすい。
メモリ不足OOM (Out Of Memory)Executor またはドライバーのメモリが枯渇して失敗する状態。タスク失敗・Executor 削除の一般的原因。
ガベージ コレクションGC (Garbage Collection)JVM のメモリ回収。過度な GC は低速化の原因になり、メモリ逼迫のサイン。
サマリー（概要）メトリックSummary Metricsステージページで、タスク指標の最小／25／中央値／75パーセンタイル／最大を示す統計。スキュー判定に使う。
UDF（ユーザー定義関数）UDF (User-Defined Function)ネイティブ関数より低速になりがちな独自関数。repartition() やネイティブ関数への書き換えで改善。
デカルト結合Cartesian Join / Nested Loop Join結合条件のない総当たり結合。非常に高コストで、DAG 上で識別できる。
小さなファイル問題Small File Problem数万個の小さなファイル（1 ファイル 8 MB 未満）を読み書きして遅くなる問題。OPTIMIZE や最適化された書き込みで改善。
スポット インスタンス損失Spot Instance Lossクラウドプロバイダーがスポット VM を回収して Executor が失われる事象。
構造化ストリーミングStructured StreamingSpark のストリーム処理エンジン。マイクロバッチ（および continuous）で動作。
チェックポイントCheckpointストリームの進捗・状態を保存する仕組み。障害回復と exactly-once の基盤。
正確に1回／少なくとも1回exactly-once / at-least-onceストリームの処理保証。foreachBatch は少なくとも1回保証のため、シンク側で冪等性が必要。
冪等性Idempotency同じ処理を複数回実行しても結果が変わらない性質。at-least-once のシンクで必須。
継続的トリガー（Continuous モード）Continuous mode (job scheduling)失敗時に自動で再起動し、指数バックオフでリトライするジョブのスケジュール方式（※ストリームのトリガー間隔ではない）。
StreamingQueryListenerStreamingQueryListenerストリームの進捗イベント（開始／進捗／アイドル／終了）を受け取り、外部にメトリクスを送るリスナー。
StreamingQueryProgressStreamingQueryProgress各マイクロバッチの進捗情報（numInputRows, inputRowsPerSecond, processedRowsPerSecond, durationMs, stateOperators, sources, sink など）。
バックログ メトリックBacklog metrics未処理データ量（numBytesOutstanding, numFilesOutstanding, Kafka の *OffsetsBehindLatest 等）。遅延監視に使う。
ログLogsドライバー／Executor ログ、コンピューティングのイベントログ。失敗原因の特定に使う。
宣言型オートメーション バンドルDeclarative Automation Bundles（旧称 Databricks Asset Bundles / DAB）ジョブ・パイプライン等の Databricks リソースを YAML で宣言し、ソース管理・テスト・CI/CD を導入する IaC ツール。Databricks CLI の機能。
databricks.ymldatabricks.ymlバンドルのルートに置く唯一のメイン構成ファイル。include で他ファイルを参照できる。
ターゲットTargetデプロイ先環境の宣言（例: dev, staging, prod）。1 つだけ default: true にできる。
デプロイ モードDeployment modeターゲットの mode。development と production があり、既定動作のセットを一括適用する。
プリセットPresetsターゲット動作をカスタマイズする設定群（name_prefix, trigger_pause_status, jobs_max_concurrent_runs, tags 等）。
リソースResourcesバンドルで管理する Databricks オブジェクト（jobs, pipelines, dashboards, clusters, model_serving_endpoints, experiments, registered_models, volumes 等）。
bundle init / validate / deploy / run / destroy同左バンドルの作成／検証／デプロイ／実行／破棄を行う CLI コマンド。
Databricks CLIDatabricks CLIバンドルを検証・デプロイ・実行する CLI。バンドル利用には v0.218.0 以降が必要。
Git フォルダーGit folders（旧称 Repos）ワークスペース内に Git リポジトリを統合するビジュアル Git クライアント＋API。
Git プロバイダーGit providerリポジトリをホストするサービス（GitHub, GitLab, Bitbucket, Azure DevOps 等。クラウド／オンプレ両対応）。
CI/CD パイプラインCI/CD pipelineビルド・テスト・デプロイを自動化する仕組み。継続的インテグレーション＋継続的デリバリー。
サービス プリンシパルService Principal人間ではなく自動化用の ID。本番デプロイ・CI/CD 実行に推奨。
ワークロード ID フェデレーションWorkload Identity Federation / OAuth token federationDatabricks シークレット不要で CI/CD 認証する最も安全な方式。
run_asrun_asバンドルのワークフローを実行する ID（ユーザーまたはサービスプリンシパル）。
スパース チェックアウトSparse checkout大きなリポジトリの一部ディレクトリだけを cone パターンで複製するクライアント側設定。

3. 詳細解説 ​

3-1. Spark UI によるデバッグ・診断（ステージ／タスク／シャッフル／スキュー／スピル／OOM の読み方と対処） ​

Spark UI の開き方と診断の全体フロー ​

  1. クラスター（コンピューティング）のページに移動する。
  2. [Spark UI] をクリックする。

公式ガイドは「手順を踏んで原因を絞り込む」ステップバイステップ形式で、以下の順に進みます。

  1. ジョブ タイムラインで主要な問題を特定する（jobs-timeline）
  2. 最長のステージを見る（long-spark-stage）
  3. スキューまたはスピルを探す（long-spark-stage-page）
  4. 最長ステージが入出力（I/O）に依存しているか判断する（long-spark-stage-io）
  5. 低速ステージの他の原因を探す（slow-spark-stage-low-io）

用語に不慣れな場合は「ドライバー・ワーカー・Executor・ステージ・タスク」という Spark アーキテクチャの基礎を先に押さえること。

(1) ジョブ タイムライン（イベント タイムライン）で当たりを付ける ​

Spark UI で [ジョブ]（Jobs）→ [イベント タイムライン]（Event Timeline）を開く。ドライバーと Executor（例: Executor 0）の追加・削除、各ジョブの並びが時系列で見える。着目パターン:

  • 失敗したジョブ／失敗した Executor: タイムライン上で 赤 表示。→ 「失敗したジョブまたは削除された Executor」（failing-spark-jobs）へ。
  • 実行のギャップ（gap）: 1 分以上 の空白を探す。短い中断はドライバーが調整するため正常。長い原因不明のギャップがパイプライン途中にある場合は「Spark ジョブ間のギャップ」へ。クラスターが常時起動しているだけの一時停止と区別する。
  • 長時間の作業（1 つの長いジョブが支配）: その長いジョブをクリックして深掘りする。
  • 多数の小さなジョブ: 数秒以下の小さな青い線が大量にある場合は「多数の小さな Spark ジョブ」へ。
  • どれにも当てはまらない: ジョブを 期間（Duration）でソート し、最長ジョブの説明リンクを開く。

(2) 最長ステージの特定（long-spark-stage） ​

ジョブのページを一番下までスクロールし、ステージ一覧を Duration でソート。最長ステージについて次の列を確認する。

  • 入力（Input）: ストレージから読み取ったデータ量（Delta / Parquet / CSV 等）。
  • 出力（Output）: ストレージに書き込んだデータ量。
  • シャッフル読み取り（Shuffle Read）: 読み取ったシャッフルデータ量。
  • シャッフル書き込み（Shuffle Write）: 書き込んだシャッフルデータ量。

これらの数値は後の判断で使うのでメモしておく。タスク数 も重要な手がかり:

  • タスクが 1 つだけ → 問題のサイン（並列化されていない）。「1 つの Spark タスク」（one-spark-task）を参照。
  • 複数タスクがある → ステージ説明のリンクからステージ詳細ページへ進み、スキュー／スピルを調べる。

(3) スピル（Spill）の診断と対処 ★最初に確認 ​

  • ステージページ上部に スピル統計（Spill (Memory) / Spill (Disk)）が表示されることがある。
  • スピルとは: Spark がメモリ不足になり、データをメモリからディスクへ移動する処理。非常に高コスト。データシャッフル中に最も一般的に発生する。
  • スピル統計が表示されない = そのステージにスピルはない。
  • 対処: シャッフルによるスピルへの対処ガイド（パーティション調整、メモリ増強、シャッフル削減）に従う。

(4) スキュー（Skew）の診断と対処 ​

  • ステージページの [概要（Summary）メトリック] までスクロールする。
  • 判定基準: タスク実行時間の 最大（Max） が 75 パーセンタイル より 50% 以上長い 場合、スキューの可能性が高い。健全なステージでは 75 パーセンタイルと Max がほぼ同じ。
  • スキューとは: 1 つまたは少数のタスクだけが他より極端に長くかかる状態 → クラスター使用率低下・全体遅延。
  • 対処: スキュー修復（ソルティング、AQE の skew join 最適化、キー分散の見直し等）を行う。

スキューもスピルも無い場合は、ページ上部の [関連付けられたジョブ ID] からジョブに戻り、次に「高 I/O」か「低 I/O の他原因」かを切り分ける。

(5) I/O が少ない低速ステージの他の原因（slow-spark-stage-low-io） ​

I/O が小さいのに遅いステージは、SQL DAG を開いて原因を特定する。ジョブページ上部の [関連付けられた SQL クエリ] から DAG を表示。各ノードの時間は 全タスクの累積時間（クロック時間ではない）だが、コストと相関するので有用。主な原因:

  • 多数の小さなファイルの読み取り: スキャン演算子を開き、読み取りファイル数を確認。数万ファイルなら小さなファイル問題。ファイルは 8 MB を下回らないようにする。原因は列が多すぎる／高カーディナリティ列でのパーティション分割。→ OPTIMIZE、予測最適化（Predictive Optimization）、ファイルレイアウト見直し。
  • 多数の小さなファイルの書き込み: 同様に 8 MB 未満を避ける。→ 予測最適化、最適化された書き込み（Optimized Writes）、ファイルレイアウト見直し。
  • 低速 UDF: DAG に UDF ノードが出る。UDF をコメントアウトして影響を確認 → ネイティブ関数へ書き換えが最善。不可なら、UDF を実行するステージのタスク数がコア数より少ない場合は事前に repartition(num_cores) する。UDF は各タスクがパーティション全体をメモリに載せるためメモリ問題も起こしうる → 再パーティションでタスクを小さくして解決。
python
(df
  .repartition(num_cores)
  .withColumn('new_col', udf(...))
)
  • デカルト結合（Cartesian / Nested Loop Join）: 結合条件が無い総当たり。非常に高コスト。意図通りか確認し、代替を検討。
  • 分解結合（Exploding Join）／explode() の爆発: ノードに入る行数より出る行数が明らかに多い場合。データ爆発の最適化を検討。

(6) 失敗したジョブ・削除された Executor・OOM の診断（failing-spark-jobs） ​

Executor が削除される主な理由:

  • 自動スケール（Autoscaling）: エラーではなく想定内。
  • スポット インスタンス損失: クラウドプロバイダーが VM を回収。→「スポット インスタンスの損失」参照。
  • Executor のメモリ不足（OOM）。

失敗したジョブの調べ方:

  1. 失敗したジョブをクリック → 下にスクロールし、失敗したステージと失敗理由 を確認。
  2. 説明リンクから詳細を取得。さらに下で 各タスクが失敗した原因 を確認（メモリ問題ならここで明確になる）。

失敗した Executor の調べ方:

  1. まずコンピューティングの [イベント ログ]（Event Log）を確認 → クラスターのサイズ変更中／スポット損失などの説明があるか。
  2. イベントログに情報が無ければ、Spark UI の [Executors] タブ をクリックし、失敗した Executor の ログ を取得する。

OOM への一般的な発想: パーティションを細かくしてタスクあたりのメモリ量を減らす、より大きな／メモリの多いコンピューティングを選ぶ、スピルやスキューを解消してメモリ圧を下げる、ドライバーに大量データを集約する処理（collect 等）を避ける。

3-2. ストリーミングの本番運用・トラブルシューティング ​

本番運用の基本方針（production） ​

Databricks は本番の構造化ストリーミングを スケジュールされた Lakeflow ジョブ（旧称 Databricks Jobs） として実行することを推奨。常に次を構成する:

  • display や count など 結果を返す不要コードをノートブックから削除 する。
  • 汎用コンピューティング（All-Purpose Compute）を使わない。ストリームは常に ジョブ コンピューティング（Jobs Compute） で実行する（失敗・再試行時に新しい計算リソースがデプロイされる）。
  • ジョブのスケジュールに Continuous（継続的）モード を使う（※これはジョブのスケジューリング機能であり、構造化ストリーミングのトリガー間隔ではない点に注意）。
  • ストリーミング用コンピューティングで 自動スケール（Autoscaling）を有効にしない（スケールダウンに制限があるため）。拡張自動スケーリングが必要なら Lakeflow パイプライン（Spark 宣言型パイプライン）を推奨。

一部ワークロードで有効なオプション: RocksDB ステートストアの構成、ステートフルクエリの 非同期状態チェックポイント処理、非同期の進行状況追跡。

サーバーレス コンピューティングでのストリーミング制約:

  • Trigger.AvailableNow() と Trigger.Once() のみサポート。Databricks は Trigger.AvailableNow() を推奨。
  • サーバーレスで継続的ストリーミングをしたい場合は、Lakeflow パイプラインの 連続（continuous）パイプライン モード を使う（トリガー型ではなく）。

障害を前提とした設計（fault tolerance） ​

  • 障害発生時に自動再起動するよう常に構成 する。スキーマ進化など一部機能は自動リトライを必要とする。
  • foreachBatch などの操作は 少なくとも1回（at-least-once）保証 であり、exactly-once ではない → 処理パイプラインを 冪等（idempotent） に作る。
  • 再起動時の挙動: 前回実行で予定されていたマイクロバッチが処理される。OOM で失敗した／バッチが大きすぎて手動キャンセルした場合は、コンピューティングのスケールアップが必要になることがある。実行間で構成を変えた場合、その構成は次の最初の新バッチに適用される。

1 ジョブで複数ストリームを動かす戦略 ​

戦略複数のタスク（Multiple tasks）複数のクエリ（Multiple queries）
コンピューティング共有各ストリーミングタスクに適サイズの Jobs Compute を推奨。必要ならタスク間で共有可。すべてのクエリが同じコンピューティングを共有。必要ならスケジューラプールに割当。
再試行の扱いジョブ再試行前にすべてのタスクが失敗する。クエリが失敗するとそのタスクが再試行する。

※ 継続的トリガーを使う場合、タスク間の依存関係は設定できない。

継続的トリガーの既定動作 ​

  • ジョブの 複数同時実行を阻止 する。
  • 前の実行が失敗したら 新しい実行を開始 する。
  • 再試行に 指数バックオフ（exponential backoff） を使う。

awaitTermination() の使いどころ ​

streamingQuery.awaitTermination() / spark.streams.awaitAnyTermination() は現在のスレッドをブロックする。

  • Lakeflow ジョブでは使わない。ジョブサービスが実行完了を自動的に防ぐため不要。使うとセル完了をブロックし、ジョブサービスの追跡（バックログメトリック・ジョブ通知）を妨げる。
  • 使うべき場面:
    • 汎用コンピューティング上の対話型ノートブック（セル実行を維持し、状態・エラーを観察）。
    • ローカル／開発環境（メインスレッド終了でプロセスが落ちるのを防ぐ）。
    • ドライバーへエラーを伝播させたいとき（ジョブ以外のコンテキストで、クエリ例外を再送出させる）。

モニタリング（stream-monitoring） ​

  • Spark UI の [Streaming] タブ に組み込みモニタリングがある。writeStream に .queryName(<name>) を付けると、どのメトリクスがどのストリームか区別しやすい。
  • StreamingQueryListener（DBR 11.3 LTS 以降、Python/Scala）で進捗イベントを外部（アラート／ダッシュボード）へプッシュできる。コールバック:
    • onQueryStarted … クエリ開始時（DataStreamWriter.start() と同期。ブロックしないこと）。
    • onQueryProgress … 進捗更新時（マイクロバッチ終了時のみ配信）。
    • onQueryIdle … ソースにデータが無く待機中。
    • onQueryTerminated … 停止時（正常・異常問わず）。
    • 注意: リスナーの処理遅延はクエリ処理速度に大きく影響する → 処理を軽くし、Kafka のような高速システムへ書くのが推奨。
  • 監視可能なメトリック（observable metrics）: df.observe("name", 集計関数...) で任意の名前付き集計を定義し、リスナーの progress.observedMetrics から取得（例: エラー行比率が 5% 超でアラート）。バッチモードは QueryExecutionListener、ストリームは StreamingQueryListener。

StreamingQueryProgress の主なフィールド（覚えるべき指標）:

フィールド意味
id再起動しても保持される一意のクエリ ID。
runId開始／再起動ごとに変わる一意 ID。
nameユーザー指定のクエリ名（未指定なら null）。
batchId処理中バッチの一意 ID（再試行で同一 ID が複数回、データ無しならインクリメントされない）。
numInputRowsトリガーで処理したレコード数（全ソース集計）。
inputRowsPerSecondデータ到着速度（全ソース集計）。
processedRowsPerSecondSpark の処理速度（全ソース集計）。
durationMs各段階の所要時間（triggerExecution, addBatch, getBatch, latestOffset, queryPlanning, walCommit, commitOffsets 等）。
stateOperatorsステートフル演算子の状態（numRowsTotal, numRowsUpdated, numRowsRemoved, memoryUsedBytes, numRowsDroppedByWatermark 等）。
eventTimeイベント時刻の avg/max/min/watermark。ウォーターマークで状態のトリミングに使う。
sources / sink各ソース・シンクの進捗とメトリクス。

バックログ（遅延）メトリック（本番監視で重要）:

  • Delta / 自動ローダー: sources.metrics.numBytesOutstanding, numFilesOutstanding（未処理量）。
  • Kafka: avgOffsetsBehindLatest, maxOffsetsBehindLatest, minOffsetsBehindLatest, estimatedTotalBytesBehindLatest（最新オフセットからの遅れ）。

inputRowsPerSecond > processedRowsPerSecond が続く／バックログが増え続ける＝ストリームが処理に追いついていないサイン。コンピューティング増強やパーティション見直しを検討する。

3-3. CI/CD と Asset Bundles（構造・ライフサイクル・ターゲット・デプロイ） ​

宣言型オートメーション バンドルとは（旧称 Databricks Asset Bundles / DAB） ​

バンドルは、ソース管理・コードレビュー・テスト・CI/CD といったソフトウェア工学のベストプラクティスをデータ／AI プロジェクトに導入するツール。プロジェクトのエンドツーエンド定義（構造・テスト・デプロイ方法）をソースファイルとして表現し、1 つのバンドルとしてターゲット環境にデプロイする。バンドルに含まれるもの:

  • 必要なクラウドインフラとワークスペース構成
  • ビジネスロジックのソースファイル（ノートブック、Python ファイル等）
  • Databricks リソースの定義・設定（Lakeflow ジョブ、Lakeflow パイプライン、ダッシュボード、モデルサービングエンドポイント、MLflow 実験、MLflow 登録済みモデル 等）
  • 単体テスト・統合テスト

いつ使うか: 複数の共同作成者と自動化が不可欠で CI/CD が必要な複雑プロジェクト。IaC が適するシナリオ（チーム開発、ML の高速反復、組織標準テンプレート、規制コンプライアンスのバージョン管理履歴）にマッチする。

しくみ: メタデータを YAML で定義し、Databricks CLI でバンドルを検証・デプロイ・実行する。IDE・ターミナル・Databricks 内から実行可能。手動作成のほか、デフォルトテンプレート／カスタムテンプレートから作成できる。

利用に必要なもの:

  • リモートワークスペースで ワークスペースファイル が有効（DBR 11.2 以降は既定で有効）。
  • Databricks CLI v0.218.0 以降（databricks --version で確認）。最新版への定期更新が推奨。
  • ワークスペースアクセスの構成。推奨は OAuth ユーザー対マシン（U2M）認証。
  • （※ワークスペース内でバンドルを使うだけなら CLI インストールは不要。）

バンドルのライフサイクル（work-tasks） ​

  1. 作成（Create）: プロジェクトからバンドルスケルトンを作る。
  2. 開発（Develop）: databricks.yml とリソース構成ファイルで、インフラ・ワークスペース設定（デプロイターゲット等）、リソース設定（ジョブ・パイプライン等）、ソースファイルを定義。
  3. 検証（Validate）: 構成・リソース定義をオブジェクトスキーマと照合し、デプロイ可能かを確認。
  4. デプロイ（Deploy）: ターゲットワークスペースへ配置。通常は個人の開発ワークスペース → ステージング → 本番の順。
  5. 実行（Run）: デプロイ済みのワークフローリソース（ジョブ等）を実行。
  6. 破棄（Destroy）: 不要になったらデプロイ済みリソースを完全削除（取り消し不可）。

作成の 3 方法: ①デフォルトテンプレート（databricks bundle init）、②カスタムテンプレート（databricks bundle init <url-or-path>）、③手動作成（databricks.yml を自作。bundle schema で JSON スキーマを生成し、VS Code / PyCharm / IntelliJ で入力補完）。

バンドルの一意性: バンドルは 名前 × ターゲット × デプロイ元 ID で一意に識別される。これらが同一だと別バンドルのデプロイが互いに干渉する。BUNDLE_ROOT 環境変数でルート外からもコマンド実行可。

databricks.yml の構造（settings / reference） ​

ルートに databricks.yml を 1 つだけ 置く（include で他の YAML を参照）。最小構成:

yaml
bundle:
  name: my_bundle

targets:
  dev:
    default: true   # default にできるターゲットは 1 つだけ

最上位（トップレベル）マッピング:

  • bundle（必須）: name（必須）、databricks_cli_version、cluster_id、deployment、git（origin_url, branch）。
  • run_as: バンドルを実行する ID（user_name または service_principal_name）。
  • include: 追加で読み込む構成ファイル（glob 可）。
  • scripts: 実行可能なスクリプト。
  • sync: 同期対象の include / exclude / paths。
  • artifacts: 成果物のビルド設定（build, executable, files, path, type, dynamic_version）。
  • variables: カスタム変数（description, default, lookup, type。複合変数は type: complex）。
  • workspace: host, profile, root_path, artifact_path, file_path, resource_path, state_path。
  • permissions: リソースへ適用するアクセス許可（level × group_name / user_name / service_principal_name）。
  • resources: 管理する Databricks オブジェクト（jobs, pipelines, clusters, dashboards, experiments, registered_models, model_serving_endpoints, schemas, volumes, sql_warehouses, apps, catalogs, quality_monitors, secret_scopes など）。
  • targets: デプロイ先の宣言。各ターゲットで artifacts, bundle, default, git, mode, permissions, presets, resources, sync, variables, workspace, run_as を上書きできる。

dev / prod のターゲット例（prod は別ワークスペース・別クラスターを使用。上書きしない部分は最上位定義にフォールバック）:

yaml
bundle:
  name: hello-bundle

resources:
  jobs:
    hello-job:
      name: hello-job
      tasks:
        - task_key: hello-task
          existing_cluster_id: 1234-567890-abcde123
          notebook_task:
            notebook_path: ./hello.py

targets:
  dev:
    default: true
  prod:
    workspace:
      host: https://<production-workspace-url>
    resources:
      jobs:
        hello-job:
          tasks:
            - task_key: hello-task
              existing_cluster_id: 2345-678901-fabcd456

移植性のヒント: 可能な限り host ではなく profile（.databrickscfg のプロファイル名）を使う。host を設定すると CLI は .databrickscfg で一致プロファイルを探す。複数一致する場合は --profile で明示する。

ファイル分割（include でモジュール化）:

yaml
# databricks.yml
bundle:
  name: hello-bundle
include:
  - '*.yml'

デプロイ モード（deployment-modes） ​

デプロイモードは任意。設定すると「よく使う設定群」を一括適用できる。

開発モード（mode: development） の主な動作:

  • ファイル／ノートブック以外のリソース名に [dev ${workspace.current_user.short_name}] プレフィックス を付け、ジョブ・パイプラインに dev タグを付与。
  • 関連する Lakeflow パイプラインを development: true にする。
  • bundle deploy --cluster-id <id> で既存クラスター定義を上書き可能（または bundle.cluster_id を設定）。
  • デプロイ済みリソースの スケジュール／トリガーを一時停止（個別に schedule.pause_status: UNPAUSED で解除可）。
  • 全ジョブで 同時実行を有効化（反復高速化。個別に max_concurrent_runs: 1 で無効化可）。
  • デプロイロックを無効化（反復高速化。bundle.deployment.lock.enabled: true で再有効化可）。

本番モード（mode: production） の主な動作:

  • 関連 Lakeflow パイプラインが development: false であることを検証。

  • ターゲット指定の Git ブランチ（git.branch）と現在のブランチが一致するか検証（任意。--force で上書き可）。

    yaml
    git:
  branch: main

  • 本番デプロイにはサービスプリンシパルを推奨。強制するには run_as にサービスプリンシパルを設定。サービスプリンシパルを使わない場合は、artifact_path/file_path/root_path/state_path が特定ユーザー用に上書きされていないこと、run_as と permissions で権限が明確化されていることを検証する。

  • development モードと異なり、--compute-id / compute_id による既存クラスター上書きは できない。

  • ヒント: 変更不可の読み取り専用フォルダー（immutable_folder）にデプロイすると、管理者以外の改変や実行中ジョブへの影響を防げる。

カスタム プリセット（presets）: mode と presets 併用時、プリセットが既定モード動作を上書きし、個別リソース設定がプリセットを上書きする（優先順位: 個別リソース > presets > mode）。

yaml
targets:
  dev:
    presets:
      name_prefix: 'testing_'          # リソース名にプレフィックス
      pipelines_development: true       # パイプラインを development に
      trigger_pause_status: PAUSED      # 全トリガー／スケジュールを一時停止
      jobs_max_concurrent_runs: 10      # 全ジョブの最大同時実行数
      tags:
        department: finance

Databricks の CI/CD 全体像（ci-cd） ​

CI/CD = 自動化パイプラインでソフトを短時間・高頻度に開発・提供するプロセス。Databricks の一般的なフロー:

  1. Version（バージョン管理）: コード・ノートブックを Git に格納。Git フォルダーで変更を作成・テストしてからコミット。必要なら bundle の Git 設定を構成。
  2. Code（コーディング）: ワークスペースのノートブック、または IDE（VS Code 拡張機能）でコードと単体テストを開発。
  3. ビルド（Build）: バンドルの成果物マッピングでデプロイ時に成果物を自動ビルド。Pylint（Databricks Labs プラグイン）でコーディング標準・バグ検出。
  4. デプロイ（Deploy）: バンドルを使い、Azure DevOps / GitHub Actions / Jenkins 等でワークスペースへデプロイ。デプロイモードで環境を構成。
  5. テスト（Test）: pytest 等で自動テスト。
  6. 実行（Run）: databricks bundle run でリソースを実行。
  7. 監視（Monitor）: ジョブ監視等で本番ワークロードのパフォーマンスを監視し、問題を特定・解決。

使用可能なツール: 宣言型オートメーション バンドル（推奨）、Databricks Terraform プロバイダー、Azure DevOps、GitHub Actions、Jenkins、Apache Airflow、CI/CD 用サービスプリンシパル、OAuth トークンフェデレーション（最も安全な認証）。

バンドルを使わない軽量なソース管理オプション（外部 CI/CD が使えない場合など）:

  • Git フォルダー（repos/ci-cd）: リモート Git の状態を反映する本番用 Git フォルダーを作り、手動プルまたは外部 CI/CD（GitHub Actions 等）でマージ時にプル。ただしソース管理されるのはコードファイル（ノートブック、ダッシュボード下書き等）のみで、ジョブ／パイプライン構成やダッシュボード発行構成は含まれない。
  • ジョブを含む Git（jobs/git）: 一部のジョブでリモート Git をコードソースに設定。実行開始時にリポジトリのスナップショットを取り、そのバージョンで全タスクを実行。ただし対応タスクが限定され、ジョブ構成（タスク順・コンピューティング・スケジュール）はソース管理されないため、複数環境のクロスワークスペース展開には不向き。

CI/CD ワークフローのベストプラクティス（flows） ​

CI/CD の基本原則（ガードレール）:

  • すべてをバージョン管理: ノートブック・スクリプト・IaC・ジョブ構成を Git へ。Gitflow など環境（dev/staging/prod）に対応したブランチ戦略を使う。
  • テストの自動化: pytest / ScalaTest で単体テスト、databricks bundle validate で構成検証、chispa 等で統合テスト。
  • IaC の採用: バンドル YAML または Terraform でクラスター・ジョブ・ワークスペースを定義。環境固有値（クラスターサイズ、シークレット）はハードコードせずパラメーター化。
  • 環境の分離: dev / staging / prod で 別ワークスペース を維持。MLflow モデルレジストリで環境間のモデルバージョン管理。
  • クラウドに合ったツール選択: Azure なら Azure DevOps + バンドル/Terraform、AWS なら GitHub Actions + バンドル/Terraform 等。
  • 監視と自動ロールバック: デプロイ成功率・ジョブ性能・テストカバレッジを追跡し、失敗デプロイの自動ロールバックを実装。
  • 資産管理の統合: バンドルでコード・ジョブ・インフラを 1 単位でデプロイし、サイロ化を回避。
  • 認証: CI/CD には ワークロード ID フェデレーション を推奨（Databricks シークレット不要で最も安全）。

バンドルを使った推奨 CI/CD ワークフロー:

  1. コードをコンパイル・テスト（PR や main へのコミットでトリガー、単体テスト実行、バージョン付き成果物 my-app-1.0.jar を出力）。
  2. コンパイル済みファイルを Unity Catalog ボリューム／アーティファクトリポジトリに保存（Git コミットハッシュ等でバージョニング: .../my-app-${{ github.sha }}.jar）。
  3. databricks bundle validate で構成を検証（不足ライブラリ等の構成ミスを早期発見）。
  4. databricks bundle deploy でステージング／本番へデプロイ。

Databricks は トランクベース分岐 を推奨（マージ競合最小化、main を常にデプロイ可能に保つ、Git コミットハッシュ等のバージョン付き成果物で追跡・ロールバック可能に）。ML では MLOps Stacks（バンドル＋事前構成 CI/CD＋テンプレート）を活用。SQL 開発者は .sql を Git 管理し、ダッシュボードは bundle generate で .lvdash.json を生成してバンドルに含める。

3-4. Git フォルダー連携と CLI・サービスプリンシパルでの自動化 ​

Git フォルダー（旧称 Repos）の概念（git-folders-concepts） ​

Git フォルダーは、ワークスペース内に Git リポジトリを統合する ビジュアル Git クライアント＋API。ノートブックとファイルでコードを開発し、バージョン管理・コラボレーション・CI/CD のベストプラクティスに従う。対応する操作: リポジトリの複製・プッシュ・プル、ブランチ作成／管理（マージ、リベース、競合解決）、IPYNB を含むノートブック編集、コミット時の差分ビジュアル比較。

Git ディレクトリ API: CI/CD パイプラインと統合し、ワークスペース Git フォルダーをプログラムで最新化できる。

サポートされる Git プロバイダー:

  • クラウド: GitHub（GitHub / GitHub Advanced Enterprise / GitHub Enterprise Cloud）、Atlassian Bitbucket Cloud、GitLab / GitLab Enterprise Edition、Microsoft Azure DevOps（Azure Repos）。
  • オンプレミス（自己管理）: GitHub Enterprise Server、Bitbucket Server / Data Center、GitLab Self-Managed、Azure DevOps Server（URL が dev.azure.com/* / visualstudio.com/* に一致しない場合は URL ドメインプレフィックスを許可リスト登録が必要）。
  • オンプレのインターネット非公開リポジトリは、社内 VPN 内に Git 認証プロキシを設置する必要がある。プロバイダー一覧にクラウドプロバイダーが無い場合、GitHub 選択がフォールバックになりうる（保証なし）。

Git 操作（git-operations-with-repos） ​

前提: Git フォルダーを作る親フォルダーへの CAN MANAGE 権限、ワークスペースへの Git 資格情報の構成。

  • クローン（Clone）: UI の [作成] > [Git フォルダー] で、Git リポジトリ URL・プロバイダー・フォルダー名・スパースチェックアウトを指定。または Web ターミナルで git clone <remote-url>（構成済み資格情報を使用）。
  • Git CLI コマンド（パブリックプレビュー）: CLI アクセス権を持つ Git フォルダーなら、ノートブック／Web ターミナル／Genie Code から 標準 Git コマンド（git stash, git push --force, git rebase -i, サブモジュール, LFS 等）を実行可能。標準 Git フォルダーの制限（2 GB メモリ／4 GB ディスク）を超えるリポジトリも扱える。要サーバーレスコンピューティング（またはクラシックコンピューティング DBR 17.0 以降）。UI からの操作には Git URL 許可リストが適用されるが、Git CLI 直接実行には適用されない。
  • ブランチ作成／切替: Git ダイアログの [Create Branch]、ブランチドロップダウンで切替。注意: 新ブランチに含まれないワークスペース資産は、ブランチ切替で削除されることがある（元ブランチに戻ると新 ID・新 URL で再作成、取り消し不可）。リモートブランチ削除後もローカルブランチは最大 30 日残る。
  • コミット＆プッシュ（Commit & Push）: 変更をコミットメッセージ付きで [コミット & プッシュ]。既定ブランチへのコミット権が無い場合は、新ブランチを作り、Git プロバイダー側で プルリクエスト（PR） を作成してマージ。ソースファイル形式（.py, .scala, .sql, .r）は既定で ノートブック出力をコミットに含めない（IPYNB 形式なら出力コミットを制御可能）。
  • プル（Pull）: [プル] で最新へ更新。重要: アップストリームの変更をプルすると ノートブックの状態がリセット される。
  • マージ（Merge）: git merge でコミット履歴を結合。初心者には強制プッシュ不要・履歴を書き換えないマージを推奨。競合は UI で解決、競合なしなら git push。
  • 競合解決: 手動編集、[現在の変更を保持] / [受信変更を受け取る]、[中止] などを UI から選択。
  • リベース（Rebase）: git rebase で線形履歴を作る。リベース後は git commit と git push --force が必要。履歴書き換えのため共同作業者に影響しうる。
  • リセット（Reset）: UI からの Git リセットは git reset --hard + git push --force 相当。ローカル／リモート両方の未コミット・コミット済み変更が失われる。
  • スパースチェックアウト（Sparse checkout）: cone パターンでリポジトリの一部だけ複製。作成時のみ有効化でき、後から無効化不可。4 GB 超の Azure DevOps リポジトリでは機能しない。除外パターン（!）は非対応。
  • コラボレーション: 各メンバーが自分の Git フォルダー（自分の開発ブランチ）を持つ。1 つの Git フォルダーで Git 操作するのは 1 人だけ（複数人が同一フォルダーで操作するとブランチが意図せず切り替わる等の問題）。

CLI・サービスプリンシパルによる自動化 ​

  • Databricks CLI: バンドルの中心ツール。認証は U2M OAuth（開発）を推奨。バンドルコマンド群（bundle init/validate/deploy/run/destroy/generate/schema/deployment bind 等）を使う。
  • サービス プリンシパル（Service Principal）: CI/CD ではユーザーの代わりにサービスプリンシパルを使う。本番モードのバンドルデプロイでは run_as にサービスプリンシパルを設定するのが推奨。
  • Git フォルダーの自動化: サービスプリンシパルで Git フォルダーをプログラム管理（automate-with-sp）、Terraform でプロビジョニング（automate-with-terraform）、Repos API で管理。
  • 監査: RBAC でロールとしてコミットした場合、Databricks 監査ログに identity_metadata.run_as（ロール）と run_by（ユーザー）の両方が記録される（Web ターミナルの生 Git コミットは個々ユーザーに帰属しない）。

4. 構文・コード例 ​

バンドルの基本ライフサイクル コマンド ​

bash
# CLI バージョン確認（バンドル利用は v0.218.0 以降が必要）
databricks --version

# 1. 作成：テンプレートから対話的に初期化
databricks bundle init
databricks bundle init <project-template-local-path-or-url>   # カスタムテンプレート

# 手動作成用に JSON スキーマを生成（IDE の入力補完に使う）
databricks bundle schema > bundle_config_schema.json

# 3. 検証：スキーマと照合（デプロイ前に必須）
databricks bundle validate

# 4. デプロイ：既定ターゲット / 明示ターゲット
databricks bundle deploy
databricks bundle deploy -t dev
databricks bundle deploy -t prod

# 5. 実行：リソースキー（jobs/pipelines の最上位キー）を指定
databricks bundle run hello_job
databricks bundle run -t dev hello_job     # dev ターゲットのコンテキストで実行

# 6. 破棄：デプロイ済みリソースを完全削除（取り消し不可）
databricks bundle destroy
databricks bundle destroy --auto-approve    # 確認プロンプトをスキップ

databricks.yml の先頭に付けると IDE でスキーマ補完が効く:

yaml
# yaml-language-server: $schema=bundle_config_schema.json

dev / prod を分けた最小バンドル ​

yaml
bundle:
  name: hello-bundle

resources:
  jobs:
    hello-job:
      name: hello-job
      tasks:
        - task_key: hello-task
          existing_cluster_id: 1234-567890-abcde123
          notebook_task:
            notebook_path: ./hello.py

targets:
  dev:
    mode: development
    default: true
  prod:
    mode: production
    workspace:
      host: https://<production-workspace-url>
    run_as:
      service_principal_name: <sp-application-id>   # 本番はサービスプリンシパルを推奨
    git:
      branch: main                                   # 本番はブランチ一致を検証

StreamingQueryListener（Python）でアラートを出す ​

python
from pyspark.sql.streaming import StreamingQueryListener

class MyListener(StreamingQueryListener):
    def onQueryStarted(self, event):
        print(f"'{event.name}' [{event.id}] got started!")
    def onQueryProgress(self, event):
        p = event.progress
        # 追いついているか（バックログ／処理速度）を監視
        if p.numInputRows and p.inputRowsPerSecond > p.processedRowsPerSecond:
            print(f"lagging: in={p.inputRowsPerSecond} proc={p.processedRowsPerSecond}")
        # 監視可能メトリックの参照（df.observe で定義した集計）
        row = p.observedMetrics.get("metric")
        if row is not None and row.malformed / row.cnt > 0.05:
            print("ALERT! too many malformed records")
    def onQueryIdle(self, event):
        pass
    def onQueryTerminated(self, event):
        print(f"{event.id} got terminated!")

spark.streams.addListener(MyListener())

本番ストリーム：Jobs Compute + 継続的トリガー + 冪等 foreachBatch（考え方） ​

python
# 汎用コンピューティングではなく Jobs Compute で、Continuous モードのジョブとして実行する。
# foreachBatch は at-least-once のため、MERGE 等で冪等に書く。
def upsert_to_delta(microBatchDF, batchId):
    (microBatchDF.sparkSession.sql("..."))  # MERGE INTO などで冪等な書き込み

(spark.readStream.format("...").load()
   .writeStream
   .foreachBatch(upsert_to_delta)
   .option("checkpointLocation", "/path/to/checkpoint")  # チェックポイントで回復・exactly-once の基盤
   .queryName("silver_upsert")                            # Spark UI / リスナーで識別しやすくする
   .trigger(availableNow=True)                            # サーバーレスは AvailableNow を推奨
   .start())
# 注：Lakeflow ジョブでは awaitTermination() は使わない

Git フォルダーの Web ターミナル操作（CLI アクセス権あり） ​

bash
cd /Workspace/Users/<your-email>/<project>/my-repo
git clone <remote-url>            # 構成済み Git 資格情報を使用
git rebase -i main                # 対話的リベース
git stash                         # 変更の一時退避
git submodule update --init --recursive
# 資格情報選択プロンプトを避けたい場合
export DB_GIT_CREDENTIAL_NAME=<credential-name>

5. 試験で問われるポイント ​

  • Spark UI の診断順序: 「ジョブタイムライン → 最長ステージ → スピル → スキュー → 高 I/O → その他原因」という切り分けの流れ。最初に見るのは スピル。
  • スキューの定量判定: サマリーメトリックで Max が 75 パーセンタイルより 50% 以上長い ならスキューの疑い。健全なら Max ≈ 75 パーセンタイル。
  • スピルの本質: メモリ不足でメモリ→ディスクへ退避する高コスト処理。シャッフル中に最も発生。統計が出なければスピル無し。
  • ステージ I/O 列の意味: Input / Output / Shuffle Read / Shuffle Write の区別。タスクが 1 つだけ = 問題のサイン。
  • 低 I/O なのに遅い原因: 小さなファイル（8 MB 未満は避ける）、低速 UDF（→ repartition かネイティブ関数化）、デカルト結合、分解結合／explode。SQL DAG で特定する。
  • Executor 削除の理由: 自動スケール（想定内）／スポットインスタンス損失／Executor OOM。原因は イベントログ と [Executors] タブのログ で確認。
  • ストリーム本番の鉄則: Jobs Compute を使い（汎用は不可）、継続的（Continuous）モード でスケジュール、自動スケールは無効、結果を返す不要コードを削除。
  • 処理保証: foreachBatch は at-least-once → シンクを 冪等 に。exactly-once は チェックポイント が基盤。
  • 継続的トリガーの既定動作: 同時実行阻止・失敗時に自動再起動・指数バックオフ。
  • awaitTermination(): Lakeflow ジョブでは使わない（追跡・通知を妨げる）。対話ノートブック／ローカル開発／エラー伝播が必要な場面でのみ使う。
  • モニタリング指標: numInputRows / inputRowsPerSecond / processedRowsPerSecond、バックログ（numBytesOutstanding, numFilesOutstanding, Kafka *OffsetsBehindLatest）。StreamingQueryListener の 4 コールバック（started / progress / idle / terminated）。
  • バンドルの一意性: 名前 × ターゲット × デプロイ元 ID。同一だと干渉する。
  • databricks.yml: ルートに 1 つだけ、include で分割。トップレベルは bundle/targets/resources/variables/workspace/artifacts/sync/permissions/run_as。default: true は 1 ターゲットのみ。
  • デプロイモードの違い: development（[dev ...] プレフィックス、スケジュール一時停止、同時実行有効、ロック無効、development: true）vs production（development: false を検証、Git ブランチ一致を検証、サービスプリンシパル run_as 推奨、クラスター上書き不可）。
  • CI/CD 推奨アプローチ: 宣言型オートメーション バンドルが 推奨。認証は ワークロード ID フェデレーション（シークレット不要で最も安全）、または サービスプリンシパル。
  • 環境分離: dev / staging / prod は 別ワークスペース。環境固有値はパラメーター化（ハードコード禁止）。
  • CLI 前提: バンドルは Databricks CLI v0.218.0 以降、ワークスペースファイル有効（DBR 11.2 以降は既定）。
  • Git フォルダー（旧称 Repos）: 対応プロバイダー（GitHub / GitLab / Bitbucket / Azure DevOps）。プルするとノートブック状態がリセット。ソースファイル形式は既定で出力を含めない。1 フォルダー 1 人で操作。既定ブランチに直接コミットできない場合は PR 経由。
  • バンドル vs 軽量 Git 連携: Git フォルダー／ジョブを含む Git はコードファイルのみをソース管理し、ジョブ・パイプライン構成は含まれない → 複数環境展開には バンドル が適切。

6. 理解度チェックリスト ​

  • [ ] Spark UI を開く手順（クラスターページ → [Spark UI]）と、ジョブ／ステージ／タスクの階層関係を説明できる。
  • [ ] ジョブタイムラインで「失敗ジョブ・実行ギャップ（1 分以上）・長いジョブ・多数の小さなジョブ」を見分け、次に進む手順を言える。
  • [ ] 診断の切り分け順序（タイムライン → 最長ステージ → スピル → スキュー → I/O → その他）を暗唱できる。
  • [ ] スピルとは何か、なぜ高コストか、どこで（主にシャッフル中）起きるかを説明できる。
  • [ ] スキューをサマリーメトリックの Max と 75 パーセンタイルの比較（50% ルール）で判定できる。
  • [ ] ステージ I/O 列（Input / Output / Shuffle Read / Shuffle Write）と「タスク 1 個 = 問題」の意味を説明できる。
  • [ ] 低 I/O で遅い原因（小さなファイル 8 MB 未満、低速 UDF、デカルト結合、分解結合）と対処（OPTIMIZE、repartition、ネイティブ関数化）を挙げられる。
  • [ ] Executor 削除の 3 大理由（自動スケール／スポット損失／OOM）と、イベントログ・[Executors] タブでの調べ方を説明できる。
  • [ ] 本番ストリームを Jobs Compute + Continuous モードで動かし、自動スケールを無効にする理由を説明できる。
  • [ ] foreachBatch が at-least-once であること、冪等性が必要な理由、チェックポイントの役割を説明できる。
  • [ ] 継続的トリガーの既定動作（同時実行阻止・自動再起動・指数バックオフ）を挙げられる。
  • [ ] awaitTermination() を Lakeflow ジョブで使うべきでない理由と、使う場面を説明できる。
  • [ ] StreamingQueryListener の 4 コールバックと、numInputRows/inputRowsPerSecond/processedRowsPerSecond・バックログ指標の意味を説明できる。
  • [ ] 宣言型オートメーション バンドル（旧称 Databricks Asset Bundles）が何を含み、いつ使うかを説明できる。
  • [ ] バンドルのライフサイクル 6 段階と対応 CLI コマンド（init / validate / deploy / run / destroy）を挙げられる。
  • [ ] databricks.yml のトップレベルマッピングと、default: true は 1 ターゲットのみという制約を説明できる。
  • [ ] development モードと production モードの動作差を 3 点以上挙げられる。
  • [ ] presets の優先順位（個別リソース > presets > mode）を説明できる。
  • [ ] Databricks CI/CD の高レベルフロー（Version → Code → Build → Deploy → Test → Run → Monitor）を言える。
  • [ ] CI/CD の基本原則（全部バージョン管理・テスト自動化・IaC・環境分離・監視/自動ロールバック）を挙げられる。
  • [ ] CI/CD 認証でワークロード ID フェデレーション／サービスプリンシパルが推奨される理由を説明できる。
  • [ ] 本番デプロイにサービスプリンシパルを run_as で使う理由を説明できる。
  • [ ] Git フォルダー（旧称 Repos）の対応プロバイダーと主要 Git 操作（clone / branch / commit&push / pull / merge / rebase / reset / sparse checkout）を説明できる。
  • [ ] プルでノートブック状態がリセットされること、既定ブランチへ直接コミットできない場合は PR 経由になることを説明できる。
  • [ ] バンドルと「Git フォルダー／ジョブを含む Git」の違い（後者はジョブ構成をソース管理しない）を説明できる。