Freigeben über

Überschreiben mit Zieleinstellungen

Auf dieser Seite wird beschrieben, wie übergeordnete Einstellungen mit Zieleinstellungen in Databricks Asset Bundles überschrieben oder kombiniert werden. Informationen zu Bundleeinstellungen finden Sie unter Databricks Asset Bundle-Konfiguration.

Außerkraftsetzung der Artefakteinstellungen

Sie können die Artefakteinstellungen in einer Zuordnung auf oberster Ebene artifacts mit den Artefakteinstellungen in einer targets Zuordnung überschreiben, z. B.:

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

Wenn eine Artefakteinstellung sowohl in der Zuordnung der obersten Ebene artifacts als auch der targets Zuordnung für dasselbe Artefakt definiert ist, hat die Einstellung in der targets Zuordnung Vorrang vor der Einstellung in der Zuordnung auf oberster Ebene artifacts .

Beispiel 1: Artefakteeinstellungen, die nur in der Zuordnung der Artefakte auf oberster Ebene definiert sind

Um zu veranschaulichen, wie dies in der Praxis funktioniert, wird path im folgenden Beispiel in der Spitzenebenen Zuordnung artifacts definiert, die alle Einstellungen für das Artefakt festlegt:

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

Wenn Sie für dieses Beispiel ausführen databricks bundle validate , lautet das resultierende Diagramm:

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

Beispiel 2: In mehreren Artefaktzuordnungen definierte Artefakteinstellungen mit Konflikten

In diesem Beispiel ist path sowohl in der Zuordnung auf oberster Ebene artifacts als auch in der Zuordnung artifacts in targets definiert. In diesem Beispiel hat path in der artifacts Zuordnung targets Vorrang gegenüber path in der Zuordnung auf oberster Ebene artifacts, um die Artefakteinstellungen festzulegen.

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

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

Wenn Sie für dieses Beispiel ausführen databricks bundle validate , lautet das resultierende Diagramm:

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

Außerkraftsetzungen für Clustereinstellungen

Sie können die Auftrags- oder Pipelineclustereinstellungen für ein Ziel außer Kraft setzen oder diesem beitreten.

Verwenden Sie job_cluster_key innerhalb einer Auftragsdefinition, um die Auftragsclustereinstellungen in der obersten Zuordnungsebene resources zu identifizieren und mit den Auftragsclustereinstellungen in einer targets Zuordnung zu verknüpfen.

# ...
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 top-level resources-Zuordnung als auch in der targets-Zuordnung für dasselbe job_cluster_key definiert ist, hat die Einstellung in der targets-Zuordnung Vorrang vor der Einstellung in der top-level resources-Zuordnung.

Verwenden Sie label für Lakeflow Spark Declarative Pipelines innerhalb der Clustereinstellungen einer Pipelinedefinition, um Clustereinstellungen in einer Zuordnung auf oberster Ebene resources zu identifizieren, um mit den Clustereinstellungen in einer targets Zuordnung zu verbinden, z. B.:

# ...
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 top-level resources-Zuordnung als auch in der targets-Zuordnung für dasselbe label definiert ist, hat die Einstellung in der targets-Zuordnung Vorrang vor der Einstellung in der top-level resources-Zuordnung.

Beispiel 1: Neue Auftragsclustereinstellungen, die in mehreren Ressourcenzuordnungen definiert sind und keine Einstellungskonflikte haben

In diesem Beispiel wird spark_version in der Zuordnung auf oberster Ebene mit resources und node_type_id in der num_workers Zuordnung in resources kombiniert, um die Einstellungen für den targets mit dem Namen job_cluster_key zu definieren.

# ...
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 das resultierende Diagramm wie folgt:

{
  "...": "...",
  "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 obersten Zuordnung resources als auch in der resources Zuordnung in targets definiert. In diesem Beispiel haben spark_version und num_workers in der Zuordnung resources in targets Vorrang vor spark_version und num_workers in der Zuordnung auf oberster Ebene resources, um die Einstellungen für den job_cluster_key benannten my-cluster zu definieren.

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

{
  "...": "...",
  "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: In mehreren Ressourcenzuordnungen definierte Pipelineclustereinstellungen und ohne Einstellungskonflikte

In diesem Beispiel wird node_type_id in der Zuordnung auf oberster Ebene mit resources in der num_workers-Zuordnung in resources kombiniert, um die Einstellungen für den targets mit dem Namen label zu definieren.

# ...
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 resultierende Diagramm wie folgt:

{
  "...": "...",
  "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 ist num_workers sowohl in der Zuordnung auf oberster Ebene resources als auch in der Zuordnung resources in targets definiert. num_workers in der resources Zuordnung haben in targets Vorrang vor num_workers in der Zuordnung auf oberster Ebene resources, um die Einstellungen für den label namens default zu definieren:

# ...
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 databricks bundle validate für dieses Beispiel ausführen, lautet das resultierende Diagramm wie folgt:

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

Außerkraftsetzung der Auftragsaufgabeneinstellungen

Sie können die tasks Zuordnung in einer Auftragsdefinition verwenden, um die Auftragsaufgabeneinstellungen in einer Zuordnung auf oberster Ebene resources mit den Auftragsaufgabeneinstellungen in einer targets Zuordnung zu verknüpfen, z. B.:

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

Um die Zuordnung der obersten Ebene resources mit der targets Zuordnung für denselbe Aufgabe zu verbinden, müssen die Aufgabenzuordnungen task_key auf denselben Wert festgelegt werden.

Wenn eine Aufgabeneinstellung sowohl in der Zuordnung der obersten Ebene resources als auch der Zuordnung targets für dasselbe task definiert ist, hat die Einstellung in der Zuordnung targets Vorrang vor der Einstellung in der obersten Ebene resources Zuordnung.

Beispiel 1: Einstellungen für Arbeitsaufgaben, die in mehreren Ressourcenzuordnungen definiert sind und ohne Konflikte in den Einstellungen.

In diesem Beispiel wird spark_version in der Zuordnung auf oberster Ebene mit resources und node_type_id in der num_workers Zuordnung in resources kombiniert, um die Einstellungen für den targets mit dem Namen task_key zu definieren.

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

Wenn Sie databricks bundle validate für dieses Beispiel ausführen, sieht das resultierende Diagramm wie folgt aus (Auslassungspunkte geben ausgelassenen Inhalt aus Platzgründen an):

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

Beispiel 2: Konfliktierende Einstellungen von Jobaufgaben, definiert in mehreren Ressourcenzuordnungen

In diesem Beispiel werden spark_version und num_workers sowohl in der obersten Zuordnung resources als auch in der resources Zuordnung in targets definiert. spark_version und num_workers in der resources Zuordnung, targets haben Vorrang vor spark_version und num_workers in der Zuordnung auf höchster Ebene resources. Dadurch werden die Einstellungen für den/die task_key genannten my-task definiert (Auslassungspunkte geben ausgelassenen Inhalt aus Platzgründen an).

# ...
resources:
  jobs:
    my-job:
      name: my-job
      tasks:
        - task_key: my-task
          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
          tasks:
            - task_key: my-task
              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:

{
  "...": "...",
  "resources": {
    "jobs": {
      "my-job": {
        "tasks": [
          {
            "new_cluster": {
              "node_type_id": "Standard_DS3_v2",
              "num_workers": 2,
              "spark_version": "12.2.x-scala2.12"
            },
            "task_key": "my-task"
          }
        ],
        "...": "..."
      }
    }
  }
}
  • Last updated on