tadata
← Retour à l'accueil

Change Data Capture : Patterns, Outils & Architecture

#data-engineering#cdc#databases#streaming#replication

Le Change Data Capture (CDC) est le pilier de l'intégration de données moderne. Plutôt que d'interroger des tables entières de manière répétée, le CDC détecte et propage uniquement les lignes modifiées. Résultat : latence réduite, charge base de données allégée et une piste d'audit fiable de chaque mutation.

Comparaison des Méthodes CDC

MéthodeMécanismeLatenceCharge DBConscience du SchemaRisque de Perte
Log-basedLecture du journal de transactions (WAL/binlog)Très faible (secondes)MinimaleÉlevée — capture les DDLFaible
Trigger-basedDes triggers écrivent dans une table miroirFaible (quasi temps réel)Moyenne — écritures supplémentairesMoyenneFaible
Query-based (timestamp)Interroge les lignes où updated_at > last_syncMoyenne (minutes)ÉlevéeAucuneMoyenne — suppressions manquées
Query-based (diff)Compare les snapshots entre exécutionsÉlevée (heures)Très élevéeAucuneMoyenne
Dual-writeL'application écrit en DB + bus d'événementsTrès faibleFaible sur DBNiveau applicationÉlevé — risque de cohérence

Le CDC log-based est le standard industriel pour les systèmes de production. Il lit le flux de réplication natif de la base, sans impact sur les performances de requêtes.

Panorama des Outils

OutilTypeSourcesDestinationsModèle TarifaireIdéal Pour
DebeziumOpen source (Kafka Connect)PostgreSQL, MySQL, MongoDB, Oracle, SQL ServerKafka, PulsarGratuitÉquipes avec expertise Kafka
AWS DMSService managé20+ relationnels/NoSQLS3, Kinesis, Redshift, RDSPar heure d'instanceMigrations AWS-native
FivetranSaaS300+ connecteursEntrepôts, lacsTarification par ligneÉquipes low-ops
AirbyteOpen source / Cloud350+ connecteursEntrepôts, lacsGratuit / usageFlexibilité + communauté
StriimPlateforme entrepriseOracle, SAP, mainframesMulti-cloudLicenceModernisation du legacy

Architecture de Référence : Pipeline CDC Log-Based

tadata
  • Base source (Postgres)
    • WAL: Connecteur Debezium
      • JSON CDC: Topics Kafka
        • → Connecteur sink
          • → Entrepôt de données (Iceberg)
        • → Traitement de flux (Flink)
tadata
Source DB DMS task Target (S3 / Redshift) loop [ongoing replication] MySQL: binlog_format=ROW;PostgreSQL: logical replicationslot read tables in parallel (full load) rows bulk write; cache changes meanwhile apply cached changes read transaction log (binlog, redo,WAL) insert / update / delete apply ongoing changes (CDC)
Source DB DMS task Target (S3 / Redshift) loop [ongoing replication] MySQL: binlog_format=ROW;PostgreSQL: logical replicationslot read tables in parallel (full load) rows bulk write; cache changes meanwhile apply cached changes read transaction log (binlog, redo,WAL) insert / update / delete apply ongoing changes (CDC)
DMS full load + CDC : la cible rattrape son retard, puis suit le journal de transactions

Extrait de la fiche « DEA-C01 Domain 1a: Data Ingestion, Batch and Streaming » · Demander la fiche complète

Pattern Outbox pour les Microservices

Le pattern transactional outbox résout le problème du dual-write. L'application écrit les événements métier dans une table outbox au sein de la même transaction. Le CDC surveille ensuite cette table et publie les événements vers Kafka.

tadata
Write side: commands Read side: queries Checkout API Lambda: placeorder TransactWriteItems:order + outbox item DynamoDB orders single transaction DynamoDB Streams(outbox) commands EventBridge Pipes → bus publish SQS perconsumer buffer, DLQ ProjectorLambda idempotentupsert Read model OpenSearch /DynamoDBview Query API subscribe results replay events Outbox transactionnel et modèles de lecture CQRS
Write side: commands Read side: queries Checkout API Lambda: placeorder TransactWriteItems:order + outbox item DynamoDB orders single transaction DynamoDB Streams(outbox) commands EventBridge Pipes → bus publish SQS perconsumer buffer, DLQ ProjectorLambda idempotentupsert Read model OpenSearch /DynamoDBview Query API subscribe results replay events Outbox transactionnel et modèles de lecture CQRS

Extrait de la fiche « SQS and SNS: Messaging Patterns in Depth » · Demander la fiche complète

Métriques Clés à Surveiller

MétriqueCibleImportance
Retard de réplication< 5 secondesLectures obsolètes en aval
Disponibilité du connecteur> 99.9%Les interruptions causent des pertes
Débit d'événementsSelon la chargeLes goulets d'étranglement cascadent
Échecs de changement de schéma0Les changements cassants arrêtent les pipelines

Ressources

Nous utilisons des cookies analytiques pour améliorer votre expérience. Aucune donnée personnelle n'est collectée.