Databricks Asset Bundles のリソース

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

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

ヒント

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

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

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

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

ヒント

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

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

アプリ

Type: Map

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

アプリを追加するには、必要な 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

アプリのコンピュート リソース。

キー	タイプ	説明
description	文字列	アプリ リソースの説明。
job	Map	使用するジョブ・リソースを識別する設定。リソース.ジョブを参照してください。
name	文字列	アプリ リソースの名前。
secret	Map	シークレットの設定。リソース.secretを参照してください。
serving_endpoint	Map	使用する配信エンドポイント リソースを識別する設定。リソース.serving_endpointを参照してください。
sql_warehouse	Map	使用するウェアハウス・リソースを識別する設定。リソース.ウェアハウスを参照してください。

例

次の例では、バンドルによって作成されたジョブを管理する 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:
            client: '1'

  # 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'

ダッシュボード

Type: Map

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

YAML

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

キー	タイプ	説明
display_name	文字列	ダッシュボードの表示名。
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オプションを使用すると、ダッシュボードに対する変更を継続的にポーリングして取得できます。バンドル設定ファイルの生成を参照してください。

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

エクスペリメント

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

ジョブ リソースを使用すると、 バンドル内でジョブとそれに対応するタスク を定義できます。 ジョブに関する情報については、「Databricksジョブを使用したオーケストレーション」を参照してください。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 に設定されたタスク ソース フィールドは、ローカルの相対パスが 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

ジョブ タスクの定義とジョブ設定のオーバーライドに関する情報については、「Databricks Asset Bundle でのジョブへのタスクの追加」、「Databricks Asset Bundles でのジョブ タスク設定のオーバーライド」、および「Databricks Asset Bundle でのクラスター設定のオーバーライド」を参照してください。

important

ジョブ git_source フィールドとタスク source フィールドが GIT に設定されているのは、ローカルの相対パスが Git リポジトリ内の同じコンテンツを指していない可能性があり、バンドルはデプロイされたジョブがデプロイされた場所のローカル コピーと同じコンテンツを持つとバンドルが想定しているため、バンドルには推奨されません。

代わりに、リポジトリをローカルにクローンし、このリポジトリ内にバンドルプロジェクトを設定して、タスクのソースがワークスペースになるようにします。

モデル(レガシー)

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 を使用してください。rate_limitsを参照してください。
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

パイプライン リソースを使用すると、DLTパイプライン を作成できます。パイプラインに関する情報については、DLTを参照してください。Asset Bundles テンプレートを使用してパイプラインを作成するチュートリアルについては、「DatabricksAsset Bundles を使用したDLT パイプラインの開発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	文字列	使用する DLT のバージョンを指定する DLT Release チャンネル。
clusters	順序	このパイプライン デプロイのクラスタリング設定。 クラスタリングを参照してください。
configuration	Map	このパイプライン実行の構成。
continuous	ブール値	パイプラインが連続しているか、トリガーされているか。これは triggerを置き換えます。
deployment	Map	このパイプラインのデプロイの種類。デプロイメントを参照してください。
development	ブール値	パイプラインが開発モードであるかどうか。デフォルトは false です。
dry_run	ブール値	パイプラインがドライ実行パイプラインであるかどうか。
edition	文字列	パイプライン製品のエディション。
event_log	Map	このパイプラインのイベント ログ構成。event_logを参照してください。
filters	Map	デプロイされたグラフに含めるパイプライン パッケージを決定するフィルター。「フィルター」を参照してください。
id	文字列	このパイプラインの一意の識別子。
ingestion_definition	Map	マネージド インジェスト パイプラインの構成。これらの設定は、 libraries、 schema、 target、または catalog 設定では使用できません。ingestion_definitionを参照してください。
libraries	順序	このデプロイに必要なライブラリまたはコード。ライブラリを参照してください。
name	文字列	このパイプラインのわかりやすい名前。
notifications	順序	このパイプラインの通知設定。「通知」を参照してください。
permissions	順序	パイプラインのアクセス許可。「パーミッション」を参照してください。
photon	ブール値	このパイプラインでPhotonが有効になっているかどうか。
schema	文字列	テーブルの読み取り元またはパブリッシュ先となるデフォルトのスキーマ (データベース)。
serverless	ブール値	このパイプラインでサーバレス コンピュートが有効になっているかどうか。
storage	文字列	チェックポイントとテーブルを格納するための DBFSルート ディレクトリ。
target	文字列	このパイプラインにテーブルを追加するターゲット スキーマ (データベース)。schema または target のいずれかを正確に指定する必要があります。Unity Catalog に公開するには、 catalog.このレガシー フィールドは、パイプライン作成では非推奨となり、 schema フィールドが優先されます。
trigger	Map	廃止。使用するパイプライン トリガー。代わりに continuous を使用してください。

例

次の例では、リソース キー が 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: ./nb.sql
      development: true
      catalog: main
      target: ${resources.schemas.my_schema.id}

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

最上位の付与マッピングは 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

ボリューム (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( T ) を使用して Unity Catalog ボリュームを作成します。

YAML

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

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

共通オブジェクト

補助 金

Type: Sequence

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