メインコンテンツまでスキップ

ターゲット設定で上書き

このページでは、Databricks アセット バンドルの最上位設定をターゲット設定でオーバーライドまたは結合する方法について説明します。バンドル設定の詳細については、 Databricks Asset Bundle の構成」を参照してください。

アーティファクト設定のオーバーライド​

最上位レベルのartifactsマッピングのアーティファクト設定を、 targetsマッピングのアーティファクト設定でオーバーライドできます。次に例を示します。

YAML
# ...
artifacts:
  <some-unique-programmatic-identifier-for-this-artifact>:
    # Artifact settings.

targets:
  <some-unique-programmatic-identifier-for-this-target>:
    artifacts:
      <the-matching-programmatic-identifier-for-this-artifact>:
        # Any more artifact settings to join with the settings from the
        # matching top-level artifacts mapping.

同じアーティファクトに対して、最上位レベルのartifactsマッピングとtargetsマッピングの両方でアーティファクト設定が定義されている場合、 targetsマッピングの設定が最上位レベルのartifactsマッピングの設定よりも優先されます。

例 1: 最上位のアーティファクト マッピングでのみ定義されたアーティファクト設定​

これが実際にどのように機能するかを示すために、次の例では、アーティファクトのすべての設定を定義する最上位レベルのartifactsマッピングでpathが定義されています。

YAML
# ...
artifacts:
  my-artifact:
    type: whl
    path: ./my_package
# ...

この例でdatabricks bundle validate実行すると、結果のグラフは次のようになります。

JSON
{
  "...": "...",
  "artifacts": {
    "my-artifact": {
      "type": "whl",
      "path": "./my_package",
      "...": "..."
    }
  },
  "...": "..."
}

例2: 複数のアーティファクトマッピングで定義された競合するアーティファクト設定​

この例では、 path最上位のartifactsマッピングとtargetsのartifactsマッピングの両方で定義されています。この例では、 targetsのartifactsマッピングのpath最上位レベルのartifactsマッピングのpathよりも優先され、アーティファクトの設定を定義します。

YAML
# ...
artifacts:
  my-artifact:
    type: whl
    path: ./my_package

targets:
  dev:
    artifacts:
      my-artifact:
        path: ./my_other_package
    # ...

この例でdatabricks bundle validate実行すると、結果のグラフは次のようになります。

JSON
{
  "...": "...",
  "artifacts": {
    "my-artifact": {
      "type": "whl",
      "path": "./my_other_package",
      "...": "..."
    }
  },
  "...": "..."
}

クラスター設定のオーバーライド​

ターゲットのジョブまたはパイプライン クラスター設定を上書きしたり、結合したりできます。

ジョブの場合、ジョブ定義内で job_cluster_key を使用して、最上位の resources マッピングのジョブ クラスター設定を識別し、 targets マッピングのジョブ クラスター設定と結合します。

YAML
# ...
resources:
  jobs:
    <some-unique-programmatic-identifier-for-this-job>:
      # ...
      job_clusters:
        - job_cluster_key: <some-unique-programmatic-identifier-for-this-key>
          new_cluster:
            # Cluster settings.

targets:
  <some-unique-programmatic-identifier-for-this-target>:
    resources:
      jobs:
        <the-matching-programmatic-identifier-for-this-job>:
          # ...
          job_clusters:
            - job_cluster_key: <the-matching-programmatic-identifier-for-this-key>
              # Any more cluster settings to join with the settings from the
              # resources mapping for the matching top-level job_cluster_key.
          # ...

クラスター設定が、トップレベルのresourcesマッピングと同じjob_cluster_keyのtargetsマッピングの両方で定義されている場合、targetsマッピングの設定は、トップレベルのresourcesマッピングの設定よりも優先されます。

Lakeflow宣言型パイプラインの場合は、パイプライン定義のクラスター設定内のlabelを使用して、targetsマッピングのクラスター設定と結合する最上位のresourcesマッピングのクラスター設定を特定します。

YAML
# ...
resources:
  pipelines:
    <some-unique-programmatic-identifier-for-this-pipeline>:
      # ...
      clusters:
        - label: default | maintenance
          # Cluster settings.

targets:
  <some-unique-programmatic-identifier-for-this-target>:
    resources:
      pipelines:
        <the-matching-programmatic-identifier-for-this-pipeline>:
          # ...
          clusters:
            - label: default | maintenance
              # Any more cluster settings to join with the settings from the
              # resources mapping for the matching top-level label.
          # ...

クラスター設定が、トップレベルのresourcesマッピングと同じlabelのtargetsマッピングの両方で定義されている場合、targetsマッピングの設定は、トップレベルのresourcesマッピングの設定よりも優先されます。

例 1: 複数のリソース マッピングで定義され、設定の競合がない新しいジョブ クラスター設定​

この例では、最上位レベルのresourcesマッピングのspark_version 、 targetsのresourcesマッピングのnode_type_idおよびnum_workersと結合され、 my-clusterという名前のjob_cluster_keyの設定が定義されます。

YAML
# ...
resources:
  jobs:
    my-job:
      name: my-job
      job_clusters:
        - job_cluster_key: my-cluster
          new_cluster:
            spark_version: 13.3.x-scala2.12

targets:
  development:
    resources:
      jobs:
        my-job:
          name: my-job
          job_clusters:
            - job_cluster_key: my-cluster
              new_cluster:
                node_type_id: n2-highmem-4
                num_workers: 1
          # ...

この例でdatabricks bundle validate実行すると、結果のグラフは次のようになります。

JSON
{
  "...": "...",
  "resources": {
    "jobs": {
      "my-job": {
        "job_clusters": [
          {
            "job_cluster_key": "my-cluster",
            "new_cluster": {
              "node_type_id": "n2-highmem-4",
              "num_workers": 1,
              "spark_version": "13.3.x-scala2.12"
            }
          }
        ],
        "...": "..."
      }
    }
  }
}

例 2: 複数のリソース マッピングで定義された新しいジョブ クラスター設定の競合​

この例では、 spark_versionとnum_workers 、最上位のresourcesマッピングとtargetsのresourcesマッピングの両方で定義されています。この例では、 targetsのresourcesマッピングのspark_versionとnum_workers 、最上位レベルのresourcesマッピングのspark_versionとnum_workersよりも優先され、 my-clusterという名前のjob_cluster_keyの設定を定義します。

YAML
# ...
resources:
  jobs:
    my-job:
      name: my-job
      job_clusters:
        - job_cluster_key: my-cluster
          new_cluster:
            spark_version: 13.3.x-scala2.12
            node_type_id: n2-highmem-4
            num_workers: 1

targets:
  development:
    resources:
      jobs:
        my-job:
          name: my-job
          job_clusters:
            - job_cluster_key: my-cluster
              new_cluster:
                spark_version: 12.2.x-scala2.12
                num_workers: 2
          # ...

この例でdatabricks bundle validate実行すると、結果のグラフは次のようになります。

JSON
{
  "...": "...",
  "resources": {
    "jobs": {
      "my-job": {
        "job_clusters": [
          {
            "job_cluster_key": "my-cluster",
            "new_cluster": {
              "node_type_id": "n2-highmem-4",
              "num_workers": 2,
              "spark_version": "12.2.x-scala2.12"
            }
          }
        ],
        "...": "..."
      }
    }
  }
}

例 3: 複数のリソース マッピングで定義され、設定の競合がないパイプライン クラスター設定​

この例では、最上位レベルのresourcesマッピングのnode_type_idが、 targetsのresourcesマッピングのnum_workersと結合され、 defaultという名前のlabelの設定を定義します。

YAML
# ...
resources:
  pipelines:
    my-pipeline:
      clusters:
        - label: default
          node_type_id: n2-highmem-4

targets:
  development:
    resources:
      pipelines:
        my-pipeline:
          clusters:
            - label: default
              num_workers: 1
          # ...

この例でdatabricks bundle validate実行すると、結果のグラフは次のようになります。

JSON
{
  "...": "...",
  "resources": {
    "pipelines": {
      "my-pipeline": {
        "clusters": [
          {
            "label": "default",
            "node_type_id": "n2-highmem-4",
            "num_workers": 1
          }
        ],
        "...": "..."
      }
    }
  }
}

例 4: 複数のリソース マッピングで定義された競合するパイプライン クラスター設定​

この例では、 num_workers最上位のresourcesマッピングとtargetsのresourcesマッピングの両方で定義されています。targetsのresourcesマッピングのnum_workersは、最上位レベルのresourcesマッピングのnum_workersよりも優先され、 defaultという名前のlabelの設定を定義します。

YAML
# ...
resources:
  pipelines:
    my-pipeline:
      clusters:
        - label: default
          node_type_id: n2-highmem-4
          num_workers: 1

targets:
  development:
    resources:
      pipelines:
        my-pipeline:
          clusters:
            - label: default
              num_workers: 2
          # ...

この例でdatabricks bundle validate実行すると、結果のグラフは次のようになります。

JSON
{
  "...": "...",
  "resources": {
    "pipelines": {
      "my-pipeline": {
        "clusters": [
          {
            "label": "default",
            "node_type_id": "n2-highmem-4",
            "num_workers": 2
          }
        ],
        "...": "..."
      }
    }
  }
}

ジョブタスク設定のオーバーライド​

ジョブ定義内でtasksマッピングを使用すると、最上位のresourcesマッピングのジョブ タスク設定をtargetsマッピングのジョブ タスク設定と結合できます。次に例を示します。

YAML
# ...
resources:
  jobs:
    <some-unique-programmatic-identifier-for-this-job>:
      # ...
      tasks:
        - task_key: <some-unique-programmatic-identifier-for-this-task>
          # Task settings.

targets:
  <some-unique-programmatic-identifier-for-this-target>:
    resources:
      jobs:
        <the-matching-programmatic-identifier-for-this-job>:
          # ...
          tasks:
            - task_key: <the-matching-programmatic-identifier-for-this-key>
              # Any more task settings to join with the settings from the
              # resources mapping for the matching top-level task_key.
          # ...

同じタスクの最上位のresourcesマッピングとtargetsマッピングを結合するには、タスク マッピングのtask_key同じ値に設定する必要があります。

同じtaskに対して、最上位のresourcesマッピングとtargetsマッピングの両方でジョブ タスク設定が定義されている場合、 targetsマッピングの設定が最上位のresourcesマッピングの設定よりも優先されます。

例1: 複数のリソースマッピングで定義され、設定の競合がないジョブタスク設定​

この例では、最上位レベルのresourcesマッピングのspark_version 、 targetsのresourcesマッピングのnode_type_idおよびnum_workersと結合され、 my-taskという名前のtask_keyの設定が定義されます。

YAML
# ...
resources:
  jobs:
    my-job:
      name: my-job
      tasks:
        - task_key: my-key
          new_cluster:
            spark_version: 13.3.x-scala2.12

targets:
  development:
    resources:
      jobs:
        my-job:
          name: my-job
          tasks:
            - task_key: my-task
              new_cluster:
                node_type_id: n2-highmem-4
                num_workers: 1
          # ...

この例でdatabricks bundle validate実行すると、結果のグラフは次のようになります (省略記号は簡潔にするために省略されたコンテンツを示します)。

JSON
{
  "...": "...",
  "resources": {
    "jobs": {
      "my-job": {
        "tasks": [
          {
            "new_cluster": {
              "node_type_id": "n2-highmem-4",
              "num_workers": 1,
              "spark_version": "13.3.x-scala2.12"
            },
            "task-key": "my-task"
          }
        ],
        "...": "..."
      }
    }
  }
}

例2: 複数のリソースマッピングで定義された競合するジョブタスク設定​

この例では、 spark_versionとnum_workers 、最上位のresourcesマッピングとtargetsのresourcesマッピングの両方で定義されています。targetsのresourcesマッピングのspark_versionとnum_workersは、最上位レベルのresourcesマッピングのspark_versionとnum_workersよりも優先されます。これは、 my-taskという名前のtask_keyの設定を定義します (省略記号は簡潔にするために省略された内容を示します)。

YAML
# ...
resources:
  jobs:
    my-job:
      name: my-job
      tasks:
        - task_key: my-task
          new_cluster:
            spark_version: 13.3.x-scala2.12
            node_type_id: n2-highmem-4
            num_workers: 1

targets:
  development:
    resources:
      jobs:
        my-job:
          name: my-job
          tasks:
            - task_key: my-task
              new_cluster:
                spark_version: 12.2.x-scala2.12
                num_workers: 2
          # ...

この例でdatabricks bundle validate実行すると、結果のグラフは次のようになります。

JSON
{
  "...": "...",
  "resources": {
    "jobs": {
      "my-job": {
        "tasks": [
          {
            "new_cluster": {
              "node_type_id": "n2-highmem-4",
              "num_workers": 2,
              "spark_version": "12.2.x-scala2.12"
            },
            "task_key": "my-task"
          }
        ],
        "...": "..."
      }
    }
  }
}
に最終更新