Du datalake au datawarehouse agile : le décisionnel à l’ère du big data

Le concept de datalake lié à la mouvance Big Data est un moyen pour les entreprises de mettre en œuvre une plateforme de stockage de données fédérée s’appuyant sur les apports des technologies Big Data. La capacité de stockage est importante et scalable tant à la fois sur des données structurées et non structurées. Le coût global de possession (TCO) moins élevé que des bases de données relationnelles « Classique ».

Mais comment combiner ce datalake avec un datawarehouse officiant déjà comme la véritable pierre angulaire du patrimoine informationnel structurée de l’entreprise ?

Voici quatre propositions pour qualifier et unifier son patrimoine de données dans une approche agile et incrémentale.

1. Le lac : Mettre en œuvre le datalake

Le datalake est une zone de stockage pour toutes les données externes ou internes (pas ou partiellement exploitées au sein de l’entreprise) nécessitant une qualification tant sur leur fiabilité que sur leur valeur ajoutée.

Les données sont donc stockées et indexées au fil de l’eau sans transformation :

• Si les données sont variées et volumineuses, ces dernières peuvent être hébergées et indexées nativement sur des plateformes Big Data distribuées de type Spark et/ou Hadoop.
• Si les données sont quasi exclusivement de type log et/ou semi-structurées, des bases de données NOSQL orientées documents clomme CouchDB et Mongo DB, clés valeurs comme RIAK et REDIS et des moteurs d’indexation comme Elastic Search ou Splunk sont à étudier.
• Si de nombreuses données non structurées sont à dénombrer, des moteurs d’indexation avec analyse sémantique de type NLP (Natural language processing) comme le projet open source apache OPEN NLP ou des solutions éditeurs comme celles d’Attivio, Expert System ou Sinequa sont à considérer, pour des solutions combinant analyse textuelle et image nous pouvons citer IBM Watson (Alchemy API).
• Enfin si le datalake venait à évoluer en termes de périmètre et de variété de données, l’ensemble des briques précédemment citées peuvent être connectées/hybridées.

Mettre en œuvre un système de traçabilité

Pour assurer une maintenabilité et exploitabilité optimale du datalake, il est alors conseillé de mettre en œuvre un système de suivi et de traçabilité des données.

Ce dernier doit a minima se matérialiser par la mise en œuvre d’arborescences claires et de nom de fichiers complets permettant d’identifier rapidement l’origine et le moment de « Captation » des données. Il s’agit d’une condition sine qua non pour que le datalake ne se transforme pas en dataswamp (marécage de données).

2. La mine : Transformer et normaliser les données du datalake à l’aide d’outils de data préparation

Les outils de data préparation ont donc pour objectif de qualifier « techniquement parlant » la qualité des données. L’objectif est ici d’exclure les données mal formées ou aberrantes ainsi que d’identifier les interactions et les croisements de données.

• Ce travail peut être grandement facilité si le ou les outils sélectionnés proposent des fonctions de « recommandations » ou des routines automatisables et ré-excutables.
• Pour exécuter les transformations  rapidement et dans une approche « ELT », de nombreuses solutions proposent des connecteurs vers des Appliances ou des plateformes Big Data. Toutefois elles ne sont pas encore toutes capables de s’exécuter nativement et de manière distribuée sur ces plateformes.
• Ce marché étant en pleine croissance, je vous invite à consulter régulièrement les derniers Magic Quadrant du Gartner ou Waves du Forrester qui portent sur le sujet.

Héberger ces résultats sur la même plateforme

Les données une fois apurées et retravaillées doivent être stockées. Pour avoir un bon compromis coût/performance il est conseillé d’héberger ces résultats sur la même plateforme que celle utilisée pour le datalake. Il est donc primordial de conserver les données avant et après transformation. A cet effet, il est nécessaire de créer des répertoires spécifiques dans le datalake. Cela permet de dissocier ce qui a déjà été qualifié de ce qui ne l’a pas encore été.

Enfin, dans une approche d’audit et de suivi des transformations sur les données, l’utilisation des fonctions de data lineage est également conseillée. Ces fonctions sont proposées soit par l’outil de data préparation soit par la plateforme de stockage de données lorsque elles existent.

3. La fonderie : Mettre en œuvre un terrain de jeux ou « datalab » pour les métiers et les data scientists

Le terrain de jeux ou datalab est un espace exclusivement dédiée à l’expérimentation et à la qualification « fonctionnelle » des données.

• Ce dernier peut être physiquement positionné sur une plateforme de traitements distribuée de type Spark et/ou hadoop. Il peut être accessible via des droits d’accès spécifiques.
• En amont, la phase de data préparation a déjà positionné des arborescences et des axes de facilitations pour fluidifier les analyses.
• Il est fortement conseillé de positionner des connecteurs vers le datawarehouse et les bases de données « opérationnelles »  pour effectuer des analyses croisées, riches en d’apprentissage.

Comme pour les étapes précédentes, il est donc souhaitable de mettre en œuvre un suivi des opérations déjà effectuées dans le datalab. Et ce, afin d’identifier et capitaliser sur ce qui a déjà été fait mais aussi identifier ce qui n’a pas encore été exploité dans le datalake.

4. Fort Knox et son rayonnage : Intégrer dans une approche agile et incrémentale les données dans le datawarehouse

Le datawarehouse – brique souvent déjà existante dans le système d’information – ne permet pas toujours d’intégrer « facilement » de nouvelles données. En effet, lorsqu’on ajoute un nouveau flux cela impacte généralement la structure des tables et la modélisation même du datawarehouse. Afin de limiter ces effets de bords, et ne pas remettre en cause l’existant, il est possible de mettre en œuvre des approches de modélisation agiles de type datavault ou anchormodeling. L’objectif étant alors :

• D’étendre la couverture du datawarehouse sans dégrader l’existant
• D’assurer une traçabilité des données
• D’industrialiser une partie des analyses menées dans le datalab
• D’unifier et centraliser en un point toutes les données stratégiques à forte valeur ajoutée sur l’entreprise et son écosystème environnant.

Il est donc important de trouver un bon équilibre entre les données qui sont à stocker dans le datalake et celles stockées dans le datawarehouse. En effet, toutes les données du datalake et du datalab ne seront pas à intégrer dans le datawarehouse (d’autant plus si leur volatité s’avère importante). Le datalake sert ainsi à des analyses ponctuelles « on demand » et non industrialisées. De son côté, le datawarehouse sert des besoins récurrents et industrialisés.

Pour conclure, la conception incrémentale et scalable du datalake ainsi que l’évolution agile du datawarehouse sont des chantiers visant à étendre une architecture décisionnelle existante. Et ce, sans remise en cause des grands principes qui la compose.

En résumé

Le décisionnel à l’ère du Big Data peut se résumer ainsi :

• Techniquement parlant par une plus grande variété des données traitées, par la mise en œuvre de plateformes d’exécution distribuées sur tout ou une partie de la chaine et par une répartition « smart » des données entre le datalake et le datawarehouse.
• Fonctionnellement parlant par la mise en œuvre d’un datalab afin d’améliorer la connaissance de toutes les données capitalisées par l’entreprise avec pour objectif une amélioration continue voir une approche totalement disruptive des processus qui la constitue.
• Organisationnellement parlant par la mise en œuvre d’une cellule « agile » de centralisation et de qualification des données.