Alimentation du datalake en donnée : Comment nourrir la bête ?

J’ai été ces trois dernières années plus que jamais un insatiable recycleur, éboueur et collectionneur de données. Il n’y a pas de système Big Data digne de ce nom qui ne s’appuie pas fondamentalement sur un socle propre, historisé et bien maîtrisé de donnée brute fraîche. L’alimentation en donnée n’est pas une simple formalité technique mais nécessite une vraie planification et une attention particulière. Je dis cela en connaissance de cause car maintenir un duplicat quasi temps-réel de l’ensemble des données d’un système d’information est en réalité un challenge. Challenge qui en vaut la peine tant il débloque des uses cases pour la suite de l’aventure.

Rappel en métaphore

Le Datalake est l’équivalent d’un étal de marché traditionnel pour la donnée. Vous y trouverez

• des épices en vrac pour lesquelles vous devez utiliser votre propre récipient en fonction de la quantité que vous voulez et de l’épice que vous avez choisi.
• des céréales en boites de taille et de contenance bien définies et non indivisibles
• du chèvre frais à consommer rapidement comme une mimolette vieille de plus de 2 ans mais toujours bonne à déguster
• des fruits secs dont la valeur se compte à la pièce à l’inverse d’épices peu chères qui se mesurent au poids
• des conserves de poisson -produit transformé- comme de l’ecorce de cannelle -produit quasi brut-
• des produits plus ou moins correctement étiquetés en terme de nature, prix, poids, origine ou présence en allergène

En terme de data, on parlera de donnée plus ou moins structurée (allant de la vidéo brute au schéma relationnel de base de donnée) sur laquelle il faut appliquer une structure au moment de la lecture (dit schema on read) (disons que c’est le contenant ramené par le client).

On parlera de donnée plus ou moins fraîche, donc plus ou moins pertinente par rapport au problèmatiques à résoudre. Le fichier de catégorisation des transactions monétique réalisé il y a 5 ans peut ne pas convenir au e-commerce d’aujourd’hui tant les usages ont changé depuis.

On parlera de donnée plus ou moins massive en fonction de la nature de celle-ci. Pour 100dhs, vous n’aurez pas la même quantité de cumin ou de safran car la valeur intrinsèque est très différente. De la même manière, il faudra plusieurs giga-octets de donnée logs comportementaux pour “équivaloir” un petit fichier contenant les catégories socio-professionnelles ou la profession de prospects par exemple.

Enfin, on parlera de donnée transformée qu’elle ait été nettoyée, catégorisée et aggregée ainsi que de donnée brute donc inchangée depuis la sortie des systèmes de production.

Le datalake n’est pas une solution miracle pour répondre à la problèmatique du cuisinier qui a besoin des bons ingrédients au bon moment pour faire sa recette, mais peut faciliter et accélerer les premières phases de préparation d’un bon plat. Les données ne sont pas silotées mais regroupées au même endroit. Elles sont brutes donc peuvent être transformées à souhait par la volonté de l’artiste culinaire. Enfin, en fonction de la données vous prenez les quantitées qu’il vous faut et payez le juste prix en terme de structuration préalable.

Le datalake, refuge pour la donnée

Pour ma part, je n’aime pas voir le datalake comme un bazar mais comme un espace bibliothécaire. Il y a des magazines, un coin vidéo et beaucoup de livres classés parfois par auteur, parfois par catégorie et parfois juste de vieilles bandes dessinées dans une section fourre-tout. J’aime m’y promener, rajouter un étage, dépoussierer une partie. Bref me dire que tout-est-là-y-a-plus-qu’à.

Trève de poésie, le Datalake est un sanctuaire pour la donnée car il préserve tout d’abord celle-ci de modifications accidentelles, ou d’évolution de schéma qui peuvent dénaturer la réalité de l’instant.

En ce sens, le datalake peut être vu comme un système d’archivage append-only chargé de prendre des snapshots du monde et nous l’utilisons de cette manière régulièrement. L’avantage principal sur un archivage classique est que la donnée garde une forme simple d’accessibilité et peut être réutilisée à tout moment. Le prix à payer est d’avoir beaucoup d’espace disque et d’être tolérant au désordre.

C’est également un sanctuaire pour des raisons plus spirituelles. Lorsque vous décidez de consacrer une équipe ainsi qu’une infrastructure dédiée à la valorisation de la donnée, vous envoyez un signal fort qui est : La data n’est plus un by-product de l’activité informatique mais un actif qui mérite considération et respect. Le sanctuaire donne de l’importance à son pensionnaire et est probablement le shift psychologique le plus important lorsqu’on veut se lancer dans l’analyse de donnée.

Le refuge est un endroit où nous sommes amenés à rencontrer d’autres personnes, souvent différentes. Pour le datalake, il s’agit un peu de la même histoire. Des données de nature, forme et contenu très différentes se retrouvent partager le même toit. Cela favorise un bon nombre de use cases grâce à l’accessibilité de la donnée et stimule l’imagination des utilisateurs du datalake.

Loin de la prod, loin des problèmes. Il n’est pas rare de voir encore des requêtes analytiques massives s’executer sur les bases de données de production. Cela ne va pas sans poser des problématiques de performance et d’impact sur les systèmes afférents. Le datalake est de part son isolation applicative et parfois hardware (cela dépend des datalakes) un système sur lequel beaucoup de choses sont techniquement possibles sans avoir foncièrement peur de l’impact technique généré.

Alors de quoi se nourrit un datalake

L’évènement, donnée relationnelle transactionnelle par excellence

S’il y a bien une chose dont rafolle le datalake, c’est bien du log comportemental. L’évènement/transaction est la farine de notre étal, la brique de base d’un grand nombre de recettes, et il faut la considérer comme la source la plus importante d’information. Autour de nous, les processus génèrent de la donnée et cette donnée est souvent convertie, transformée et agrégée de manière à ne garder que le nécessaire d’un point de vue métier. Pour un client qui achète un produit en ligne, on ne trouvera typiquement dans la base de donnée commerciale que les caractéristiques de la vente mais aucune information sur :

• les pages accédées avant et après la vente
• les liens cliqués dans les 5 dernières minutes avant la vente
• le temps passé à réfléchir sur la page de confirmation

Toutes ces informations sont des évènements qui caractérisent la vente d’une manière que le Big Data rend utilisable. Un bon site de e-commerce se doit de logguer chacun de ces évènement séparement dans une base de donnée classique ou idéalement dans des bases de données log-friendly (car la donnée de log n’a pas vocation a être accédée de la même manière et avec les mêmes contraintes). Chaque évènement est nécessairement timestampé et doit indiquer “qui”, “quand”, “comment” et bien sur “quoi”.

Par essence, cette donnée événementielle est volumineuse et se prête parfaitement à l’analyse comportementale (la construction de nouvelles variables prédictives ou la segmentation en des axes différents). Cette donnée ne se périme jamais car elle décrit une réalité à un moment donné par le timestamp de l’évènement.

Elle a aussi l’immense avantage pour nous d’être immutable dans le temps. La profession d’un client peut changer dans une base de donnée mais pas l’évènement. Nous pouvons donc récupérer cette information à tout moment sans s’inquiéter d’une quelconque altération postérieure.

Pour la stocker, nous avons dans le datalake des bases d’archives partitionnées par année. Ainsi qu’une base courante qui donne le statut de la dernière archive jusqu’à la veille. La mise à jour sur la base courante se fait régulièrement sur la base du timestamp. Idéalement chaque jour de manière à garder un datalake frais.

L’état, donnée relationnelle non-transactionnelle par excellence

Pour fonctionner correctement, le système d’information a besoin d’avoir à disposition un état courant du monde dans lequel les processus se déroulent. Par exemple, la profession du client au moment de la vente ou encore le nombre d’achats qu’il a réalisé précédemment. Ces informations sont contextuelles à la vente et peuvent changer selon chacune son rythme. Il est bien entendu possible de les reconstruire à partir des évènements :

• La profession se retrouve à partir des évènements “déclaration de changement de profession” dans l’espace personnel client, puisqu’il suffit de prendre le dernier évènement de la sorte
• Le nombre d’achats se construit en faisant la somme du nombre d’évènements de vente pour ce client

Malheureusement, il arrive bien souvent que les évènements de cette nature ne soient pas stockés (typiquement le changement de profession ou la déclaration du nombre d’enfants à charge) et cela est une erreur majeure lorsqu’on anticipe l’alimentation d’un système Big Data. Le concepteur du système a pensé à ses propres besoins (l’état du monde) et pas aux besoin de ceux qui ont besoin de connaître l’histoire (les événèments qui ont conduits à cet état du monde).

Pour notre part, nous allons simplement prendre des snapshots réguliers des bases de données état. Avec le risque que si une donnée se modifie plusieurs fois dans l’intervalle du snapshot, l’information du changement est perdu. Ce système de snapshot n’est pas parfait car il ne remplace pas l’évènement, mais tend à essayer de l’approximer puisque l’évènement sera la différence entre deux snapshots consécutifs. Le coût en espace disque est exorbitant mais c’est le prix à payer pour un design peu friendly au départ.

Le fichier excel, couteau suisse de l’analyste et début des problèmes du data manager

Le fichier excel est l’antithèse de toutes les données que nous stockons dans le datalake pour plusieurs raisons :

• La donnée a été très probablement saisie manuellement (et donc soumise à erreur)
• Elle ne sera jamais rafraichie automatiquement (et il faudra penser à le faire bientôt)
• On ne sait pas qui a créé et a modifié le fichier excel (et il a probablement déjà démissionné)
• On ne connaît ni le contexte ni la période de validité de l’information (et on a rien d’autre de toute façon)

Le fichier excel est handy car c’est un moyen simple et efficace de faire circuler et récolter l’information dans toutes les strates de l’organisation. Nos fichiers excels à nous contiennent très souvent de la catégorisation et du paramétrage métier :

1. Par exemple telle transaction est considérée comme une opération purement digitale mais il faut comptabiliser cette autre transaction dans la catégorie des opérations cross-canal.
2. Ou par exemple, les paiements monétiques de catégorie “Restauration” ont les sous-catégories suivantes : “Fast-Food”, “Restaurant populaire”, “Pizzeria” etc.

Le fichier excel est quasiment toujours structuré ce qui en fait une donnée facilement ingérable par le datalake mais ses inconvénients me font dire parfois qu’il faut utiliser la donnée avec précaution : tout résultat qui utilise de la donnée ayant touché ce type de fichier doit porter un grand signe “attention” et il faudrait idéalement responsabiliser la personne à l’origine du fichier quant à la maintenance de la donnée qu’il contient.

La donnée non structurée, un des piliers du Big Data moderne

Les avancées les plus médiatisées du Big Data ne concernent pas la donnée structurée mais la donnée non structurée : le son, la vidéo, le texte etc. Quand on dit non structurée, on n’entend pas par là que la donnée n’a aucune structure intrinsèque : L’image porte des formes, des mouvements, des couleurs et évidemment les lois de la physiques qui gouvernent les objets. Le texte porte la grammaire, l’orthographe (ou pas), les usages courants (smileys, language sms). La donnée “unstructured” est une donnée dont la structure n’est pas facilement accessible. C’est-à-dire que vous ne pouvez pas extraire simplement à partir d’une image le nombre de personnes sur cette image alors que celle-ci contient cette information.

En banque, ce sont surtout des documents scannés que nous traitons et il est question de conformité de document, de signature et de contenu textuel. Les challenges sont donc loin de la reconnaissance de visage ou de l’analyse de foule. Ces documents sont stockés en base64 dans des fichiers sans aucun pré-traitement et attendent le passage d’algorithmes de Deep Learning pour en extraire de l’information et la stocker dans des bases relationnelles plus facilement exploitables.

La combinaison de ces sources de données regroupe la quasi totalité des données exploitables d’un datalake et tout le travail à partir de là est de déclencher un processus de raffinage de donnée avec plusieurs étages.

Credits

https://unsplash.com

• Photo by Clément Bergey on Unsplash
• Photo by Max Langelott on Unsplash
• Photo by Andrik Langfield on Unsplash
• Photo by Rick Mason on Unsplash