Change Data Capture (CDC)

Aperçu de la fonction CDC

L'alimentation d'entrepôts de données implique l'extraction et la migration de données d'une ou plusieurs bases de données vers un ou plusieurs systèmes afin d'être analysées. Mais ces processus d'extraction et de migration de gros volumes de données sont très coûteux en ressources et en temps.

Ainsi le Change Data Capture (CDC) permet de ne capturer que les changements effectués aux données source et de les envoyer en temps réel vers un ou plusieurs systèmes cible. Cette fonction de capture de données réduit le trafic de données sur le réseau et, ainsi, réduit le temps de traitement ETL.

Le CDC utilisé dans le Studio Talend simplifie le processus d'identification des changements apportés aux données depuis la dernière extraction. Le CDC dans le Studio Talend identifie rapidement et capture les données qui ont été ajoutées, mises à jour ou supprimées des tables des bases de données, notamment : Oracle, MySQL, DB2, PostgreSQL, Sybase, MS SQL Server, Informix, Ingres, Teradata et AS/400, et les met à disposition pour une utilisation future par des applications ou des personnes.

Dans le Studio Talend, il existe trois modes de captures (CDC) différents :

• Trigger : ce mode est le mode utilisé par défaut dans les composants CDC.

• Redo/Archive log : ce mode est uniquement disponible pour les bases de données Oracle et AS/400.

• XStream : ce mode est utilisé uniquement avec Oracle 12 avec OCI.

Pour plus d'informations concernant ces trois modes, consultez les trois sections suivantes.

Mode Trigger

Le mode Trigger est disponible pour les bases de données suivantes : Oracle, MySQL, DB2, PostgreSQL, Sybase, MS SQL Server, Informix, Ingres et Teradata.

Ce mode place un trigger (ou déclencheur) déclenchant la capture des deltas sur chaque table source monitorée. La mise en place de ces triggers nécessite de légères modifications dans la structure de la base de données.

Avec ce mode, l'extraction de données se fait en même temps que l'insertion, la mise à jour et la suppression des données dans les tables d'une base de données et les données modifiées sont stockées dans les tables de changements de cette même base de données. Les données modifiées et capturées jusqu'à présent sont mises à disposition pour le(s) système(s) cible de manière limitée à l'aide d'une souscription.

Le CDC crée des tables de souscription pour contrôler l'accès aux données des tables de changements par le(s) système(s) cible puisque le système CDC en mode Trigger ne peut avoir qu'un seul éditeur mais plusieurs souscripteurs. Le CDC crée des tables de souscription pour contrôler l’accessibilité des données de la table des modifications par le(s) système(s) cible. Un système cible peut correspondre à n'importe quelle application souhaitant utiliser les données capturées du système source.

Le schéma ci-dessous vous montre les notions de base d'un environnement CDC en mode Trigger dans le Studio Talend.

Dans cet exemple, le CDC surveille les changements effectués sur une table Produit. Les deltas sont récupérés et publiés dans la table des changements, à laquelle deux souscripteurs ont accès : une application CRM et une application Accounting. Ces deux systèmes cible récupèrent les deltas et les utilisent pour mettre à jour leurs données.

Mode CDC Redo log

Le mode Redo/Archive log est uniquement disponible pour les bases de données AS/400 et Oracle Enterprise Editions v11. C'est l'équivalent du mode archive log d'Oracle et du mode journal d'AS/400.

Dans une base de données Oracle, un fichier Redo log est un fichier journal historisant les changements apportés à cette base. Dans l'environnement AS/400, les changements sont automatiquement historisés dans le journal interne à la base de données AS/400. Ces changements correspondent aux opérations d'insertion, de mise à jour et de suppression effectuées sur les données.

Le mode Redo/Archive log sont moins intrusifs que le mode Trigger, car, contrairement au mode Trigger, il ne nécessite pas de modifications dans la structure de la base de données.

Avec le mode Redo/Archive log d'Oracle, un seul souscripteur peut avoir accès à la table des changements et ce souscripteur est un utilisateur ou une utilisatrice de la base de données ayant les droits de souscription. Ce souscripteur est un utilisateur ou une utilisatrice de la base de données ayant les droits de souscription. De plus, la table de souscription, contrôlant l'accès aux données des tables des changements au souscripteur. La table des changements de souscription est une table interne globale à l'instance de la base de données Oracle créée lors de l'activation de l'option Redo/Archive log dans la base de données Oracle.

Lors de la mise en place de ce mode dans AS/400, un fichier savf appelé fitcdc.savf et fourni dans votre Studio Talend est restauré dans l'AS/400 et utilisé pour installer un programme appelé RUNCDC. Lorsque le souscripteur va prévisualiser (View all changes) ou consommer (à l'aide du composant tAS400CDC) ces changements afin de les réutiliser, le programme RUNCDC va lire et analyser ce journal et le récepteur attaché depuis la table source et mettre à jour la table des changements en conséquence. Le mode CDC Redo/Archive log (journal) d'AS/400 crée des tables de souscription pour contrôler l'accès aux données des tables des changements par le·s système·s cible·s. Un système cible peut correspondre à n'importe quelle application souhaitant utiliser les données capturées du système source.

Dans cet exemple, le CDC surveille les changements effectués sur une table Produit grâce aux données de log contenues dans les fichiers journaux de la base de données. Le CDC lit ces journaux et capture les changements apportés aux données. Ces deltas sont récupérés et publiés dans la table des changements, et deux souscripteurs, une application CRM et une application Accounting, ont accès à ces données. Ces deux systèmes cible récupèrent les deltas et les utilisent pour mettre à jour leurs données.

Mode XStream

XStream fournit un framework de partage de modifications de données en temps réel, avec des performances et une utilisabilité exceptionnelles, entre des bases de données Oracle et d'autres systèmes tels que des bases de données non-Oracle et des applications tierces. XStream comprend deux fonctionnalités majeures : XStream Out et XStream In.

XStream Out fournit des composants de base de données Oracle et des interfaces de programmation qui vous permettent de partager des modifications de données d'une base de données Oracle avec d'autres systèmes. Il fournit également une interface de transactions pour diffuser les changements capturés depuis le log Redo d'une base de données Oracle à des applications client avec un serveur de sortie. Un serveur de sortie est un processus d'arrière-plan Oracle optionnel qui envoie des modifications de données à une application client.

XStream In fournit des composants de base de données Oracle et des interfaces de programmation qui vous permettent de partager des modifications de données d'autres systèmes avec une base de données Oracle. Il fournit également une interface de transactions pour envoyer des informations à une base de données Oracle depuis des applications client avec un serveur d'entrée. Une serveur d'entrée est un processus d'arrière-plan Oracle optionnel qui reçoit des modifications de données provenant d'une application client.

Le mode XStream est uniquement disponible avec Oracle 12 avec OCI dans le Studio Talend. Pour plus d'informations concernant le mode XStream, consultez Database XStream Guide (en anglais).