Partager via

Remplacer par les paramètres de cible

Cette page explique comment remplacer ou joindre des paramètres de niveau supérieur avec des paramètres cibles dans les bundles de ressources Databricks. Pour plus d’informations sur les paramètres d’offre groupée, consultez la configuration de Databricks Asset Bundle.

Remplacement des paramètres d’artefact

Vous pouvez remplacer les paramètres d’artefact dans un mappage de niveau supérieur artifacts par les paramètres d’artefact dans un mappage targets, par exemple :

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

Si un paramètre d’artefact est défini à la fois dans le mappage supérieur artifacts et dans le mappage targets pour le même artefact, le paramètre du mappage targets prend le pas sur le paramètre du mappage supérieur artifacts.

Exemple 1 : Paramètres d’artefact définis uniquement dans le mappage des artefacts de niveau supérieur

Pour montrer comment cela fonctionne dans la pratique, dans l’exemple suivant, path est défini dans le mappage de niveau artifacts supérieur, qui définit tous les paramètres de l’artefact :

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

Lorsque vous exécutez databricks bundle validate pour cet exemple, le graphique obtenu est :

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

Exemple 2 : Paramètres d’artefact en conflit définis dans plusieurs mappages d’artefacts

Dans cet exemple, path est défini à la fois dans le mappage artifacts de niveau supérieur et dans le mappage artifacts dans targets. Dans cet exemple, path dans le mappage artifacts dans targets prend le pas sur path dans le mappage de niveau supérieur artifacts pour définir les paramètres de l’artefact :

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

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

Lorsque vous exécutez databricks bundle validate pour cet exemple, le graphique obtenu est :

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

Remplacements des paramètres de cluster

Vous pouvez remplacer ou joindre les paramètres du travail ou du cluster de pipeline pour une cible.

Pour les jobs, utilisez job_cluster_key dans une définition de job pour identifier les paramètres de cluster de jobs dans le mappage de niveau supérieur à joindre avec les paramètres du cluster de jobs dans un mappage resources :

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

Si un paramètre de cluster est défini à la fois dans le mappage de niveau resources supérieur et dans le mappage targets pour le même job_cluster_key, alors le paramètre du mappage targets a priorité sur le paramètre du mappage de niveau resources supérieur.

Pour les pipelines déclaratifs Spark Lakeflow, utilisez label dans les paramètres de cluster d'une définition de pipeline pour identifier les paramètres de cluster dans un mappage de niveau supérieur resources afin de les joindre avec les paramètres de cluster dans un mappage targets, par exemple :

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

Si un paramètre de cluster est défini à la fois dans le mappage de niveau resources supérieur et dans le mappage targets pour le même label, alors le paramètre du mappage targets a priorité sur le paramètre du mappage de niveau resources supérieur.

Exemple 1 : Nouveaux paramètres de cluster de travail définis dans plusieurs mappages de ressources et sans conflit de paramètres

Dans cet exemple, spark_version dans le mappage de niveau supérieur resources est combiné avec node_type_id et num_workers dans le mappage resources dans targets, dans lequel on définit les paramètres pour le job_cluster_key nommé my-cluster.

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

Lorsque vous exécutez databricks bundle validate cet exemple, le graphique résultant est le suivant :

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

Exemple 2 : Conflits de nouveaux paramètres de cluster de travail définis dans plusieurs mappages de ressources

Dans cet exemple, spark_versionet num_workers sont définis à la fois dans le mappage de niveau resources supérieur et dans le resources mappage dans targets. Dans cet exemple, spark_version et num_workers dans le mappage resources du targets ont la priorité sur spark_version et num_workers dans le mappage principal de resources, afin de définir les paramètres du job_cluster_key appelé my-cluster:

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

Lorsque vous exécutez databricks bundle validate cet exemple, le graphique résultant est le suivant :

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

Exemple 3 : Paramètres de cluster de pipeline définis dans plusieurs mappages de ressources et sans conflit de paramètres

Dans cet exemple, node_type_id au niveau supérieur resources est combiné avec num_workers dans le mappage resources de targets pour définir les paramètres du label appelé default.

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

Lorsque vous exécutez databricks bundle validate cet exemple, le graphique résultant est le suivant :

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

Exemple 4 : Paramètres de cluster de pipeline en conflit définis dans plusieurs mappages de ressources

Dans cet exemple, num_workers est défini à la fois dans le mappage resources de niveau supérieur et dans le mappage resources dans targets. num_workers dans le resources cartographie en targets priment sur num_workers du mappage de niveau supérieur, pour définir les paramètres du resources nommé 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
          # ...

Lorsque vous exécutez databricks bundle validate cet exemple, le graphique résultant est le suivant :

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

Remplacement des paramètres de tâche de travail

Vous pouvez utiliser le tasks mappage dans une définition de tâche pour associer les paramètres des tâches dans un mappage de niveau supérieur resources avec les paramètres de tâche dans un mappage targets, par exemple :

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

Pour joindre le mappage supérieur de niveau resources et le mappage targets pour la même tâche, les tâches de mappage task_key doivent être définies sur la même valeur.

Si un paramètre de tâche d'emploi est défini à la fois dans le mappage resources de niveau supérieur et le mappage targets pour le même task, alors le paramètre du mappage targets prend le pas sur le paramètre dans le mappage resources de niveau supérieur.

Exemple 1 : Paramètres de tâche de travail définis dans plusieurs mappages de ressources et sans conflit de paramètres

Dans cet exemple, spark_version dans le mappage de niveau supérieur resources est combiné avec node_type_id et num_workers dans le mappage resources dans targets, dans lequel on définit les paramètres pour le task_key nommé my-task.

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

Lorsque vous exécutez databricks bundle validate cet exemple, le graphique résultant est le suivant (les points de suspension indiquent le contenu omis, pour la concision) :

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

Exemple 2 : paramètres de tâche en conflit définis dans plusieurs mappages de ressources

Dans cet exemple, spark_versionet num_workers sont définis à la fois dans le mappage de niveau resources supérieur et dans le resources mappage dans targets. spark_version et num_workers dans le mappage resources prennent la priorité sur targets et spark_version dans le mappage de niveau supérieur num_workers. Cela définit les paramètres du task_key nommé my-task (les points de suspension indiquent le contenu omis, à des fins de concision) :

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

Lorsque vous exécutez databricks bundle validate cet exemple, le graphique résultant est le suivant :

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