Comme toute nouvelle innovation technologique, les Datalakes apportent leur lot de challenges à relever, parmi lesquels des choix majeurs de gouvernance à arbitrer. Alianor SIBAI, consultante mc2i Groupe, donne ses explications aux lecteurs de Solutions Numériques.
Les Datalakes constituent dorénavant les fondements de la nouvelle plate-forme de données, permettant aux entreprises de stocker, traiter, analyser et mettre le Big Data au profit de leur business. Y résident des données à la fois structurées provenant de bases de données relationnelles, semi-structurées comme des CSV, logs, XML, JSON, non structurées telles que des emails et PDF, et même binaires comme des images, des audios et des vidéos.
La flexibilité et l’évolutivité de ces solutions, alliées à la possibilité de disposer d’un éventail aussi large de données historiques de tout type, ouvrent désormais aux entreprises qui ont osé franchir le pas des horizons d’exploitation de la donnée qui semblent infinis.
Bien entendu, comme toute nouvelle innovation technologique, les Datalakes apportent leur lot de challenges à relever, parmi lesquels des choix majeurs de gouvernance à arbitrer.
L’organisation du Datalake en plusieurs zones
Le principal avantage du Datalake par rapport à son prédécesseur le Datawarehouse, est le passage de la modélisation « on-write » (à l’écriture) à la modélisation « on-read » (à la lecture). En effet, un entrepôt de données classique n’étant pas fait pour accueillir des données non-structurées, il est impossible de stocker des données en faisant abstraction de leurs usages futurs, car la modélisation et la structuration des données doivent impérativement se faire de manière préalable à leur stockage.
Dans un Datalake, à l’inverse, il n’y a nul besoin de structurer et d’organiser la donnée avant de l’injecter ; Le stockage de la donnée se fait sans traitement, permettant aux métiers de pouvoir s’affranchir de cette phase préalable d’études et d’identification des cas d’usages.
Cependant, l’absence de structure des données ne doit pas être synonyme d’absence d’organisation du stockage dans le Datalake. La structuration du lac en zones permet d’instaurer une séparation à la fois logique et physique des données afin de préserver l’intégrité, la sécurité, l’organisation et la souplesse du Datalake.
En règle générale, le Datalake est structuré en quatre zones : une zone de stockage temporaire, une zone de stockage des données brutes, une zone de bac à sable dédiée à l’exploration, et une zone de stockage des données enrichies et prêtes pour être exploitées par des solutions de Data Analytics.
Le Data Steward et son rôle clef
Un projet Datalake est généralement accompagné par la constitution d’une armée de techniciens de la Data :
- Les Data Engineers et Data Architects sont responsables de l’infrastructure. D’une part, ils sont chargés de la connectique du Datalake, en entrée avec les sources de données, et en sortie vers les applications clientes, et d’autre part, ils sont à la fois les concepteurs de l’infrastructure informatique supportant le Datalake, et les administrateurs des clusters de calcul distribué. La délimitation des rôles de ces deux catégories d’experts dépend de l’organisation de l’équipe et varie d’une entreprise à une autre.
- Les Data Scientists sont quant à eux des spécialistes de la science de la donnée, ils explorent en profondeur la masse de données, et les exploitent à des fins statistiques et de prospection, afin de dégager des tendances et identifier des opportunités business pour l’entreprise.
- Les Data Analysts, enfin, sont des spécialistes de l’analyse de la donnée. Ils ont pour mission d’agréger et de traiter les données, afin d’en extraire des informations à destination du pilotage opérationnel des activités, dans un but d’amélioration de la performance de l’entreprise.
Outre ces différents rôles fréquemment rencontrés dans le cadre de projets Datalake, deux rôles importants et complémentaires ne doivent pas être négligés, ceux du Data Steward et du Data Owner. En effet, ils détiennent à eux deux l’une des clefs de la réussite du projet.
Le Data Owner est le propriétaire de la donnée métier. Il en connaît la provenance, la définition et la qualité. Le Datalake étant alimenté par une multitude de sources d’informations, plusieurs Data Owners peuvent être nommés dans le cadre du projet.
Le Data Steward, avec l’appui du Data Owner, est le véritable responsable référent de la gouvernance de la donnée, en particulier dans le cadre d’un projet Datalake. Chargé de l’organisation et de la gestion des données, le Data Steward doit connaître toutes les données et métadonnées du Datalake sur le bout des doigts. Il documente non seulement la donnée, mais également tous les processus, les traitements et les contrôles qui lui sont appliqués, en partie grâce au Data Lineage (se référer au paragraphe suivant pour plus d’informations). Il s’assure également de l’absence de doublons, veille à éviter toute obsolescence, et il est le garant de la qualité des données ainsi que de leurs processus de mise en qualité. Il résulte de ce travail une cartographie détaillée des données et des processus de leurs traitements, à destination à la fois des métiers, de l’équipe projet et des équipes techniques.
Le Data Lineage, épine dorsale de votre Datalake
Le « lignage » de la donnée (Data Lineage in english) est la tâche ardue de cartographie de l’ensemble des processus de traitements, règles de transformation et caractéristiques de l’information, à la maille de la donnée. Il peut s’agir de traitements aussi simples que le changement de nom d’une colonne ou d’un champ dans un fichier, ou plus complexes, tels que la jonction de plusieurs tables provenant de sources différentes, chacune pouvant avoir subi plusieurs autres transformations en amont.
L’objectif est de fournir une traçabilité et une description de la donnée, permettant de comprendre l’origine du champ ou du jeu de données, ainsi qu’un journal d’audit permettant de restituer où, quand, pour quelles raisons et par qui une modification a été apportée. Le Data Lineage doit être réalisé de bout en bout par le Data Steward (souvent à l’aide de solutions logicielles prévues à cet effet), et livré lors de la mise en place du Datalake, puis complété au fur et à mesure que de nouvelles sources de données sont ajoutées, ou que des sources existantes sont mises à jour ou modifiées.
Allié à un dictionnaire de données applicatives et métiers, et à une cartographie applicative du système d’informations, le Data Lineage se révèle être un vrai levier de gain opérationnel pour l’entreprise. Mais au-delà de ses aspects business, il permet également de mieux maîtriser le traitement des données à caractère personnel, et d’apporter par la même occasion des réponses à plusieurs des problématiques soulevées par le RGPD.
La sécurisation des données et des accès
La sécurité des données est un enjeu important de tout projet SI, mais il devient majeur dans le cas d’un projet Datalake nécessitant la centralisation et le stockage en masse de grandes quantités de données multi-sources, hétérogènes, et pour certaines personnelles voire sensibles. Afin d’assurer un niveau de sécurité conforme aux réglementations en vigueur, plusieurs solutions existent.
Tout d’abord, il peut sembler évident que pour limiter les risques de fuite ou d’usage non autorisé de données personnelles, il faille procéder à leur anonymisation. En effet, plusieurs solutions logicielles et algorithmes permettent l’anonymisation (perte irréversible du caractère identifiable de l’individu) des données lors de leur stockage dans le Datalake, ou à la volée lorsqu’elles sont restituées. Ces données anonymes n’entrent alors plus dans le champ d’application du RGPD. Cependant, cela peut rapidement devenir un vrai casse-tête lorsqu’il s’agit de définir un niveau d’altération des données suffisant pour les rendre non identifiables, même après corrélation et mise en commun de plusieurs sources ou fichiers de données, sans pour autant les dénaturer complètement afin qu’elles gardent leur valeur et restent exploitables par les Data Scientists et autres analystes de la donnée.
D’autres techniques de traitement de données à caractère personnel ont été introduites par le RGPD comme compromis lorsque l’anonymisation est difficile à mettre en place. Il s’agit de techniques de pseudonymisation : les données sont chiffrées, et la clé d’identification permettant de remonter jusqu’à l’identité de l’individu est stockée à part, rendant le traitement réversible. Ces techniques présentent un inconvénient lié à la nécessité de mettre en place une sécurité accrue et un contrôle permanant des accès aux clés d’identification. De plus, la pseudonymisation nécessite des capacités de calculs et de traitements assez conséquentes, et doit donc être limitée aux données sensibles afin de ne pas impacter considérablement les performances et temps de réponse du système.
En complément de ces deux types de solutions (qui sont loin d’être mutuellement exclusifs), il est également important de faire appel à des outils de monitoring ou surveillance automatisée du Datalake, permettant de sécuriser non plus les données en elles-mêmes, mais l’accès aux données : il est possible de générer et d’envoyer des alertes de sécurité aux administrateurs du système lorsqu’un accès aux données, ou un transfert ou déplacement des données est opéré sans autorisation préalable.
Les restrictions d’accès doivent également s’opérer au niveau des différentes zones de stockage du Datalake : l’accès aux zones de stockage temporaire et stockage des données brutes doit être extrêmement limité. Ensuite, au fur et à mesure que ces données sont transformées et sécurisées, l’accès aux zones ultérieures peut être étendu à des groupes d’utilisateurs plus larges.
Ainsi, afin de réussir la gouvernance de son Datalake, il est nécessaire de mettre en place une approche centrée sur la donnée, et de s’entourer des bons profils et des bonnes compétences. Et pour tirer pleinement profit de la scalabilité offerte par les Datalakes, le projet doit être mené dans un cadre méthodologique agile, avec un déploiement progressif et une priorisation des usages futurs.
Avec en plus un sponsoring à un niveau hiérarchique élevé pour éviter les blocages, un alignement des enjeux du Datalake sur la stratégie d’entreprise, et une équipe projet technico-fonctionnelle polyvalente, vous disposerez d’un fondement solide pour bâtir le terrain de jeu idéal du Big Data.
Bibliographie
https://www.dataversity.net/data-lineage-demystified/#
https://www.lemagit.fr/conseil/7-etapes-pour-creer-son-data-lake
https://www.sqlchick.com/entries/2017/12/30/zones-in-a-data-lake
