Diagramme d'architecture de pipeline de données : CDC, streaming et entrepôt

Les pipelines de données tombent en panne sans bruit. Un tableau de bord affiche les chiffres de la veille, une colonne change de type en amont et un job supprime des lignes sans erreur, ou un slot de réplication dont plus personne ne se souvient retient le journal d'écriture anticipée sur la base de production jusqu'à ce que le disque soit plein. Chacun de ces cas est une étape ou un contrat que personne n'a dessiné.

Un diagramme d'architecture de pipeline de données montre d'où viennent les données, comment elles circulent, où elles sont stockées à chaque étape, qui les transforme et quand, et comment chacun sait qu'elles sont fraîches et correctes. Cet article en construit un pour une configuration courante, la capture des changements de données (CDC) depuis PostgreSQL via Kafka vers un lake et un entrepôt, et détaille ce qu'il faut étiqueter à chaque étape.

Extractions par lots, CDC ou événements

Il existe trois façons courantes de sortir les données d'une base opérationnelle :

La capture des changements basée sur le journal (CDC) est populaire pour l'analytique, car elle ne demande aucune modification de l'application, voit les suppressions et ajoute peu de charge de requêtes. Ses coûts sont opérationnels, et ils ont leur place sur le diagramme.

Comment fonctionne le CDC basé sur le journal avec PostgreSQL

PostgreSQL expose les changements par le décodage logique, qui transforme le journal d'écriture anticipée (WAL) en un flux de modifications de lignes. Il faut pour cela wal_level = logical, un plugin de sortie et un slot de réplication. Le connecteur PostgreSQL de Debezium utilise le plugin standard pgoutput, fourni avec PostgreSQL 10 et les versions ultérieures. Au premier démarrage, il prend un instantané cohérent des tables, puis diffuse chaque insertion, mise à jour et suppression validée, par défaut vers un topic Kafka par table, nommé topicPrefix.schemaName.tableName.

Le slot de réplication est la partie qui fait mal. La documentation de PostgreSQL explique qu'un slot empêche la suppression du WAL dont son consommateur a encore besoin, même quand rien n'est connecté. Si le connecteur s'arrête un week-end, le WAL continue de grossir sur le primaire. Le paramètre max_slot_wal_keep_size plafonne la quantité de WAL que les slots peuvent retenir ; sa valeur par défaut, -1, signifie aucune limite. Un plafond protège la base, au prix de l'invalidation du slot, c'est-à-dire d'un nouvel instantané. Dans tous les cas, surveillez le retard du slot et dessinez le slot sur le diagramme.

Les couches du lake et l'entrepôt

Une fois les changements dans Kafka, un sink les écrit dans un stockage, et des transformations les rendent exploitables. Databricks a popularisé l'architecture en médaillon pour nommer les étapes :

• Bronze contient les données brutes telles qu'elles sont arrivées, avec leurs métadonnées de chargement, pour pouvoir retraiter sans relire la source.
• Silver contient des enregistrements nettoyés, dédoublonnés et harmonisés : une ligne courante par commande, des types et des clés cohérents.
• Gold contient les tables métier et les agrégats que lisent les tableaux de bord et les modèles.

L'emplacement de chaque couche est un choix de conception : un stockage objet avec un format de table ouvert comme Apache Iceberg, ou l'entrepôt lui-même. Dessinez l'emplacement réel, car c'est lui qui décide du coût, du contrôle d'accès et de qui peut interroger les données.

Orchestration et contrats

Les transformations de bronze vers gold s'exécutent selon un planning ou à l'arrivée de nouvelles données, pilotées par un orchestrateur comme Airflow ou Dagster, souvent avec des modèles SQL dans dbt. Deux choses font la différence entre un pipeline et un passif :

• Les contrats. Les schémas des événements de changement sont enregistrés dans un registre de schémas avec des règles de compatibilité, si bien qu'un changement cassant dans la table source échoue bruyamment chez le producteur au lieu d'échouer en silence dans un rapport.
• Les contrôles. Des contrôles de fraîcheur, de nombre de lignes, d'unicité et de valeurs nulles s'exécutent après chaque étape, et un échec alerte le responsable avant que le tableau de bord soit faux.

L'exemple : une boutique en ligne

La base PostgreSQL de la boutique contient les commandes, les paiements et les clients. Debezium tourne dans Kafka Connect, lit le WAL via un slot de réplication et publie shop.public.orders, shop.public.payments et shop.public.customers. Un connecteur sink ajoute les événements de changement à des tables bronze. Toutes les 15 minutes, l'orchestrateur exécute les modèles dbt qui construisent silver et gold, puis lance les contrôles de données. Les tableaux de bord lisent gold.

Comment le lire :

• Rangée du haut, la capture. Les changements quittent PostgreSQL par le slot de réplication, deviennent des événements de changement dans Debezium, qui enregistre leurs schémas, puis transitent par un topic Kafka par table jusqu'au connecteur sink.
• Rangée du bas, le stockage, de droite à gauche. Le sink ajoute les changements bruts au bronze. Les transformations les fusionnent dans silver et agrègent silver dans gold, que les tableaux de bord interrogent.
• En dessous, le pilotage. L'orchestrateur exécute les transformations et les contrôles ; un contrôle en échec déclenche une alerte.
• Le bloc Markdown liste les règles d'exploitation du slot et des changements de schéma.

Ce qu'il faut étiqueter

• Le slot et sa limite sur le premier lien, et qui est alerté quand il prend du retard.
• Les noms des topics ou une règle de nommage, pour qu'un consommateur sache à quoi s'abonner.
• Les plannings et les objectifs de fraîcheur sur les liens de transformation, par exemple « toutes les 15 min, fraîcheur sous 30 min ».
• La rétention par couche. Le bronze garde souvent l'historique le plus long ; c'est votre tampon de rejeu.
• Les responsables de chaque couche et de chaque contrôle.
• Les données personnelles. Indiquez où elles sont stockées et où elles sont masquées ou supprimées ; voir le diagramme de cartographie des données RGPD.

Erreurs courantes

• Une seule flèche de la base vers l'entrepôt. Elle cache le slot, les schémas et chaque endroit où des données peuvent se perdre ou prendre du retard.
• Des requêtes analytiques sur le primaire. Les extractions par lots sur le primaire de production concurrencent le trafic client ; utilisez le CDC ou une réplique, et dessinez laquelle.
• Aucun chemin de rejeu. Si le bronze n'est pas conservé, un bug dans une transformation oblige à relire la source.
• Des tables brutes comme interface publique. Les consommateurs qui lisent les événements de changement de tables internes cassent quand le schéma change. Pour les événements destinés à d'autres équipes, publiez plutôt des événements conçus pour eux ; le diagramme d'architecture orientée événements couvre ce côté.
• Des contrôles qui ne font que journaliser. Un test qui échoue sans alerter personne n'est qu'un commentaire.

Pour le côté base de données du même système, voir le diagramme de réplication de base de données et l'exemple de diagramme ER.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Depuis le pack Données, ajoutez un nœud Postgres pour la base source et un nœud Kafka pour les topics.
3. Ajoutez des nœuds Conteneur du pack Modèle C4 pour Debezium, le registre de schémas, le connecteur sink et les tableaux de bord.
4. Ajoutez un Cadre du pack Base nommé Lake and warehouse, avec deux nœuds Magasin d'objets du pack Données pour bronze et silver et un Entrepôt de données pour gold.
5. Depuis le pack DevOps, ajoutez un Pipeline CI/CD pour l'orchestrateur et une Alerte pour les contrôles de données. Dessinez les liens de pilotage en pointillé.
6. Ajoutez un bloc Markdown du pack Base avec les règles du slot et des schémas.

L'exemple utilise 13 nœuds de diagramme et reste dans les limites de l'offre Free. Si vous conservez le schéma source en SQL, l'outil PostgreSQL vers diagramme ER dessine les tables qui se trouvent derrière les topics.

FAQ

Le CDC est-il meilleur que les extractions par lots ? Pour la fraîcheur, les suppressions et la charge sur la source, généralement oui. Le traitement par lots est plus simple à exploiter et convient quand des heures de retard sont acceptables et que les lignes ne sont jamais supprimées physiquement.

Ai-je besoin de Kafka pour le CDC ? Debezium tourne le plus souvent sur Kafka Connect, et Kafka vous offre le rejeu et de nombreux consommateurs. D'autres configurations existent ; dessinez le transport que vous exploitez réellement et sa rétention.

Comment gérer les changements de schéma ? Enregistrez les schémas avec des règles de compatibilité, ajoutez des colonnes au lieu de les modifier et rendez les modèles en aval tolérants aux nouvelles colonnes. Dessinez le registre, car c'est là que vit le contrat.

Où exécuter les contrôles de qualité des données ? Après chaque couche, dans le cadre de l'exécution orchestrée, avec des alertes vers le responsable. Les contrôles de fraîcheur sur gold détectent la plupart des pannes silencieuses.

Comment garder le diagramme du pipeline à jour ? Modifiez-le dans la même pull request que la configuration du connecteur et de l'orchestrateur ; voir des diagrammes d'architecture qui ne se périment pas.

Commencez gratuitement — un siège, sans carte bancaire.