Qu'est-ce que la capture de données modifiées ?

Qu'est-ce que la capture de données modifiées ?

La capture de données modifiées (CDC) est une technique d'intégration de données qui identifie et enregistre les changements au niveau des lignes apportés à un dataset, tels que les insertions, les mises à jour et les suppressions. Au lieu d'extraire de manière répétée des tables entières, la CDC ne capture que les enregistrements modifiés et les applique aux systèmes en aval. Cette approche incrémentielle permet de maintenir les plateformes d'analytique, les applications opérationnelles et les pipelines de machine learning alignés sur les informations actuelles, sans le coût ou le délai des refreshs complètes.

Les pipelines de traitement par lots traditionnels reposent sur des tâches d'ingestion périodiques qui effectuent des analyses complètes ou rechargent de grands ensembles de données. Ces flux de travail sont simples et rentables, mais inefficaces lorsque l'on monte en charge, car ils ajoutent de la latence et traitent de manière répétée des données inchangées. La CDC résout ces limitations en détectant en continu les modifications grâce à des mécanismes tels que les journaux de transactions, les déclencheurs, les horodatages ou les flux de modifications natifs, ce qui permet aux plateformes d'architecture data lakehouse de fonctionner avec des données plus récentes et une surcharge de calcul réduite.

Fonctionnement du CDC dans le processus ETL

Au sein d'un pipeline ETL, le CDC est le mécanisme qui extrait uniquement les données qui ont changé depuis le dernier chargement. Plutôt que d'exécuter des extractions planifiées de tables complètes, la CDC capture les lignes nouvelles ou modifiées au fur et à mesure qu'elles apparaissent dans la base de données source. En modifiant uniquement les événements collectés à partir des journaux, des déclencheurs ou des deltas d'instantanés, il peut former un stream incrémentiel représentant l'évolution continue du dataset via des processus d'extraction, de transformation et de chargement (ETL).

Une fois que les événements entrent dans le pipeline, le processus ETL prend le relais, avec tout nettoyage, enrichissement ou validation exécuté sur chaque enregistrement modifié, et non sur l'ensemble du dataset. L'étape de chargement finale n'applique que ces mises à jour incrémentielles à la table ou au référentiel cible, ce qui se traduit par une ingestion légère et continue. Cette approche réduit les E/S et maintient les systèmes en aval étroitement alignés sur la source.

En permettant l'extraction, la transformation et le chargement en continu, le CDC modernise l'ETL, qui passe d'un workflow orienté batch à un pipeline en temps réel. L'analytique, les tableaux de bord et les pipelines de machine learning reflètent de manière cohérente les données les plus récentes sans dépendre de Jobs de longue durée ou de fenêtres de maintenance, grâce à l'analytique en streaming.

L'importance du CDC pour l'architecture de données moderne

Les écosystèmes de données modernes dépendent d'informations précises et opportunes circulant entre les systèmes opérationnels, les plateformes d'analytique et les pipelines de machine learning. Dans des environnements tels que l'e-commerce, la banque ou la logistique, les données changent constamment à mesure que de nouvelles données sont créées par des actions comme des achats, des mises à jour de profil ou des ajustements de stock. Sans le CDC, ces mises à jour restent isolées dans les systèmes sources jusqu'à la prochaine tâche ETL batch, ce qui peut obliger les tableaux de bord, les rapports et les modèles à s'appuyer sur des datasets obsolètes.

Le CDC résout ce problème en permettant une synchronisation en temps réel, garantissant que tous les systèmes connectés restent alignés sur la même source unique de vérité.

Ce processus prend également en charge les migrations sans interruption, qui sont un élément clé de la modernisation du cloud. Au lieu de geler les écritures ou d'effectuer des basculements risqués, le CDC réplique en continu les changements entre les anciens et les nouveaux systèmes afin de permettre des migrations transparentes.

CDC et ETL traditionnel : principales différences

Bien que les pipelines ETL traditionnels restent essentiels pour de nombreuses charges de travail analytiques, leur fonctionnement est très différent de celui du CDC. L'ETL déplace généralement les données par lots planifiés, par exemple toutes les heures, toutes les nuits ou à un autre intervalle fixe. Chaque exécution extrait des données du système source, les transforme et les recharge dans des plateformes en aval optimisées par Databricks Data Engineering. Ce modèle est prévisible, mais il peut introduire de la latence et exiger que le système analyse des tables entières ou de grandes partitions, même si seule une petite partie des enregistrements a changé.

En capturant les changements au moment où ils se produisent, le CDC élimine le décalage entre le moment où les données changent dans le système source et celui où elles deviennent disponibles pour l'analytique ou les opérations.

L'importance du CDC devient encore plus évidente lorsque l'on compare la manière dont le CDC et l'ETL gèrent le mouvement des données. Alors que l'ETL traditionnel repose souvent sur des analyses de tables complètes ou des rechargements en masse, le CDC ne transmet que les changements incrémentiels. Cela réduit considérablement le compute et améliore l'efficacité globale de votre pipeline de données.

L'ETL par batch dépend également des fenêtres de maintenance pour garantir des lectures cohérentes. La CDC supprime cette dépendance en capturant les changements sans interrompre l'activité normale de la base de données. La CDC est donc une solution idéale pour les systèmes qui nécessitent des données très à jour, comme les tableaux de bord en temps réel, les moteurs de recommandation ou les analyses opérationnelles. Cependant, l'ETL reste adapté aux remplissages historiques volumineux ou aux transformations périodiques, et ensemble, la CDC et l'ETL peuvent former une stratégie d'ingestion complémentaire dans les architectures modernes.

Le CDC dans les écosystèmes de données modernes

La CDC permet aux données de circuler de manière continue et fiable entre les data warehouse, les lakehouses et les plateformes de streaming. Comme chaque changement est capturé dans l'ordre où il se produit, les tableaux de bord et les applications restent synchronisés avec les systèmes opérationnels. La CDC prend également en charge l'auditabilité et la gouvernance en conservant un enregistrement clair de l'évolution des données, ce qui est une exigence essentielle pour les Secteurs d'activité réglementés tels que la finance et la santé, en particulier lors de la mise en œuvre de stratégies de migration du data warehouse vers le lakehouse.

Méthodes d'implémentation du CDC : comparaison et sélection

CDC vs. SCD : Comprendre la relation

La CDC et la SCD jouent des rôles différents au sein d'un pipeline de données. La CDC est responsable de la détection et de l'extraction des changements au niveau des lignes d'un système source, tandis que la SCD détermine comment ces changements sont stockés dans le système cible.

Lorsque le CDC identifie un changement, tel qu'un client qui met à jour son adresse, le SCD de type 1 écrase l'enregistrement existant car les valeurs historiques ne sont pas nécessaires. Le SCD de type 2 crée plutôt un nouvel enregistrement versionné avec des horodatages de début et de fin pour préserver l'historique complet. En d'autres termes, le CDC fournit les événements de changement incrémentiels ; le SCD applique les règles qui déterminent la manière dont ces événements sont représentés, soit sous forme d'instantanés de l'état actuel, soit sous forme de chronologies historiques.

Les organisations peuvent mettre en œuvre le CDC de plusieurs manières, en fonction des performances de leur système, de sa complexité et de leurs besoins métier. Les méthodes les plus courantes que les organisations exploitent détectent les changements différemment.

CDC basé sur les journaux : ce processus lit directement les journaux de transactions de la base de données, tels que le binlog MySQL, le WAL PostgreSQL ou les journaux redo d'Oracle. Parce qu'il fonctionne au niveau de la base de données au lieu d'interroger des tables actives, il minimise l'impact sur les systèmes de production tout en capturant toutes les insertions, mises à jour et suppressions en temps réel. Des frameworks comme Debezium et l'intégration d'Apache Kafka utilisent cette méthode pour fournir des flux de données fiables et à haut volume.

CDC basé sur des Triggers : cette méthode utilise des Triggers de base de données ou des procédures stockées pour enregistrer les changements dans des tables de suivi. Bien qu'elle introduise une légère surcharge d'écriture, elle offre un contrôle précis et peut inclure une logique ou des transformations personnalisées, ce qui peut être utile pour les charges de travail réglementées.

CDC basée sur les requêtes : cette méthode identifie les enregistrements modifiés à l'aide de Timestamps ou de numéros de version. Elle est simple et fonctionne bien pour les systèmes plus petits ou hérités, mais elle peut manquer des suppressions et être moins efficace pour monter en charge.

Une fois les changements capturés par le système, les modèles de dimensions à variation lente (SCD) définissent la manière dont ils sont appliqués. Cela peut se produire de deux manières différentes :

Le SCD de type 1 écrase les enregistrements existants pour ne conserver que la version la plus récente. C'est idéal pour les corrections ou les mises à jour non critiques, comme la correction d'un nom de client mal orthographié ou la mise à jour de l'adresse e-mail d'un utilisateur. Dans les pipelines déclaratifs Spark, cela peut être configuré avec seulement quelques lignes de code, tandis que Lakeflow gère automatiquement le séquençage, les dépendances et les événements désordonnés.

Le SCD de type 2 préserve l'historique complet avec une gestion automatique des colonnes _START_AT et _END_AT, prenant en charge les audits et les analyses temporelles avec les transactions ACID de Delta Lake, garantissant que les états passés restent disponibles pour l'analyse. Ceci est idéal pour des tâches telles que le suivi de l'adresse d'un client au fil du temps, le monitoring des changements de prix des produits ou la conservation de pistes d'audit à des fins de conformité.

En combinant les méthodes CDC avec les pipelines déclaratifs Spark, les utilisateurs peuvent créer des pipelines CDC prêts pour la production et à faible maintenance, qui montent en charge à travers les environnements de traitement par lots et de streaming.

Implémentation du CDC : déploiement étape par étape

Une CDC efficace démarre par la planification et la préparation. Tout d'abord, évaluez les exigences de votre entreprise et de votre système pour des éléments tels que le volume de données, la tolérance à la latence et la fréquence des mises à jour. Les systèmes à haut débit peuvent nécessiter une ingestion en streaming, tandis que les sources à évolution plus lente peuvent s'appuyer sur des mises à jour périodiques. Ensuite, confirmez l'accès au système source et les autorisations pour garantir la possibilité de lire les logs de transactions ou les snapshots. Enfin, concevez des schémas cibles capables de stocker à la fois les données actuelles et historiques à l'aide de stratégies de partitionnement ou de gestion des versions.

Databricks simplifie la CDC grâce aux pipelines déclaratifs Lakeflow, qui assurent un traitement des données évolutif et incrémentiel, incluant une couche de stockage conforme aux normes ACID avec Delta Lake, permettant à une seule copie des données de servir à la fois les charges de travail par lots et en streaming pour plus de cohérence et des économies de coûts.

Lakeflow s'appuie sur cela avec les API AUTO CDC, qui gèrent automatiquement le séquençage, résolvent les enregistrements désordonnés et maintiennent la cohérence du schéma. Les utilisateurs peuvent séquencer les données par timestamp, ID ou clé composite pour un classement déterministe.

Pour les systèmes sans flux de modifications natifs, AUTO CDC FROM SNAPSHOT compare des snapshots consécutifs – tels que des tables ou des exportations d'Oracle et de MySQL – pour détecter efficacement les changements.

Comparé aux méthodes manuelles comme MERGE INTO ou foreachBatch, AUTO CDC est une alternative low-code avec une prise en charge intégrée des opérations DELETE et TRUNCATE fournie par Databricks Lakeflow Connect. Intégrés aux tables Delta, ces pipelines peuvent diffuser les mises à jour en streaming vers Kafka, Iceberg ou des data warehouses, prenant ainsi en charge divers cas d'utilisation d'analytique et de streaming.

Ensemble, Delta Lake et Lakeflow rendent la CDC déclarative, fiable et prête pour la production, s'alignant sur la vision du lakehouse de Databricks pour une analytique unifiée en temps réel.

Mise en œuvre du CDC spécifique à la plateforme

Le comportement du CDC varie selon les bases de données sources :

SQL Server : les fonctionnalités CDC natives de SQL Server capturent automatiquement les insertions, les mises à jour et les suppressions d'une table source dans des tables de modifications dédiées au sein de la base de données. Ces tables incluent des métadonnées telles que le type d'opération et le timestamp du commit, ce qui facilite la détermination des lignes qui ont été modifiées dans un intervalle donné. SQL Server fournit également des contrôles de rétention pour empêcher une croissance illimitée tout en garantissant que les systèmes en aval disposent de suffisamment de temps pour lire les événements capturés. Les organisations peuvent tirer parti des stratégies de migration de SQL Server vers Databricks pour moderniser leur infrastructure de données.

Oracle : Oracle permet la CDC grâce à des technologies telles que LogMiner et GoldenGate, qui lisent les logs pour détecter les changements validés sans impacter la charge de travail source. Ces outils permettent une réplication à haut volume et à faible latence, et les équipes peuvent suivre les meilleures pratiques de migration d'Oracle vers Databricks pour une mise en œuvre réussie.

MySQL : MySQL expose les événements de changement via son journal binaire, permettant aux outils de CDC de consommer efficacement les mises à jour au niveau des lignes.

PostgreSQL : PostgreSQL utilise son journal WAL (Write-Ahead Log) pour permettre le décodage logique, qui fait remonter les événements de changement que les consommateurs en aval peuvent traiter.

Sur toutes les plateformes, le modèle est cohérent : la base de données source écrit les changements dans les logs ou les tables de changements, et les outils CDC extraient ces événements pour alimenter les pipelines en aval.

Optimisation du CDC : performances et qualité des données

Une fois en cours d'exécution, les pipelines CDC doivent être optimisés en termes de performance, de qualité et de résilience. Une gestion rigoureuse de la qualité des données garantit la fiabilité des pipelines.

Cela start avec la parallélisation et le partitionnement, qui divisent les données par région, date ou clé pour traiter plusieurs Streams en parallèle. L'ajustement de la taille des batches et de l'allocation des Ressources aide à mieux équilibrer la latence et le coût ; par exemple, des batches plus petits réduisent le décalage tandis que des batches plus grands améliorent le throughput.

Lors du déplacement de données entre plusieurs systèmes, la CDC garantit la cohérence entre les systèmes cibles sans la surcharge gourmande en ressources d'une réplication complète. En ne traitant que les changements provenant des systèmes sources, vous maintenez une faible latence pour les consommateurs en aval tout en garantissant que les applications en aval reçoivent des données à jour pour les décisions urgentes.

En monitoring régulier des métriques clés telles que la latence des commits et le nombre d'échecs, les utilisateurs peuvent détecter les problèmes de performance à un stade précoce. De plus, des politiques de rétention bien définies empêchent la croissance inutile des tables de changements, et l'évolution automatisée des schémas maintient la compatibilité à mesure que les structures sources se modifient. Les validations Databricks intégrées confirment que les mises à jour respectent les exigences du schéma, tandis que les pistes d'audit suivent chaque insertion, mise à jour et suppression pour plus de transparence.

Bien sûr, le travail avec les données présente de multiples défis, tels que des mises à jour multiples au sein d'un seul microlot. Pour résoudre ce problème et garantir l'exactitude, Databricks regroupe les enregistrements par clé primaire et n'applique que le dernier changement à l'aide d'une colonne de séquençage. Les mises à jour désordonnées sont gérées par un séquençage déterministe, et les modèles de suppression douce (soft-delete) marquent les enregistrements comme inactifs avant que les Jobs de nettoyage ne les suppriment plus tard. Ces stratégies préservent l'intégrité des données sans interrompre les opérations.

Cas d'utilisation avancés et considérations futures

La CDC va au-delà de la simple réplication. Les organisations utilisent la CDC pour connecter plusieurs systèmes et clouds, synchroniser des environnements distribués et alimenter l'analytique en temps réel. Parce que la CDC préserve l'ordre des événements, elle maintient un état cohérent sur les différentes plateformes sans lourdes tâches de traitement par lots.

Le CDC prend également en charge les pipelines de caractéristiques de machine learning en fournissant des mises à jour continues qui maintiennent l'alignement entre l'entraînement et l'inférence, réduisant ainsi l'asymétrie online/offline. Les Magasins de fonctionnalités, tels que le Databricks Feature Store, s'appuient sur les données CDC pour des recherches précises et tenant compte du temps, ce qui permet une ingénierie des fonctionnalités avancée pour le machine learning.

À mesure que les architectures évoluent, l'automatisation via les tâches Lakeflow et les pipelines déclaratifs Spark simplifie l'orchestration et la surveillance. La CDC Serverless réduit la surcharge opérationnelle, les formats de table ouverts comme Delta et Iceberg augmentent la flexibilité, et les conceptions événementielles utilisent la CDC comme colonne vertébrale pour un mouvement de données rapide et fiable.

CDC et streaming d'événements : la connexion Kafka

Comme nous l'avons vu avec le CDC et le SCD, le CDC et Apache Kafka traitent différentes parties du pipeline de déplacement de données, mais ils sont très complémentaires. Tandis que le CDC capture les nouvelles données, Kafka est une plateforme de streaming distribuée conçue pour transporter et traiter des données d'événements à grande échelle grâce à ses capacités de plateforme de streaming de données. Les deux sont souvent utilisés ensemble dans un pipeline de données.

Dans une architecture typique, un outil de CDC basé sur les logs tel que Debezium lit les événements de changement directement depuis les logs de transactions de la base de données. Au lieu d'écrire immédiatement ces événements dans une table cible, Debezium les publie dans des rubriques Kafka, où ils deviennent partie intégrante d'un flux d'événements durable. Kafka Connect fournit la couche d'intégration qui rend cela possible, permettant à des sources comme MySQL, PostgreSQL ou SQL Server d'alimenter Kafka avec de nouvelles données sans code personnalisé. Une fois les événements CDC dans Kafka, d'autres systèmes, tels que les data warehouses ou les lakehouses, stockent les données les plus récentes au fur et à mesure de leur arrivée.

De plus, les services peuvent s'abonner aux événements de changement plutôt que d'interroger la base de données de manière répétée, ce qui réduit la latence et améliore l'évolutivité. Comme le CDC garantit que les données les plus récentes entrent dans Kafka dès leur génération, les processus en aval opèrent toujours sur des information actuelles, qu'il s'agisse de mettre à jour des vues matérialisées, de déclencher des workflows ou d'effectuer de l'analytique en temps réel. De cette manière, la CDC fournit les événements de changement, et Kafka agit comme le système qui distribue efficacement ces événements à travers l'écosystème de données de l'organisation.

FAQ

Questions fréquentes sur le Change Data Capture

Qu'est-ce que le processus CDC dans l'ETL ?

Le CDC est le mécanisme qui identifie et ne fournit que les lignes qui ont changé depuis la dernière extraction. Au lieu d'analyser ou de recharger des tables entières, le CDC capture les insertions, les mises à jour et les suppressions directement depuis le système source et les envoie en aval sous forme d'événements incrémentiels. Cela permet aux étapes de transformation et de chargement de s'exécuter en continu plutôt qu'à des intervalles de batch fixes. À mesure que chaque nouvel événement circule dans le pipeline, il est validé, transformé et appliqué au système cible en quasi-temps réel.

Quelle est la différence entre l'ETL et la CDC ?

L'ETL est un large flux de travail de données qui extrait des données des systèmes sources, les transforme pour assurer leur cohérence et les charge dans des data warehouse ou des lakehouses en aval. L'ETL traditionnel repose souvent sur le traitement par batch, où des tables complètes ou de grandes partitions sont déplacées à des intervalles programmés. La CDC se concentre plutôt sur l'identification et la transmission uniquement des changements qui se produisent entre les cycles ETL. La CDC ne remplace pas l'ETL, mais l'améliore en rendant l'étape d'extraction incrémentielle et continue. Cela réduit le compute overhead, élimine la dépendance vis-à-vis des fenêtres batch et garantit que les systèmes en aval reçoivent les mises à jour en temps opportun sans rechargement complet.

Quelle est la différence entre le CDC et le SCD ?

Le CDC et le SCD fonctionnent à différents niveaux d'un pipeline de données. Le CDC capture les changements du système source, tandis que le SCD est un modèle de modélisation qui détermine comment ces changements capturés doivent être stockés dans le système cible. Par exemple, lorsque le CDC détecte une mise à jour, le SCD de type 1 écrase l'enregistrement existant, tandis que le SCD de type 2 ajoute une nouvelle ligne versionnée avec des horodatages de début et de fin pour conserver l'historique complet.

Quelle est la différence entre la CDC et Kafka ?

La CDC et Kafka ont des objectifs complémentaires. La CDC est la technique utilisée pour capturer les changements au niveau des lignes à partir des bases de données sources, tandis que Kafka est une plateforme de streaming d'événements distribuée conçue pour stocker, transporter et traiter ces événements à grande échelle. Dans de nombreuses architectures modernes, les outils de CDC comme Debezium utilisent la capture basée sur les journaux pour détecter les nouvelles données dans le système source, puis publient les événements qui en résultent dans des topics Kafka. À partir de là, les applications, services ou plateformes de données en aval consomment les données les plus récentes en temps réel.

Conclusion

Le Change Data Capture est devenu une capacité essentielle pour les équipes de données modernes. Qu'il s'agisse d'alimenter des tableaux de bord en temps réel, des modèles de machine learning ou de permettre des migrations de données fluides grâce à la modernisation des entrepôts de données cloud et à l'architecture lakehouse, la CDC aide à maintenir les systèmes alignés et les données fiables, avec une synchronisation des données en temps réel.

Le succès de ce processus dépend d'une conception réfléchie : sélectionnez la bonne méthode, planifiez la montée en charge et surveillez la qualité. À partir de là, évaluez comment ces principes s'intègrent à votre architecture, commencez modestement avec une preuve de concept, puis affinez au fur et à mesure de votre croissance. Avec la bonne approche, le CDC dépasse le statut de simple tâche de pipeline pour devenir un avantage commercial durable.

Vous voulez plus de conseils et de bonnes pratiques pour l'ingénierie des données moderne ? Obtenez la boîte à outils Data Engineering, une sélection de Ressources pour des pipelines de données fiables.