Share via


Außerkraftsetzen von Einstellungen von Auftragsaufgaben in Databricks-Ressourcenpaketen

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

Sie können in Azure Databricks-Paketkonfigurationsdateien z. B. die task-Zuordnung innerhalb einer Auftragsdefinition verwenden, um die Auftragsaufgabeneinstellungen in einer resources-Zuordnung auf oberster Ebene mit den Auftragsaufgabeneinstellungen in einer targets-Zuordnung zu verknüpfen (Auslassungspunkte weisen auf Inhalte hin, die der Übersichtlichkeit halber weggelassen wurden):

# ...
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 resources-Zuordnung der obersten Ebene und die targets-Zuordnung für dasselbe task zu verknüpfen, müssen die task_key der task-Zuordnungen auf denselben Wert festgelegt werden.

Wenn eine neue Auftragsaufgabeneinstellung sowohl in der resources-Zuordnung auf oberster Ebene als auch in der targets-Zuordnung für denselben task definiert ist, hat die Einstellung in der targets-Zuordnung Vorrang vor der Einstellung in der resources-Zuordnung auf oberster Ebene.

Beispiel 1: Auftragsaufgabeneinstellungen, die ohne Einstellungskonflikte in mehreren Ressourcenzuordnungen 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 task_key namens my-task zu definieren (Auslassungspunkte weisen auf Inhalte hin, die der Übersichtlichkeit halber weggelassen wurden):

# ...
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 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": {
        "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: Auftragsaufgabeneinstellungen, die in mehreren Ressourcenzuordnungen definiert sind und miteinander in Konflikt stehen

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. spark_version und num_workers in der resources-Zuordnung in targets haben Vorrang vor spark_version und num_workers in der resources-Zuordnung auf oberster Ebene. Dadurch werden die Einstellungen für den task_key namens my-task definiert (Auslassungspunkte weisen auf Inhalte hin, die der Übersichtlichkeit halber weggelassen wurden):

# ...
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 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": {
        "tasks": [
          {
            "new_cluster": {
              "node_type_id": "Standard_DS3_v2",
              "num_workers": 2,
              "spark_version": "12.2.x-scala2.12"
            },
            "task_key": "my-task"
          }
        ],
        "...": "..."
      }
    }
  }
}