Databricks Asset Bundles のリソース

Databricks Asset Bundles を使用すると、バンドル構成の resources マッピングで、バンドルで使用される Databricks リソースに関する情報を指定できます。リソース・マッピングとリソース・キー・リファレンスを参照してください。

この記事では、バンドルでサポートされているリソースの種類の概要を説明し、サポートされている各種類の詳細と例を示します。その他の例については、バンドル設定の例を参照してください。

ヒント

既存のリソースに対してYAMLを生成するには、 databricks bundle generate コマンドを使用します。「 databricks バンドルの生成」を参照してください。

サポートされているリソース

次の表に、バンドルでサポートされているリソースの種類を示します。一部のリソースは、バンドルで定義してバンドルをデプロイすることで作成でき、一部のリソースは、バンドルに含める既存のアセットを参照することによってのみ作成できます。

リソースは、対応する Databricks REST API オブジェクトの作成操作要求ペイロードを使用して定義され、オブジェクトのサポートされるフィールド (YAML として表される) は、リソースのサポートされているプロパティです。各リソースの対応するペイロードのドキュメントへのリンクを表に示します。

ヒント

databricks bundle validate コマンドは、バンドル構成ファイルに不明なリソース・プロパティーが見つかった場合に警告を戻します。

リソース	対応する REST API オブジェクト
アプリ	App オブジェクト
クラスター	クラスターオブジェクト
ダッシュボード	ダッシュボードオブジェクト
database_catalog	データベース・カタログ・オブジェクト
database_instance	データベース・インスタンス・オブジェクト
database_table	データベーステーブルオブジェクト
experiment	エクスペリメントオブジェクト
ジョブ	ジョブオブジェクト
モデル(レガシー)	モデル(レガシー)オブジェクト
model_serving_endpoint	モデルサービング endpoint object
パイプライン	パイプラインオブジェクト
quality_monitor	品質モニターオブジェクト
registered_model (Unity Catalog)	登録済みのモデルオブジェクト
スキーマ (Unity Catalog)	スキーマオブジェクト
secret_scope	シークレットスコープオブジェクト
ボリューム (Unity Catalog)	ボリュームオブジェクト

アプリ

Type: Map

アプリリソースは、 Databricks アプリを定義します。Databricks Appsに関する情報については、「Databricksアプリ」を参照してください。

アプリを追加するには、必要な source_code_pathなど、アプリを定義するための設定を指定します。

ヒント

Streamlit Databricks アプリでバンドルを初期化するには、次のコマンドを使用します。

databricks bundle init https://github.com/databricks/bundle-examples --template-dir contrib/templates/streamlit-app

YAML
apps:
  <app-name>:
    <app-field-name>: <app-field-value>

キー	タイプ	説明
`budget_policy_id`	文字列	アプリの予算ポリシー ID。
`config`	Map	廃止。代わりに、アプリ構成コマンドと環境変数を `app.yaml` ファイルで定義します。「Databricks アプリの構成」を参照してください。
`description`	文字列	アプリの説明。
`name`	文字列	アプリの名前。名前には、小文字の英数字とハイフンのみを含める必要があります。ワークスペース内で一意である必要があります。
`permissions`	順序	アプリの権限。「パーミッション」を参照してください。
`resources`	順序	The app コンピュートリソース. apps.name リソースを参照してください。
`source_code_path`	文字列	Databricks アプリのソースコードの `./app` ローカルパス。このフィールドは必須です。
`user_api_scopes`	順序	ユーザー API のスコープ。

apps.name リソース

Type: Sequence

アプリのコンピュートリソース。 Databricks API リファレンスのリソースを参照してください。

キー	タイプ	説明
`description`	文字列	アプリリソースの説明。
`database`	Map	使用する Lakebase データベースを識別する設定。
`job`	Map	使用するジョブ・リソースを識別する設定。
`name`	文字列	アプリリソースの名前。
`secret`	Map	使用する Databricks シークレットリソースを識別する設定。
`serving_endpoint`	Map	使用するモデルサービングエンドポイントリソースを識別する設定。
`sql_warehouse`	Map	使用するウェアハウスリソース SQLを識別する設定。
`us_securable`	Map	使用する Unity Catalog ボリュームを識別する設定。

例

次の例では、バンドルによって作成されたジョブを管理する my_app という名前のアプリを作成します。

YAML
resources:
  jobs:
    # Define a job in the bundle
    hello_world:
      name: hello_world
      tasks:
        - task_key: task
          spark_python_task:
            python_file: ../src/main.py
          environment_key: default

      environments:
        - environment_key: default
          spec:
            environment_version: '2'

  # Define an app that manages the job in the bundle
  apps:
    job_manager:
      name: 'job_manager_app'
      description: 'An app which manages a job created by this bundle'

      # The location of the source code for the app
      source_code_path: ../src/app

      # The resources in the bundle which this app has access to. This binds the resource in the app with the bundle resource.
      resources:
        - name: 'app-job'
          job:
            id: ${resources.jobs.hello_world.id}
            permission: 'CAN_MANAGE_RUN'

対応する app.yaml は、アプリを実行するための構成を定義します。

YAML
command:
  - flask
  - --app
  - app
  - run
  - --debug
env:
  - name: JOB_ID
    valueFrom: 'app-job'

Databricks アプリの例の完全なバンドルについては、 bundle-examples GitHub リポジトリを参照してください。

クラスター

Type: Map

クラスターリソースは、クラスターを定義します。

YAML
clusters:
  <cluster-name>:
    <cluster-field-name>: <cluster-field-value>

キー	タイプ	説明
`apply_policy_default_values`	ブール値	true に設定すると、ポリシーの固定値とデフォルト値が省略されたフィールドに使用されます。 false に設定すると、ポリシーの固定値のみが適用されます。
`autoscale`	Map	負荷に基づいてクラスターを自動的にスケールアップおよびスケールダウンするために必要なパラメーター。オートスケールを参照してください。
`autotermination_minutes`	Integer	クラスターがこの時間 (分単位) 非アクティブになると、自動的に終了します。設定しない場合、このクラスターは自動的に終了しません。指定する場合、しきい値は 10 分から 10000 分の間でなければなりません。ユーザーは、この値を 0 に設定して、自動終了を明示的に無効にすることもできます。
`aws_attributes`	Map	Amazon Web サービスで実行されるクラスターに関連する属性。クラスターの作成時に指定しない場合は、一連のデフォルト値が使用されます。 aws_attributesを参照してください。
`azure_attributes`	Map	Microsoft Azureで実行されるクラスターに関連する属性。クラスターの作成時に指定しない場合は、一連のデフォルト値が使用されます。 azure_attributesを参照してください。
`cluster_log_conf`	Map	Spark ログを長期保存先に配信するための構成。クラスターを参照してください。
`cluster_name`	文字列	ユーザーが要求したクラスター名。これは一意である必要はありません。作成時に指定しない場合、クラスター名は空の文字列になります。
`custom_tags`	Map	クラスターリソースの追加タグ。 Databricks は、すべてのクラスターリソース ( AWS インスタンスや EBS ボリュームなど) に、 `default_tags`. custom_tagsを参照してください。
`data_security_mode`	文字列	クラスターからデータにアクセスするときに使用するデータガバナンスモデル。 data_security_modeを参照してください。
`docker_image`	Map	カスタムDockerイメージ。 Dockerを参照してください。
`driver_instance_pool_id`	文字列	クラスターのドライバーのインスタンスプールのオプションのIDが属します。プールクラスターは、ドライバープールが割り当てられていない場合、ID (instance_pool_id) のインスタンスプールを使用します。
`driver_node_type_id`	文字列	Spark ドライバーのノードの種類。このフィールドはオプションであることに注意してください。設定を解除すると、ドライバーノードタイプは、上記で定義した `node_type_id` と同じ値に設定されます。このフィールドは、node_type_id とともに、virtual_cluster_size が設定されている場合は設定しないでください。driver_node_type_id、node_type_id、virtual_cluster_size の両方を指定すると、driver_node_type_id と node_type_idが優先されます。
`enable_elastic_disk`	ブール値	オートスケール Local Storage: 有効にすると、このクラスターは、 Spark ワーカーのディスク容量が不足しているときに、追加のディスク容量を動的に取得します。この機能が正しく機能するには、特定のAWS権限が必要です - 詳細については、ユーザーガイドを参照してください。
`enable_local_disk_encryption`	ブール値	クラスター VM のローカルディスクで LUKS を有効にするかどうか
`gcp_attributes`	Map	Google Cloud Platform で実行されるクラスターに関連する属性。クラスターの作成時に指定しない場合は、一連のデフォルト値が使用されます。 gcp_attributesを参照してください。
`init_scripts`	順序	initスクリプトを格納するための設定です。目的地はいくつでも指定できます。スクリプトは、指定された順序で順番に実行されます。init_scriptsを参照してください。
`instance_pool_id`	文字列	クラスターが属するインスタンスプールのオプションの ID。
`is_single_node`	ブール値	このフィールドは、 `kind = CLASSIC_PREVIEW`場合にのみ使用できます。true に設定すると、Databricks は 1 つのノードに関連する `custom_tags`、 `spark_conf`、を自動的に設定します `num_workers`
`kind`	文字列	このコンピュート仕様で描かれているコンピュートの種類。
`node_type_id`	文字列	このフィールドは、このクラスターの各 Spark ノードで使用可能なリソースを 1 つの値でエンコードします。たとえば、 Spark ノードをプロビジョニングし、メモリやコンピュートの負荷の高いワークロード用に最適化できます。使用可能なノードの種類の一覧は、 :method を使用して取得できます/listNodeTypes API 呼び出し。
`num_workers`	Integer	このクラスターに必要なワーカーノードの数。クラスターには、1 つの Spark ドライバーと `num_workers` つのエグゼキューターがあり、合計 `num_workers` + 1 つの Spark ノードがあります。
`permissions`	順序	クラスターのアクセス許可。「パーミッション」を参照してください。
`policy_id`	文字列	クラスターの作成に使用されたクラスターポリシーの ID(該当する場合)。
`runtime_engine`	文字列	クラスターのランタイムエンジン ( `STANDARD` または `PHOTON`) を決定します。
`single_user_name`	文字列	1 つのユーザー名 (data_security_mode の場合) `SINGLE_USER`
`spark_conf`	Map	オプションのユーザー指定の Spark 構成のキーと値のペアのセットを含むオブジェクト。ユーザーは、追加のJVMオプションの文字列を、 `spark.driver.extraJavaOptions` と `spark.executor.extraJavaOptions` を介してドライバーとエグゼキューターにそれぞれ渡すこともできます。spark_confを参照してください。
`spark_env_vars`	Map	オプションのユーザー指定の環境変数のキーと値のペアのセットを含むオブジェクト。
`spark_version`	文字列	クラスターの Spark バージョン(例: `3.3.x-scala2.11`。使用可能な Spark バージョンの一覧は、 :method を使用して取得できます/sparkVersions API 呼び出し。
`ssh_public_keys`	順序	このクラスターの各 Spark ノードに追加されるSSH公開鍵の内容。対応する秘密鍵を使用して、ポート `2200`でユーザー名`ubuntu`でログインできます。キーは 10 個まで指定できます。
`use_ml_runtime`	ブール値	このフィールドは、 `kind = CLASSIC_PREVIEW`場合にのみ使用できます。 `effective_spark_version` は、 `spark_version` (DBR リリース)、このフィールド `use_ml_runtime`、および GPU ノードであるかどうか `node_type_id` によって決まります。
`workload_type`	Map	クラスターワークロードの種類を示す属性。 workload_typeを参照してください。

例

次の例では、 Databricks Runtime 15.4 LTS とクラスターポリシーを使用して、現在のユーザー専用の (シングルユーザー) クラスターを作成します。

YAML
resources:
  clusters:
    my_cluster:
      num_workers: 0
      node_type_id: 'i3.xlarge'
      driver_node_type_id: 'i3.xlarge'
      spark_version: '15.4.x-scala2.12'
      spark_conf:
        'spark.executor.memory': '2g'
      autotermination_minutes: 60
      enable_elastic_disk: true
      single_user_name: ${workspace.current_user.userName}
      policy_id: '000128DB309672CA'
      enable_local_disk_encryption: false
      data_security_mode: SINGLE_USER
      runtime_engine": STANDARD

この例では、単純なクラスター my_cluster を作成し、それを my_jobでノートブックを実行するために使用するクラスターとして設定します。

YAML
bundle:
  name: clusters

resources:
  clusters:
    my_cluster:
      num_workers: 2
      node_type_id: 'i3.xlarge'
      autoscale:
        min_workers: 2
        max_workers: 7
      spark_version: '13.3.x-scala2.12'
      spark_conf:
        'spark.executor.memory': '2g'

  jobs:
    my_job:
      tasks:
        - task_key: test_task
          notebook_task:
            notebook_path: './src/my_notebook.py'
          existing_cluster_id: ${resources.clusters.my_cluster.id}

ダッシュボード

Type: Map

ダッシュボードリソースを使用すると、 AI/BI ダッシュボードをバンドルで管理できます。 AI/BIダッシュボードに関する情報については、「ダッシュボード」を参照してください。

注記

ダッシュボード Git をサポートする Databricks アセットバンドルを使用する場合は、同期マッピングを追加してダッシュボードをファイルとしての同期から除外することで、重複するダッシュボードが生成されないようにします。

YAML
sync:
  exclude:
    - src/*.lvdash.json

YAML
dashboards:
  <dashboard-name>:
    <dashboard-field-name>: <dashboard-field-value>

キー	タイプ	説明
`display_name`	文字列	ダッシュボードの表示名。
`embed_credentials`	ブール値	バンドル・デプロイメントのID資格証明を使用して、すべてのダッシュボード・ビューアーの問合せを実行するかどうか。`false`に設定されている場合、閲覧者の資格情報が使用されます。デフォルト値は `false`です。
`etag`	文字列	ダッシュボードの etag。オプションで更新時に提供して、ダッシュボードが最後の読み取り以降に変更されていないことを確認できます。
`file_path`	文字列	ダッシュボードアセットのローカルパス (ファイル名を含む)。エクスポートされたダッシュボードのファイル拡張子は常に `.lvdash.json`です。
`permissions`	順序	ダッシュボードの権限。「パーミッション」を参照してください。
`serialized_dashboard`	すべて	ダッシュボードの内容 (シリアル化された文字列形式)。
`warehouse_id`	文字列	ダッシュボードの実行に使用されたウェアハウス ID。

例

次の例では、サンプルの NYC タクシー乗車分析 ダッシュボードを含め、Databricks ワークスペースにデプロイします。

YAML
resources:
  dashboards:
    nyc_taxi_trip_analysis:
      display_name: 'NYC Taxi Trip Analysis'
      file_path: ../src/nyc_taxi_trip_analysis.lvdash.json
      warehouse_id: ${var.warehouse_id}

UI を使用してダッシュボードを変更する場合、UI を使用して明示的に更新しない限り、UI で行われた変更は、を使用して明示的に更新しない限り、ローカルバンドル内のダッシュボード JSON ファイルには適用されません bundle generate。--watch オプションを使用して、ダッシュボードへの変更を継続的にポーリングおよび取得できます。「 databricks バンドルの生成」を参照してください。

さらに、リモートワークスペース内のものとは異なるダッシュボード JSON ファイルを含むバンドルをデプロイしようとすると、エラーが発生します。リモートワークスペースのダッシュボードを強制的にデプロイし、ローカルワークスペースで上書きするには、 --force オプションを使用します。「 databricks バンドルのデプロイ」を参照してください。

database_catalogs

Type: Map

データベース・カタログ・リソースを使用すると、バンドル内のデータベース・インスタンスに対応するデータベース・カタログを定義できます。データベースカタログは、Unity Catalog カタログとして登録されている Lakebase データベースです。

データベースカタログに関する情報については、「カタログの作成」を参照してください。

YAML
database_catalogs:
  <database_catalog-name>:
    <database_catalog-field-name>: <database_catalog-field-value>

キー	タイプ	説明
`create_database_if_not_exists`	ブール値	データベースが存在しない場合にデータベースを作成するかどうか。
`database_instance_name`	文字列	データベースを格納するインスタンスの名前。
`database_name`	文字列	カタログに関連付けられているデータベース (インスタンス内) の名前。
`name`	文字列	Unity Catalog のカタログの名前。

例

次の例では、対応するデータベース・カタログを持つデータベース・インスタンスを定義します。

YAML
resources:
  database_instances:
    my_instance:
      name: my-instance
      capacity: CU_1
  database_catalogs:
    my_catalog:
      database_instance_name: ${resources.database_instances.my_instance.name}
      name: example_catalog
      database_name: my_database
      create_database_if_not_exists: true

database_instances

Type: Map

データベース・インスタンス・リソースを使用すると、バンドル内のデータベース・インスタンスを定義できます。Lakebase データベースインスタンスは、ストレージとコンピュートリソースを管理し、ユーザーが接続するエンドポイントを提供します。

important

データベースインスタンスを使用してバンドルをデプロイすると、インスタンスはすぐに実行を開始し、価格の対象となります。「 Lakebase の価格」を参照してください。

データベースインスタンスに関する情報については、データベースインスタンスとはを参照してください。

YAML
database_instances:
  <database_instance-name>:
    <database_instance-field-name>: <database_instance-field-value>

キー	タイプ	説明
`capacity`	文字列	インスタンスの SKU。有効な値は、 `CU_1`、 `CU_2`、 `CU_4`、 `CU_8`です。
`enable_pg_native_login`	ブール値	インスタンスで PG ネイティブパスワードログインが有効になっているかどうか。デフォルトは `true`です。
`enable_readable_secondaries`	ブール値	セカンダリが読み取り専用トラフィックを処理できるようにするかどうか。デフォルトは `false`です。
`name`	文字列	インスタンスの名前。これは、インスタンスの一意の識別子です。
`node_count`	Integer	1 つのプライマリと 0 つ以上のセカンダリで構成されるインスタンス内のノードの数。デフォルトは 1 プライマリと 0 セカンダリです。
`parent_instance_ref`	Map	親インスタンスの参照。これは、インスタンスが子インスタンスの場合にのみ使用できます。入力: 子インスタンスを作成する親インスタンスを指定します。親インスタンスを参照してください。
`permissions`	順序	データベース・インスタンスの権限。「権限」を参照してください。
`retention_window_in_days`	Integer	インスタンスの保持期間。これは、ヒストリカルデータが保持される日数単位の時間枠です。デフォルト値は 7 日です。有効な値は 2 日から 35 日です。
`stopped`	ブール値	インスタンスが停止されているかどうか。

例

次の例では、対応するデータベース・カタログを持つデータベース・インスタンスを定義します。

YAML
resources:
  database_instances:
    my_instance:
      name: my-instance
      capacity: CU_1
  database_catalogs:
    my_catalog:
      database_instance_name: ${resources.database_instances.my_instance.name}
      name: example_catalog
      database_name: my_database
      create_database_if_not_exists: true

データベースインスタンスと対応するデータベースカタログを定義する方法を示すバンドルの例については、 bundle-examples GitHub リポジトリを参照してください。

synced_database_tables

Type: Map

同期されたデータベーステーブルリソースを使用すると、 Lakebase データベーステーブルをバンドルで定義できます。

同期されたデータベーステーブルに関する情報については、「データベースインスタンスとは」を参照してください。

YAML
synced_database_tables:
  <synced_database_table-name>:
    <synced_database_table-field-name>: <synced_database_table-field-value>

キー	タイプ	説明
`database_instance_name`	文字列	ターゲット・データベース・インスタンスの名前。これは、標準カタログに同期されたデータベース表を作成するときに必要です。これは、登録済みカタログに同期されたデータベース表を作成する場合にオプションです。
`logical_database_name`	文字列	このテーブルのターゲット Postgres データベースオブジェクト (論理データベース) の名前。
`name`	文字列	テーブルのフルネーム ( `catalog.schema.table`の形式)。
`spec`	Map	データベーステーブルの仕様。同期されたデータベース表の仕様を参照してください。

例

次の例では、対応するデータベースカタログ内で同期されたデータベーステーブルを定義します。

YAML
resources:
  database_instances:
    my_instance:
      name: my-instance
      capacity: CU_1
  database_catalogs:
    my_catalog:
      database_instance_name: my-instance
      database_name: 'my_database'
      name: my_catalog
      create_database_if_not_exists: true
  synced_database_tables:
    my_synced_table:
      name: ${resources.database_catalogs.my_catalog.name}.${resources.database_catalogs.my_catalog.database_name}.my_destination_table
      database_instance_name: ${resources.database_catalogs.my_catalog.database_instance_name}
      logical_database_name: ${resources.database_catalogs.my_catalog.database_name}
      spec:
        source_table_full_name: 'my_source_table'
        scheduling_policy: SNAPSHOT
        primary_key_columns:
          - my_pk_column
        new_pipeline_spec:
          storage_catalog: 'my_delta_catalog'
          storage_schema: 'my_delta_schema'

エクスペリメント

Type: Map

エクスペリメントリソースを使用すると、バンドル内のエクスペリメントMLflowを定義できます。MLflow エクスペリメントに関する情報については、「MLflow エクスペリメントを使用してトレーニング実行を整理する」を参照してください。

YAML
experiments:
  <experiment-name>:
    <experiment-field-name>: <experiment-field-value>

キー	タイプ	説明
`artifact_location`	文字列	エクスペリメント用のアーティファクトが格納されている場所。
`name`	文字列	エクスペリメントを識別するフレンドリ名。
`permissions`	順序	エクスペリメントの権限。「パーミッション」を参照してください。
`tags`	順序	追加のメタデータのキーと値のペア。タグを参照してください。

例

次の例では、すべてのユーザーが表示できるエクスペリメントを定義しています。

YAML
resources:
  experiments:
    experiment:
      name: my_ml_experiment
      permissions:
        - level: CAN_READ
          group_name: users
      description: MLflow experiment used to track runs

ジョブ

Type: Map

ジョブリソースを使用すると、バンドル内でジョブとそれに対応するタスクを定義できます。ジョブに関する情報については、「ジョブLakeflow」を参照してください。Databricks Asset Bundles テンプレートを使用してジョブを作成するチュートリアルについては、「 Databricks Asset Bundles を使用してジョブを開発する」を参照してください。

YAML
jobs:
  <job-name>:
    <job-field-name>: <job-field-value>

キー	タイプ	説明
`budget_policy_id`	文字列	このジョブに使用するユーザー指定の予算ポリシーの ID。指定しない場合、ジョブを作成または変更するときにデフォルトの予算ポリシーが適用される場合があります。このワークロードで使用される予算ポリシーについては、 `effective_budget_policy_id` を参照してください。
`continuous`	Map	このジョブのオプションの連続プロパティ。continuous プロパティにより、常に 1 つの実行が実行されるようになります。`schedule`と`continuous`のどちらか一方しか使用できません。「continuous」を参照してください。
`deployment`	Map	外部ソースによって管理されるジョブのデプロイメント情報。デプロイメントを参照してください。
`description`	文字列	ジョブの説明 (オプション)。最大長は UTF-8 エンコードで 27700 文字です。
`edit_mode`	文字列	ジョブの編集モード ( `UI_LOCKED` または `EDITABLE`のいずれか)
`email_notifications`	Map	このジョブの実行が開始または完了したとき、およびこのジョブが削除されたときに通知されるEメールアドレスのオプションセット。 Eメールを参照してください。
`environments`	順序	このジョブのサーバレスタスクが参照できるタスク実行環境の仕様の一覧です。サーバレスタスクには環境が存在する必要があります。サーバレスノートブックタスクの場合、環境はノートブック環境パネルでアクセスできます。その他のサーバレスタスクについては、タスク設定のenvironment_keyを使用してタスク環境を指定する必要があります。「環境」を参照してください。
`format`	文字列	ジョブの形式。
`git_source`	Map	タスクで使用されるソースコードを含むリモート Git リポジトリのオプションの仕様。大事な： `git_source` フィールドと `GIT` に設定されたタスク `source` フィールドは、ローカルの相対パスが Git リポジトリ内の同じコンテンツを指していない可能性があり、デプロイされたジョブがデプロイされた場所のローカルコピーと同じコンテンツを持つことをバンドルは想定しているため、バンドルには推奨されません。代わりに、リポジトリをローカルにクローンし、このリポジトリ内にバンドルプロジェクトを設定して、タスクのソースがワークスペースになるようにします。
`health`	Map	このジョブに定義できる正常性ルールのオプションセット。「健康」を参照してください。
`job_clusters`	順序	このジョブのタスクで共有および再利用できるジョブクラスタースペシフィケーションの一覧。クラスターを参照してください。
`max_concurrent_runs`	Integer	ジョブの並列実行の最大許容数 (オプション)。同じジョブの複数の実行を同時に実行できるようにする場合は、この値を設定します。max_concurrent_runsを参照してください。
`name`	文字列	ジョブのオプションの名前。最大長は UTF-8 エンコードで 4096 バイトです。
`notification_settings`	Map	このジョブの各 `email_notifications` と `webhook_notifications` に通知を送信するときに使用するオプションの通知設定。notification_settingsを参照してください。
`parameters`	順序	ジョブ・レベルのパラメーター定義。パラメーターを参照してください。
`performance_target`	文字列	PerformanceTarget は、サーバレスでの実行のパフォーマンスまたはコスト効率を定義します。
`permissions`	順序	ジョブのアクセス許可。「パーミッション」を参照してください。
`queue`	Map	ジョブのキュー設定。「キュー」を参照してください。
`run_as`	Map	書き込み専用設定。ジョブを実行するユーザーまたはサービスプリンシパルを指定します。指定しない場合、ジョブはジョブを作成したユーザーとして実行されます。`user_name` または `service_principal_name` を指定する必要があります。そうでない場合は、エラーがスローされます。「Databricks Asset Bundles ワークフローの実行 ID を指定する」を参照してください。
`schedule`	Map	このジョブのオプションの定期的なスケジュール。デフォルトの動作は、ジョブUIで[実行]をクリックするか、 API リクエストを `runNow`に送信してトリガーされた場合にのみジョブが実行されることです。スケジュールを参照してください。
`tags`	Map	ジョブに関連付けられたタグのマップ。これらは、ジョブクラスターのクラスタータグとしてクラスターに転送され、クラスタータグと同じ制限が適用されます。ジョブには最大 25 個のタグを追加できます。
`tasks`	順序	このジョブによって実行されるタスク仕様のリスト。「Databricks アセットバンドルのジョブにタスクを追加する」を参照してください。
`timeout_seconds`	Integer	このジョブの各実行に適用されるオプションのタイムアウト。値 `0` は、タイムアウトがないことを意味します。
`trigger`	Map	特定の条件が満たされたときに実行をトリガーする構成。トリガーを参照してください。
`webhook_notifications`	Map	このジョブの実行が開始または完了したときに通知するシステム通知 ID のコレクション。webhook_notificationsを参照してください。

例

次の例では、リソースキー hello-job を持つジョブと 1 つのノートブックタスクを定義します。

YAML
resources:
  jobs:
    hello-job:
      name: hello-job
      tasks:
        - task_key: hello-task
          notebook_task:
            notebook_path: ./hello.py

次の例では、SQL ノートブックを使用してジョブを定義します。

YAML
resources:
  jobs:
    job_with_sql_notebook:
      name: 'Job to demonstrate using a SQL notebook with a SQL warehouse'
      tasks:
        - task_key: notebook
          notebook_task:
            notebook_path: ./select.sql
            warehouse_id: 799f096837fzzzz4

その他のジョブ設定例については、ジョブ設定を参照してください。

ジョブタスクの定義とジョブ設定の上書きに関する情報については、以下を参照してください。

モデル(レガシー)

Type: Map

モデルリソースを使用すると、レガシーモデルをバンドルで定義できます。 Databricks では、代わりに Unity Catalog に登録されたモデルを使用することをお勧めします。

モデル_サービス_エンドポイント

Type: Map

model_serving_endpoint リソースを使用すると、モデルサービングエンドポイントを定義できます。モデルサービングエンドポイントの管理を参照してください。

YAML
model_serving_endpoints:
  <model_serving_endpoint-name>:
    <model_serving_endpoint-field-name>: <model_serving_endpoint-field-value>

キー	タイプ	説明
`ai_gateway`	Map	サービスエンドポイントの AI Gateway 構成。注: 現在サポートされているのは、外部モデルとプロビジョニングされたスループットエンドポイントのみです。「AI」を参照してください。
`config`	Map	サービスエンドポイントのコア構成。「config」を参照してください。
`name`	文字列	配信エンドポイントの名前。このフィールドは必須であり、Databricks ワークスペース全体で一意である必要があります。エンドポイント名は、英数字、ダッシュ、アンダースコアで構成できます。
`permissions`	順序	モデルサービングエンドポイントのアクセス許可。「パーミッション」を参照してください。
`rate_limits`	順序	廃止。配信エンドポイントに適用されるレート制限。AI Gateway を使用してレート制限を管理します。
`route_optimized`	ブール値	サービスエンドポイントのルート最適化を有効にします。
`tags`	順序	タグは、配信エンドポイントにアタッチされ、請求ログに自動的に反映されます。タグを参照してください。

例

次の例では、 Unity Catalog モデルサービングエンドポイントを定義しています。

YAML
resources:
  model_serving_endpoints:
    uc_model_serving_endpoint:
      name: 'uc-model-endpoint'
      config:
        served_entities:
          - entity_name: 'myCatalog.mySchema.my-ads-model'
            entity_version: '10'
            workload_size: 'Small'
            scale_to_zero_enabled: 'true'
        traffic_config:
          routes:
            - served_model_name: 'my-ads-model-10'
              traffic_percentage: '100'
      tags:
        - key: 'team'
          value: 'data science'

パイプライン

Type: Map

パイプラインリソースを使用すると、 Lakeflow 宣言型パイプラインパイプラインを作成できます。パイプラインに関する情報については、「 Lakeflow 宣言型パイプライン」を参照してください。 Asset Bundles テンプレートを使用してパイプラインを作成するチュートリアルについては、「Databricksアセットバンドルを使用した Lakeflow宣言型パイプラインの開発Databricks 」を参照してください。

YAML
pipelines:
  <pipeline-name>:
    <pipeline-field-name>: <pipeline-field-value>

キー	タイプ	説明
`allow_duplicate_names`	ブール値	false の場合、名前が別のパイプラインの名前と競合すると、デプロイは失敗します。
`catalog`	文字列	このパイプラインからデータを発行するための Unity Catalog のカタログ。`target` を指定すると、このパイプライン内のテーブルは、`catalog` 内の`target`スキーマ (`catalog`.`target`.`table`など) に発行されます。`target` を指定しない場合、データは Unity Catalogに公開されません。
`channel`	文字列	使用する Lakeflow 宣言型パイプライン Release チャンネル Lakeflow 使用します。
`clusters`	順序	このパイプラインデプロイのクラスター設定。クラスターを参照してください。
`configuration`	Map	このパイプライン実行の構成。
`continuous`	ブール値	パイプラインが連続しているか、トリガーされているか。これは `trigger`を置き換えます。
`deployment`	Map	このパイプラインのデプロイの種類。デプロイメントを参照してください。
`development`	ブール値	パイプラインが開発モードであるかどうか。デフォルトは false です。
`dry_run`	ブール値	パイプラインがドライ実行パイプラインであるかどうか。
`edition`	文字列	パイプライン製品のエディション。
`environment`	Map	サーバレスコンピュートに依存関係をインストールするために使用するこのパイプラインの環境仕様。このキーは、Databricks CLI バージョン 0.258 以降でのみサポートされます。
`event_log`	Map	このパイプラインのイベントログ構成。event_logを参照してください。
`filters`	Map	デプロイされたグラフに含めるパイプラインパッケージを決定するフィルター。「フィルター」を参照してください。
`id`	文字列	このパイプラインの一意の識別子。
`ingestion_definition`	Map	マネージドインジェストパイプラインの構成。これらの設定は、 `libraries`、 `schema`、 `target`、または `catalog` 設定では使用できません。ingestion_definitionを参照してください。
`libraries`	順序	このデプロイに必要なライブラリまたはコード。ライブラリを参照してください。
`name`	文字列	このパイプラインのわかりやすい名前。
`notifications`	順序	このパイプラインの通知設定。「通知」を参照してください。
`permissions`	順序	パイプラインのアクセス許可。「パーミッション」を参照してください。
`photon`	ブール値	このパイプラインでPhotonが有効になっているかどうか。
`root_path`	文字列	このパイプラインのルートパス。これは、Databricks ユーザーインターフェイスでパイプラインを編集するときにルートディレクトリとして使用され、パイプラインの実行中に Python ソースを実行するときに sys.path に追加されます。
`run_as`	Map	パイプラインが実行される ID。指定しない場合、パイプラインはパイプラインを作成したユーザーとして実行されます。指定できるのは `user_name` または `service_principal_name` のみです。両方を指定すると、エラーがスローされます。「 Databricks Asset Bundles ワークフローの実行 ID を指定する」を参照してください。
`schema`	文字列	テーブルの読み取り元またはパブリッシュ先となるデフォルトのスキーマ (データベース)。
`serverless`	ブール値	このパイプラインでサーバレスコンピュートが有効になっているかどうか。
`storage`	文字列	チェックポイントとテーブルを格納するための DBFSルートディレクトリ。
`tags`	Map	パイプラインに関連付けられているタグのマップ。これらはクラスタータグとしてクラスターに転送されるため、同じ制限が適用されます。パイプラインには最大 25 個のタグを追加できます。
`target`	文字列	このパイプラインにテーブルを追加するターゲットスキーマ (データベース)。`schema` または `target` のいずれかを正確に指定する必要があります。Unity Catalog に公開するには、 `catalog`.このレガシーフィールドは、パイプライン作成では非推奨となり、 `schema` フィールドが優先されます。

例

次の例では、リソースキーが hello-pipelineを持つパイプラインを定義しています。

YAML
resources:
  pipelines:
    hello-pipeline:
      name: hello-pipeline
      clusters:
        - label: default
          num_workers: 1
      development: true
      continuous: false
      channel: CURRENT
      edition: CORE
      photon: false
      libraries:
        - notebook:
            path: ./pipeline.py

その他のパイプライン構成例については、「パイプライン構成」を参照してください。

quality_monitor (Unity Catalog)

Type: Map

quality_monitor リソースを使用すると、 Unity Catalog テーブル・モニターを定義できます。モニターに関する情報については、「Databricks レイクハウスモニタリングの概要」を参照してください。

YAML
quality_monitors:
  <quality_monitor-name>:
    <quality_monitor-field-name>: <quality_monitor-field-value>

キー	タイプ	説明
`assets_dir`	文字列	モニタリングアセットを保存するディレクトリ(例: dashboard, メトリクステーブル)。
`baseline_table_name`	文字列	ドリフトメトリクスのコンピュートの元となるベースラインテーブルの名前。監視対象テーブルの列は、ベースラインテーブルにも存在する必要があります。
`custom_metrics`	順序	Custom メトリクス to コンピュート on the monitored table. これらは、aggregate メトリクス、derived メトリクス (すでにコンピュート aggregate メトリクスから)、または drift メトリクス (タイムウィンドウ間でメトリクスを比較する) です。 custom_metricsを参照してください。
`inference_log`	Map	モニタリング推論ログの構成。 inference_logを参照してください。
`notifications`	Map	モニターの通知設定。「通知」を参照してください。
`output_schema_name`	文字列	出力メトリクステーブルが作成されるスキーマ。
`schedule`	Map	メトリクステーブルの自動更新と更新のスケジュール。スケジュールを参照してください。
`skip_builtin_dashboard`	ブール値	データ品質メトリクスをまとめたデフォルトダッシュボードの作成をスキップするかどうか。
`slicing_exprs`	順序	ターゲットを絞った分析のためにデータをスライスする列式のリスト。データは各式ごとに個別にグループ化されるため、述語とその補数ごとに個別のスライスが作成されます。カーディナリティの高い列の場合、頻度の上位 100 個の一意の値のみがスライスを生成します。
`snapshot`	Map	モニタリングスナップショットテーブルの構成。
`table_name`	文字列	テーブルのフルネーム。
`time_series`	Map	モニタリング時系列テーブルの設定。 time_seriesを参照してください。
`warehouse_id`	文字列	ダッシュボード作成用のウェアハウスを指定するオプションの引数。指定しない場合は、最初に稼働しているウェアハウスが使用されます。

例

quality_monitorを定義する完全なバンドルの例については、mlops_demoバンドルを参照してください。

次の例では、 InferenceLog、 TimeSeries、およびスナップショットプロファイルタイプの品質モニターを定義しています。

YAML
# InferenceLog profile type
resources:
  quality_monitors:
    my_quality_monitor:
      table_name: dev.mlops_schema.predictions
      output_schema_name: ${bundle.target}.mlops_schema
      assets_dir: /Workspace/Users/${workspace.current_user.userName}/databricks_lakehouse_monitoring
      inference_log:
        granularities: [1 day]
        model_id_col: model_id
        prediction_col: prediction
        label_col: price
        problem_type: PROBLEM_TYPE_REGRESSION
        timestamp_col: timestamp
      schedule:
        quartz_cron_expression: 0 0 8 * * ? # Run Every day at 8am
        timezone_id: UTC

YAML
# TimeSeries profile type
resources:
  quality_monitors:
    my_quality_monitor:
      table_name: dev.mlops_schema.predictions
      output_schema_name: ${bundle.target}.mlops_schema
      assets_dir: /Workspace/Users/${workspace.current_user.userName}/databricks_lakehouse_monitoring
      time_series:
        granularities: [30 minutes]
        timestamp_col: timestamp
      schedule:
        quartz_cron_expression: 0 0 8 * * ? # Run Every day at 8am
        timezone_id: UTC

YAML
# Snapshot profile type
resources:
  quality_monitors:
    my_quality_monitor:
      table_name: dev.mlops_schema.predictions
      output_schema_name: ${bundle.target}.mlops_schema
      assets_dir: /Workspace/Users/${workspace.current_user.userName}/databricks_lakehouse_monitoring
      snapshot: {}
      schedule:
        quartz_cron_expression: 0 0 8 * * ? # Run Every day at 8am
        timezone_id: UTC

registered_model (Unity Catalog)

Type: Map

登録済みのモデルリソースを使用すると、Unity Catalog でモデルを定義できます。登録されたモデルに関する情報については、「Unity Catalog でのモデルのライフサイクルの管理Unity Catalog 」を参照してください。

YAML
registered_models:
  <registered_model-name>:
    <registered_model-field-name>: <registered_model-field-value>

キー	タイプ	説明
`catalog_name`	文字列	スキーマと登録済みモデルが存在するカタログの名前。
`comment`	文字列	登録したモデルに添付されたコメント。
`grants`	順序	登録されたモデルに関連付けられている助成金。「グラント」を参照してください。
`name`	文字列	登録されているモデルの名前。
`schema_name`	文字列	登録されたモデルが存在するスキーマの名前。
`storage_location`	文字列	モデルバージョンのデータファイルが保存されるクラウド上の保存場所。

例

次の例では、Unity Catalog に登録されているモデルを定義しています。

YAML
resources:
  registered_models:
    model:
      name: my_model
      catalog_name: ${bundle.target}
      schema_name: mlops_schema
      comment: Registered model in Unity Catalog for ${bundle.target} deployment target
      grants:
        - privileges:
            - EXECUTE
          principal: account users

スキーマ (Unity Catalog)

Type: Map

スキーマリソースの種類を使用すると、バンドルの一部として作成されたワークフローとパイプライン内のテーブルやその他のアセットの Unity Catalog スキーマを定義できます。スキーマは、他のリソースタイプとは異なり、次の制限があります。

スキーマリソースの所有者は常にデプロイメントユーザーであり、変更することはできません。バンドルにrun_asが指定されている場合、スキーマに対する操作では無視されます。
対応するスキーマオブジェクト作成 API でサポートされているフィールドのみが、スキーマリソースで使用できます。たとえば、 enable_predictive_optimization は更新 API でのみ使用できるため、サポートされていません。

YAML
schemas:
  <schema-name>:
    <schema-field-name>: <schema-field-value>

キー	タイプ	説明
`catalog_name`	文字列	親カタログの名前。
`comment`	文字列	ユーザーが提供する自由形式のテキストの説明。
`grants`	順序	スキーマに関連付けられた権限。「グラント」を参照してください。
`name`	文字列	親カタログを基準としたスキーマの名前。
`properties`	Map	スキーマにアタッチされたキーと値のプロパティのマップ。
`storage_root`	文字列	スキーマ内のマネージドテーブルのストレージルート URL。

例

次の例では、リソースキー my_pipeline を使用してパイプラインを定義し、キー my_schema をターゲットとして Unity Catalog スキーマを作成します。

YAML
resources:
  pipelines:
    my_pipeline:
      name: test-pipeline-{{.unique_id}}
      libraries:
        - notebook:
            path: ../src/nb.ipynb
        - file:
            path: ../src/range.sql
      development: true
      catalog: ${resources.schemas.my_schema.catalog_name}
      target: ${resources.schemas.my_schema.id}

  schemas:
    my_schema:
      name: test-schema-{{.unique_id}}
      catalog_name: main
      comment: This schema was created by Databricks Asset Bundles.

最上位の付与マッピングは Databricks Asset Bundle ではサポートされていないため、スキーマの付与を設定する場合は、 schemas マッピング内でスキーマの付与を定義します。権限の詳細については、「権限の表示、付与、および取り消し」を参照してください。

次の例では、許可を使用して Unity Catalog スキーマを定義しています。

YAML
resources:
  schemas:
    my_schema:
      name: test-schema
      grants:
        - principal: users
          privileges:
            - SELECT
        - principal: my_team
          privileges:
            - CAN_MANAGE
      catalog_name: main

secret_scope

Type: Map

secret_scope リソースを使用すると、バンドルにシークレットスコープを定義できます。シークレットスコープに関する情報については、「シークレット管理」を参照してください。

YAML
secret_scopes:
  <secret_scope-name>:
    <secret_scope-field-name>: <secret_scope-field-value>

キー	タイプ	説明
`backend_type`	文字列	スコープが作成されるバックエンドの種類。指定しない場合、デフォルトは `DATABRICKS`です。
`keyvault_metadata`	Map	シークレットスコープのメタデータ ( `backend_type` が `AZURE_KEYVAULT`の場合)
`name`	文字列	ユーザーが要求したスコープ名。スコープ名は一意です。
`permissions`	順序	シークレットスコープに適用する権限。権限は、シークレットスコープ ACL によって管理されます。「パーミッション」を参照してください。

例

次の例では、キーコンテナーバックエンドを使用するシークレットスコープを定義しています。

YAML
resources:
  secret_scopes:
    secret_scope_azure:
      name: test-secrets-azure-backend
      backend_type: 'AZURE_KEYVAULT'
      keyvault_metadata:
        resource_id: my_azure_keyvault_id
        dns_name: my_azure_keyvault_dns_name

次の例では、シークレットスコープとアクセス許可を使用してカスタム ACL を設定します。

YAML
resources:
  secret_scopes:
    my_secret_scope:
      name: my_secret_scope
      permissions:
        - user_name: admins
          level: WRITE
        - user_name: users
          level: READ

シークレットスコープと、バンドル内でそこから読み取るタスクを持つジョブを定義する方法を示すバンドルの例については、 bundle-examples GitHub リポジトリを参照してください。

ボリューム (Unity Catalog)

Type: Map

ボリュームリソースの種類を使用すると、Unity Catalog ボリュームをバンドルの一部として定義および作成できます。ボリュームが定義されたバンドルをデプロイする場合は、次の点に注意してください。

ボリュームは、ワークスペースに存在するまで、バンドルの artifact_path で参照できません。したがって、Databricks Asset Bundles を使用してボリュームを作成する場合は、まずバンドルでボリュームを定義し、それをデプロイしてボリュームを作成し、その後のデプロイで artifact_path で参照する必要があります。
バンドル内のボリュームは、デプロイメントターゲットがmode: development設定されている場合、dev_${workspace.current_user.short_name}プレフィックスが先頭に付けられません。ただし、このプレフィックスは手動で設定できます。「カスタムプリセット」を参照してください。

YAML
volumes:
  <volume-name>:
    <volume-field-name>: <volume-field-value>

キー	タイプ	説明
`catalog_name`	文字列	スキーマとボリュームのカタログの名前。
`comment`	文字列	ボリュームに添付されたコメント。
`grants`	順序	ボリュームに関連付けられている許可。「グラント」を参照してください。
`name`	文字列	ボリュームの名前。
`schema_name`	文字列	ボリュームがあるスキーマの名前。
`storage_location`	文字列	クラウド上のストレージの場所。
`volume_type`	文字列	ボリューム・タイプ ( `EXTERNAL` または `MANAGED`のいずれか)。外部ボリュームは、指定された外部ロケーションにあります。管理対象ボリュームは、親スキーマ、親カタログ、またはメタストアによって指定されたデフォルトの場所にあります。「管理対象ボリュームと外部ボリューム」を参照してください。

例

次の例では、キー my_volume_id( T ) を使用して Unity Catalog ボリュームを作成します。

YAML
resources:
  volumes:
    my_volume_id:
      catalog_name: main
      name: my_volume
      schema_name: my_schema

Unity Catalog ボリューム内のファイルに書き込むジョブを実行するバンドルの例については、 bundle-examples GitHub リポジトリを参照してください。

共通オブジェクト

補助金

Type: Sequence

キー	タイプ	説明
`principal`	文字列	権限を付与されるプリンシパルの名前。
`privileges`	順序	指定したエンティティに付与する特権。

サポートされているリソース​

アプリ​

apps.name リソース​

例​

クラスター​

例​

ダッシュボード​

例​

database_catalogs​

例​

database_instances​

例​

synced_database_tables​

例​

エクスペリメント​

例​

ジョブ​

例​

モデル(レガシー)​

モデル_サービス_エンドポイント​

例​

パイプライン​

例​

quality_monitor (Unity Catalog)​

例​

registered_model (Unity Catalog)​

例​

スキーマ (Unity Catalog)​

例​

secret_scope​

例​

ボリューム (Unity Catalog)​

例​

共通オブジェクト​

補助 金​

サポートされているリソース

アプリ

apps.name リソース

例

クラスター

例

ダッシュボード

例

database_catalogs

例

database_instances

例

synced_database_tables

例

エクスペリメント

例

ジョブ

例

モデル(レガシー)

モデル_サービス_エンドポイント

例

パイプライン

例

quality_monitor (Unity Catalog)

例

registered_model (Unity Catalog)

例

スキーマ (Unity Catalog)

例

secret_scope

例

ボリューム (Unity Catalog)

例

共通オブジェクト

補助金