Außerkraftsetzen von Clustereinstellungen in Databricks-Ressourcenpaketen

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

In Azure Databricks Bündelkonfigurationsdateienkönnen Sie die Clustereinstellungen in einer resources Zuordnung auf oberster Ebene mit den Clustereinstellungen in einer targets Zuordnung wie folgt 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 Clustereinstellung sowohl in der Zuordnung auf oberster Ebene resources als auch in der targets-Zuordnung für dieselbe job_cluster_keydefiniert ist, hat die Einstellung in der targets-Zuordnung Vorrang vor der Einstellung in der Zuordnung auf oberster Ebene resources.

Verwenden Sie für DLT-Pipelines die label-Zuordnung innerhalb der cluster einer Pipelinedefinition, um die Clustereinstellungen in einer resources-Zuordnung auf oberster Ebene mit den Clustereinstellungen in einer targets-Zuordnung zu verbinden, z. B. (Auslassungspunkte deuten auf ausgelassenen Inhalt hin, aus Platzgründen):

# ...
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 Clustereinstellung sowohl in der Zuordnung auf oberster Ebene resources als auch in der Zuordnung targets für dieselbe labeldefiniert ist, hat die Einstellung in der Zuordnung targets Vorrang vor der Zuordnung resources auf oberster Ebene.

Beispiel 1: Neue Job-Cluster-Einstellungen, die in mehreren Ressourcenzuordnungen definiert sind und keine Einstellungskonflikte aufweisen

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 databricks bundle validate für dieses Beispiel ausführen, lautet die resultierende Grafik wie folgt (Ellipsen geben ausgelassenen Inhalt aus Platzgründen an):

{
  "...": "...",
  "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: Widersprüchliche 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 databricks bundle validate für dieses Beispiel ausführen, lautet das resultierende Diagramm wie folgt (Hinweis: Auslassungspunkte geben ausgelassenen Inhalt aus Platzgründen an):

{
  "...": "...",
  "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 databricks bundle validate für dieses Beispiel ausführen, lautet das daraus resultierende Diagramm wie folgt (Auslassungspunkte geben den ausgelassenen Inhalt aus Platzgründen an):

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

Beispiel 4: In mehreren Ressourcenzuordnungen definierte Einstellungen für konfliktierende Pipelinecluster

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
          }
        ],
        "...": "..."
      }
    }
  }
}