Databricks Asset Bundles のリソース

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

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

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

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

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

ヒント

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

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

クラスタリング

クラスタリングリソースは、 All-Purposeクラスターを定義します。

例

次の例では、 my_cluster という名前のクラスタリングを作成し、それを my_jobでノートブックを実行するために使用するクラスタリングとして設定します。

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"

ダッシュボード

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

例

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

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 オプションを使用します。バンドルのデプロイを参照してください。

エクスペリメント

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

例

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

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

ジョブ

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

例

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

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 でのクラスタリング設定のオーバーライド」を参照してください。

モデル(レガシー)

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

model_serving_endpoint

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

例

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

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"

quality_monitor (Unity Catalog)

quality_monitor リソースを使用すると、 Unity Catalog テーブル・モニターを定義できます。モニターに関する情報については、「モニターモデルの品質とエンドポイントの正常性」を参照してください。

例

次の例では、品質モニターを定義します。

resources:
  quality_monitors:
    my_quality_monitor:
      table_name: dev.mlops_schema.predictions
      output_schema_name: ${bundle.target}.mlops_schema
      assets_dir: /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

registered_model (Unity Catalog)

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

例

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

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

パイプライン

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

例

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

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

スキーマ (Unity Catalog)

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

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

例：

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

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 スキーマを定義しています。

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

ボリューム (Unity Catalog)

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

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

例

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

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

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