Architecture Data-Centric de vos données
Performance, scalabilité, budget et sécurité
Les architectures autour des données ont considérablement évolué dans le contexte suivant :
- Le Big Data a voulu résoudre l’impact de l’inflation des volumes, de leur variété et des exigences de vélocité.
- Les hyperscalers ont apporté la notion d’infrastructure en mode service, associée à la scalabilité, synonyme de flexibilité et d’adaptation aux besoins.
- Les éditeurs ont renouvelé leurs offres en mode SaaS.
- La plateformisation a introduit l’idée de regrouper les différentes attentes — analytique, data science, opérationnelle — dans une solution partagée.
- La responsabilisation des acteurs métiers (Data Mesh) impose une gouvernance renouvelée des données : mise en qualité et gestion des accès.
Optimiser le stockage et le compute pour améliorer les performances et réduire le TCO
Rationaliser l’écosystème IT selon les besoins métiers : type d’accès, latence, autonomie, monétisation …
Observabilité, sécurité, personnalisation, Finops : des enjeux transverses qui renouvellent le travail des architectes
Il en résulte une approche Data-centric qui place les données au cœur des processus, des décisions et des stratégies d’une organisation. Lorsqu’elles sont collectées, gérées et analysées, les données offrent des insights précieux qui aident à améliorer les performances, à innover et à se différencier sur le marché.
L’architecture Data-centric doit faciliter le parcours de la donnée entre ingestion, stockage, transformation et restitution. Si le concept et les objectifs sont clairs, les méthodes techniques et les stratégies pour les réaliser diffèrent selon les exigences de volumes, de temporalité, de confidentialité, et, en premier lieu, de types de données.
Il en résulte une approche Data-centric qui place les données au cœur des processus, des décisions et des stratégies d’une organisation. Lorsqu’elles sont collectées, gérées et analysées, les données offrent des insights précieux qui aident à améliorer les performances, à innover et à se différencier sur le marché.
L’architecture Data-centric doit faciliter le parcours de la donnée entre ingestion, stockage, transformation et restitution. Si le concept et les objectifs sont clairs, les méthodes techniques et les stratégies pour les réaliser diffèrent selon les exigences de volumes, de temporalité, de confidentialité, et, en premier lieu, de types de données.
Architecture et types de données
Une architecture Data-centric doit intégrer divers modèles et technologies pour gérer efficacement les spécificités des différentes typologies de données qui l’alimentent.
Une stratégie "référentiel" autour du MDM ?
L’architecture prend en compte la consolidation des données au sein d’un catalogue d’objets métiers qui reflète son activité. Les mêmes objets métiers (un même client ou un produit) sont présents à plusieurs endroits et avec des cycles de vie différents. En conséquence, la réconciliation des différentes versions d’un même objet métier, pour constituer une version consolidée et la plus exacte, est un processus spécifique mettant en jeu, particulièrement, des règles de mise en qualité, de rapprochement et de fusion.
Le Master Data Management (MDM) propose un socle technique comme réponse à ces exigences et, à ce titre, est très souvent présent dans les architectures Data-centric. Ce composant MDM permet de construire une vision 360° des différents objets métiers, de leurs attributs et de leurs relations. Il relie les différentes clés des systèmes sources contributeurs à l’identifiant unique du Golden Record, créant ainsi une base de références croisées qui trace l’origine des données. Ce lien entre identifiants est également important pour associer le Golden Record avec le reste des données d’origine transactionnelle dans une plateforme élargie. Le composant MDM doit également pouvoir assurer l’historisation des changements au nom des exigences de lineage et de respect des réglementations.
Notons que le MDM évolue pour s’insérer de plus en plus dans le cycle transactionnel des données. Des pipelines d’ingestion au fil de l’eau, suivis de traitements puis de propagations événementielles, font partie intégrante des solutions les plus performantes du marché.
Architecture et types de données
Une architecture Data-centric doit intégrer divers modèles et technologies pour gérer efficacement les spécificités des différentes typologies de données qui l’alimentent.
Une stratégie "référentiel" autour du MDM ?
L’architecture prend en compte la consolidation des données au sein d’un catalogue d’objets métiers qui reflète son activité. Les mêmes objets métiers (un même client ou un produit) sont présents à plusieurs endroits et avec des cycles de vie différents. En conséquence, la réconciliation des différentes versions d’un même objet métier pour constituer une version consolidée et la plus exacte est un processus spécifique mettant en jeu, particulièrement, des règles de mise en qualité, de rapprochement et de fusion.
Le Master Data Management (MDM) propose un socle technique comme réponse à ces exigences et, à ce titre, est très souvent présent dans les architectures Data-centric. Ce composant MDM permet de construire une vision 360° des différents objets métiers, de leurs attributs et de leurs relations. Il relie les différentes clés des systèmes sources contributeurs à l’identifiant unique du Golden Record, créant ainsi une base de références croisées qui trace l’origine des données. Ce lien entre identifiants est également important pour associer le Golden Record avec le reste des données d’origine transactionnelle dans une plateforme élargie. Le composant MDM doit également pouvoir assurer l’historisation des changements au nom des exigences de lineage et de respect des réglementations.
Notons que le MDM évolue pour s’insérer de plus en plus dans le cycle transactionnel des données. Des pipelines d’ingestion au fil de l’eau, suivis de traitements puis de propagations événementielles, font partie intégrante des solutions les plus performantes du marché.
L'ingénierie des données transactionnelles et comportementales
Les données transactionnelles sont volumineuses, plus complexes et riches en attributs. Leur volumétrie soulève des problématiques lors de leur ingestion par les différents processus d’acheminement vers les zones de stockage. Ces données sont souvent très détaillées : un enregistrement de vente, par exemple, contiendra des informations sur le produit, le client, la date et le montant. Il est donc essentiel d’arbitrer correctement le périmètre fonctionnel à intégrer pour définir les pipelines adéquats, selon les ambitions analytiques, mais aussi opérationnelles.
Les données comportementales, quant à elles, capturent les interactions et les comportements des utilisateurs, clients ou systèmes. Elles constituent des données chaudes qui s’insèrent souvent dans des « customer journeys ». En plus d’être volumineuses, elles se présentent sous différents formats, comme par exemple les clics, les temps de session ou les avis clients. Elles sont donc généralement stockées dans des systèmes de Big Data, des data lakes ou des bases de données adaptées, notamment des bases chronologiques ou orientées séries temporelles.
L'ingestion des données
L’extraction des données sources doit se faire en respectant leur cycle de vie, avec plusieurs approches possibles : l’exportation des données par les sources (en mode complet ou incrémental), l’utilisation d’API d’exposition ou encore la capture des changements au niveau de la couche de persistance.
L’ingestion des données ne se limite plus au processus traditionnel d’ETL ou d’ELT, mais intègre de plus en plus des flux de données complexes, en temps réel ou en streaming.
Des traitements tels que le filtrage, le nettoyage et la standardisation peuvent être mis en œuvre dans le processus d’ingestion en s’appuyant notamment sur certaines solutions du marché.
Après l’extraction, les données doivent être converties dans un format plus universel et standardisé et passer par des étapes de mise en qualité, de transcodification ou d’enrichissement.
L’architecture Data-centric définit au final des pipelines pour collecter, déplacer, transformer, mais aussi pointer vers des destinations et des usages spécifiques.
Le traitement des données
L’analyse et l’interprétation des données constituent une grande part de la valeur ajoutée d’une plateforme Data-centric. Des traitements de préparation servent les cas d’usage suivants : recourir à des algorithmes de Machine Learning et à des modèles statistiques pour orienter les plans d’action, personnaliser l’expérience client, exploiter les données pour détecter des opportunités sur le marché ou des besoins émergents. Cela requiert une synergie d’outils, de technologies, de compétences analytiques et de processus bien définis pour maximiser leur utilité.
Au cœur de cette problématique, les ressources de type « Compute » doivent être optimisées pour privilégier scalabilité et capacité à traiter les données selon les différentes priorités. Il existe pour cela de nombreuses combinaisons d’outils disponibles pour accélérer les performances et/ou minimiser les temps de traitement. On jouera en particulier sur l’affectation des calculs et sur le stockage selon les différentes étapes au sein du pipeline des données.
Le stockage des données
Le stockage des données au sein de l’architecture Data-centric doit tenir compte de la finalité attendue :
- Publication pour les consommateurs ou rétro-alimentation des systèmes sources.
- Traitements analytiques pour la prise de décision et la création de tableaux de bord.
- Préparation des données à des fins métiers, en particulier marketing (ex. ciblage des audiences).
- Entraînement de modèles de Machine Learning pour différents cas d'utilisation (clustering).
Les data lakes tels qu’Amazon S3, Azure Data Lake Storage et Google Cloud Storage sont des solutions spécialement conçues pour stocker de vastes quantités de données dans divers formats, qu’ils soient structurés, semi-structurés ou non structurés.
Ces data lakes sont souvent le premier réceptacle des données issues des processus d’ingestion, qui alimentent eux-mêmes une couche de données dans des formats de tables interopérables, tels qu’Iceberg ou Delta Lake. Ces formats sont compatibles avec plusieurs moteurs de calculs distribués comme Apache Spark, Databricks et Microsoft Fabric.
L’ingénierie des données est elle-même réalisée dans des plateformes comme Snowflake, Databricks, Azure Fabric, Amazon Redshift et Google BigQuery, spécifiquement conçues à cet effet, et qui associent des fonctions de data science, d’analyses et de BI.
Les bases de données NoSQL et le stockage au format JSON bénéficient nativement de la scalabilité horizontale et, pour cette raison, sont intéressants lorsqu’un grand nombre d’utilisateurs a besoin de requêter les données.
Le choix d’un type de stockage dépend donc des exigences en termes de modélisation, de scalabilité et de niveau de service requis pour soutenir efficacement les processus métiers. Une évaluation approfondie de ces éléments permet de choisir la solution qui gère le plus efficacement les données, tout en optimisant performance et coûts.
Niveaux de service et Finops
Maintenir des niveaux de service adéquats tout en gérant des volumes de données et des traitements fluctuants exige que les composants clés de l’architecture soient à la fois scalables et élastiques.
Le concept d’élasticité est essentiel dans les services de stockage et de calcul, représentant un point déterminant des offres des hyperscalers. Il est donc logique de se tourner vers l’écosystème de services de ces fournisseurs pour élaborer une architecture Data-centric capable de s’ajuster aux fluctuations des charges de travail.
Cependant, il est crucial de gérer avec précision les ressources provisionnées et les coûts associés, afin d’optimiser les bénéfices tout en évitant l’inflation du budget. Le TCO (Total Cost of Ownership) est d’abord lié à l’allocation dynamique des ressources, en particulier à la variation de coûts du compute (l’utilisation du stockage est en général plus linéaire et moins onéreuse). Il faut aussi tenir compte de la complexité de la gouvernance à mettre en place. Cette gouvernance peut se baser sur des fonctions existantes au sein de la plateforme utilisée, ou se construire au travers d’une plateforme dont la vocation est d’unifier les différents paramétrages de gestion des droits d’accès, de la sécurité, etc.
Il est crucial que l’adoption d’une architecture Data-centric soit accompagnée d’une stratégie FinOps, afin de mettre en place des outils et des pratiques de gestion des coûts permettant une visibilité sur les dépenses. De plus en plus, la décomposition de la plateforme en workspaces ou warehouses dédiés permet une ventilation ad hoc et une responsabilisation des acteurs (notamment par le plafonnement de leurs engagements).