Remplacer les paramètres de cluster dans les bundles 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 groupés Azure Databricks , vous pouvez joindre les paramètres du cluster dans un mappage au niveau supérieur resources avec les paramètres du cluster dans un mappage targets, de la manière suivante.

Pour les tâches, utilisez le mappage job_cluster_key au sein d’une définition de tâche pour joindre les paramètres du cluster dans un mappage de niveau supérieur resources avec les paramètres du cluster dans un mappage targets, par exemple (les points de suspension indiquent le contenu omis, pour plus de 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 de 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 le paramètre du mappage de niveau supérieur resources.

Pour les pipelines Delta Live Tables, utilisez le mappage label au sein de la cluster d'une définition de pipeline pour associer les paramètres de cluster d'un mappage resources de niveau supérieur avec ceux d'un mappage targets, par exemple (les points de suspension indiquent le contenu omis pour plus de 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 de 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 le paramètre du mappage de niveau supérieur resources.

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 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 job_cluster_key nommée my-cluster (les points de suspension indiquent le contenu omis, à des fins 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 le contenu omis, pour la 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 : 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 resources de niveau supérieur et dans le mappage resources dans targets. Dans cet exemple, spark_version et num_workers dans le mappage de resources dans targets sont prioritaires sur spark_version et les num_workers dans le mappage de resources de niveau supérieur, pour définir les paramètres du job_cluster_key nommé my-cluster (les points de suspension indiquent le contenu omis, à des fins 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 le contenu omis, pour la 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 cluster de pipeline définis dans plusieurs mappages de ressources et sans conflit de paramètres

Dans cet exemple, node_type_id dans le mappage de niveau supérieur resources est combiné avec num_workers dans le mappage resources dans targets pour définir les paramètres du label nommé default (les points de suspension indiquent le contenu omis, pour la 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 le contenu omis, pour la concision) :

{
  "...": "...",
  "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éfinie à la fois dans le mappage resources de niveau supérieur et dans le mappage resources dans targets. num_workers dans le mappage de resources dans targets prennent précédence sur num_workers dans le mappage de resources de niveau supérieur, afin de définir les paramètres du label nommé default (les points de suspension indiquent le contenu omis, à des fins 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 le contenu omis, pour la concision) :

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