ingérer 10 To de données par jour
Maintenir une latence de bout en bout inférieure à la seconde
Rester entièrement sans serveur, fiable et de qualité production.
Ce billet détaille notre architecture, les défis que nous avons rencontrés et la façon dont nous avons optimisé le système pour atteindre les objectifs de performance et de rentabilité.
Objectifs
Volume d'ingestion: 10TB/jour (~115MB/sec soutenu)
Objectif de latence: < 1 seconde entre le chargement des données et la visibilité dans BigQuery
Contraintes de conception: Sans serveur, mise à l'échelle automatique, opérations minimales
Services de base: Cloud Functions, Pub/Sub, Dataflow (Apache Beam), BigQuery
Conception de l'architecture et aperçu
[Producteurs de données → GCS Upload]
↓
(Événement de finalisation d'objet) [Fonction cloud déclenchée par GCS]
↓
[Sujet Pub/Sub (Buffer)]
↓
[Job de streaming de flux de données]
↓
[BigQuery (couche analytique)]
Fonction cloud déclenchée par le téléchargement GCS
Notre pipeline d'ingestion commence lorsque les fichiers sont téléchargés sur Google Cloud Storage. Une fonction cloud est automatiquement déclenchée par les événements "objet finalisé" de GCS.
Cette fonction :
analyse les métadonnées GCS (bac, nom de fichier, horodatage, source)
ajoute des balises personnalisées ou des informations sur la version du schéma
Publie un message dans un sujet Pub/Sub avec les métadonnées.
Optimisations
Allocation de suffisamment de mémoire (~512MB) pour réduire les démarrages à froid
Réutilisation des clients réseau pour éviter les surcharges de socket
1000 exécutions simultanées ont été possibles, sans blocage de la tentative.
Pub/Sub : Découplage et mise en mémoire tampon
Pub/Sub a agi comme notre tampon de messages, permettant :
une mise à l'échelle horizontale des consommateurs en aval
des capacités de relecture en cas de défaillance en aval
la protection contre la pression en retour grâce au contrôle de flux.
Chaque message contenait les métadonnées nécessaires à Dataflow pour charger, transformer et acheminer les données.
Flux de données : Moteur de traitement des flux
Nous avons utilisé Dataflow (Apache Beam, Java SDK) en mode streaming pour :
Récupérer et analyser le contenu des fichiers bruts à partir de GCS
Appliquer des transformations tenant compte des schémas
Gérer la déduplication en utilisant le fenêtrage et le filigrane
écrire des données enrichies dans BigQuery avec un délai inférieur à la seconde
Optimisations du flux de données
Activation du moteur de streaming + Runner v2
Utilisation du rééquilibrage dynamique du travail et de la mise à l'échelle automatique (5-200 travailleurs)
Découpage de fichiers volumineux en morceaux plus petits (ParDo + batching)
BigQuery : Couche d'analyse en temps réel
Les données ont été introduites en continu dans une table d'atterrissage dans BigQuery via l'insertion en continu. Une tâche de transformation programmée distincte a partitionné et regroupé les données dans des tables classées.
Optimisations BigQuery
Partitionnement par date d'ingestion
Regroupement par identifiant de source, type d'événement
Compactage des fichiers quotidiens à l'aide de requêtes programmées
Utilisation des métriques des tampons de streaming pour détecter les pics de lag.
Goulets d'étranglement et défis
Récupération et observabilité
Répétitions: Fonctions cloud et tentatives Pub/Sub + backoff
Files d'attente de la lettre morte: Pour les événements malformés ou les incohérences de schéma
Journalisation: Centralisée avec Cloud Logging et étiquettes personnalisées
Mesures: Fraîcheur des données, latence, débit et nombre d'erreurs
Retraitement: Relecture manuelle ou programmée du flux de données à partir de GCS + Pub/Sub
Surveillance, optimisation des coûts et reprise sur panne
Il ne suffit pas de construire un pipeline ETL très performant, il faut aussi pouvoir l'observer et le résilier. Voici comment nous avons assuré la visibilité, le contrôle des coûts et une gestion robuste des erreurs dans notre pipeline ETL GCP de 10 To/jour.
Surveillance du pipeline
Nous avons tiré parti de la surveillance et de la journalisation en nuage pour suivre chaque composant en temps réel :
Fonction Cloud:
Suivi du nombre d'invocations, de la durée d'exécution et des taux d'erreur à l'aide des tableaux de bord de Cloud Monitoring.
Nous avons configuré des alertes en cas d'échec des exécutions ou d'augmentation anormale de la durée d'exécution.
Pub/Sub:
Suivi de l'arriéré de messages et du débit via les mesures Pub/Sub.
Des alertes ont été définies pour détecter la croissance de l'arriéré de messages, indiquant des abonnés lents ou défaillants.
Flux de données:
Surveillance du comportement d'autoscaling, de l'utilisation de l'unité centrale, de l'utilisation de la mémoire et du décalage du système.
Configuration d'alertes personnalisées pour détecter les retards de traitement (par exemple, filigranes élevés en retard par rapport à l'ingestion).
Utilisation des journaux des tâches Dataflow pour déboguer les erreurs de transformation, les problèmes de mémoire ou les partitions asymétriques.
BigQuery:
Surveillance des erreurs d'insertion en continu et du débit à l'aide des journaux d'audit BigQuery.
Suivi du coût des requêtes, de l'utilisation des slots et de la latence afin d'optimiser les performances et le budget.
Outils: Les tableaux de bord de surveillance du cloud ont été personnalisés pour notre pipeline, avec des graphiques pour :
Débit (fichiers/min, enregistrements/sec)
Latence (de bout en bout, de GCS à BQ)
Alertes en cas d'échec d'un travail
Mesures des coûts par service (stockage/requête BQ, VMs Dataflow, etc.)
Résultats
Mise à l'échelle à une charge soutenue de 10 To/jour
Latence de bout en bout de ~600 ms en moyenne
Entièrement sans serveur et mise à l'échelle automatique avec un minimum de frais d'exploitation.
Les requêtes en temps réel et les analyses en aval sont disponibles en quelques secondes.
Enseignements tirés
Le fait d'être " cloud-native " ne signifie pas qu'une latence inférieure à la seconde est réalisable avec les bons modèles.
Les déclencheurs de GCS basés sur des fichiers sont fiables si vous prévoyez des tentatives et des interruptions de service.
La clé de la performance est le pré-dimensionnement, l'ajustement des lots et le découplage des étapes.
Conclusion
GCP fournit une base solide pour construire des pipelines ETL à haut débit et à faible latence. En combinant les déclencheurs événementiels, le découplage Pub/Sub et les flux de données en continu, nous avons pu traiter des téraoctets de données par jour avec des accords de niveau de service en temps réel.
Que vous modernisiez un système batch ou que vous construisiez une nouvelle architecture de streaming, cette conception peut servir de modèle. Contactez-nous pour en savoir plus ou consultez notre page carrière pour découvrir comment vous pouvez faire partie de l'équipe Improving.
