Databricks Asset Bundlesで実現するアセット配布と環境差分管理

Declarative Automation Bundlesは、ジョブ、DLTパイプライン、ノートブック、MLモデルなどの Databricksアセットをコードとして定義し、複数環境（dev / staging / prod）に一貫してデプロイするための仕組みです。 databricks.ymlファイルにアセットの構成を記述し、Databricks CLIのbundleコマンドで検証・デプロイ・実行・削除を行います。

この記事では、DABsの基本概念、databricks.ymlの構造、環境ごとのtargets設定、主要コマンド、そしてTerraformやReposとの使い分けを解説します。

Declarative Automation Bundlesとは

DABsは、Databricksの「Infrastructure as Code（IaC）+ Application as Code」を実現するツールです。 従来のDatabricks開発では、ジョブやパイプラインをUIで手動作成し、 環境間の移行（dev → staging → prod）も手動でコピーしていました。 DABsではこれらをYAMLファイルで定義し、Git管理 + CI/CDによる自動デプロイを実現します。

DABsが管理できるアセットは以下の通りです。

• ジョブ（Workflows / Lakeflow Jobs）
• DLTパイプライン（Lakeflow Spark Declarative Pipelinesパイプライン定義）
• MLflow実験・モデル
• ノートブック / Pythonスクリプト
• ダッシュボード（Databricks SQL Dashboards）
• スキーマ / ボリューム（UCオブジェクト）

databricks.ymlの基本構造

DABsのプロジェクトルートに配置するdatabricks.ymlは、以下の主要セクションで構成されます。

bundle:
  name: my-etl-pipeline

variables:
  catalog_name:
    description: "ターゲットカタログ"
    default: "dev_catalog"
  warehouse_id:
    description: "SQL Warehouse ID"

workspace:
  root_path: /Workspace/Users/${workspace.current_user.userName}/.bundle/${bundle.name}/${bundle.target}

resources:
  jobs:
    daily_etl:
      name: "daily-etl-${bundle.target}"
      schedule:
        quartz_cron_expression: "0 0 2 * * ?"
        timezone_id: "Asia/Tokyo"
      tasks:
        - task_key: ingest
          notebook_task:
            notebook_path: ./src/ingest.py
          new_cluster:
            spark_version: "14.3.x-scala2.12"
            num_workers: 4
            node_type_id: "i3.xlarge"
        - task_key: transform
          depends_on:
            - task_key: ingest
          notebook_task:
            notebook_path: ./src/transform.py
          new_cluster:
            spark_version: "14.3.x-scala2.12"
            num_workers: 8

  pipelines:
    dlt_pipeline:
      name: "dlt-pipeline-${bundle.target}"
      target: "${var.catalog_name}.bronze"
      libraries:
        - notebook:
            path: ./src/dlt_definitions.py

targets:
  dev:
    mode: development
    default: true
    variables:
      catalog_name: "dev_catalog"
  staging:
    variables:
      catalog_name: "staging_catalog"
  prod:
    mode: production
    variables:
      catalog_name: "prod_catalog"
    run_as:
      service_principal_name: "prod-deployer-sp"

targets（環境）の設計

targetsセクションは、同一のアセット定義を異なる環境にデプロイするための仕組みです。各targetでvariables、権限、実行ユーザー（run_as）をオーバーライドできます。

developmentモードでは、リソース名に[dev ユーザー名]のプレフィックスが自動付加されるため、 複数開発者が同じワークスペースでバンドルをデプロイしても名前が衝突しません。 productionモードではrun_asの指定が必須で、サービスプリンシパルで実行するのがベストプラクティスです。

主要CLIコマンド

環境変数とシークレット管理

variablesはdatabricks.yml内で定義し、targetsごとにデフォルト値をオーバーライドするか、CLI実行時に--varフラグで注入します。

# CLI実行時に変数を注入
databricks bundle deploy -t prod --var="catalog_name=prod_catalog"

# CI/CDパイプライン（GitHub Actions）での例
- name: Deploy to prod
  run: |
    databricks bundle deploy -t prod \
      --var="catalog_name=${{ secrets.PROD_CATALOG }}" \
      --var="warehouse_id=${{ secrets.PROD_WAREHOUSE_ID }}"

シークレット（パスワード、APIキーなど）はdatabricks.ymlには記述せず、DatabricksのSecret Scopeに保存し、ノートブック内でdbutils.secrets.getで取得するのがベストプラクティスです。

Automation Bundles vs Terraform vs Repos 比較表

試験で問われるポイント

Declarative Automation Bundles（旧Databricks Asset Bundles）は、Data Engineer Associate（セクション5「Implementing CI/CD」）とData Engineer Professional（セクション1と、セクション8「Debugging and Deploying」）の試験ガイドに明記されています。ML Professionalの試験ガイドにも、DABsでモデルサービングエンドポイント・MLflow実験・登録済みモデルを定義・構成する目標があります。

• 「ジョブとDLTパイプラインをdev/staging/prodに一貫してデプロイするには？」→ Automation Bundles（targets設定）
• 「databricks.ymlで環境ごとにカタログ名を切り替えるには？」→ variables + targetsでオーバーライド
• 「本番デプロイでジョブの実行ユーザーを固定するには？」→ run_asでサービスプリンシパルを指定
• 「TerraformとDABsの使い分けは？」→ インフラ基盤はTerraform、アプリケーションアセットはDABs

問題で確認

よくある質問