Stratégies d'intégration et de synchronisation des données dans les produits de données

Au fil des ans, de nombreuses approches différentes ont été créées pour déplacer et fusionner des données qui soutiennent les processus métier et la prise de décision. Chacune d'entre elles possède ses propres capacités et avantages. Il est essentiel de comprendre ces capacités et la manière dont elles sont liées au résultat souhaité de votre stratégie de données pour concevoir un système optimal.

Plusieurs variables et exigences doivent être prises en compte lors de l'élaboration d'une stratégie visant à maintenir toutes vos données optimisées, accessibles et intégrées, notamment :

• Dans quel délai avez-vous besoin de données actualisées ?
• Quelles sont vos contraintes de bande passante et de stockage ?
• Quels types de ressources techniques sont disponibles ?
• Combien de copies des mêmes données devez-vous conserver ?
• Quelle est la taille de vos ensembles de données ?

Traitement par lots

Le traitement par lots transfère les données à intervalles réguliers ou par lots. Ces modèles incluent les outils Extract Transform Load (ETL), Extract Load Transform (ELT), Reverse ETL, Mirroring ou Replication et Write-back.

Formation continue et perfectionnement (FLE) et formation continue (ELT)

L'ETL est l'approche traditionnelle du transfert de données. Les données sont extraites d'une source de données, transformées en fonction de règles métier et chargées dans une base de données cible. Cette approche peut être très sûre mais également peu flexible. Cette rigidité nécessite que les ensembles de données soient très structurés et documentés, ce qui facilite les transformations complexes. Les bases de données des systèmes hérités étant généralement très structurées et rigides, l'ETL est une bonne solution pour ces systèmes. Pour créer ces processus, les développeurs doivent avoir une connaissance approfondie de la structure des données et des langages de programmation.

L'ELT est similaire à l'ETL, mais la transformation intervient après le chargement dans la base de données cible. Cette approche plus contemporaine permet une plus grande flexibilité car les données brutes restent dans la base de données cible après leur transformation. Par conséquent, les transformations peuvent être exécutées de manière itérative ou rétroactive sans extraire les données de la source de données d'origine, réduisant ainsi les ressources nécessaires à l'extraction d'un nouvel ensemble de données. L'ELT est plus adapté aux ensembles de données plus étendus et moins structurés où le traitement et les transformations des données peuvent être exécutés plus près de l'utilisateur final.

ETL inversé

L'ETL inversé est un autre processus par lots, mais les données circulent dans la direction opposée d'un pipeline ETL. Les données sont extraites d'une application tierce opérationnelle et chargées dans une base de données centrale. Cette approche permet à une organisation de consolider une version d'un ensemble de données dans un entrepôt central et permet aux applications opérationnelles d'utiliser les mêmes données que celles que d'autres applications ou analyses peuvent utiliser. L'ETL inversé prend en charge une « source unique de vérité » pour l'organisation.

Le défi est que Reverse ETL fonctionne par lots. Dans les organisations dynamiques où les données changent constamment, des groupes distincts peuvent utiliser différentes versions des mêmes données en raison de calendriers de mise à jour différents. Les stratégies de synchronisation Reverse ETL peuvent également surcharger les systèmes opérationnels, car de grandes quantités de données sont chargées dans les systèmes opérationnels à partir de plusieurs sources. Cela peut entraîner des conflits et des versions de données identiques.

Mise en miroir et réplication

La mise en miroir et la réplication enregistrent les données dans une base de données distincte sans aucune transformation et sont souvent mises en œuvre pour sauvegarder des ensembles de données en cas de perte de données. Elles peuvent également s'avérer utiles pour optimiser la gestion des données et créer un ensemble de données persistant lorsque les données sont en mouvement. La mise en miroir réplique non seulement les données, mais également l'ensemble de la structure de la base de données et du système de gestion.

La réplication est légèrement différente de la mise en miroir car elle ne copie pas le système de gestion de base de données, mais uniquement les données. L'accès aux données de différents systèmes est beaucoup plus facile avec la réplication, car le système de gestion de base de données ne les définit pas.

La mise en miroir est une meilleure option pour équilibrer la charge. Les bases de données source et copiées sont identiques, ce qui permet d'accéder facilement aux données à partir de l'une ou l'autre source. La reprise après sinistre et l'optimisation de l'utilisation des ressources sont des cas d'utilisation courants de la mise en miroir. Elle convient également pour capturer un instantané des données en mouvement. Par exemple, les données virtualisées utilisées régulièrement peuvent être mises en miroir dans un magasin de données persistant.

En temps réel

L'intégration et la gestion des données en temps réel engendrent de nombreuses complexités, notamment lors de la fusion de divers ensembles de données. Les différents ensembles de données étant en constante évolution, des écarts entre les données sources et les données fusionnées existeront toujours. Les données en temps réel sont plus applicables aux systèmes opérationnels de suivi des capteurs ou des données financières.

Capture des données modifiées (CDC)

CDC est un modèle basé sur les événements dans lequel les modifications apportées à une base de données sont automatiquement répercutées dans une autre lorsque des événements définis se produisent. Ce modèle prend en charge les flux de données bidirectionnels afin que les bases de données source et cible puissent échanger des données pour garantir la synchronisation. CDC est un moyen beaucoup plus efficace de déplacer des données que ETL, car seules les données modifiées sont transférées vers la base de données cible, et non l'ensemble de données.

CDC fonctionne bien avec les bases de données ou les applications qui ne peuvent pas être intégrées. Les processus CDC peuvent organiser les données dans une base de données distincte, et les modifications peuvent ensuite être partagées à partir des données organisées vers les bases de données cibles. Cette méthode nécessite de conserver une source de données dynamique distincte, ce qui crée une complexité excessive et entraîne un risque d'erreur plus élevé.

Données en streaming

Le streaming de données implique une ingestion, un traitement et un déplacement constants des données vers leur destination. En général, il s'agit de données de capteurs de services financiers. Dans de nombreux cas, le streaming est transformé en route vers sa base de données cible.

Bien que le streaming de données soit rapide, il présente quelques inconvénients. Les données en streaming se déplacent constamment et empruntent des chemins différents sur Internet, ce qui ne garantit pas que les données sont traitées dans le bon ordre. Certaines données peuvent arriver pour être traitées après des données plus récentes, ce qui crée une confusion quant aux données les plus précises. Une orchestration appropriée doit être mise en œuvre pour garantir que les données sont traitées dans l'ordre approprié.

La diffusion de données en continu expose également le modèle de données de la source de données aux utilisateurs en aval. Lorsque les applications en aval sont connectées directement au modèle de données source, les modifications apportées à ce modèle provoquent des ravages en aval.

Si les données en streaming sont empaquetées dans un produit de données, les modèles de données sources internes peuvent être mappés au modèle de données d'un produit de données. Cette structure facilite le partage des données avec des groupes externes.

Capacités d'écriture différée

Les fonctionnalités d'écriture différée des outils BI front-end constituent une autre méthode permettant d'apporter des modifications à une base de données source. Ce modèle émergent permet aux analystes travaillant avec des outils BI d'inclure des modifications dans la base de données source directement à partir de l'outil BI. Ces modifications sont immédiatement répercutées dans la source de données et dans le travail des analystes. Cela permet à l'analyste qui a la meilleure compréhension des données d'ajuster ou de corriger la source de données d'origine.

Les capacités d'écriture différée réduisent également la dépendance des analystes de données vis-à-vis des feuilles de calcul Excel, car ils ont désormais la possibilité de mettre à jour une base de données aussi rapidement qu'ils le peuvent avec Excel.

Intégration d'applications

Les applications SaaS partagent généralement des données via des API REST. Il s'agit de processus simples permettant d'extraire des données d'une base de données d'application. À elles seules, les API ne peuvent pas transformer les données, mais si elles sont exécutées via une plateforme iPaaS, des processus de transformation automatisés peuvent être effectués sur les données avant de les envoyer à l'application cible.

Les API REST fonctionnent bien pour les échanges de données simples entre une ou deux applications, mais ce type d'approche n'est pas très évolutif. Si une application modifie son API, les applications en aval peuvent être interrompues.

Virtualisation des données

La virtualisation des données consiste à exécuter du code qui crée un nouvel ensemble de données virtualisées extraites de bases de données connectées. Ce nouvel ensemble de données est créé à chaque exécution du code, mais les données ne sont conservées que le temps nécessaire. C'est le modèle utilisé par la plateforme Avrio pour générer des ensembles de données à analyser. L'utilisation de cette technologie pour l'intégration des données présente plusieurs avantages :

Tout d'abord, la virtualisation des données sépare la base de données et la structure sous-jacentes des données elles-mêmes. Cela rend la virtualisation des données beaucoup plus évolutive et flexible.

Deuxièmement, la virtualisation des données ne crée pas de copie persistante de la base de données. Comme un nouvel ensemble de données est créé à chaque fois, le code est exécuté et les données les plus récentes sont extraites de la base de données source. Cette approche évite les conflits entre plusieurs versions des mêmes données. Les coûts de stockage peuvent également être minimisés.

Troisièmement, des connecteurs sophistiqués, des moteurs de requête fédérés et la virtualisation peuvent interroger, transformer et fusionner des données provenant de plusieurs bases de données à la fois. Avec un magasin de métadonnées consolidé et un modèle de données unifié superposé, cette approche permet aux analystes de données d'extraire des données de divers magasins de données comme s'il s'agissait d'une seule base de données.

Enfin, la virtualisation des données permet un meilleur contrôle de vos données. Étant donné que les données circulent via cette couche de virtualisation, des contrôles de qualité des données peuvent être effectués et des contrôles d'accès granulaires peuvent être mis en œuvre.

Avrio et les modèles d'intégration de données

Chaque approche d'intégration et de synchronisation présente ses avantages et ses inconvénients. Quelle que soit votre approche, l'attention portée à la gouvernance, à la sécurité et à la qualité des données est primordiale pour une architecture de données saine. L'utilisation d'approches adaptées dans une plateforme consolidée peut donner lieu à une solution puissante et flexible.

Au cœur des fonctionnalités d'Avrio se trouve la virtualisation des données, qui permet d'intégrer les données à analyser afin de créer un nouvel ensemble de données à chaque exécution du code. Lorsque des données persistantes sont requises, mais que des modifications sont régulièrement apportées, Avrio propose également des fonctionnalités CDC qui reproduisent uniquement les modifications de la base de données source dans l'environnement en miroir.

Avrio propose également des fonctionnalités de mise en miroir pour créer des ensembles de données persistants à partir d'ensembles de données virtualisés. Lorsque les données ne changent pas souvent mais sont utilisées régulièrement, la mise en miroir peut réduire l'utilisation des ressources de bande passante.

La plateforme Avrio permet à des tiers d'accéder aux produits de données via une API. Cette couche frontale d'Avrio propose également des fonctionnalités d'écriture différée pour intégrer les modifications apportées dans un outil BI avec la base de données back-end connectée à la plateforme Avrio.

Combiner plusieurs modèles d’intégration et de synchronisation pour obtenir un résultat commercial est une stratégie judicieuse. Chaque situation est différente et nécessite des capacités uniques. La plateforme Avrio combine les technologies et les modèles appropriés pour rendre les données accessibles sur plusieurs silos de données avec des produits de données en libre-service dotés d’une gouvernance et d’une sécurité intégrées, conçus pour l’ère de l’IA, l’analyse rapide et une meilleure prise de décision.

Avrio s'adapte également parfaitement à vos outils et infrastructures d'intégration existants. Si vous diffusez des données vers un lac de données, Avrio peut créer un produit de données pour capturer un instantané des données en streaming à des fins d'analyse. Si vous avez créé des pipelines ETL bien établis et qui ne changent pas beaucoup, Avrio peut incorporer ces données dans un produit de données qui peut les rendre plus accessibles et intégrer des ensembles de données provenant d'autres systèmes.