Remplacer les paramètres des tâches de travail dans les bundles de ressources Databricks

Cet article décrit le remplacement des paramètres des tâches de travail Azure Databricks dans les packs de ressources Databricks. Consultez Que sont les packs de ressources Databricks ?

Dans les fichiers de paramètres de pack Azure Databricks, vous pouvez utiliser le mappage task dans une définition de tâche pour joindre les paramètres des tâches de travail d’un mappage resources de niveau supérieur avec les paramètres des tâches de travail d’un mappage targets, par exemple (les points de suspension indiquent du contenu omis, par souci de concision) :

# ...
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 de niveau resources supérieur et le targets mappage pour le même task, les task mappages task_key doivent être définis sur la même valeur.

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

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 resources de niveau supérieur est combiné avec node_type_id et num_workers dans le mappage resources dans targets pour définir les paramètres de la task_key nommée 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-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 pour 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 resources de niveau supérieur et dans le mappage resources dans targets. spark_version et num_workers dans le mappage de resources dans targets sont prioritaires sur spark_version et num_workers au niveau supérieur du mappage de resources. Cela définit les paramètres de la task_key nommée 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 pour 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": 2,
              "spark_version": "12.2.x-scala2.12"
            },
            "task_key": "my-task"
          }
        ],
        "...": "..."
      }
    }
  }
}