Meilleures pratiques : configuration du cluster

Azure Databricks fournit un certain nombre d’options lorsque vous créez et configurez des clusters pour vous aider à obtenir des performances optimales au coût le plus bas. Toutefois, cette flexibilité peut créer des problèmes lorsque vous essayez de déterminer des configurations optimales pour vos charges de travail. En tenant compte de la façon dont les utilisateurs utiliseront les clusters, vous allez guider les options de configuration lorsque vous créerez des clusters ou configurez des clusters existants. Voici quelques éléments à prendre en compte lors de la détermination des options de configuration :

  • Quel type d’utilisateur utilisera-t-il le cluster ? Un scientifique des données peut exécuter différents types de tâches avec des exigences différentes par rapport à un ingénieur de données ou à un analyste de données.
  • Quels types de charges de travail les utilisateurs devront-ils exécuter sur le cluster ? Par exemple, les tâches d’extraction, de transformation et de chargement (ETL) par lot auront probablement des exigences différentes de celles des charges de travail analytiques.
  • Quel est le niveau de contrat de niveau de service (SLA) dont vous avez besoin pour répondre ?
  • Quelles sont les contraintes budgétaires que vous avez ?

Cet article fournit des recommandations de configuration de cluster pour différents scénarios en fonction de ces considérations. Cet article aborde également les fonctionnalités spécifiques de Azure Databricks clusters et les considérations à prendre en compte pour ces fonctionnalités.

Vos décisions de configuration nécessitent un compromis entre les coûts et les performances. Le coût principal d’un cluster comprend les unités Databricks (DBUs) consommées par le cluster et le coût des ressources sous-jacentes nécessaires à l’exécution du cluster. Ce qui n’est peut-être pas évident, c’est que les coûts secondaires, tels que le coût pour votre entreprise, ne répondent pas à un contrat SLA, diminuent l’efficacité des employés ou gaspillent des ressources en raison de contrôles médiocres.

Fonctionnalités du cluster

Avant d’aborder les scénarios de configuration de cluster plus détaillés, il est important de comprendre certaines fonctionnalités de Azure Databricks clusters et la meilleure façon d’utiliser ces fonctionnalités.

Clusters de travail et clusters à usage général

Lorsque vous créez un cluster , vous sélectionnez un type de cluster : un cluster à usage général ou un cluster de travail. Les clusters à usage général peuvent être partagés par plusieurs utilisateurs et sont préférables pour l’analyse ad hoc, l’exploration de données ou le développement. Une fois que vous avez terminé l’implémentation de votre traitement et que vous êtes prêt à faire fonctionner votre code, passez à l’exécuter sur un cluster de travail. Les clusters de travail se terminent à la fin de votre travail, ce qui réduit l’utilisation des ressources et les coûts.

Mode cluster

Azure Databricks prend en charge trois modes de cluster: standard, haute concurrence et nœud unique. La plupart des utilisateurs standard utilisent des clusters standard ou à nœud unique.

  • Les clusters standard sont idéaux pour traiter de grandes quantités de données avec Apache Spark.
  • Les clusters à nœud unique sont conçus pour les travaux qui utilisent de petites quantités de données ou des charges de travail non distribuées, telles que les bibliothèques à nœud unique Machine Learning.
  • Les clusters à haute concurrence sont idéaux pour les groupes d’utilisateurs qui doivent partager des ressources ou exécuter des travaux ad hoc. Les administrateurs créent généralement des clusters à forte concurrence. Databricks recommande l’activation de la mise à l’échelle automatique pour les clusters à forte concurrence.

Instances à la demande et sur place

Pour réduire les coûts, Azure Databricks prend en charge la création de clusters à l’aide d’une combinaison d’instances à la demande et ponctuelles. Vous pouvez utiliser des instances ponctuelles pour tirer parti de la capacité inutilisée sur Azure pour réduire le coût d’exécution de vos applications, augmenter la capacité de calcul de votre application et augmenter le débit.

Mise à l’échelle automatique

La mise à l’échelle automatique permet au cluster de se redimensionner automatiquement en fonction des charges de travail. La mise à l’échelle automatique peut tirer parti de nombreux cas d’usage et scénarios du point de vue des coûts et des performances, mais il peut être difficile de comprendre quand et comment utiliser la mise à l’échelle automatique. Voici quelques éléments à prendre en considération pour déterminer s’il faut utiliser la mise à l’échelle automatique et comment tirer le meilleur parti :

  • La mise à l’échelle automatique réduit généralement les coûts par rapport à un cluster de taille fixe.
  • La mise à l’échelle automatique des charges de travail peut s’exécuter plus rapidement qu’un cluster de taille fixe sous-approvisionné.
  • Certaines charges de travail ne sont pas compatibles avec les clusters de mise à l’échelle automatique, y compris les travaux Spark-Submit et certains packages Python.
  • Avec les clusters à un seul utilisateur, les utilisateurs peuvent constater que la mise à l’échelle automatique ralentit leur développement ou leur analyse lorsque le nombre minimal de Workers est défini sur une valeur trop faible. Cela est dû au fait que les commandes ou les requêtes qu’elles exécutent sont souvent espacées de quelques minutes, du temps d’inactivité du cluster et peuvent réduire les coûts. Lors de l’exécution de la commande suivante, le gestionnaire de cluster tente de monter en puissance, en quelques minutes pendant la récupération des instances du fournisseur de Cloud. Pendant ce temps, les travaux peuvent s’exécuter avec des ressources insuffisantes, ce qui ralentit le temps nécessaire à la récupération des résultats. Tout en augmentant le nombre minimal de Workers, vous augmentez également les coûts. C’est un autre exemple où les coûts et les performances doivent être équilibrés.
  • Si la mise en cache Delta est utilisée, il est important de se souvenir que toutes les données mises en cache sur un nœud sont perdues si ce nœud est arrêté. Si la conservation des données mises en cache est importante pour votre charge de travail, envisagez d’utiliser un cluster de taille fixe.
  • Si vous disposez d’un cluster de travail exécutant une charge de travail ETL, vous pouvez parfois redimensionner votre cluster de manière appropriée si vous savez que votre travail est peu susceptible de changer. Toutefois, la mise à l’échelle automatique vous offre une grande souplesse en cas d’augmentation de la taille des données. Il est également intéressant de noter que la mise à l’échelle automatique optimisée peut réduire les dépenses liées à des travaux de longue durée si le cluster est sous-exploité ou en attente de résultats d’un autre processus. Une fois encore, votre travail peut rencontrer des retards mineurs, car le cluster tente de monter en puissance de manière appropriée. Si vous avez des contrats SLA étroits pour un travail, un cluster de taille fixe peut être un meilleur choix ou envisager d’utiliser un pool de Azure Databricks pour réduire les délais de démarrage du cluster.

Azure Databricks prend également en charge la mise à l’échelle automatique du stockage local. Avec la mise à l’échelle automatique du stockage local, Azure Databricks surveille la quantité d’espace disque disponible sur les Workers Spark de votre cluster. Si un processus de travail commence à s’exécuter sur un disque faible, Azure Databricks associe automatiquement un nouveau volume géré au processus de travail avant qu’il ne manque d’espace disque.

Pools

Les Pools réduisent les temps de démarrage et de montée en puissance des clusters en conservant un ensemble d’instances disponibles et prêtes à l’emploi. Databricks recommande de tirer parti des pools pour améliorer le temps de traitement tout en minimisant les coûts.

Versions de Databricks Runtime

Databricks recommande l’utilisation de la dernière version de Databricks Runtime pour les clusters à usage général. L’utilisation de la version la plus récente vous permet de bénéficier des dernières optimisations et de la compatibilité la plus à jour entre votre code et les packages préchargés.

Pour les clusters de travail qui exécutent des charges de travail opérationnelles, envisagez d’utiliser la version de support à long terme (LTS) Databricks Runtime. L’utilisation de la version LTS permet de s’assurer que vous ne rencontrez pas de problèmes de compatibilité et que vous pouvez tester minutieusement votre charge de travail avant la mise à niveau. Si vous avez un cas d’usage avancé autour du Machine Learning ou de la génomique, tenez compte des versions Databricks Runtime spécialisées.

Stratégies de cluster

Les stratégies de cluster Azure Databricks permettent aux administrateurs d’appliquer des contrôles sur la création et la configuration des clusters. Databricks recommande l’utilisation de stratégies de cluster pour vous aider à appliquer les recommandations présentées dans ce guide. En savoir plus sur les stratégies de cluster dans le Guide des meilleures pratiquespour les stratégies de cluster.

Arrêt automatique

De nombreux utilisateurs ne pensent pas mettre fin à leurs clusters lorsqu’ils ont fini de les utiliser. Heureusement, les clusters sont automatiquement arrêtés après une période définie, avec une valeur par défaut de 120 minutes.

Les administrateurs peuvent modifier ce paramètre par défaut lors de la création de stratégies de cluster. La diminution de ce paramètre peut réduire les coûts en réduisant le temps d’inactivité des clusters. Il est important de se souvenir que lorsqu’un cluster est terminé, tout l’État est perdu, y compris toutes les variables, les tables temporaires, les caches, les fonctions, les objets, etc. Tout cet État doit être restauré au redémarrage du cluster. Si un développeur parcourt une pause déjeuner de 30 minutes, il serait inutile de consacrer ce même laps de temps pour rétablir le même état d’un Notebook qu’auparavant.

Important

Les clusters inactifs continuent à accumuler les frais des instances DBU et Cloud pendant la période d’inactivité avant la fin de l’opération.

Garbage collection

Bien qu’il puisse être moins évident que les autres considérations abordées dans cet article, il peut être utile garbage collection d’optimiser les performances du travail sur vos clusters. Le fait de fournir une grande quantité de RAM peut aider les travaux à s’exécuter plus efficacement, mais peut également entraîner des retards au cours de garbage collection.

Pour réduire l’impact des balayages de longue garbage collection, évitez de déployer des clusters avec de grandes quantités de mémoire vive configurées pour chaque instance. Le fait d’avoir plus de RAM allouée à l’exécuteur entraînera une plus longue garbage collection fois. Au lieu de cela, configurez des instances avec des tailles de RAM plus petites et déployez davantage d’instances si vous avez besoin de davantage de mémoire pour vos travaux. Toutefois, dans certains cas, il est recommandé d’utiliser moins de nœuds avec davantage de RAM, par exemple, les charges de travail qui nécessitent un grand nombre de lectures aléatoires, comme indiqué dans considérations sur le dimensionnement des clusters.

Contrôle d’accès au cluster

Vous pouvez configurer deux types d’autorisations de cluster :

  • L’autorisation autoriser la création de cluster contrôle la capacité des utilisateurs à créer des clusters.
  • Les autorisations au niveau du cluster contrôlent la possibilité d’utiliser et de modifier un cluster spécifique.

Pour en savoir plus sur la configuration des autorisations de cluster, consultez contrôle d’accès au cluster.

Vous pouvez créer un cluster si vous disposez d’autorisations de création de cluster ou d’un accès à une stratégie de cluster, ce qui vous permet de créer n’importe quel cluster dans les spécifications de la stratégie. Le créateur du cluster est le propriétaire et peut gérer les autorisations, ce qui leur permettra de le partager avec n’importe quel autre utilisateur dans les limites des autorisations d’accès aux données du cluster.

La compréhension des autorisations de cluster et des stratégies de cluster est importante lorsque vous décidez des configurations de cluster pour les scénarios courants.

Balises de cluster

Les balises de cluster vous permettent de surveiller facilement le coût des ressources cloud utilisées par différents groupes de votre organisation. Vous pouvez spécifier des balises en tant que chaînes de valeur de clé lors de la création d’un cluster, et Azure Databricks applique ces balises aux ressources de Cloud, telles que les instances et les volumes EBS. En savoir plus sur l' application des balises dans le guide des meilleures pratiques pour les stratégies de cluster.

Considérations sur la taille des clusters

Azure Databricks exécute un exécuteur par nœud Worker. Par conséquent, les termes Executor et Worker sont utilisés de manière interchangeable dans le contexte de l’architecture Azure Databricks. Les gens considèrent souvent la taille de cluster en termes de nombre de threads, mais il existe d’autres facteurs importants à prendre en compte :

  • Nombre total de cœurs d’exécuteur (calcul) : nombre total de cœurs sur tous les exécuteurs. Cela détermine le parallélisme maximal d’un cluster.
  • Mémoire totale de l’exécuteur : quantité totale de RAM sur tous les exécuteurs. Cela détermine la quantité de données qui peut être stockée en mémoire avant de la déborder sur le disque.
  • Stockage local de l’exécuteur : type et quantité de stockage sur disque local. Le disque local est principalement utilisé en cas de débordement au cours de la mise en cache et de la mise en cache.

Les considérations supplémentaires incluent le type et la taille de l’instance de travail, qui influencent également les facteurs ci-dessus. Lors du dimensionnement de votre cluster, tenez compte des éléments suivants :

  • Quelle est la quantité de données consommées par votre charge de travail ?
  • Quelle est la complexité de calcul de votre charge de travail ?
  • Où sont lues les données ?
  • Comment les données sont-elles partitionnées dans un stockage externe ?
  • De quel degré de parallélisme avez-vous besoin ?

La réponse à ces questions vous aidera à déterminer les configurations de cluster optimales en fonction des charges de travail. Pour les charges de travail de style ETL simples qui utilisent des transformations restrictives uniquement (transformations où chaque partition d’entrée contribuera à une seule partition de sortie), concentrez-vous sur une configuration optimisée pour le calcul. Si vous prévoyez un grand nombre de lectures aléatoires, la quantité de mémoire est importante, ainsi que le stockage pour tenir compte des dépassements de données. Moins d’instances de grande taille peuvent réduire les e/s réseau lors du transfert de données entre des machines pendant des charges de travail complexes.

Il existe un acte d’équilibrage entre le nombre de threads de travail et la taille des types d’instance de travail. Un cluster avec deux Workers, chacun avec 40 cœurs et 100 Go de RAM, a le même calcul et la même mémoire que les huit clusters de travail avec 10 cœurs et 25 Go de RAM.

Si vous prévoyez de nombreuses relectures des mêmes données, vos charges de travail peuvent tirer parti de la mise en cache. Considérez une configuration optimisée pour le stockage avec le cache Delta.

Exemples de dimensionnement de cluster

Les exemples suivants illustrent des recommandations de cluster basées sur des types de charges de travail spécifiques. Ces exemples incluent également des configurations pour éviter et pourquoi ces configurations ne conviennent pas aux types de charges de travail.

Analyse des données

Les analystes de données effectuent généralement un traitement nécessitant des données à partir de plusieurs partitions, ce qui entraîne de nombreuses opérations de lecture aléatoire. Un cluster avec un plus petit nombre de nœuds peut réduire le réseau et les e/s de disque nécessaires pour effectuer ces lectures aléatoires. Le cluster A dans le diagramme suivant est probablement le meilleur choix, en particulier pour les clusters prenant en charge un seul analyste.

Le cluster D fournira probablement les pires performances dans la mesure où un plus grand nombre de nœuds avec moins de mémoire et de stockage nécessitera davantage de réopération de réopération pour terminer le traitement.

Dimensionnement du cluster d’analyse des données

Les charges de travail analytiques auront probablement besoin de lire les mêmes données à plusieurs reprises. par conséquent, les types de travail recommandés sont optimisés pour le stockage avec le cache Delta activé.

Les fonctionnalités supplémentaires recommandées pour les charges de travail analytiques sont les suivantes :

  • Activez la terminaison automatique pour vous assurer que les clusters sont terminés après une période d’inactivité.
  • Envisagez d’activer la mise à l’échelle automatique en fonction de la charge de travail classique de l’analyste.
  • Envisagez d’utiliser des pools, ce qui permet de limiter les clusters aux types d’instance pré-approuvés et de garantir la cohérence des configurations de cluster.

Fonctionnalités qui ne sont probablement pas utiles :

  • Stockage la mise à l’échelle automatique, car cet utilisateur ne produira probablement pas beaucoup de données.
  • Des clusters à concurrence élevée, puisque ce cluster est destiné à un seul utilisateur, et que les clusters à haute concurrence sont mieux adaptés à une utilisation partagée.

ETL de base pour le traitement par lots

Les travaux ETL simples qui ne nécessitent pas de transformations étendues, telles que les jointures ou les agrégations, tirent généralement parti des clusters optimisés pour le calcul. Pour ces types de charges de travail, l’un des clusters dans le diagramme suivant est probablement acceptable.

Dimensionnement du cluster ETL de base par lot

Les types de travail optimisés pour le calcul sont recommandés ; celles-ci seront moins chères et ces charges de travail ne nécessiteront probablement pas de mémoire ou de stockage significative.

L’utilisation d’un pool peut fournir un avantage pour les clusters prenant en charge des travaux ETL simples en diminuant les délais de lancement de cluster et en réduisant le runtime total lors de l’exécution de pipelines de travail. Toutefois, étant donné que ces types de charges de travail s’exécutent généralement comme des tâches planifiées où le cluster ne s’exécute que suffisamment longtemps pour terminer le travail, l’utilisation d’un pool peut ne pas fournir d’avantage.

Les fonctionnalités suivantes ne sont probablement pas utiles :

  • La mise en cache Delta, car les données de nouvelle lecture ne sont pas attendues.
  • L’arrêt automatique n’est probablement pas nécessaire, car il s’agit probablement de tâches planifiées.
  • La mise à l’échelle automatique n’est pas recommandée, car le calcul et le stockage doivent être préconfigurés pour le cas d’usage.
  • Les clusters à concurrence élevée sont destinés aux utilisateurs multiples et ne bénéficient pas d’un cluster exécutant un seul travail.

ETL (traitement par lots ) complexe

Les travaux ETL plus complexes, tels que le traitement qui requiert des unions et des jointures sur plusieurs tables, fonctionneront probablement mieux si vous pouvez réduire la quantité de données en mélange. Étant donné que la réduction du nombre de threads de travail dans un cluster permet de réduire les mutations, vous devez envisager un cluster plus petit comme cluster A dans le diagramme suivant sur un cluster de plus grande taille, comme le cluster D.

Dimensionnement du cluster ETL complexe

Les transformations complexes peuvent nécessiter beaucoup de ressources de calcul. par conséquent, pour certaines charges de travail qui atteignent un nombre optimal de cœurs, il se peut que vous deviez ajouter des nœuds supplémentaires au cluster.

À l’instar des travaux ETL simples, les types de Worker optimisés par calcul sont recommandés. celles-ci seront moins chères et ces charges de travail ne nécessiteront probablement pas de mémoire ou de stockage significative. De même, comme les travaux ETL simples, la fonctionnalité de cluster principale à prendre en compte est l’utilisation de pools pour réduire les délais de lancement de cluster et réduire le temps d’exécution total lors de l’exécution de pipelines de travail.

Les fonctionnalités suivantes ne sont probablement pas utiles :

  • La mise en cache Delta, car les données de nouvelle lecture ne sont pas attendues.
  • L’arrêt automatique n’est probablement pas nécessaire, car il s’agit probablement de tâches planifiées.
  • La mise à l’échelle automatique n’est pas recommandée, car le calcul et le stockage doivent être préconfigurés pour le cas d’usage.
  • Les clusters à concurrence élevée sont destinés aux utilisateurs multiples et ne bénéficient pas d’un cluster exécutant un seul travail.

Apprentissage des modèles de machine learning

Étant donné que les itérations initiales d’apprentissage d’un modèle de Machine Learning sont souvent expérimentales, un cluster plus petit, tel que le cluster A, est un bon choix. Un cluster plus petit réduira également l’impact des lectures aléatoires.

Si la stabilité est un problème, ou pour des étapes plus avancées, un cluster plus grand, tel que le cluster B ou C, peut être un bon choix.

Un cluster de grande taille tel que le cluster D n’est pas recommandé en raison de la surcharge liée à la permutation des données entre les nœuds.

Dimensionnement du cluster machine learning

Les types de Worker recommandés sont stockage optimisé avec la mise en cache Delta activée pour tenir compte des lectures répétées des mêmes données et pour activer la mise en cache des données d’apprentissage. Si les options de calcul et de stockage fournies par les nœuds optimisés pour le stockage ne sont pas suffisantes, envisagez les nœuds optimisés GPU. Un inconvénient possible est l’absence de prise en charge de la mise en cache Delta avec ces nœuds.

Les fonctionnalités supplémentaires recommandées pour les charges de travail analytiques sont les suivantes :

  • Activez la terminaison automatique pour vous assurer que les clusters sont terminés après une période d’inactivité.
  • Envisagez d’activer la mise à l’échelle automatique en fonction de la charge de travail classique de l’analyste.
  • Utilisez des pools, ce qui permet de limiter les clusters aux types d’instance pré-approuvés et de garantir la cohérence des configurations de cluster.

Fonctionnalités qui ne sont probablement pas utiles :

  • La mise à l’échelle automatique, puisque les données mises en cache peuvent être perdues lorsque les nœuds sont supprimés en cas de mise à l’échelle du cluster. En outre, les tâches de Machine Learning courantes consomment souvent tous les nœuds disponibles, auquel cas la mise à l’échelle automatique n’offre aucun avantage.
  • Stockage la mise à l’échelle automatique, car cet utilisateur ne produira probablement pas beaucoup de données.
  • Des clusters à concurrence élevée, puisque ce cluster est destiné à un seul utilisateur, et que les clusters à haute concurrence sont mieux adaptés à une utilisation partagée.

Scénarios courants

Les sections suivantes fournissent des recommandations supplémentaires pour la configuration des clusters pour les modèles d’utilisation de cluster courants :

  • Plusieurs utilisateurs qui exécutent l’analyse des données et le traitement ad hoc.
  • Des cas d’usage spécialisés comme Machine Learning.
  • Prendre en charge les travaux de traitement par lots planifiés.

Clusters multi -utilisateurs

Scénario

Vous devez fournir à plusieurs utilisateurs l’accès aux données pour exécuter l’analyse des données et les requêtes ad hoc. L’utilisation du cluster peut fluctuer au fil du temps, et la plupart des travaux ne nécessitent pas beaucoup de ressources. Les utilisateurs nécessitent principalement un accès en lecture seule aux données et souhaitent effectuer des analyses ou créer des tableaux de bord par le biais d’une interface utilisateur simple.

L’approche recommandée pour l’approvisionnement de cluster est une approche hybride de l’approvisionnement de nœuds dans le cluster, ainsi que la mise à l’échelle automatique. Une approche hybride implique la définition du nombre d’instances à la demande et des instances de points pour le cluster et l’activation de la mise à l’échelle automatique entre le nombre minimal et le nombre maximal d’instances.

Scénario multi-utilisateur

Ce cluster est toujours disponible et partagé par les utilisateurs appartenant à un groupe par défaut. L’activation de la mise à l’échelle automatique permet à la mise à l’échelle du cluster en fonction de la charge.

Les utilisateurs n’ont pas accès pour démarrer/arrêter le cluster, mais les instances à la demande initiales sont immédiatement disponibles pour répondre aux requêtes de l’utilisateur. Si la requête de l’utilisateur nécessite davantage de capacité, la mise à l’échelle automatique provisionne automatiquement davantage de nœuds (principalement des instances de point) pour prendre en charge la charge de travail.

Azure Databricks a d’autres fonctionnalités pour améliorer davantage les cas d’utilisation d’architecture mutualisée :

Cette approche permet de réduire le coût global en :

  • Utilisation d’un modèle de cluster partagé.
  • Utilisation d’une combinaison d’instances à la demande et ponctuelles.
  • Utilisation de la mise à l’échelle automatique pour éviter les paiements pour les clusters sous-exploités.

Charges de travail spécialisées

Scénario

Vous devez fournir des clusters pour des cas d’usage spécialisés ou des équipes au sein de votre organisation, par exemple, des scientifiques de données qui exécutent des algorithmes d’exploration de données et d’Machine Learning complexes. Un modèle classique est qu’un utilisateur a besoin d’un cluster pendant une brève période pour l’exécution de son analyse.

La meilleure approche pour ce type de charge de travail consiste à créer des stratégies de cluster avec des configurations prédéfinies pour les plages de paramètres, fixes et par défaut. Ces paramètres peuvent inclure le nombre d’instances, les types d’instance, les instances de type spot et à la demande, les rôles, les bibliothèques à installer, etc. L’utilisation de stratégies de cluster permet aux utilisateurs ayant des exigences plus avancées de faire tourner rapidement les clusters qu’ils peuvent configurer en fonction de leurs besoins, et d’appliquer les coûts et la conformité avec les stratégies.

Charges de travail spécialisées

Cette approche offre davantage de contrôle aux utilisateurs tout en maintenant la possibilité de garder le contrôle des coûts en prédéfinissant les configurations de cluster. Cela vous permet également de configurer des clusters pour différents groupes d’utilisateurs disposant d’autorisations d’accès à différents jeux de données.

L’un des inconvénients de cette approche est que les utilisateurs doivent travailler avec des administrateurs pour toutes les modifications apportées aux clusters, telles que la configuration, les bibliothèques installées, etc.

Charges de travail par lots

Scénario

Vous devez fournir des clusters pour les travaux de traitement par lots planifiés, tels que les travaux ETL de production qui effectuent la préparation des données. La meilleure pratique recommandée consiste à lancer un nouveau cluster pour chaque exécution de travail. L’exécution de chaque travail sur un nouveau cluster permet d’éviter les défaillances et les contrats SLA manqués provoqués par d’autres charges de travail exécutées sur un cluster partagé. En fonction du niveau de criticité du travail, vous pouvez utiliser toutes les instances à la demande pour respecter les SLA ou équilibrer les coûts entre les instances de l’emplacement et à la demande pour réaliser des économies.

Charges de travail batch planifiées