Les concepts de lacs de données, une introduction
En règle générale, les organisations gèrent des centaines d’applications qui, au fil du temps, sont remplacées, et ces systèmes obsolètes sont mis hors service. Dans cet article, nous aborderons le concept de base des lacs de données et la manière dont il est lié aux systèmes legacy. Dans la deuxième partie, nous évaluerons les conséquences des applications patrimoniales sur votre lac de données.
Une définition comme point de départ
Qu’entendons-nous par “lac de données” ? Les lacs de données désignent “une architecture solide, logiquement centralisée, un environnement hautement évolutif rempli de différents types de données analytiques provenant à la fois de l’intérieur et de l’extérieur de votre entreprise avec des temps de latence variables, et qui sera la destination principale pour les informations basées sur les données de votre organisation”, comme défini dans le livre Data lakes for dummies écrit par Alan R. Simon.
Les données d’un lac de données peuvent être considérées comme des données anciennes qui ont été remises à neuf et qui pourraient être réutilisées par un nouveau propriétaire.
L’ingestion de données typique pour un lac de données est le processus ELT (Extract Load and Transform). L’astuce réside dans le fait que la transformation peut avoir lieu à un stade ultérieur. Aucune analyse préalable des données n’est nécessaire(schéma à la lecture plutôt que schéma à l’écriture). Les outils ETL historiques typiques sont fournis par Informatica ou IBM datastage, mais de nouveaux outils sont désormais disponibles, tels que AWS lake formation.
Un référentiel de plusieurs sources
Les lacs de données sont construits à partir de dizaines de sources potentielles qui peuvent être des applications, des produits, des services, l’IdO ou toute autre source de données. Le flux peut provenir du batch, du streaming, ou plus probablement des deux types de sources. Il s’agit d’une architecture à couplage lâche.
Un catalogue, ou répertoire, garde la trace des données contenues dans le lac de données et des règles associées qui s’appliquent aux différents groupes de données. Il s’agit des “métadonnées”. Pour obtenir des rapports (OLAP/BI) à partir de votre lac de données, vous devrez ajouter une couche sémantique. Une couche sémantique peut être un découpage temporel de faits (tels que les revenus) en fonction de dimensions (telles que les clients).
Le problème des entrepôts de données est qu’ils peuvent devenir des décharges de données, tandis que le problème des lacs de données est qu’ils peuvent devenir des marécages de données.
Une architecture à base de composants
Une caractéristique importante du lac de données est qu’il est possible d’utiliser différentes options de stockage (c’est-à-dire le stockage de blob et le stockage de base de données SQL par exemple) pour différents usages. Votre lac de données n’a pas besoin d’être une architecture monolithique mais devient une architecture basée sur des composants.
Les données semi-structurées se situent entre les données structurées et non structurées. Elles comprennent, sans s’y limiter, les articles de blog, les messages sur les médias sociaux, les messages d’équipe ou Slack, les textes et les courriels.
Et parfois, les lacs de données sont des architectures héritées du passé
La plupart des entreprises devront faire face à des données et des données analytiques héritées, très probablement issues d’entrepôts de données et de marteaux de données. Par exemple, dans les environnements SAP, les systèmes SAP BI ne seront plus entretenus d’ici 2027/2030 et seront remplacés par SAP Datasphere.
Différentes zones en tant que pipeline
Considérons les trois parties d’un lac de données : La zone bronze, la zone argent et la zone or :
A. Zone de bronze
La zone bronze (également appelée zone brute ou zone d’atterrissage) comprend les éléments suivants : l’ingestion des données, le stockage et la gestion des données, et le catalogage des données. Il y a quelques années, nous aurions considéré HDFS ici (Hadoop Distributed Dile system), mais cette technologie semble aujourd’hui dépassée.
La zone bronze peut inclure le stockage d’une base de données, ce qui vous permet d’ingérer la structure complète d’une table de base de données, les relations entre les clés primaires et étrangères, ainsi que les contraintes de plage de valeurs et de liste de valeurs.
Les données brutes peuvent toujours être utilisées, c’est pourquoi la zone bronze prend également en charge l’analyse sous différentes formes.
B. Zone argentée
La zone argentée, également appelée zone traitée, permet de nettoyer et de transformer les données, de les affiner et de les enrichir.
C. Zone aurifère
La zone or (également appelée zone publiée) est celle où l’on trouve les données les plus pertinentes. Elle est parfois appelée “la source d’or” ou “la source de vérité”.
Quelques autres caractéristiques importantes du lac de données
- Il ne faut pas oublier le cheminement des données, c’est-à-dire le processus de suivi du flux de données au fil du temps, qui permet de comprendre clairement l’origine des données, leur évolution et leur destination finale dans le pipeline de données.
- Et combien de temps les données doivent-elles être conservées dans votre lac de données ? Eh bien, cela peut être pour toujours, ou seulement pour quelques heures (la durée de résidence par défaut du flux de données Amazon Kinesis est de 24 heures, juste pour donner un exemple d’un service courant de flux en temps réel à grande échelle). Vous pouvez également classer les données entre Hot, Cool et Archive, ou entre Hot, Cold et Frozen, ou encore entre Hot, Warm et Cold (différentes terminologies s’appliquent).
- Nous avons différents types d’utilisateurs dans un lac de données : les utilisateurs passifs n’auront accès qu’aux PDF statiques (les histoires de SAP SAC), mais un utilisateur analytique léger peut également accéder aux données réelles.
Lac de données, maillage de données ou tissu de données ?
Veuillez noter que nous parlons ici de lacs de données, et non d’entrepôts de données, de maillages de données ou de tissus de données. Ces termes ont beaucoup en commun. Par exemple, le terme data mesh a été inventé pour la première fois en 2018 (Forester Research) comme une approche des données qui décentralise la propriété et démocratise l’accès. Le Data Mesh a été utilisé ces dernières années, à commencer par Mark Russinovich et sa “gravité des données” : lorsque les entreprises collectent de plus grandes quantités d’informations et peinent ensuite à les gérer.
Personnellement, je m’alignerai davantage sur le concept de tissu de données et sur celui de pipeline de données. Selon la définition de Padmaraj Nidagundi, ingénieur logiciel expérimenté, “les tissus de données font le lien entre les environnements legacy et les nouvelles implémentations cloud-natives en fournissant aux systèmes legacy les données spécifiques dont ils ont besoin tout en maintenant les préoccupations en matière de sécurité. Les tissus de données sont un cadre, pas une technologie”.
Le mot de la fin
En conclusion, le concept de lacs de données représente une évolution cruciale dans la gestion et l’exploitation de vastes quantités de données diverses provenant de sources internes et externes. Cet article a exploré la définition fondamentale des lacs de données, en mettant l’accent sur leur rôle de référentiel centralisé et évolutif pour une variété de données analytiques. Alors que les organisations sont aux prises avec des applications héritées, le lien entre les lacs de données et ces systèmes obsolètes devient crucial, la partie 2 à venir abordant les conséquences sur les lacs de données.
Restez informé et soyez le premier à savoir ! Abonnez-vous à notre lettre d’information pour recevoir les derniers articles et les dernières informations sur SAP Data Volume Management.
