Informations de référence sur les stratégies de calcul

Cette page est une référence pour les définitions de stratégie de calcul, y compris une liste d’attributs de stratégie disponibles et de types de limitation. Il existe également des exemples de stratégies que vous pouvez référencer pour les cas d’usage courants.

Qu’est-ce que les définitions de stratégie ?

Les définitions de stratégie sont des règles de stratégie individuelles exprimées en JSON.

Une définition peut ajouter une règle à l’un des attributs contrôlés avec l’API Clusters. Par exemple, ces définitions définissent un temps de fin automatique par défaut, interdisent aux utilisateurs d’utiliser des pools et appliquent l’utilisation de Photon :

{
  "autotermination_minutes": {
    "type": "unlimited",
    "defaultValue": 4320,
    "isOptional": true
  },
  "instance_pool_id": {
    "type": "forbidden",
    "hidden": true
  },
  "runtime_engine": {
    "type": "fixed",
    "value": "PHOTON",
    "hidden": true
  }
}

Il ne peut y avoir qu’une seule limitation par attribut. Le chemin d’accès d’un attribut reflète le nom de l’attribut d’API. Pour les attributs imbriqués, le chemin concatène les noms d’attributs imbriqués à l’aide de points. Les attributs qui ne sont pas définis dans une définition de stratégie ne seront pas limités.

Configurer des définitions de stratégie à l’aide du nouveau formulaire de stratégie

Le nouveau formulaire de stratégie vous permet de configurer des définitions de stratégie à l’aide de menus déroulants et d’autres éléments d’interface utilisateur. Cela signifie que les administrateurs peuvent écrire des stratégies sans avoir à apprendre ou à référencer la syntaxe de la stratégie.

Les définitions de stratégie JSON sont toujours prises en charge dans le nouveau formulaire. Ceux-ci peuvent être ajoutés au champ JSON personnalisé sous Options avancées.

Limitations connues à l’aide du nouveau formulaire de stratégie

Si une stratégie n’est pas prise en charge par le nouveau formulaire de stratégie de calcul, toutes les définitions incompatibles apparaissent dans le champ JSON personnalisé dans la section Options avancées . Pour les champs ci-dessous, seul un sous-ensemble de stratégies valides est pris en charge :

• workload_type : la stratégie doit définir les deux workload_type.clients.notebooks et workload_type.clients.jobs. Chacune de ces règles doit être fixée à l’une ou l’autre true de falseces règles.
• dbus_per_hour : seules les stratégies de plage qui spécifient maxValue et ne spécifient minValue pas sont prises en charge.
• ssh_public_keys : seules les stratégies fixes sont prises en charge. Les ssh_public_keys stratégies ne doivent pas ignorer d’index. Par exemple, ssh_public_keys.0, ssh_public_keys.1ssh_public_keys.2 est valide, mais ssh_public_keys.0, ssh_public_keys.2n’est ssh_public_keys.3 pas valide.
• cluster_log_conf : il cluster_log_conf.path ne peut pas s’agir d’une liste verte ou d’une liste de blocs.
• init_scripts : les stratégies indexées (autrement dit, init_scripts.0.volumes.destination) doivent être corrigées. Les stratégies génériques (autrement dit, init_scripts.*.volumes.destination) doivent être interdites. Les stratégies indexées ne doivent pas ignorer d’index.

Attributs pris en charge

Les stratégies prennent en charge tous les attributs contrôlés avec l’API Clusters. Le type de restrictions que vous pouvez placer sur les attributs peut varier en fonction de leur type et de leur relation avec les éléments de l’interface utilisateur. Vous ne pouvez pas utiliser de stratégies pour définir des autorisations de calcul.

Vous pouvez également utiliser des stratégies pour définir les unités de base de données maximales par heure et le type de cluster. Consultez les chemins d’accès des attributs virtuels.

Le tableau suivant répertorie les chemins pris en charge pour les attributs de stratégie.

Chemins des attributs virtuels

Ce tableau comprend deux attributs synthétiques supplémentaires pris en charge par les stratégies. Si vous utilisez le nouveau formulaire de stratégie, ces attributs peuvent être définis dans la section Options avancées .

Types de nœuds flexibles

Les attributs de types de nœuds flexibles vous permettent de spécifier d’autres types de nœuds que la ressource de calcul peut utiliser si le type de nœud principal n’est pas disponible. Ces attributs ont des exigences de stratégie spéciales :

• Seules les stratégies fixes sont prises en charge. Tous les autres types de stratégie ne sont pas autorisés et seront rejetés au moment de la création de la stratégie.
• Une chaîne vide dans la politique correspond à une liste vide de types de nœuds alternatifs, ce qui désactive effectivement les types de nœuds flexibles.

Correction d’une liste spécifique de types de nœuds

Contrairement aux champs d’API Clusters correspondants qui utilisent un tableau de chaînes, les attributs de stratégie de calcul utilisent une valeur de chaîne unique qui encode le tableau de types de nœuds en tant que liste séparée par des virgules. Par exemple:

{
  "worker_node_type_flexibility.alternate_node_type_ids": {
    "type": "fixed",
    "value": "nodeA,nodeB"
  }
}

Si vous utilisez l’API Clusters pour créer une ressource de calcul avec une stratégie affectée, Databricks recommande de ne pas définir les champs worker_node_type_flexibility ou driver_node_type_flexibility. Si vous définissez ces champs, les types de nœuds et l’ordre du tableau doivent correspondre exactement à la liste séparée par des virgules de la stratégie, ou bien le calcul ne peut pas être créé. Par exemple, la définition de stratégie ci-dessus est définie comme suit :

"worker_node_type_flexibility": {
  "alternate_node_type_ids": ["nodeA", "nodeB"]
}

Désactiver les types de nœuds flexibles

Pour désactiver les types de nœuds flexibles, définissez la valeur sur une chaîne vide. Par exemple:

{
  "worker_node_type_flexibility.alternate_node_type_ids": {
    "type": "fixed",
    "value": ""
  }
}

Valeurs de stratégie spéciales pour la sélection de Databricks Runtime

L’attribut spark_version prend en charge des valeurs spéciales qui correspondent dynamiquement à une version databricks Runtime basée sur l’ensemble actuel de versions de Databricks Runtime prises en charge.

Les valeurs suivantes peuvent être utilisées dans l’attribut spark_version :

• auto:latest : correspond à la dernière version de Databricks Runtime en disponibilité générale.
• auto:latest-ml : correspond à la dernière version de Databricks Runtime ML.
• auto:latest-lts : correspond à la dernière version de Databricks Runtime avec support à long terme (LTS).
• auto:latest-lts-ml : correspond à la dernière version de Databricks Runtime ML avec LTS.
• auto:prev-major : correspond à l’avant-dernière version de Databricks Runtime en disponibilité générale. Par exemple, si la valeur de auto:latest est 14,2, alors auto:prev-major est 13,3.
• auto:prev-major-ml : correspond à l’avant-dernière version de Databricks Runtime ML en disponibilité générale. Par exemple, si la valeur de auto:latest est 14,2, alors auto:prev-major est 13,3.
• auto:prev-lts : correspond à l’avant-dernière version de Databricks Runtime avec LTS. Par exemple, si auto:latest-lts est 13.3, alors auto:prev-lts est 12.2.
• auto:prev-lts-ml : correspond à l’avant-dernière version de Databricks Runtime ML avec LTS. Par exemple, si auto:latest-lts est 13.3, alors auto:prev-lts est 12.2.

Types de stratégies pris en charge

Cette section inclut une référence pour chacun des types de stratégie disponibles. Il existe deux catégories de types de stratégie : les stratégies fixes et les stratégies de limitation.

Les stratégies fixes empêchent la configuration utilisateur sur un attribut. Les deux types de stratégies fixes sont les suivants :

• Stratégie fixe
• Stratégie interdite

La limitation des stratégies limite les options d’un utilisateur pour la configuration d’un attribut. La limitation des stratégies vous permet également de définir des valeurs par défaut et de rendre les attributs facultatifs. Consultez les champs de stratégie de limitation supplémentaires.

Vos options de limitation des stratégies sont les suivantes :

• Stratégie de liste d’autorisation
• Stratégie de liste de blocage
• Politique de Regex
• Politique de gamme
• Stratégie illimitée

Stratégie fixe

Les stratégies fixes limitent l’attribut à la valeur spécifiée. Pour les valeurs d’attribut autres que numériques et booléennes, la valeur doit être représentée par ou convertible en chaîne.

Avec des stratégies fixes, vous pouvez également masquer l’attribut de l’interface utilisateur en définissant le champ hidden sur true.

interface FixedPolicy {
    type: "fixed";
    value: string | number | boolean;
    hidden?: boolean;
}

Cet exemple de stratégie corrige la version de Databricks Runtime et masque le champ de l’interface utilisateur :

{
  "spark_version": { "type": "fixed", "value": "auto:latest-lts", "hidden": true }
}

Stratégie interdite

Une stratégie interdite empêche les utilisateurs de configurer un attribut. Les stratégies interdites sont compatibles uniquement avec les attributs facultatifs.

interface ForbiddenPolicy {
    type: "forbidden";
}

Cette stratégie interdit l’attachement de pools au calcul pour les nœuds Worker. Les pools sont également interdits pour le nœud de pilote, car driver_instance_pool_id hérite de la stratégie.

{
  "instance_pool_id": { "type": "forbidden" }
}

Stratégie de liste d’autorisation

Une stratégie de liste d’autorisation spécifie une liste de valeurs que l’utilisateur peut choisir lors de la configuration d’un attribut.

interface AllowlistPolicy {
  type: "allowlist";
  values: (string | number | boolean)[];
  defaultValue?: string | number | boolean;
  isOptional?: boolean;
}

Cet exemple de liste d'autorisation permet à l’utilisateur de choisir parmi deux versions de Databricks Runtime :

{
  "spark_version": { "type": "allowlist", "values": ["13.3.x-scala2.12", "12.2.x-scala2.12"] }
}

Stratégie de liste de blocage

La stratégie de liste de blocs répertorie les valeurs non autorisées. Étant donné que les valeurs doivent être des correspondances exactes, cette politique peut ne pas fonctionner comme prévu lorsque l’attribut est tolérant quant à la manière dont la valeur est représentée (par exemple, en autorisant les espaces au début et à la fin).

interface BlocklistPolicy {
  type: "blocklist";
  values: (string | number | boolean)[];
  defaultValue?: string | number | boolean;
  isOptional?: boolean;
}

Cet exemple bloque l’utilisateur de sélectionner 7.3.x-scala2.12 comme runtime Databricks.

{
  "spark_version": { "type": "blocklist", "values": ["7.3.x-scala2.12"] }
}

Stratégie Regex

Une politique de regex limite les valeurs disponibles à celles qui correspondent au regex. Pour plus de sécurité, assurez-vous que votre regex est ancré au début et à la fin de la valeur de chaîne.

interface RegexPolicy {
  type: "regex";
  pattern: string;
  defaultValue?: string | number | boolean;
  isOptional?: boolean;
}

Cet exemple limite les versions de Databricks Runtime qu’un utilisateur peut sélectionner parmi :

{
  "spark_version": { "type": "regex", "pattern": "13\\.[3456].*" }
}

Politique de portée

Une politique de plage limite la valeur à une plage spécifiée en utilisant les champs minValue et maxValue. La valeur doit être un nombre décimal. Les limites numériques doivent être représentées comme une valeur à virgule flottante double. Pour indiquer l’absence d’une limite spécifique, vous pouvez omettre l’une ou l’autre minValuemaxValuede ces limites.

interface RangePolicy {
  type: "range";
  minValue?: number;
  maxValue?: number;
  defaultValue?: string | number | boolean;
  isOptional?: boolean;
}

Cet exemple limite la quantité maximale de travailleurs à 10 :

{
  "num_workers": { "type": "range", "maxValue": 10 }
}

Stratégie illimitée

La stratégie illimitée est utilisée pour rendre les attributs obligatoires ou pour définir la valeur par défaut dans l’interface utilisateur.

interface UnlimitedPolicy {
  type: "unlimited";
  defaultValue?: string | number | boolean;
  isOptional?: boolean;
}

Cet exemple ajoute la COST_BUCKET balise au calcul :

{
  "custom_tags.COST_BUCKET": { "type": "unlimited" }
}

Pour définir une valeur par défaut pour une variable de configuration Spark, mais également autoriser l’omission (suppression) :

{
  "spark_conf.spark.my.conf": { "type": "unlimited", "isOptional": true, "defaultValue": "my_value" }
}

Champs de politique de limitation supplémentaires

Pour limiter les types de stratégie, vous pouvez spécifier deux champs supplémentaires :

• defaultValue - La valeur qui s'insère automatiquement dans l’interface utilisateur de création du calcul.
• isOptional - Une stratégie de limitation sur un attribut le rend automatiquement nécessaire. Pour rendre l’attribut facultatif, définissez le isOptional champ sur true.

Cet exemple de stratégie spécifie la valeur id1 par défaut du pool pour les nœuds de travail, mais la rend facultative. Lorsque vous créez le calcul, vous pouvez sélectionner un autre pool ou choisir de ne pas en utiliser un. Si driver_instance_pool_id n’est pas défini dans la stratégie ou lors de la création des ressources de calcul, le même pool est utilisé pour les nœuds de travail et le nœud du pilote.

{
  "instance_pool_id": { "type": "unlimited", "isOptional": true, "defaultValue": "id1" }
}

Écriture de stratégies pour les attributs de tableau

Vous pouvez spécifier des stratégies pour les attributs de tableau de deux façons :

• Limitations génériques pour tous les éléments de tableau. Ces limitations utilisent le caractère générique * dans le chemin de la stratégie.
• Limitations spécifiques pour un élément de tableau à un index spécifique. Ces limitations utilisent un nombre dans le chemin.

Par exemple, pour l’attribut init_scripts de tableau, les chemins génériques commencent par init_scripts.* et les chemins spécifiques avec init_scripts.<n>, où <n> représente un index entier dans le tableau, en commençant par 0. Vous pouvez combiner des limitations génériques et spécifiques, auquel cas la limitation générique s’applique à chaque élément de tableau qui n’a pas de limitation spécifique. Dans chaque cas, une seule limitation de stratégie s’applique.

Les sections suivantes présentent des exemples d’exemples courants qui utilisent des attributs de tableau.

Exiger des entrées spécifiques pour l’inclusion

Vous ne pouvez pas exiger de valeurs spécifiques sans spécifier l’ordre. Par exemple:

{
  "init_scripts.0.volumes.destination": {
    "type": "fixed",
    "value": "<required-script-1>"
  },
  "init_scripts.1.volumes.destination": {
    "type": "fixed",
    "value": "<required-script-2>"
  }
}

Exiger une valeur fixe de la liste entière

{
  "init_scripts.0.volumes.destination": {
    "type": "fixed",
    "value": "<required-script-1>"
  },
  "init_scripts.*.volumes.destination": {
    "type": "forbidden"
  }
}

Interdire complètement l’utilisation

{
  "init_scripts.*.volumes.destination": {
    "type": "forbidden"
  }
}

Autoriser les entrées qui suivent une restriction spécifique

{
  "init_scripts.*.volumes.destination": {
    "type": "regex",
    "pattern": ".*<required-content>.*"
  }
}

Correction d’un ensemble spécifique de scripts init

Dans le cas des init_scripts chemins d’accès, le tableau peut contenir l’une des différentes structures pour lesquelles toutes les variantes possibles devront peut-être être gérées en fonction du cas d’usage. Par exemple, pour exiger un ensemble spécifique de scripts init et interdire toute variante de l’autre version, vous pouvez utiliser le modèle suivant :

{
  "init_scripts.0.volumes.destination": {
    "type": "fixed",
    "value": "<volume-paths>"
  },
  "init_scripts.1.volumes.destination": {
    "type": "fixed",
    "value": "<volume-paths>"
  },
  "init_scripts.*.workspace.destination": {
    "type": "forbidden"
  },
  "init_scripts.*.abfss.destination": {
    "type": "forbidden"
  },
  "init_scripts.*.file.destination": {
    "type": "forbidden"
  }
}

Exemples de stratégie

Cette section inclut des exemples de stratégie que vous pouvez utiliser comme références pour créer vos propres stratégies. Vous pouvez également utiliser les familles de stratégies fournies par Azure Databricks comme modèles pour les cas d’usage courants de stratégie.

• Stratégie de calcul générale
• Définir des limites sur le calcul de pipelines déclaratifs Spark Lakeflow
• Stratégie simple de taille moyenne
• Politique exclusivement liée à l'emploi
• Stratégie de metastore externe
• Empêcher l’utilisation des ressources de calcul avec des tâches.
• Supprimer la stratégie de mise à l’échelle automatique
• Mise en application de balises personnalisées

Stratégie de calcul générale

Une stratégie de calcul à usage général destinée à guider les utilisateurs et à restreindre certaines fonctionnalités, tout en exigeant des balises, en limitant le nombre maximal d’instances et en appliquant le délai d’expiration.

{
  "instance_pool_id": {
    "type": "forbidden",
    "hidden": true
  },
  "spark_version": {
    "type": "regex",
    "pattern": "12\\.[0-9]+\\.x-scala.*"
  },
  "node_type_id": {
    "type": "allowlist",
    "values": ["Standard_L4s", "Standard_L8s", "Standard_L16s"],
    "defaultValue": "Standard_L16s_v2"
  },
  "driver_node_type_id": {
    "type": "fixed",
    "value": "Standard_L16s_v2",
    "hidden": true
  },
  "autoscale.min_workers": {
    "type": "fixed",
    "value": 1,
    "hidden": true
  },
  "autoscale.max_workers": {
    "type": "range",
    "maxValue": 25,
    "defaultValue": 5
  },
  "autotermination_minutes": {
    "type": "fixed",
    "value": 30,
    "hidden": true
  },
  "custom_tags.team": {
    "type": "fixed",
    "value": "product"
  }
}

Définir des limites sur le calcul de pipelines déclaratifs Spark Lakeflow

Pour configurer une stratégie pour un calcul de pipeline, créez une stratégie avec le cluster_type champ défini sur dlt. L’exemple suivant crée une stratégie minimale pour un calcul de pipelines déclaratifs Spark Lakeflow :

{
  "cluster_type": {
    "type": "fixed",
    "value": "dlt"
  },
  "num_workers": {
    "type": "unlimited",
    "defaultValue": 3,
    "isOptional": true
  },
  "node_type_id": {
    "type": "unlimited",
    "isOptional": true
  },
  "spark_version": {
    "type": "unlimited",
    "hidden": true
  }
}

Stratégie simple de taille moyenne

Permet aux utilisateurs de créer un calcul de taille moyenne avec une configuration minimale. Le seul champ obligatoire au moment de la création est le nom du calcul ; le reste est fixe et masqué.

{
  "instance_pool_id": {
    "type": "forbidden",
    "hidden": true
  },
  "spark_conf.spark.databricks.cluster.profile": {
    "type": "forbidden",
    "hidden": true
  },
  "autoscale.min_workers": {
    "type": "fixed",
    "value": 1,
    "hidden": true
  },
  "autoscale.max_workers": {
    "type": "fixed",
    "value": 10,
    "hidden": true
  },
  "autotermination_minutes": {
    "type": "fixed",
    "value": 60,
    "hidden": true
  },
  "node_type_id": {
    "type": "fixed",
    "value": "Standard_L8s_v2",
    "hidden": true
  },
  "driver_node_type_id": {
    "type": "fixed",
    "value": "Standard_L8s_v2",
    "hidden": true
  },
  "spark_version": {
    "type": "fixed",
    "value": "auto:latest-ml",
    "hidden": true
  },
  "custom_tags.team": {
    "type": "fixed",
    "value": "product"
  }
}

Stratégie de travail uniquement

Permet aux utilisateurs de créer un calcul de travail pour exécuter des travaux. Les utilisateurs ne peuvent pas créer de calcul à usage entier à l’aide de cette stratégie.

{
  "cluster_type": {
    "type": "fixed",
    "value": "job"
  },
  "dbus_per_hour": {
    "type": "range",
    "maxValue": 100
  },
  "instance_pool_id": {
    "type": "forbidden",
    "hidden": true
  },
  "num_workers": {
    "type": "range",
    "minValue": 1
  },
  "node_type_id": {
    "type": "regex",
    "pattern": "Standard_[DLS]*[1-6]{1,2}_v[2,3]"
  },
  "driver_node_type_id": {
    "type": "regex",
    "pattern": "Standard_[DLS]*[1-6]{1,2}_v[2,3]"
  },
  "spark_version": {
    "type": "unlimited",
    "defaultValue": "auto:latest-lts"
  },
  "custom_tags.team": {
    "type": "fixed",
    "value": "product"
  }
}

Stratégie de metastore externe

Permet aux utilisateurs de créer un calcul avec un metastore défini par l’administrateur déjà attaché. Cela est utile pour permettre aux utilisateurs de créer leur propre calcul sans nécessiter de configuration supplémentaire.

{
  "spark_conf.spark.hadoop.javax.jdo.option.ConnectionURL": {
    "type": "fixed",
    "value": "jdbc:sqlserver://<jdbc-url>"
  },
  "spark_conf.spark.hadoop.javax.jdo.option.ConnectionDriverName": {
    "type": "fixed",
    "value": "com.microsoft.sqlserver.jdbc.SQLServerDriver"
  },
  "spark_conf.spark.databricks.delta.preview.enabled": {
    "type": "fixed",
    "value": "true"
  },
  "spark_conf.spark.hadoop.javax.jdo.option.ConnectionUserName": {
    "type": "fixed",
    "value": "<metastore-user>"
  },
  "spark_conf.spark.hadoop.javax.jdo.option.ConnectionPassword": {
    "type": "fixed",
    "value": "<metastore-password>"
  }
}

Empêcher l’utilisation des ressources de calcul avec des tâches

Cette stratégie empêche les utilisateurs d’utiliser le calcul pour exécuter des travaux. Les utilisateurs pourront uniquement utiliser le calcul avec des notebooks.

{
  "workload_type.clients.notebooks": {
    "type": "fixed",
    "value": true
  },
  "workload_type.clients.jobs": {
    "type": "fixed",
    "value": false
  }
}

Supprimer la stratégie de mise à l’échelle automatique

Cette stratégie désactive la mise à l’échelle automatique et permet à l’utilisateur de définir le nombre de workers dans une plage donnée.

{
  "num_workers": {
    "type": "range",
    "maxValue": 25,
    "minValue": 1,
    "defaultValue": 5
  }
}

Mise en application de balises personnalisées

Pour ajouter une règle de balise de calcul à une stratégie, utilisez l’attribut custom_tags.<tag-name> .

Par exemple, tout utilisateur utilisant cette stratégie doit remplir une COST_CENTER balise avec 9999, 9921 ou 9531 pour que le calcul soit lancé :

{ "custom_tags.COST_CENTER": { "type": "allowlist", "values": ["9999", "9921", "9531"] } }