Aller au contenu principal
Dernière mise à jour le

Remplacer avec les paramètres cibles

Cette page explique comment remplacer ou combiner les paramètres de niveau supérieur avec les paramètres cibles dans Declarative Automation Bundles. Pour plus d'informations sur les paramètres cibles des bundles, consultez les cibles.

Remplacement des paramètres d'artefact​

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

YAML
# ...
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 artifacts de niveau supérieur et le mappage targets pour le même artefact, alors le paramètre du mappage targets prévaut sur le paramètre du mappage artifacts de niveau supérieur.

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

Pour illustrer son fonctionnement dans la pratique, dans l'exemple suivant, path est défini dans le mappage artifacts de niveau supérieur, qui définit tous les paramètres de l'artefact :

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

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

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

Exemple 2 : Paramètres d’artefacts contradictoires 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 de targets. Dans cet exemple, path du mappage artifacts de targets l'emporte sur path du mappage artifacts de premier niveau pour définir les paramètres de l'artefact :

YAML
# ...
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 graphe résultant est :

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

Remplacements des paramètres de cluster​

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

Pour les Jobs, utilisez job_cluster_key dans une définition de Job pour identifier les paramètres des clusters de Job dans le mappage resources de niveau supérieur afin de les joindre aux paramètres des clusters de Job dans un mappage targets :

YAML
# ...
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 clusters est défini à la fois dans le mappage resources de niveau supérieur et dans le mappage targets pour le même job_cluster_key, alors le paramètre du mappage targets prévaut sur le paramètre du mappage resources de niveau supérieur.

Pour les LakeFlow Pipelines, utilisez label dans les paramètres de cluster d'une définition de pipeline pour identifier les paramètres de cluster dans un mappage resources de niveau supérieur à joindre aux paramètres de cluster dans un mappage targets, par exemple :

YAML
# ...
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 clusters est défini à la fois dans le mappage resources de niveau supérieur et dans le mappage targets pour le même label, alors le paramètre du mappage targets prévaut sur le paramètre du mappage resources de niveau supérieur.

Exemple 1 : Nouveaux paramètres de cluster Job définis dans plusieurs mappages de ressources et sans conflits de paramètres​

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

YAML
# ...
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: i3.xlarge
                num_workers: 1
          # ...

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

JSON
{
  "...": "...",
  "resources": {
    "jobs": {
      "my-job": {
        "job_clusters": [
          {
            "job_cluster_key": "my-cluster",
            "new_cluster": {
              "node_type_id": "i3.xlarge",
              "num_workers": 1,
              "spark_version": "13.3.x-scala2.12"
            }
          }
        ],
        "...": "..."
      }
    }
  }
}

Exemple 2 : Paramètres de nouveau cluster de job en conflit définis dans plusieurs mappages de ressources​

Dans cet exemple, spark_version et num_workers sont définis à la fois dans le mappage resources de niveau supérieur et dans le mappage resources dans targets. Dans cet exemple, spark_version et num_workers dans la correspondance resources dans targets l’emportent sur spark_version et num_workers dans la correspondance de niveau supérieur resources, afin de définir les paramètres de job_cluster_key nommé my-cluster:

YAML
# ...
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: i3.xlarge
            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 pour cet exemple, le graphe résultant est le suivant :

JSON
{
  "...": "...",
  "resources": {
    "jobs": {
      "my-job": {
        "job_clusters": [
          {
            "job_cluster_key": "my-cluster",
            "new_cluster": {
              "node_type_id": "i3.xlarge",
              "num_workers": 2,
              "spark_version": "12.2.x-scala2.12"
            }
          }
        ],
        "...": "..."
      }
    }
  }
}

Exemple 3 : Paramètres de clusters pipeline définis dans plusieurs mappages de ressources et sans conflits de paramètres​

Dans cet exemple, node_type_id dans le mappage resources de niveau supérieur est combiné à num_workers dans le mappage resources de targets pour définir les paramètres de label nommé default:

YAML
# ...
resources:
  pipelines:
    my-pipeline:
      clusters:
        - label: default
          node_type_id: i3.xlarge

targets:
  development:
    resources:
      pipelines:
        my-pipeline:
          clusters:
            - label: default
              num_workers: 1
          # ...

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

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

Exemple 4 : paramètres de pipeline contradictoires de clusters 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 de targets. num_workers dans le mappage resources de targets prévalent sur num_workers dans le mappage resources de niveau supérieur, afin de définir les paramètres de label nommé default:

YAML
# ...
resources:
  pipelines:
    my-pipeline:
      clusters:
        - label: default
          node_type_id: i3.xlarge
          num_workers: 1

targets:
  development:
    resources:
      pipelines:
        my-pipeline:
          clusters:
            - label: default
              num_workers: 2
          # ...

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

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

Remplacement des paramètres de tâche du Job​

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

YAML
# ...
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 la mise en correspondance resources de niveau supérieur et la mise en correspondance targets pour la même tâche, la task_key des mises en correspondance de tâches doit être définie sur la même valeur.

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

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

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

YAML
# ...
resources:
  jobs:
    my-job:
      name: my-job
      tasks:
        - task_key: my-task
          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: i3.xlarge
                num_workers: 1
          # ...

Lorsque vous exécutez databricks bundle validate pour cet exemple, le Graphe résultant est le suivant (les ellipses indiquent le contenu omis, pour des raisons de concision) :

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

Exemple 2 : Paramètres de tâche de Job contradictoires définis dans plusieurs mappages de ressources​

Dans cet exemple, spark_version et num_workers sont définis à la fois dans le mappage resources de niveau supérieur et dans le mappage resources dans targets. spark_version et num_workers dans le mapping resources de targets priment sur spark_version et num_workers dans le mapping resources de niveau supérieur. Ceci définit les paramètres pour le task_key nommé my-task (les points de suspension indiquent un contenu omis, par souci de concision) :

YAML
# ...
resources:
  jobs:
    my-job:
      name: my-job
      tasks:
        - task_key: my-task
          new_cluster:
            spark_version: 13.3.x-scala2.12
            node_type_id: i3.xlarge
            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 graphe résultant est le suivant :

JSON
{
  "...": "...",
  "resources": {
    "jobs": {
      "my-job": {
        "tasks": [
          {
            "new_cluster": {
              "node_type_id": "i3.xlarge",
              "num_workers": 2,
              "spark_version": "12.2.x-scala2.12"
            },
            "task_key": "my-task"
          }
        ],
        "...": "..."
      }
    }
  }
}
Sur cette page