Außerkraftsetzen von Clustereinstellungen in Databricks-Ressourcenpaketen

In diesem Artikel wird beschrieben, wie Sie die Einstellungen für Azure Databricks-Cluster in Databricks-Ressourcenpaketen außer Kraft setzen. Weitere Informationen finden Sie unter Was sind Databricks-Ressourcenpakete?

In Bündelkonfigurationsdateien von Azure Databricks können Sie die Clustereinstellungen in einer resources-Zuordnung auf oberster Ebene mit den Clustereinstellungen in einer targets-Zuordnung folgendermaßen verknüpfen.

Verwenden Sie für Aufträge beispielsweise die job_cluster_key-Zuordnung innerhalb einer Auftragsdefinition, um die Clustereinstellungen in einer resources-Zuordnung auf oberster Ebene mit den Clustereinstellungen in einer targets-Zuordnung zu verknüpfen (die Auslassungspunkte stehen für aus Platzgründen ausgelassene Inhalte):

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

Wenn eine beliebige Clustereinstellung in der resources-Zuordnung auf oberster Ebene und der targets-Zuordnung für denselben job_cluster_key-Wert definiert ist, hat die Einstellung in der targets-Zuordnung auf oberster Ebene Vorrang vor der Einstellung in der resources-Zuordnung auf oberster Ebene.

Verwenden Sie für Delta Live Tables-Pipelines beispielsweise die label-Zuordnung innerhalb der cluster-Instanz einer Pipelinedefinition, um die Clustereinstellungen in einer resources-Zuordnung auf oberster Ebene mit den Clustereinstellungen in einer targets-Zuordnung zu verknüpfen (die Auslassungspunkte stehen für aus Platzgründen ausgelassene Inhalte):

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

Wenn eine beliebige Clustereinstellung in der resources-Zuordnung auf oberster Ebene und der targets-Zuordnung für denselben label-Wert definiert ist, hat die Einstellung in der targets-Zuordnung auf oberster Ebene Vorrang vor der Einstellung in der resources-Zuordnung auf oberster Ebene.

Beispiel 1: Neue Auftragsclustereinstellungen, die in mehreren Ressourcenzuordnungen ohne Einstellungskonflikte definiert sind

In diesem Beispiel wird spark_version in der resources-Zuordnung auf oberster Ebene mit node_type_id und num_workers in der resources-Zuordnung in targets kombiniert, um die Einstellungen für job_cluster_key namens my-cluster zu definieren (Auslassungspunkte weisen auf Inhalte hin, die der Übersichtlichkeit halber weggelassen wurden):

# ...
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: Standard_DS3_v2
                num_workers: 1
          # ...

Wenn Sie für dieses Beispiel databricks bundle validate ausführen, sieht der resultierende Graph wie folgt aus (Auslassungspunkte weisen auf Inhalte hin, die der Übersichtlichkeit halber weggelassen wurden):

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

Beispiel 2: Miteinander in Konflikt stehende neue Auftragsclustereinstellungen, die in mehreren Ressourcenzuordnungen definiert sind

In diesem Beispiel werden spark_version und num_workers sowohl in der resources-Zuordnung auf oberster Ebene als auch in der resources-Zuordnung in targets definiert. In diesem Beispiel haben spark_version und num_workers in der resources-Zuordnung in targets Vorrang vor spark_version und num_workers in der resources-Zuordnung auf der obersten Ebene, um die Einstellungen für job_cluster_key namens my-cluster zu definieren (Auslassungspunkte weisen auf Inhalte hin, die der Übersichtlichkeit halber weggelassen wurden):

# ...
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: Standard_DS3_v2
            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
          # ...

Wenn Sie für dieses Beispiel databricks bundle validate ausführen, sieht der resultierende Graph wie folgt aus (Auslassungspunkte weisen auf Inhalte hin, die der Übersichtlichkeit halber weggelassen wurden):

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

Beispiel 3: Pipelineclustereinstellungen, die in mehreren Ressourcenzuordnungen ohne Einstellungskonflikte definiert sind

In diesem Beispiel wird node_type_id in der resources-Zuordnung auf oberster Ebene mit num_workers in der resources-Zuordnung in targets kombiniert, um die Einstellungen für label namens default zu definieren (die Auslassungspunkte stehen für aus Platzgründen ausgelassene Inhalte):

# ...
resources:
  pipelines:
    my-pipeline:
      clusters:
        - label: default
          node_type_id: Standard_DS3_v2

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

Wenn Sie für dieses Beispiel databricks bundle validate ausführen, sieht der resultierende Graph wie folgt aus (Auslassungspunkte weisen auf Inhalte hin, die der Übersichtlichkeit halber weggelassen wurden):

{
  "...": "...",
  "resources": {
    "pipelines": {
      "my-pipeline": {
        "clusters": [
          {
            "label": "default",
            "node_type_id": "Standard_DS3_v2",
            "num_workers": 1
          }
        ],
        "...": "..."
      }
    }
  }
}

Beispiel 4: Miteinander in Konflikt stehende Pipelineclustereinstellungen, die in mehreren Ressourcenzuordnungen definiert sind

In diesem Beispiel wird num_workers sowohl in der resources-Zuordnung auf oberster Ebene als auch in der resources-Zuordnung in targets definiert. num_workers in der resources-Zuordnung in targets hat Vorrang vor num_workers in der resources-Zuordnung auf oberster Ebene, um die Einstellungen für label namens default zu definieren (die Auslassungspunkte stehen für aus Platzgründen ausgelassene Inhalte):

# ...
resources:
  pipelines:
    my-pipeline:
      clusters:
        - label: default
          node_type_id: Standard_DS3_v2
          num_workers: 1

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

Wenn Sie für dieses Beispiel databricks bundle validate ausführen, sieht der resultierende Graph wie folgt aus (Auslassungspunkte weisen auf Inhalte hin, die der Übersichtlichkeit halber weggelassen wurden):

{
  "...": "...",
  "resources": {
    "pipelines": {
      "my-pipeline": {
        "clusters": [
          {
            "label": "default",
            "node_type_id": "Standard_DS3_v2",
            "num_workers": 2
          }
        ],
        "...": "..."
      }
    }
  }
}