Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Concevoir pour la flexibilité et l'efficacité sur Dataflow

Ce document explique la conception pour la flexibilité et l'efficacité (DFE, Design for Flexibility and Efficiency), un ensemble de bonnes pratiques architecturales pour créer des pipelines Dataflow résilients.

Passer de contraintes d'infrastructure rigides à des définitions de ressources flexibles vous permet :

Optimisez l'obtention de ressources de calcul.
Assurez un autoscaling fluide en période de forte demande régionale.
Évitez les retards de lancement des pipelines et éliminez les goulots d'étranglement liés à la capacité.

Par exemple, au lieu de limiter votre pipeline à un type de machine spécifique dans une zone, comme en exigeant des nœuds de calcul n1-standard-4 dans us-central1-a, vous pouvez définir des besoins minimaux en ressources (comme 4 vCPU et 16 Go de RAM). Si us-central1-a ou la série de machines N1 rencontrent des contraintes de capacité temporaires, Dataflow peut provisionner automatiquement des VM de nœud de calcul compatibles dans d'autres zones et familles de machines (telles que E2, N2 ou N2D). Cette flexibilité permet de s'assurer que votre pipeline démarre et évolue sans attendre un pool de matériel unique et limité.

Ce document s'adresse aux ingénieurs de données, aux architectes cloud et aux administrateurs de plate-forme qui gèrent des charges de travail Dataflow et souhaitent optimiser la fiabilité, le débit et la disponibilité de l'infrastructure des pipelines.

Présentation de DFE

Dataflow est un service de traitement de données sans serveur entièrement géré qui provisionne de manière dynamique des instances de machines virtuelles (VM) Compute Engine pour exécuter des pipelines Apache Beam. Dans les pipelines de traitement par lot et de flux de données à grande échelle, les pools de nœuds de calcul sont souvent mis à l'échelle pour atteindre des dizaines ou des centaines d'instances de VM.

Les pipelines configurés avec des contraintes d'infrastructure rigides sont susceptibles de subir des retards de provisionnement en période de forte demande. Voici quelques exemples de contraintes rigides :

Coder en dur un seul type de machine, tel que n1-standard-4.
Épingler le pipeline à une zone Compute Engine spécifique.

Si ce type de machine ou cette zone spécifiques connaissent une forte demande temporaire, Dataflow ne peut pas allouer de ressources de calcul. Cela peut entraîner des retards de provisionnement ou des erreurs telles que ZONE_RESOURCE_POOL_EXHAUSTED ou RESOURCE_POOL_EXHAUSTED.

L'utilisation des principes DFE vous aide à faire passer l'architecture de votre pipeline de déclarations d'infrastructure rigides et statiques à des définitions de ressources flexibles et basées sur les exigences. Cette flexibilité permet à Dataflow de distribuer dynamiquement la puissance de calcul sur différents pools de matériel disponibles dans Google Cloud, ce qui vous aide à maximiser la disponibilité de la puissance de calcul tout en minimisant le surcoût opérationnel.

Bonnes pratiques pour DFE

Adoptez les bonnes pratiques suivantes pour maximiser la disponibilité du calcul, améliorer la réactivité de l'autoscaling et créer des pipelines résilients.

Activer la sélection automatique de VM

Au lieu de coder en dur un type de machine statique avec l'option de pipeline worker machine type, utilisez Auto VM selection avec les indications de ressources Apache Beam. Lorsque vous spécifiez des exigences minimales en termes de ressources (min_ram ou cpu_count), Dataflow active automatiquement la flexibilité des instances et provisionne des nœuds de calcul à partir d'une liste de types de machines compatibles.

Charges de travail compatibles :

Pipelines par lot : l'adaptation des ressources et la sélection automatique de VM sont automatiquement activées lorsque vous spécifiez des optimisations de ressources.
Pipelines de traitement en flux continu : pour un dimensionnement adapté, vous devez définir l'option de pipeline --experiments=enable_streaming_rightfitting, ainsi que l'autoscaling horizontal (activé par défaut) et Streaming Engine (--enable_streaming_engine).

Pour configurer la sélection automatique de VM, spécifiez les exigences minimales en termes de ressources (min_ram ou cpu_count) au niveau du pipeline à l'aide des options de ligne de commande, des options de pipeline du SDK ou des paramètres d'exécution du modèle Flex. Pour obtenir des instructions de configuration détaillées et des exemples de code pour Java et Python, consultez Utiliser des indications de ressources.

Utiliser le placement régional des nœuds de calcul (éviter l'épinglage zonal)

Configurez Dataflow pour planifier dynamiquement les VM de nœud de calcul dans n'importe quelle zone saine de la région choisie.

Spécifiez l'option de pipeline --region et omettez --zone et --worker_zone. Exemple :

--region=us-central1

Dissocier l'état et le brassage à l'aide de services gérés

Les pipelines qui n'utilisent pas de services de backend gérés exécutent les opérations de brassage de données et le stockage de l'état de flux directement sur les disques et la mémoire des VM de nœud de calcul. Ce couplage étroit nécessite des disques de nœud de calcul plus volumineux et lie la survie de la charge de travail à des instances de VM spécifiques, ce qui rend le remplacement des nœuds de calcul plus difficile en cas de contraintes de capacité.

Pour les jobs par lot, utilisez Dataflow Shuffle : Dataflow Shuffle est activé par défaut pour les pipelines par lot s'exécutant sur les types de machines de nœud de calcul compatibles. Il décharge les opérations de brassage des données des VM de nœud de calcul vers un service de backend dédié géré par Google.
Pour les jobs de traitement de flux, utilisez Streaming Engine : Streaming Engine décharge le stockage de l'état des fenêtres et la gestion des minuteurs des VM de nœud de calcul vers une infrastructure de backend spécialisée et très réactive. Pour les pipelines utilisant le SDK Apache Beam 2.30.0 ou version ultérieure, Streaming Engine est activé par défaut. Pour l'activer explicitement, transmettez l'option de pipeline --enable_streaming_engine.

Utiliser la planification flexible des ressources (FlexRS) pour les pipelines par lots

Pour les charges de travail par lot non urgentes, telles que l'ETL nocturne, l'ingestion de lac de données ou les cumuls quotidiens, utilisez la planification flexible des ressources (FlexRS).

Pour activer FlexRS, définissez l'option de pipeline flexRSGoal :

Pour les pipelines Python : --flexrs_goal=COST_OPTIMIZED
Pour les pipelines Java : --flexRSGoal=COST_OPTIMIZED

Configurer des types de VM de lanceur flexibles pour les modèles Flex

Lorsque vous lancez des pipelines à l'aide de modèles Flex, la VM de lanceur de pipeline est définie par défaut sur e2-standard-2. La VM par défaut fonctionne dans la plupart des cas, mais si vous rencontrez des contraintes de capacité, vous pouvez personnaliser la configuration à l'aide de l'option --launcher-machine-type lorsque vous exécutez la commande gcloud dataflow flex-template run :

gcloud dataflow flex-template run my-job \
    --template-file-gcs-location="gs://my-bucket/template.json" \
    --region="us-central1" \
    --launcher-machine-type="n2-standard-2"

Considérations et compromis opérationnels

Si l'adoption des bonnes pratiques DFE améliore considérablement la disponibilité du calcul, la réactivité de l'autoscaling et la fiabilité opérationnelle, tenez compte des facteurs et compromis opérationnels suivants lors de la conception de votre architecture :

Points à prendre en compte pour la sélection automatique de VM

Fiabilité par rapport aux performances maximales : la sélection automatique de VM privilégie la fiabilité du lancement des jobs et la disponibilité du calcul par rapport aux performances d'exécution maximales. Étant donné que Dataflow provisionne des machines à partir de plusieurs familles de machines candidates (E2, N2, N4 et N2D, par exemple), les performances et le débit d'exécution peuvent varier légèrement en fonction de la famille de machines provisionnée. Pour les charges de travail gourmandes en calcul avec des SLA d'exécution stricts, testez votre pipeline avec la sélection automatique de VM afin d'établir une référence de performances avant de le déployer à grande échelle. Si une charge de travail nécessite une plate-forme matérielle ou une vitesse d'horloge spécifiques et que vous pouvez tolérer les contraintes de capacité, vous pouvez continuer à définir un type de machine spécifique.
Quota Compute Engine pour les familles candidates : étant donné que la sélection automatique de VM peut provisionner des nœuds de calcul à partir de plusieurs familles de machines candidates, assurez-vous que votre projet Google Cloud dispose d'un quota suffisant de vCPU et de mémoire Compute Engine pour chaque famille candidate dans votre région cible. Si une pénurie de capacité se produit dans la famille principale et que votre projet manque de quota pour la famille de secours, le provisionnement des nœuds de calcul échoue avec une erreur QUOTA_EXCEEDED.
Prérequis pour les pipelines de traitement en flux continu : pour les pipelines de traitement en flux continu, le dimensionnement approprié et la sélection automatique de VM ne sont pas activés par défaut. Vous devez spécifier explicitement --experiments=enable_streaming_rightfitting et vous assurer que Streaming Engine (--enable_streaming_engine) et l'autoscaling horizontal sont actifs.

Exclusions de configuration : la sélection automatique de VM est automatiquement contournée ou n'est pas prise en charge si vous configurez l'une des fonctionnalités ou options du tableau suivant :

Fonctionnalité	Option ou indicateur de configuration	Remarques
Types de machines explicites	`--worker_machine_type` ou `--machine_type` (Python) `--workerMachineType` (Java)	La sélection automatique de VM est ignorée au profit du type de machine spécifié.
Types de disques personnalisés, IOPS ou débit provisionnés	`--disk_type`, `--disk_provisioned_iops` ou `--disk_provisioned_throughput_mibps`	La sélection automatique de VM est ignorée. Il est possible de définir une taille de disque personnalisée avec `--disk_size_gb`.
Configurations minimales de la plate-forme du processeur	`--min_cpu_platform` (Python) `--minCpuPlatform` (Java)	La définition d'une plate-forme de processeur minimale contourne la sélection automatique de VM.
Confidential VMs	`--experiments=enable_confidential_compute`	Les instances Confidential VM ne sont pas compatibles avec la sélection automatique de VM.
Accélérateurs GPU ou TPU	Indication de ressource `--dataflow_service_options=worker_accelerator=...` ou `accelerator`	La sélection automatique de VM ne s'applique qu'aux charges de travail sans accélérateurs.
Dataflow Prime	`--dataflow_service_options=enable_prime`	Dataflow Prime utilise l'autoscaling vertical et l'ajustement dynamique au lieu de la sélection automatique de VM.
Planification flexible des ressources (FlexRS)	`--flexrs_goal=COST_OPTIMIZED` (Python) `--flexRSGoal=COST_OPTIMIZED` (Java)	FlexRS gère son propre pool de nœuds de calcul et sa propre marge de planification.

Compromis liés à la planification flexible des ressources (FlexRS)

Délai de planification : FlexRS peut introduire un délai de planification de six heures maximum avant le début de l'exécution du job. N'utilisez pas FlexRS pour les pipelines avec des SLA stricts concernant le délai d'exécution ou des dépendances en aval strictes.

Emplacement régional et localité des données

Prérequis pour le service géré : le placement régional des nœuds de calcul n'est compatible qu'avec les jobs qui utilisent Dataflow Shuffle pour le traitement par lot ou Streaming Engine pour le traitement par flux. Les jobs qui n'utilisent pas ces services de backend gérés utilisent le placement automatique des zones, qui sélectionne la meilleure zone unique de la région.
Localité des données et sortie multirégionale : le placement régional distribue les nœuds de calcul dans les zones disponibles de la région choisie. Pour minimiser la latence du réseau et éviter les frais de sortie réseau interrégionaux, assurez-vous que toutes les sources et tous les récepteurs de données (tels que les buckets Cloud Storage, les ensembles de données BigQuery et les sujets Pub/Sub) se trouvent dans la même région que votre job Dataflow.

Réservations Compute Engine

Affinité de réservation : les jobs Dataflow à la demande consomment automatiquement les réservations Compute Engine correspondantes qui utilisent l'affinité de réservation ANY. Toutefois, la sélection automatique de VM n'est pas compatible avec l'utilisation d'instances provenant de réservations nommées spécifiques.
Adaptation aux charges de travail transitoires : les réservations Compute Engine ne sont généralement pas recommandées pour les charges de travail par lot de courte durée, à autoscaling ou sujettes aux pics. De plus, la création de réservations pendant une pénurie zonale active échoue en raison des mêmes contraintes de capacité que la création de VM à la demande.