Planifier votre pipeline Dataflow

Cette page explique les points importants à prendre en compte lors de la planification de votre pipeline de données avant de commencer à développer du code. Les pipelines de données déplacent les données d'un système à un autre et constituent souvent des composants critiques des systèmes d'information d'entreprise. Les performances et la fiabilité de votre pipeline de données peuvent avoir un impact sur ces systèmes plus larges et sur la satisfaction de vos besoins métier.

Bien planifier vos pipelines de données avant d'en commencer le développement permet d'en améliorer les performances et la fiabilité. Cette page explique les différents éléments à prendre en compte lors de la planification des pipelines Dataflow, parmi lesquels :

• Les attentes en termes de performances de vos pipelines, y compris les normes de mesurabilité
• L'intégration de vos pipelines à des sources de données, des récepteurs et d'autres systèmes connectés
• La régionalisation des pipelines, des sources et des récepteurs
• La sécurité, par exemple le chiffrement des données et la mise en réseau privée

Définir et mesurer des SLO

Une mesure importante des performances est la capacité de votre pipeline à répondre aux exigences de votre entreprise. Les objectifs de niveau de service (SLO, Service Level Objective) fournissent des définitions concrètes des performances que vous pouvez comparer à des seuils acceptables. Par exemple, vous pouvez définir les exemples de SLO suivants pour votre système :

• Fraîcheur des données : générez 90 % des recommandations de produits résultant de l'activité des utilisateurs sur le site Web dans un délai maximum de trois minutes tout au plus.

• Exactitude des données : dans un mois civil, moins de 0,5 % des factures des clients contiennent des erreurs.

• Isolation des données/Équilibrage de charge : au cours d'un jour ouvré, traitez tous les paiements de priorité élevée dans les 10 minutes suivant le dépôt de la demande, puis effectuez les paiements de priorité standard le jour ouvré suivant.

Vous pouvez utiliser des indicateurs de niveau de service (SLI) pour mesurer la conformité aux SLO. Les SLI sont des métriques quantifiables qui indiquent dans quelle mesure votre système atteint un SLO donné. Par exemple, vous pouvez mesurer l'exemple de SLO de fraîcheur des données en utilisant l'ancienneté de l'activité utilisateur la plus récemment traitée comme SLI. Si votre pipeline génère des recommandations à partir d'événements d'activité utilisateur et que votre SLI signale un délai de quatre minutes entre l'heure de l'événement et le traitement de l'événement, les recommandations ne prennent pas en compte les activités de l'utilisateur sur le site Web qui remontent à plus de 4 minutes. Si un pipeline qui traite des données en streaming dépasse une latence système de quatre minutes, vous savez que le SLO n'est pas atteint.

Étant donné que les composants système autres que votre pipeline affectent votre SLO, il est important de capturer un éventail de SLI décrivant les performances globales du système au-delà des performances du pipeline lui-même, y compris des métriques décrivant la santé de bout en bout de votre système. Par exemple, votre pipeline Dataflow peut calculer les résultats dans un délai acceptable, mais un problème de performances peut survenir avec un système en aval et affecter des SLO plus larges.

Pour en savoir plus sur les SLO importants à prendre en compte, consultez le livre Ingénierie de fiabilité des sites.

Fraîcheur des données

La fraîcheur des données fait référence à la facilité d'utilisation des données par rapport à leur ancienneté. Les SLO de fraîcheur des données suivants sont mentionnés dans le livre sur l'ingénierie en fiabilité des sites comme les formats de SLO de fraîcheur des données d'un pipeline les plus courants :

• X % de données traitées en Y [secondes, jours, minutes]. Ce SLO fait référence au pourcentage des données traité pendant une période donnée. Il est couramment utilisé pour les pipelines de traitement par lot qui traitent des sources de données limitées. Les métriques de ce type de SLO sont les tailles des données d'entrée et de sortie aux étapes de traitement clés par rapport au temps d'exécution du pipeline écoulé. Vous pouvez choisir une étape qui lit un ensemble de données d'entrée et une autre étape qui traite chaque élément de l'entrée. Voici un exemple de SLO : "Pour le jeu Shave the Yak, 99 % des activités des utilisateurs ayant une incidence sur les scores des joueurs sont prises en compte dans les 30 minutes suivant la fin du match".

• Les données les plus anciennes ne datent pas de plus de X [secondes, jours, minutes]. Ce SLO fait référence à l'ancienneté des données produites par le pipeline. Il est couramment utilisé pour les pipelines de traitement par flux qui traitent des données provenant de sources illimitées. Pour ce type de SLO, utilisez des métriques qui indiquent le temps nécessaire à votre pipeline pour traiter les données. Deux métriques possibles sont l'ancienneté du plus ancien élément non traité (temps passé par un élément non traité dans la file d'attente) ou l'ancienneté de l'élément traité le plus récemment. Voici un exemple de SLO : "Les recommandations de produits sont générées à partir d'une activité utilisateur ne datant pas de plus de cinq minutes".

• Le job de pipeline a été exécuté en X [secondes, jours, minutes]. Ce SLO définit une date limite pour une exécution réussie, et est généralement utilisé pour les pipelines de traitement par lot qui traitent des données provenant de sources de données limitées. Ce SLO nécessite le temps d'exécution total écoulé du pipeline et l'état d'achèvement du job, en plus d'autres signaux indiquant la réussite du job (par exemple, le pourcentage d'éléments traités qui génèrent des erreurs). Voici un exemple de SLO : "Les commandes client passées dans le jour ouvré en cours sont traitées avant 9:00 le lendemain".

Pour en savoir plus sur l'utilisation de Cloud Monitoring pour mesurer la fraîcheur des données, consultez la section Métriques de job Dataflow.

Exactitude des données

L'exactitude des données fait référence à l'absence d'erreurs dans les données. Vous pouvez déterminer l'exactitude des données de différentes manières, par exemple :

• Des tests unitaires et des tests d'intégration, que vous pouvez automatiser à l'aide de l'intégration continue.

• Des tests de pipeline de bout en bout, que vous pouvez exécuter dans un environnement de préproduction une fois que le pipeline a réussi les tests unitaires et d'intégration. Vous pouvez automatiser les tests de pipeline de bout en bout avec la livraison continue.

• Des pipelines s'exécutant en production, lorsque vous utilisez la surveillance pour observer les métriques liées à l'exactitude des données.

Pour les pipelines en cours d'exécution, la définition d'un objectif d'exactitude des données implique généralement de mesurer l'exactitude sur une période donnée. Exemple :

• Par job, moins de X % des éléments d'entrée contiennent des erreurs de données. Vous pouvez utiliser ce SLO pour mesurer l'exactitude des données des pipelines de traitement par lot. Voici un exemple de SLO : "Pour chaque job par lot quotidienne permettant de traiter les relevés de compteurs d'électricité, moins de 3 % des relevés contiennent des erreurs de saisie de données".
• Sur une période de X minutes, moins de Y % des éléments d'entrée contiennent des erreurs de données. Vous pouvez utiliser ce SLO pour mesurer l'exactitude des données pour les pipelines de traitement par flux. Voici un exemple de SLO : "Moins de 2 % des relevés de compteurs d'électricité au cours de la dernière heure contiennent des valeurs négatives".

Pour mesurer ces SLO, utilisez les métriques sur une période appropriée pour comptabiliser le nombre d'erreurs par type. Les exemples de types d'erreurs incluent par exemple les données incorrectes en raison d'un schéma incorrect, ou les données qui ne sont pas comprises dans une plage valide.

Pour en savoir plus sur l'utilisation de Cloud Monitoring pour mesurer l'exactitude des données, consultez la page Métriques de job Dataflow.

Isolation des données et équilibrage de charge

L'isolation des données implique leur segmentation par attribut, ce qui peut faciliter l'équilibrage de charge. Par exemple, dans une plate-forme de traitement des paiements en ligne, vous pouvez segmenter les données de sorte que les paiements individuels soient de priorité standard ou élevée. Votre pipeline peut ensuite utiliser l'équilibrage de charge pour s'assurer que les paiements de priorité élevée sont traités avant les paiements de priorité standard.

Supposons que vous définissiez les SLO suivants pour le traitement des paiements :

• Les paiements de priorité élevée sont traités dans un délai de 10 minutes.
• Les paiements de priorité standard sont traités d'ici 9h le lendemain.

Si la plate-forme de paiement respecte ces SLO, les clients peuvent consulter les paiements de priorité élevée finalisés dans un tableau de bord de création de rapports dès qu'ils ont été effectués. En revanche, les paiements de priorité standard peuvent ne pas apparaître sur le tableau de bord avant le lendemain.

Dans cet exemple de scénario, vous disposez des options suivantes :

• Exécuter un seul pipeline pour traiter les paiements de priorité standard et de priorité élevée
• Isoler les données et équilibrer la charge en fonction des priorités sur plusieurs pipelines

Les sections suivantes décrivent chaque option en détail.

Utiliser un seul pipeline pour livrer des données avec des SLO mixtes

Le schéma suivant présente un seul pipeline permettant de traiter à la fois les paiements de priorité élevée et ceux de priorité standard. Le pipeline reçoit une notification de nouveaux paiements provenant d'une source de données en flux continu, par exemple un sujet Pub/Sub ou Apache Kafka. Il traite ensuite immédiatement les paiements et écrit les événements dans BigQuery à l'aide d'insertions en flux continu.

L'avantage de n'avoir qu'un seul pipeline est la simplification de vos exigences opérationnelles, car vous ne devez gérer qu'une seule source de données et qu'un seul pipeline. Dataflow utilise les fonctionnalités de réglage automatique pour vous aider à exécuter votre job aussi rapidement et efficacement que possible.

L'inconvénient d'un pipeline unique est que le pipeline partagé ne peut pas privilégier les paiements de priorité élevée par rapport aux paiements de priorité standard et que les ressources du pipeline sont partagées entre les deux types de paiements. Dans le scénario métier décrit précédemment, votre pipeline doit essayer de satisfaire le plus strict des deux SLO. Autrement dit, le pipeline doit utiliser le SLO pour les paiements de priorité élevée, quelle que soit la priorité réelle des paiements traités. Un autre inconvénient est qu'en cas de retard dans les tâches, le pipeline de traitement par flux ne peut pas hiérarchiser le traitement en attente en fonction de l'urgence des tâches.

Utiliser plusieurs pipelines adaptés à des SLO spécifiques

Vous pouvez utiliser deux pipelines pour isoler les ressources et livrer les données en fonction de SLO spécifiques. Le schéma suivant illustre cette approche.

Les paiements de priorité élevée sont isolés dans un pipeline de traitement par flux en vue de leur traitement prioritaire. Les paiements de priorité standard sont traités par un pipeline de traitement par lot qui s'exécute quotidiennement et qui utilise des jobs de chargement BigQuery pour écrire les résultats traités.

L'isolation des données dans différents pipelines présente des avantages. Pour les paiements de priorité élevée qui doivent respecter des SLO plus stricts, vous pouvez raccourcir les temps de traitement en affectant plus de ressources au pipeline dédié aux paiements de priorité élevée. Les configurations de ressources incluent l'ajout de nœuds de calcul Dataflow, l'utilisation de machines de capacité supérieure et l'activation de l'autoscaling. L'isolation des éléments de priorité élevée dans une file d'attente de traitement distincte peut également réduire les retards de traitement en cas d'afflux soudain de paiements de priorité standard.

Lorsque vous utilisez plusieurs pipelines pour isoler et équilibrer la charge de données provenant de sources par lot et par flux, le modèle de programmation Apache Beam permet aux pipelines de traitement des éléments de priorité élevée (par flux) et de priorité standard (par lot) de partager le même code. La seule exception est la transformation de lecture initiale, qui lit une source limitée pour le pipeline de traitement par lot. Pour en savoir plus, consultez la page Créer des bibliothèques de transformations réutilisables.

Planifier les sources et les récepteurs de données

Pour traiter des données, un pipeline de données doit être intégré à d'autres systèmes. Ces systèmes sont appelés sources et récepteurs. Les pipelines de données lisent les données des sources et les écrivent dans les récepteurs. En plus des sources et des récepteurs, les pipelines de données peuvent interagir avec des systèmes externes pour l'enrichissement des données, le filtrage ou l'appel de la logique métier externe dans une étape de traitement.

À des fins d'évolutivité, Dataflow exécute les étapes de votre pipeline en parallèle sur plusieurs nœuds de calcul. Les facteurs extérieurs au code de votre pipeline et le service Dataflow ont également une incidence sur l'évolutivité de votre pipeline. Ces facteurs peuvent inclure les suivants :

• Évolutivité des systèmes externes : les systèmes externes avec lesquels votre pipeline interagit peuvent limiter les performances et constituer la limite supérieure de l'évolutivité. Par exemple, un sujet Apache Kafka configuré avec un nombre insuffisant de partitions pour le débit de lecture dont vous avez besoin peut affecter les performances de votre pipeline. Pour vous assurer que le pipeline et ses composants atteignent vos objectifs de performances, consultez la documentation sur les bonnes pratiques pour les systèmes externes que vous utilisez. Vous pouvez également simplifier la planification de la capacité de l'infrastructure en utilisant des services Google Cloud offrant une évolutivité intégrée. Pour en savoir plus, consultez la section Utiliser des sources et des récepteurs gérés Google Cloud sur la présente page.

• Choix des formats de données : certains formats de données peuvent être plus rapides à lire que d'autres. Par exemple, l'utilisation de formats de données compatibles avec les lectures chargeables en parallèle, comme Avro, est généralement plus rapide que l'utilisation de fichiers CSV contenant des retours à la ligne intégrés dans les champs, et est plus rapide que d'utiliser des fichiers compressés.

• Emplacement des données et topologie du réseau : la proximité géographique et les caractéristiques de mise en réseau des sources et des récepteurs de données par rapport au pipeline de données peuvent avoir un impact sur les performances. Pour en savoir plus, consultez la section Points à prendre en compte concernant les régions sur la présente page.

Appels de services externes

L'appel de services externes à partir de votre pipeline entraîne une surcharge par appel qui peuvent réduire les performances et l'efficacité de votre pipeline. Si votre pipeline de données appelle des services externes, regroupez plusieurs éléments de données dans des requêtes uniques quand cela est possible afin de réduire les frais généraux. De nombreuses transformations d'E/S Apache Beam natives effectuent automatiquement cette tâche, y compris BigQueryIO et les opérations d'insertion en flux continu. En plus des limites de capacité, certains services externes appliquent également des quotas qui limitent le nombre total d'appels sur une période donnée (par exemple, un quota quotidien) ou restreignent le taux d'appels (par exemple, le nombre de requêtes par seconde).

Étant donné que Dataflow charge en parallèle les tâches sur plusieurs nœuds de calcul, un trafic trop important peut surcharger un service externe ou épuiser les quotas disponibles. Lorsque l'autoscaling est utilisé, Dataflow peut tenter de compenser ce phénomène en ajoutant des nœuds de calcul pour exécuter une étape lente, comme un appel externe. L'ajout de nœuds de calcul peut augmenter la pression exercée sur les systèmes externes. Assurez-vous que les systèmes externes peuvent répondre aux exigences de charge attendues ou limitez le trafic de votre pipeline à des niveaux viables. Pour en savoir plus, consultez la section Limiter les tailles de lot et les appels simultanés à des services externes.

Utiliser des sources et des récepteurs gérés Google Cloud

L'utilisation des services gérés Google Cloud avec votre pipeline Dataflow simplifie la gestion de la capacité en fournissant une évolutivité intégrée, une constance des performances, ainsi que des quotas et des limites qui répondent à la plupart des exigences. Vous devez toujours être conscient des différents quotas et limites applicables aux opérations de pipeline. Dataflow lui-même applique des quotas et des limites. Vous pouvez augmenter certains d'entre eux en contactant l'assistance Google Cloud.

Dataflow utilise des instances de VM Compute Engine pour exécuter vos jobs. Vous avez donc besoin d'un quota Compute Engine suffisant. Un quota Compute Engine insuffisant peut gêner l'autoscaling du pipeline ou empêcher le démarrage des jobs.

Les autres parties de cette section expliquent comment les différents quotas et les différentes limites Google Cloud peuvent influencer la conception, le développement et la surveillance de votre pipeline. Pub/Sub et BigQuery sont utilisés comme exemples de sources et de récepteurs de pipeline.

Exemple 1 : Pub/Sub

Lorsque vous utilisez Pub/Sub avec Dataflow, Pub/Sub est un service d'ingestion d'événements évolutif et durable permettant de distribuer des messages depuis et vers vos pipelines de données par flux. Vous pouvez utiliser la console Google Cloud pour afficher la consommation des quotas Pub/Sub et augmenter les limites de quota. Nous vous recommandons de demander une augmentation de quotas si votre pipeline dépasse les quotas et limites par projet.

Les quotas et les limites Pub/Sub sont conçus sur la base de l'utilisation au niveau du projet. Plus précisément, les éditeurs et les abonnés de différents projets se voient attribuer des quotas de débit de données indépendants. Si plusieurs pipelines publient du contenu ou s'abonnent à un sujet unique, vous pouvez obtenir un débit maximal autorisé sur ce sujet en déployant chaque pipeline dans son propre projet. Dans cette configuration, chaque pipeline utilise un compte de service basé sur un projet différent pour consommer et publier des messages.

Dans le schéma suivant, le pipeline 1 et le pipeline 2 partagent le même quota de débit d'abonné et d'éditeur que celui disponible pour le projet A. En revanche, le pipeline 3 peut utiliser la totalité du quota de débit d'abonné et d'éditeur associé au projet B.

Plusieurs pipelines peuvent lire à partir d'un seul sujet Pub/Sub en utilisant des abonnements distincts au sujet, ce qui permet aux pipelines Dataflow d'extraire des messages et d'en accuser réception indépendamment des autres abonnés (dans ce cas, d'autres pipelines). Cette fonctionnalité facilite le clonage des pipelines en créant des abonnements Pub/Sub supplémentaires. La création d'abonnements supplémentaires est utile pour créer des pipelines d'instances dupliquées à des fins de haute disponibilité (généralement pour les cas d'utilisation par flux), pour exécuter des pipelines de test supplémentaires par rapport aux mêmes données et pour activer les mises à jour des pipelines.

Exemple 2 : BigQuery

La lecture et l'écriture de données BigQuery sont compatibles avec le SDK Apache Beam pour plusieurs langages, y compris Java, Python et Go. Lorsque vous utilisez Java, c'est la classe BigQueryIO qui fournit cette fonctionnalité. BigQueryIO accepte deux méthodes de lecture des données : EXPORT (exportation de table) et DIRECT_READ. Les différentes méthodes de lecture consomment différents quotas BigQuery.

L'exportation de table est la méthode de lecture par défaut. Elle se déroule comme indiqué dans le schéma suivant :

Ce flux est représenté dans le diagramme suivant :

1. BigQueryIO appelle une requête d'exportation BigQuery pour exporter des données de table. Les données de la table exportée sont écrites dans un emplacement Cloud Storage temporaire.
2. BigQueryIO lit les données de la table à partir de l'emplacement Cloud Storage temporaire.

Les requêtes d'exportation BigQuery sont limitées par des quotas d'exportation. La requête d'exportation doit également se terminer pour que le pipeline puisse commencer à traiter les données, ce qui augmente le temps d'exécution du job.

En revanche, l'approche de lecture directe utilise l'API BigQuery Storage pour lire les données de table directement à partir de BigQuery. L'API BigQuery Storage fournit des performances de lecture à haut débit pour les données de ligne de table à l'aide de gRPC. L'utilisation de l'API BigQuery Storage rend l'étape d'exportation inutile, ce qui évite les restrictions de quota d'exportation et réduit potentiellement le temps d'exécution du job.

Le schéma suivant illustre le flux si vous utilisez l'API BigQuery Storage. Contrairement au flux qui utilise une requête d'exportation BigQuery, ce flux est plus simple car il ne comporte qu'une seule étape de lecture directe pour faire passer les données de la table au pipeline.

L'écriture de données dans des tables BigQuery a également ses propres implications en termes de quota. Les pipelines de traitement par lot qui utilisent des jobs de chargement BigQuery consomment différents quotas de jobs de chargement BigQuery qui s'appliquent au niveau de la table et du projet. De même, les pipelines de traitement par flux qui utilisent des insertions en flux continu BigQuery consomment des quotas d'insertions en flux continu BigQuery.

Pour déterminer les méthodes les plus appropriées pour lire et écrire des données, examinez votre cas d'utilisation. Par exemple, évitez d'utiliser des jobs de chargement BigQuery pour ajouter des données des milliers de fois par jour dans une table. Utilisez un pipeline de traitement par flux pour écrire des données dans BigQuery quasiment en temps réel. Pour cela, votre pipeline de traitement par flux doit utiliser des insertions en flux continu ou l'API Storage Write.

Points à prendre en compte concernant les régions

Dataflow est proposé en tant que service géré dans plusieurs régions Google Cloud. Lorsque vous choisissez une région à utiliser pour exécuter vos jobs, tenez compte des facteurs suivants :

• Emplacement des sources et des récepteurs de données
• Préférences ou restrictions sur les emplacements de traitement des données
• Fonctionnalités Dataflow proposées uniquement dans des régions spécifiques
• La région utilisée pour gérer l'exécution d'un job donné
• Zone utilisée pour les nœuds de calcul du job

Pour un job donné, le paramètre de région que vous utilisez pour le job et pour les nœuds de calcul peut différer. Pour en savoir plus, en particulier sur la spécification des régions et des zones, consultez la documentation sur les régions Dataflow.

En spécifiant les régions dans lesquelles exécuter vos jobs Dataflow, vous pouvez planifier la haute disponibilité et la reprise après sinistre sur la base des points à prendre en compte concernant les régions. Pour en savoir plus, consultez la section Haute disponibilité et redondance géographique.

Régions

Les régions Dataflow stockent et gèrent les métadonnées liées à votre job, par exemple les informations sur le graphique Apache Beam lui-même telles que les noms des transformations. Ils contrôlent également les comportements des nœuds de calcul, tels que l'autoscaling. La spécification d'une région vous permet de répondre à vos besoins en termes de sécurité, de conformité, de localité des données et d'emplacement régional d'un job. Pour éviter que des appels réseau interrégionaux n'affectent les performances, nous vous recommandons d'utiliser la même région pour le job et pour les nœuds de calcul.

Nœuds de calcul Dataflow

Les jobs Dataflow utilisent des instances de VM Compute Engine (appelées nœuds de calcul Dataflow) pour exécuter votre pipeline. Les jobs Dataflow peuvent utiliser n'importe quelle zone Compute Engine pour les nœuds de calcul, y compris les régions dans lesquelles il n'existe pas d'emplacements Dataflow. En spécifiant une région de nœud de calcul pour votre job, vous pouvez contrôler l'emplacement régional de vos nœuds de calcul. Pour spécifier une région ou une zone de nœud de calcul, procédez comme suit :

• Si vous utilisez gcloud CLI pour créer un job à partir d'un modèle Dataflow, utilisez l'option --worker-region pour ignorer la région des nœuds de calcul ou l'option --worker-zone pour ignorer la zone des nœuds de calcul.
• Si vous utilisez le SDK Java Apache Beam pour créer votre job, vous définissez des régions et des zones pour les nœuds de calcul à l'aide des options de pipeline. Utilisez workerRegion pour ignorer la région des nœuds de calcul ou workerZone pour ignorer la zone des nœuds de calcul.

Pour améliorer la latence et le débit du réseau, nous vous recommandons de créer des nœuds de calcul dans une région géographiquement proche de vos sources et récepteurs de données. Si vous ne spécifiez pas de région ni de zone pour les nœuds de calcul lorsque vous créez un job, Dataflow utilise par défaut une zone située dans la même région que le job.

Si vous n'utilisez pas le service Dataflow Shuffle ou Streaming Engine, les données traitées par le job (c'est-à-dire celles stockées dans un objet PCollection) résident sur les nœuds de calcul du job, en supposant qu'aucun code utilisateur ne transmet des données en dehors des nœuds de calcul. Si le service Dataflow Shuffle ou Streaming Engine est activé, l'ensemble de données distribué représenté par un objet PCollection peut être transmis entre les nœuds de calcul et ces services.

Points à prendre en compte concernant le chiffrement des données

En tant que service entièrement géré, Dataflow chiffre automatiquement les données qui transitent par votre pipeline de données à l'aide de clés appartenant à Google et gérées par Google pour les données en cours de transfert et au repos. Au lieu d'utiliser des clés appartenant à Google et gérées par Google, vous pouvez gérer vos propres clés de chiffrement. Dans ce cas, Dataflow accepte les clés de chiffrement gérées par le client (CMEK) à l'aide de Cloud Key Management Service (KMS). Vous pouvez également utiliser Cloud HSM, un service de module de sécurité matériel sur le cloud qui permet d'héberger des clés de chiffrement et d'effectuer des opérations cryptographiques dans un cluster de modules HSM certifiés FIPS 140-2 niveau 3.

Lorsque vous utilisez une CMEK, Dataflow utilise votre clé Cloud KMS pour chiffrer les données, sauf pour les opérations basées sur des clés de données telles que le fenêtrage, le regroupement et la jointure. Si les clés de données contiennent des données sensibles, telles que des informations personnelles, vous devez les hacher ou les transformer d'une autre manière avant qu'elles ne pénètrent dans le pipeline Dataflow.

Points à prendre en compte concernant les réseaux privés

Vos exigences de termes de mise en réseau et de sécurité peuvent impliquer que les charges de travail basées sur des VM, telles que les jobs Dataflow, n'utilisent que des adresses IP privées. Dataflow vous permet de forcer les nœuds de calcul à utiliser des adresses IP privées pour toutes les communications réseau. Si les adresses IP publiques sont désactivées, vous devez activer l'accès privé à Google sur le sous-réseau afin que les nœuds de calcul Dataflow puissent atteindre les API et les services Google.

Nous vous recommandons de désactiver les adresses IP publiques pour les nœuds de calcul Dataflow, sauf si vos jobs Dataflow nécessitent des adresses IP publiques pour accéder à des ressources réseau en dehors de Google Cloud. La désactivation des adresses IP publiques empêche les nœuds de calcul Dataflow d'accéder aux ressources situées en dehors du sous-réseau ou d'accéder aux réseaux VPC appairés. De même, l'accès réseau aux nœuds de calcul de VM situés en dehors du sous-réseau ou des réseaux VPC appairés est bloqué.

Pour en savoir plus sur l'utilisation de l'option de pipeline --usePublicIps pour spécifier si les nœuds de calcul ne doivent disposer que d'adresses IP privées, consultez la section Options de pipeline.

Étapes suivantes

• Développez et testez votre pipeline.
• Apprenez à concevoir des workflows de pipeline complets.
• Apprenez-en plus sur les pratiques d'ingénierie en fiabilité des sites (SRE) pour les pipelines de traitement des données.