Udostępnij przez

Nadpisz ustawieniami docelowymi

Na tej stronie opisano, jak zastąpić lub dołączyć ustawienia najwyższego poziomu, używając ustawień docelowych w pakietach zasobów Databricks. Aby uzyskać informacje o ustawieniach pakietu, zobacz Konfiguracja pakietu zasobów usługi Databricks.

Nadpisanie ustawień artefaktu

Ustawienia artefaktu można zastąpić w mapowaniu najwyższego poziomu artifacts przy użyciu ustawień artefaktu w mapowaniu targets, na przykład:

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

Jeśli dowolne ustawienie artefaktu jest zdefiniowane zarówno w mapowaniu najwyższego poziomu artifacts jak i w mapowaniu targets dla tego samego artefaktu, ustawienie w mapowaniu targets ma pierwszeństwo przed ustawieniem w mapowaniu artifacts najwyższego poziomu.

Przykład 1: Ustawienia artefaktów zdefiniowane tylko w mapowaniu artefaktów najwyższego poziomu

Aby zademonstrować, jak to działa w praktyce, path w poniższym przykładzie jest definiowane w mapowaniu najwyższego poziomu artifacts , które definiuje wszystkie ustawienia artefaktu:

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

Po uruchomieniu databricks bundle validate tego przykładu, wynikowy wykres jest następujący:

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

Przykład 2. Ustawienia artefaktu powodujące konflikt zdefiniowane w wielu mapowaniach artefaktów

W tym przykładzie path jest zdefiniowane zarówno w mapowaniu najwyższego poziomu artifacts, jak i w mapowaniu artifacts w targets. W tym przykładzie path w mapowaniu artifacts w targets ma pierwszeństwo przed path w mapowaniu najwyższego poziomu artifacts, aby zdefiniować ustawienia artefaktu:

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

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

Po uruchomieniu databricks bundle validate tego przykładu, wynikowy wykres jest następujący:

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

Przesłonięcia ustawień klastra

Możesz zastąpić lub dołączyć ustawienia zadania lub klastra potoku dla elementu docelowego.

W przypadku zadań użyj job_cluster_key w definicji zadania, aby zidentyfikować ustawienia klastra zadań w mapowaniu najwyższego poziomu resources i połączyć je z ustawieniami klastra zadań w mapowaniu targets.

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

Jeśli jakiekolwiek ustawienie klastra jest zdefiniowane zarówno w mapowaniu najwyższego poziomu resources, jak i w mapowaniu targets dla tego samego job_cluster_key, wtedy ustawienie w mapowaniu targets ma pierwszeństwo przed ustawieniem w mapowaniu najwyższego poziomu resources.

W przypadku deklaratywnych potoków Lakeflow Spark użyj label w ustawieniach klastra definicji rurociągu, aby zidentyfikować ustawienia klastra w nadrzędnym mapowaniu resources do połączenia z ustawieniami klastra w mapowaniu targets, na przykład:

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

Jeśli jakiekolwiek ustawienie klastra jest zdefiniowane zarówno w mapowaniu najwyższego poziomu resources, jak i w mapowaniu targets dla tego samego label, wtedy ustawienie w mapowaniu targets ma pierwszeństwo przed ustawieniem w mapowaniu najwyższego poziomu resources.

Przykład 1: Nowe ustawienia klastra zadań zdefiniowane w wielu mapowaniach zasobów i bez konfliktów ustawień

W tym przykładzie w mapowaniu najwyższego poziomu spark_version łączy się z resources i node_type_id w mapowaniu num_workers w resources w celu zdefiniowania ustawień dla elementu targets, nazwanego job_cluster_key.

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

Po uruchomieniu databricks bundle validate dla tego przykładu wynikowy wykres wygląda następująco:

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

Przykład 2. Konflikt nowych ustawień klastra zadań zdefiniowanych w wielu mapowaniach zasobów

W tym przykładzie spark_version i num_workers są zdefiniowane zarówno w mapowaniu najwyższego poziomu resources, jak i w mapowaniu resources w targets. W tym przykładzie spark_version i num_workers w mapowaniu resources mają pierwszeństwo nad targets i spark_version w mapowaniu najwyższego poziomu num_workers, w celu zdefiniowania ustawień dla resources o nazwie job_cluster_key.

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

Po uruchomieniu databricks bundle validate dla tego przykładu wynikowy wykres wygląda następująco:

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

Przykład 3. Ustawienia klastra potoku zdefiniowane w wielu mapowaniach zasobów i bez konfliktów między ustawieniami

W tym przykładzie node_type_id w mapowaniu najwyższego poziomu resources i num_workers w mapowaniu resources w targets celu zdefiniowania ustawień dla elementu nazwanego labeldefault:

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

Po uruchomieniu databricks bundle validate dla tego przykładu wynikowy wykres wygląda następująco:

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

Przykład 4: Konflikt ustawień klastra rurociągu zdefiniowanych w wielu mapowaniach zasobów

W tym przykładzie num_workers jest zdefiniowane zarówno w mapowaniu najwyższego poziomu resources, jak i w mapowaniu resources w targets. num_workers w mapowaniu resources w targets ma pierwszeństwo przed mapowaniem najniższego poziomu num_workers, aby zdefiniować ustawienia dla resources o nazwie label:

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

Po uruchomieniu databricks bundle validate dla tego przykładu wynikowy wykres wygląda następująco:

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

Nadpisanie ustawień zadania

Za pomocą tasks mapowania w definicji zadania można połączyć ustawienia zadań w mapowaniu najwyższego poziomu resources z ustawieniami zadań w targets mapowaniu, na przykład:

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

Aby połączyć mapowanie najwyższego poziomu resources oraz mapowanie targets dla tego samego zadania, wartości task_key w mapowaniach zadań muszą być identyczne.

Jeśli jakiekolwiek ustawienie zadania jest zdefiniowane zarówno w mapowaniu najwyższego poziomu resources, jak i w mapowaniu targets dla tego samego task elementu, ustawienie w mapowaniu targets ma pierwszeństwo przed ustawieniem w mapowaniu najwyższego poziomu resources.

Przykład 1: Ustawienia zadania określone z wieloma mapowaniami zasobów i bez konfliktów ustawień

W tym przykładzie w mapowaniu najwyższego poziomu spark_version łączy się z resources i node_type_id w mapowaniu num_workers w resources w celu zdefiniowania ustawień dla elementu targets, nazwanego task_key.

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

Po uruchomieniu przykładowego databricks bundle validate, wynikowy wykres jest następujący (wielokropek wskazuje pominiętą zawartość dla przejrzystości):

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

Przykład 2. Ustawienia zadania powodujące konflikt zdefiniowane w wielu mapowaniach zasobów

W tym przykładzie spark_version i num_workers są zdefiniowane zarówno w mapowaniu najwyższego poziomu resources, jak i w mapowaniu resources w targets. spark_version i num_workers w mapowaniu resources mają pierwszeństwo przed targets i spark_version w mapowaniu najwyższego poziomu num_workers. Definiuje ustawienia dla task_key o nazwie my-task (wielokropek wskazuje pominiętą zawartość dla zwięzłości):

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

Po uruchomieniu databricks bundle validate dla tego przykładu wynikowy wykres wygląda następująco:

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