À mesure que la transformation numérique touche de plus en plus d’industries, le nombre de points de données générés augmente de façon exponentielle. En tant que telles, les stratégies d’intégration de données pour collecter de tels volumes de données provenant de différentes sources dans des formats et des structures variés sont désormais une préoccupation majeure pour les équipes d’ingénierie des données. Les approches traditionnelles de l’intégration de données, qui se sont largement concentrées sur la conservation de données hautement structurées dans des entrepôts de données, ont du mal à gérer le volume et l’hétérogénéité des nouveaux ensembles de données.
Les données de séries chronologiques présentent une couche supplémentaire de complexité. Par nature, la valeur de chaque point de données de série chronologique diminue avec le temps, car la granularité des données perd de sa pertinence à mesure qu’elle devient obsolète. Il est donc crucial que les équipes planifient soigneusement les stratégies d’intégration des données dans les bases de données de séries chronologiques (TSDB) pour s’assurer que l’analyse reflète les tendances et la situation en temps quasi réel.
Dans cet article, nous examinerons certaines des approches les plus populaires de l’intégration de données pour les TSDB :
Étant donné le besoin d’informations en temps réel pour les données de séries chronologiques, la plupart des architectures modernes pilotées par les événements implémentent désormais le streaming de données avec CDC. Pour illustrer comment cela fonctionne dans la pratique, nous allons parcourir une implémentation de référence avec QuestDB (une TSDB rapide) pour montrer que CDC peut gérer avec souplesse les besoins d’une source de données de séries chronologiques.
Extraire, Transformer, Charger (ETL)
ETL est une stratégie d’intégration de données traditionnelle et populaire qui consiste d’abord à transformer les données en une structure prédéterminée avant de charger les données dans le système cible (généralement un entrepôt de données).
Image par l’auteur
L’un des principaux avantages d’ETL est qu’il offre le plus haut degré de personnalisation. Étant donné que les données sont d’abord extraites vers une zone intermédiaire où elles sont transformées en un format propre et standardisé, les systèmes ETL peuvent gérer un large éventail de formats et de structures. De plus, une fois les données chargées dans l’entrepôt de données, les équipes de science des données peuvent exécuter des requêtes et des analyses efficaces. Enfin, compte tenu de la maturité de l’écosystème ETL, il existe une pléthore d’outils d’entreprise parmi lesquels choisir.
D’un autre côté, ETL est à la fois gourmand en temps et en ressources à maintenir. La logique de nettoyage et de transformation des données peut être complexe et coûteuse en calculs. C’est pourquoi la plupart des systèmes ETL sont généralement orientés par lots, ne chargeant les données que périodiquement dans l’entrepôt. À mesure que le volume de données et les sources de données augmentent, cela peut devenir un goulot d’étranglement.
Compte tenu de ces qualités, les systèmes ETL sont les plus utilisés pour les ensembles de données qui nécessitent une logique de transformation complexe avant l’analyse. Cela peut également bien fonctionner pour les ensembles de données qui ne nécessitent pas d’informations en temps réel et peuvent être stockés pour une analyse des tendances à long terme.
Extraire, Charger, Transformer (ELT)
ELT, comme son nom l’indique, charge d’abord les données dans le système cible (généralement un lac de données) et effectue la transformation au sein du système lui-même. Compte tenu des responsabilités du système cible pour gérer à la fois les charges rapides et les transformations, les pipelines ELT exploitent généralement des lacs de données modernes basés sur le cloud qui peuvent gérer les exigences de traitement.
Image par l’auteur
Par rapport aux pipelines ETL, les systèmes ELT peuvent fournir une analyse plus en temps réel des données puisque les données brutes sont ingérées et transformées à la volée. La plupart des lacs de données basés sur le cloud fournissent des SDK ou des points de terminaison pour ingérer efficacement des données en micro-lots et fournir une évolutivité presque illimitée. Cependant, l’ELT n’est pas sans inconvénients. Étant donné que la transformation est effectuée par le système cible, ces opérations sont limitées par les capacités prises en charge par les lacs de données. Si vous avez besoin d’une logique de transformation plus complexe, des étapes supplémentaires peuvent être nécessaires pour réextraire les données et les stocker dans un format plus convivial.
Dans la plupart des cas d’utilisation, ELT est une stratégie d’intégration de données plus efficace qu’ETL. Si votre application peut tirer parti d’outils basés sur le cloud et ne nécessite pas de traitement complexe, ELT peut être un excellent choix pour gérer de grandes quantités de données en temps quasi réel.
Modification de la capture de données (CDC)
Pour les nouveaux projets, les équipes peuvent prévoir d’utiliser les TSDB comme l’un des systèmes cibles dans un pipeline ETL ou ELT. Cependant, pour les projets existants, la migration vers ou l’ajout d’une TSDB dans le mix peut être un défi. D’une part, il peut être nécessaire de modifier ou d’utiliser un nouveau pilote/SDK pour diffuser des données dans la TSDB. Même si les mêmes pilotes sont pris en charge, les formats de données peuvent également devoir changer pour tirer pleinement parti des fonctionnalités de TSDB. Les outils du CDC peuvent être utiles pour combler cette lacune.
CDC est simple dans son principe : les outils CDC tels que Debezium surveillent en permanence les changements dans le système source et informent votre pipeline de données chaque fois qu’il y a un changement. L’application à l’origine du changement n’est souvent même pas consciente qu’un processus CDC écoute les changements. Cela fait de CDC un bon choix pour intégrer de nouveaux pipelines de données en temps réel dans des architectures existantes, car cela nécessite peu ou pas de modifications dans les applications existantes. En tant que tel, CDC peut être utilisé en conjonction avec des pipelines ETL ou ELT. Par exemple, le système source peut être un SGBDR SQL (par exemple, MySQL, PostgreSQL, etc.) ou une base de données NoSQL (par exemple, MongoDB, Casandra), et l’un des systèmes cibles peut être un TSDB avec d’autres lacs de données ou entrepôts.
Image par l’auteur
Le principal avantage de l’utilisation de CDC pour l’intégration de données est qu’il fournit une réplication de données en temps réel. Contrairement aux systèmes ETL et ELT traditionnels qui fonctionnent avec des lots, les modifications apportées au système source sont transmises en continu à un ou plusieurs systèmes cibles. Cela peut être utile pour répliquer un sous-ensemble ou l’intégralité des données sur plusieurs bases de données en temps quasi réel. Les bases de données cibles peuvent même se trouver dans différentes régions géographiques ou servir à des fins différentes (par exemple, stockage à long terme ou analyse en temps réel). Pour les données de séries chronologiques où les changements de valeur au fil du temps sont souvent les plus utiles, CDC capture efficacement ce delta pour des informations en temps réel.
Implémentation de référence pour CDC
Pour illustrer plus concrètement le fonctionnement de CDC, prenons l’implémentation de référence sur laquelle j’ai écrit récemment pour diffuser les cours des actions dans QuestDB.
Image par l’auteur
À un niveau élevé, une application Java Spring publie des informations sur le cours des actions dans PostgreSQL. Le connecteur Debezium lit ensuite les modifications depuis PostgreSQL et les publie sur Kafka. De l’autre côté, le connecteur Kafka de QuestDB lit les sujets Kafka et les diffuse sur QuestDB.
Pour une plongée plus profonde, veuillez vous référer à Modifier la capture de données avec QuestDB et Debezium.
Dans cette architecture de référence, l’application Java Spring transforme et charge les données sur PostgreSQL avant qu’elles ne soient répliquées sur TSDB pour une analyse plus approfondie. Si un pipeline plus proche de l’ELT est souhaité, les données brutes d’un autre fournisseur auraient pu être chargées directement sur PostgreSQL et transformées ultérieurement dans QuestDB également.
La chose importante à noter avec cette architecture est que CDC peut s’intégrer de manière transparente aux systèmes existants. Du point de vue de l’application, il peut conserver les garanties transactionnelles de PostgreSQL tout en ajoutant un nouveau composant TSDB dans le pipeline.
Conclusion
L’intégration des données joue un rôle important pour les organisations qui utilisent une TSDB pour stocker et analyser des données de séries chronologiques. Dans cet article, nous avons examiné certains avantages et inconvénients de l’utilisation d’ETL ou d’ELT. Nous avons également examiné comment CDC peut être utilisé conjointement avec ces pipelines pour fournir une réplication en temps réel dans les TSDB.
Compte tenu des qualités particulières des données de séries chronologiques, il est important d’utiliser une TSDB pour les stocker et les analyser correctement. Si vous commencez à zéro, cherchez à créer un pipeline ELT pour diffuser des données dans une TSDB. Pour intégrer un système existant, envisagez d’utiliser les outils CDC pour limiter les perturbations de l’architecture actuelle.