Dans Cloud Data Fusion, la configuration de cluster consiste à définir la manière dont vos pipelines de traitement de données utilisent les ressources de calcul lors de l'exécution de jobs Spark sur Dataproc. Cette page décrit les principales approches de configuration des clusters.
Clusters éphémères par défaut (recommandé)
L'utilisation des clusters par défaut est l'approche recommandée pour les pipelines Cloud Data Fusion.
- Cloud Data Fusion provisionne et gère automatiquement les clusters Dataproc éphémères pour chaque exécution de pipeline. Il crée un cluster au début de l'exécution du pipeline, puis le supprime une fois l'exécution du pipeline terminée.
- Avantages des clusters éphémères :
- Simplicité : vous n'avez pas besoin de configurer ni de gérer manuellement le cluster.
- Rentabilité : vous ne payez que les ressources utilisées lors de l'exécution du pipeline.
Pour ajuster les clusters et optimiser les performances, consultez Dimensionnement des clusters.
Clusters statiques (pour des scénarios spécifiques)
Vous pouvez utiliser des clusters statiques dans les scénarios suivants :
- Pipelines de longue durée : pour les pipelines qui s'exécutent en continu ou pendant de longues périodes, un cluster statique peut être plus rentable que la création et la suppression répétées de clusters éphémères.
- Gestion centralisée des clusters : si votre organisation exige un contrôle centralisé des règles de création et de gestion des clusters, vous pouvez utiliser des clusters statiques avec des outils tels que Terraform.
- Temps de création du cluster : lorsque le temps nécessaire à la création d'un cluster pour chaque pipeline est prohibitif pour votre cas d'utilisation.
Toutefois, les clusters statiques nécessitent une configuration manuelle plus importante et impliquent de gérer vous-même le cycle de vie du cluster.
Pour utiliser un cluster statique, vous devez définir les propriétés suivantes sur le cluster Dataproc :
dataproc:dataproc.conscrypt.provider.enable=false
capacity-scheduler:yarn.scheduler.capacity.resource-calculator="org.apache.hadoop.yarn.util.resource.DefaultResourceCalculator"
Options de configuration de cluster pour les clusters statiques
Si vous choisissez d'utiliser des clusters statiques, Cloud Data Fusion propose des options de configuration pour les aspects suivants :
- Type de machine de nœud de calcul : spécifiez le type de machine virtuelle pour les nœuds de calcul de votre cluster. Cela détermine les processeurs virtuels et la mémoire disponibles pour chaque nœud de calcul.
- Nombre de nœuds de calcul : définissez le nombre initial de nœuds de calcul dans votre cluster. Dataproc peut toujours effectuer un autoscaling de ce nombre en fonction de la charge de travail.
- Zone : sélectionnez la zone Google Cloud de votre cluster. L'emplacement peut avoir une incidence sur la localité des données et les performances du réseau.
- Configurations supplémentaires : vous pouvez configurer des options avancées pour votre cluster statique, telles que les paramètres de préemption, les paramètres réseau et les actions d'initialisation.
Bonnes pratiques
Lorsque vous créez un cluster statique pour vos pipelines, utilisez les configurations suivantes.
| Paramètres | Description |
|---|---|
yarn.nodemanager.delete.debug-delay-sec |
Conserve les journaux YARN. Valeur recommandée : 86400 (équivalent à un jour) |
yarn.nodemanager.pmem-check-enabled |
Permet à YARN de vérifier les limites de mémoire physique et de supprimer les conteneurs si ceux-ci dépassent la mémoire physique. Valeur recommandée : false |
yarn.nodemanager.vmem-check-enabled |
Permet à YARN de vérifier les limites de mémoire virtuelle et de supprimer les conteneurs s'ils dépassent la mémoire physique. Valeur recommandée : false |
dataproc.scheduler.driver-size-mb |
L'empreinte mémoire moyenne du pilote fait que Dataproc met en file d'attente le job si le nœud maître ne dispose pas de suffisamment de mémoire pour exécuter le processus du pilote. Cela peut avoir un impact sur la concurrence des jobs, mais peut être atténué en utilisant un nœud maître avec plus de mémoire. Valeur recommandée : 2048 |
Pour en savoir plus, consultez Exécuter un pipeline sur un cluster Dataproc existant.
Réutiliser des clusters
Vous pouvez réutiliser les clusters Dataproc entre les exécutions pour améliorer le temps de traitement. La réutilisation des clusters est implémentée dans un modèle semblable au regroupement de connexions ou de threads. Tout cluster est maintenu en état de fonctionnement pendant une durée spécifiée après la fin de l'exécution. Lorsqu'une exécution est lancée, elle tente de trouver un cluster inactif disponible qui correspond à la configuration du profil de calcul. Si un cluster est présent, il sera utilisé. Sinon, un nouveau cluster sera démarré.
Éléments à prendre en compte pour la réutilisation de clusters
- Les clusters ne sont pas partagés. Comme pour le modèle de provisionnement de cluster éphémère standard, un cluster exécute une seule exécution de pipeline à la fois. Un cluster n'est réutilisé que s'il est inactif.
- Si vous activez la réutilisation des clusters pour toutes vos exécutions, le nombre de clusters nécessaires au traitement de toutes vos exécutions sera créé selon les besoins. Comme pour le provisionneur Dataproc éphémère, il n'y a pas de contrôle direct sur le nombre de clusters créés. Vous pouvez toujours utiliser les quotas Google Cloud pour gérer les ressources. Par exemple, si vous exécutez 100 exécutions avec un maximum de 7 exécutions parallèles, vous aurez jusqu'à 7 clusters à un moment donné.
Les clusters sont réutilisés entre différentes pipelines dès que ces pipelines utilisent le même profil et partagent les mêmes paramètres de profil. Si la personnalisation du profil est utilisée, les clusters seront toujours réutilisés, mais uniquement si les personnalisations sont exactement les mêmes, y compris tous les paramètres de cluster tels que l'étiquetage des clusters.
Lorsque la réutilisation de clusters est activée, deux principaux aspects liés aux coûts sont à prendre en compte :
- Moins de ressources sont utilisées pour le démarrage et l'initialisation du cluster.
- Plus de ressources sont utilisées pour que les clusters restent inactifs entre les exécutions de pipeline et après la dernière exécution de pipeline.
Bien qu'il soit difficile de prédire l'effet du réemploi des clusters sur les coûts, vous pouvez adopter une stratégie pour maximiser les économies. La stratégie consiste à identifier un chemin critique pour les pipelines enchaînés et à activer la réutilisation du cluster pour ce chemin critique. Cela permet de s'assurer que le cluster est immédiatement réutilisé, qu'aucun temps d'inactivité n'est gaspillé et que les avantages en termes de performances sont maximaux.
Activer la réutilisation du cluster
Dans la section "Configuration de calcul" de la configuration du pipeline déployé ou lors de la création d'un profil de calcul :
- Activez l'option Skip Cluster Delete (Ignorer la suppression du cluster).
- Le temps d'inactivité maximal correspond à la durée pendant laquelle un cluster attend le prochain pipeline pour le réutiliser. Le délai d'inactivité maximal par défaut est de 30 minutes. Pour la durée d'inactivité maximale, tenez compte du coût par rapport à la disponibilité du cluster pour la réutilisation. Plus la valeur de la durée maximale d'inactivité est élevée, plus les clusters restent inactifs, prêts à être exécutés.
Dépannage : compatibilité des versions
Problème : la version de votre environnement Cloud Data Fusion peut ne pas être compatible avec la version de votre cluster Dataproc.
Recommandé : effectuez une mise à niveau vers la dernière version de Cloud Data Fusion et utilisez l'une des versions Dataproc compatibles.
Les versions antérieures de Cloud Data Fusion ne sont compatibles qu'avec les versions non acceptées de Dataproc. Dataproc ne fournit pas de mises à jour ni de compatibilité pour les clusters créés avec ces versions. Même si vous pouvez continuer à exécuter un cluster créé avec une version non compatible, nous vous recommandons de le remplacer par un cluster créé avec une version compatible.
| Version de Cloud Data Fusion | Version de Dataproc |
|---|---|
| 6.11.1 | 2.3 |
| 6.10.1.1 | 2.2***, 2.1, 2.0 * |
| 6.10 | 2.1, 2.0 * |
| 6,9 | 2.1, 2.0, 1.5 * |
| 6.7-6.8 | 2,0, 1,5* |
| 6.4-6.6 | 2,0*, 1,3** |
| 6.1-6.3 | 1.3** |
major.minor.Pour spécifier la version de l'OS utilisée dans votre cluster Dataproc, celle-ci doit être compatible avec l'une des versions Dataproc acceptées pour votre Cloud Data Fusion dans le tableau précédent.
Dépannage : Le conteneur s'est arrêté avec un code de sortie différent de zéro (3)
Problème : aucune règle d'autoscaling n'est utilisée, et les clusters Dataproc statiques rencontrent une pression de mémoire, ce qui entraîne l'apparition d'une exception de mémoire insuffisante dans les journaux : Container exited with a non-zero
exit code 3.
Recommandation : augmentez la mémoire de l'exécuteur.
Augmentez la mémoire en ajoutant un argument d'exécution task.executor.system.resources.memory au pipeline. L'exemple d'argument d'exécution suivant définit la mémoire sur 4 096 Mo :
"task.executor.system.resources.memory": 4096
Pour en savoir plus, consultez Dimensionnement des clusters.
Étapes suivantes
- Consultez Modifier la version de l'image Dataproc.