Partager via


Remplacer les paramètres des clusters dans les packs de ressources Databricks

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

Dans les fichiers de configuration du pack Azure Databricks, vous pouvez joindre comme suit les paramètres du cluster dans un mappage resources de niveau supérieur avec les paramètres du cluster dans un mappage targets.

Pour les tâches, utilisez le mappage job_cluster_key dans une définition de tâche pour joindre les paramètres de cluster dans un mappage resources de niveau supérieur avec les paramètres de cluster dans un mappage targets, par exemple (les points de suspension indiquent le contenu omis, pour une concision) :

# ...
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 d'un cluster est défini à la fois dans le mappage resources de niveau supérieur et le mappage targets pour le même job_cluster_key, le paramètre du mappage targets est prioritaire sur celui du mappage resources de niveau supérieur.

Pour les pipelines Delta Live Tables, utilisez le mappage label dans le cluster d'une définition de pipeline pour joindre les paramètres de cluster dans un mappage resources de niveau supérieur avec les paramètres du cluster dans un mappage targets, par exemple (les points de suspension indiquent le contenu omis, pour la concision) :

# ...
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 d'un cluster est défini à la fois dans le mappage resources de niveau supérieur et le mappage targets pour le même label, le paramètre du mappage targets est prioritaire sur celui du mappage resources de niveau supérieur.

Exemple 1 : paramètres des nouveaux clusters de travail définis dans plusieurs mappages de ressources et sans conflit 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 (les points de suspension indiquent du contenu omis, par souci de concision) :

# ...
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 pour cet exemple, le graphique résultant est le suivant (les points de suspension indiquent du contenu omis, par souci de concision) :

{
  "...": "...",
  "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 : paramètres des nouveaux clusters de travail 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 ainsi que dans le mappage resources dans targets. Dans cet exemple, spark_version et num_workers dans le mappage resources de targets sont prioritaires sur spark_version et num_workers dans le mappage resources de niveau supérieur, pour définir les paramètres de job_cluster_key nommé my-cluster (les points de suspension indiquent du contenu omis, par souci de concision) :

# ...
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 pour cet exemple, le graphique résultant est le suivant (les points de suspension indiquent du contenu omis, par souci de concision) :

{
  "...": "...",
  "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 clusters définis dans plusieurs mappages des ressources et sans conflit de paramètres

Dans cet exemple, node_type_id dans le mappage resources de niveau supérieur est combiné avec num_workers dans le mappage resources dans targets pour définir les paramètres pour le label nommé default (les points de suspension indiquent du contenu omis, par souci de concision) :

# ...
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 pour cet exemple, le graphique résultant est le suivant (les points de suspension indiquent du contenu omis, par souci de concision) :

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

Exemple 4 : conflits entre les paramètres des clusters de pipelines définis dans plusieurs mappages des ressources

Dans cet exemple, num_workers est défini à la fois dans le mappage de resources de premier niveau ainsi que dans le mappage de resources dans targets. num_workers dans le mappage resources dans targets sont prioritaires sur num_workers dans le mappage de niveau supérieur resources, pour définir les paramètres de label nommé default (les points de suspension indiquent du contenu omis, par souci de concision) :

# ...
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 pour cet exemple, le graphique résultant est le suivant (les points de suspension indiquent du contenu omis, par souci de concision) :

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