Dans Cloud Data Fusion, la configuration d'un cluster consiste à définir la manière Les pipelines de traitement des données utilisent des ressources de calcul lors de l'exécution de Spark sur Dataproc. Cette page décrit les principales approches configuration du cluster.
Clusters éphémères par défaut (recommandé)
L'approche recommandée pour les pipelines Cloud Data Fusion consiste à utiliser les clusters par défaut.
- Cloud Data Fusion provisionne et gère automatiquement les espaces de travail éphémères Clusters Dataproc 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 cluster.
- Rentabilité : vous ne payez que pour les ressources utilisées lors de l'exécution du pipeline.
Pour ajuster les clusters et ajuster les performances, consultez la page Dimensionnement des clusters.
Clusters statiques (pour des scénarios spécifiques)
Dans les scénarios suivants, vous pouvez utiliser des clusters statiques:
- 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 de créer et de détruire de manière répétée des clusters éphémères.
- Gestion centralisée des clusters: si votre organisation a besoin un contrôle centralisé sur les règles de création et de gestion des clusters, les clusters peuvent être utilisés avec des outils tels que Terraform.
- Temps de création de cluster : lorsque le temps nécessaire à la création d'un cluster pour chaque pipeline est prohibitif pour votre cas d'utilisation.
Cependant, les clusters statiques nécessitent une configuration plus manuelle et impliquent une gestion vous-même le cycle de vie du cluster.
Pour utiliser un cluster statique, vous devez définir la propriété suivante sur le cluster Dataproc :
dataproc:dataproc.conscrypt.provider.enable=false
Options de configuration de cluster pour les clusters statiques
Si vous choisissez d'utiliser des clusters statiques, Cloud Data Fusion propose de configuration pour les aspects suivants:
- Worker machine type (Type de machine des nœuds de calcul) : spécifiez le type de machine virtuelle du nœud de calcul. les nœuds du cluster. Cela détermine les vCPU 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 de votre cluster. Dataproc peut toujours procéder à un autoscaling de ce nombre, en fonction charge de travail spécifique.
- 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 . |
Pour en savoir plus, consultez Exécuter un pipeline sur un cluster Dataproc existant.
Réutiliser des clusters
Vous pouvez réutiliser des clusters Dataproc entre les exécutions pour améliorer le temps de traitement. La réutilisation de clusters est implémentée dans un modèle semblable au regroupement de connexions ou au regroupement de threads. Tout cluster est maintenu et opérationnel pendant une fois l'exécution terminée. Lorsqu'une nouvelle 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 réutiliser des clusters
- Les clusters ne sont pas partagés. Semblable au cluster éphémère standard modèle de provisionnement, un cluster exécute une seule exécution de pipeline à la fois. A n'est réutilisé que s'il est inactif.
- Si vous activez la réutilisation du cluster pour toutes vos exécutions, le nombre nécessaire d'instances clusters pour traiter toutes vos exécutions seront créés en fonction des besoins. Comme pour le provisionneur Dataproc éphémère, il n'est pas possible de contrôler directement le nombre de clusters créés. Vous pouvez toujours utiliser des devis Google Cloud pour gérer les ressources. Par exemple, si vous exécutez 100 exécutions avec 7 exécutions au maximum vous avez jusqu'à sept clusters à un moment donné.
Les clusters sont réutilisés entre différents pipelines dès que ces pipelines utilisent le même profil et partagent les mêmes paramètres de profil. Profil si personnalisée est utilisée, les clusters seront tout de même réutilisés, mais uniquement si sont parfaitement identiques, y compris tous les paramètres de cluster tels que l'étiquetage de cluster.
Lorsque la réutilisation de cluster est activée, deux facteurs importants sont à prendre en compte en termes de coût:
- Moins de ressources sont utilisées pour le démarrage et l'initialisation du cluster.
- Davantage de ressources sont utilisées pour que les clusters restent inactifs entre le pipeline et après la dernière exécution du pipeline.
Bien qu'il soit difficile de prédire l'impact sur les coûts de la réutilisation d'un cluster, vous pouvez utiliser un pour économiser le plus possible. La stratégie consiste à identifier un chemin critique pour les pipelines en série et à permettre la réutilisation des clusters pour ce chemin critique. Cela garantirait 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 de clusters
Dans la section "Compute Config" (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 délai d'inactivité maximal correspond au délai pendant lequel un cluster attend que le pipeline suivant le réutilise. La durée d'inactivité maximale par défaut est de 30 minutes. Pour le délai d'inactivité maximal, tenez compte du coût par rapport à la disponibilité du cluster pour la réutilisation. Plus la valeur définie sur "Temps d'inactivité maximal", plus il y a de clusters inactifs et prêts à être exécutés.
Résoudre les problèmes de compatibilité des versions
Problème: La version de votre environnement Cloud Data Fusion peut ne sont pas compatibles 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 compatibles de Dataproc.
Les versions antérieures de Cloud Data Fusion ne sont compatibles qu'avec versions non compatibles 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.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, 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, la version de l'OS doit être compatible avec l'une des versions Dataproc compatibles avec votre Cloud Data Fusion dans le tableau précédent.
Dépannage: fermeture du conteneur avec un code de sortie 3 différent de zéro
Problème : Une stratégie d'autoscaling n'est pas utilisée, et les clusters Dataproc statiques rencontrent une pression de mémoire, ce qui entraîne l'affichage d'une exception de manque de mémoire 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'environnement d'exécution suivant définit la mémoire sur 4 096 Mo :
"task.executor.system.resources.memory": 4096
Pour en savoir plus, consultez la section Dimensionnement des clusters.
Étape suivante
- Consultez Modifier la version de l'image Dataproc.