Datalakes : L'Architecture Big Data

Avant tout, donnons une définition : un Data Lake est un support de stockage de données et de calcul adapté au Big Data.

Si cette définition a le mérite de la concision, elle ne donne pas la mesure de la complexité qu'elle implique :

• Comment stocker ? Que stocker ? Quelles données rapatrier ? Ces données doivent-elles être supprimées de l'application source ? À quelle fréquence ?
• Comment réaliser de manière efficace des traitements sur ces gros volumes ? Quelle partie précalculer ? Comment coordonner les traitements ?
• Comment le reste du monde arrivera-t-il à accéder à ces données ? Quels services exposer ? Comment interagir avec le reste du SI ?
• Si un Data Lake comprend de tels volumes d'information, comment le sécuriser ?
• Comment administrer et superviser les contenus ?

Une autre définition pose la question sous l'angle métier. Un Data Lake est un projet transverse. Chaque application au sein d'un SI réalise une tâche et une seule, adressant bien une problématique précise. Elle permet de répondre à des questions fines sur son domaine. Mais le problème est : sur son domaine uniquement.

Aucune application ne semble vraiment capable de répondre à des questions importantes, mais impliquant tout un pan métier, et en général plusieurs dizaines d'applications. Nous sommes assez catégoriques pour plusieurs raisons : citons l'incapacité physique de contenir les données d'autant d'applications dans un SGBDR classique, ou l'incapacité de mobiliser plusieurs téraoctets de mémoire pour mener à bien tous les calculs. L'évidence est là : il faut passer à l'échelle supérieure, il faut une architecture conséquente, donc un Data Lake.

Par exemple, dans le domaine de l'assurance, la notion de vision client 360 consiste à croiser les données relatives aux clients, à ses assurances, à ses sinistres, toutes catégories confondues. Là encore, ce n'est pas anodin, que ce soit sur le volume ou sur les temps de traitement de données. Cependant, quand on en dispose, on peut commencer à poser de très bonnes questions, des questions transverses :

• Quand tel client sera-t-il susceptible de résilier ses assurances ?
• Quel peut être l'impact de telle ou telle loi, disons la loi Hamon, sur le CA de l'entreprise ?

De manière plus générale, quand on a commencé à stocker les données d'applications critiques en termes métier, le cœur de son SI, on peut commencer à alimenter un backlog complet de cas d'utilisation :

• Qui sont nos clients ?
• Quels sont leurs produits préférés ? Que leur recommander ?
• Mais aussi, comment détecter la fraude ?

Fondamentalement, l'équivalent de la couche « données » comprend deux parties dans un Data Lake : le stockage à proprement parler, et l'ingestion ou l'import de données.

L'import s'exécute suivant deux axes :

• Comment intégrer des données de sources externes, comme des bases relationnelles, à des fréquences de l'ordre d'un jour à titre d'exemple.
• Comment intégrer des données des SI existants qui sont du (presque) temps réel (Twitter, cours de bourse…)

Dans le premier cas, le standard est Apache Sqoop qui offre l'import de tables, voire de bases, dans un cluster HDFS. Dans le second, plusieurs options s'offrent à vous : Apache Flume et Apache Kafka. Vous avez, dans tous les cas, à trancher le format de stockage. Mentionnons deux options :

• Avro est un format de sérialisation efficace pour Flume, notamment, puisque les insertions vont se faire au fil de l'eau par construction.
• Parquet par contre, est un format orienté colonnes, et compressé, ce qui le rend beaucoup plus adapté à des insertions en une seule passe, comme les copies de tables et de base. Et donc, ce format s'intègre fort bien avec du Sqoop.

L'accès aux données, ensuite, utilise plusieurs techniques :

• Une base de données adaptée aux gros volumes, avec notamment Hbase. Mais, l'habitude jouant, vous aurez envie d'y accéder via un langage proche de la syntaxe SQL. Citons le projet Phoenix qui se chargera de le faire pour vous.
• Hive a un rôle particulier, son origine reste de générer du map reduce à partir de SQL. La notion de vue externe vous permet de « faire comme si » vous disposiez d'une base au-dessus du HDFS. Évidemment, compte tenu des volumes, il va vous falloir partitionner intelligemment votre structure de répertoires.

On a, à ce stade, une base, des données, du SQL, exactement « comme avant ». On peut commencer à tirer de l'information utile de ces gros volumes. Il y a plusieurs écoles, reflétant l'histoire de la technologie :

• Pig génère du map reduce depuis un langage de script. En pratique, on peut s'en servir pour des petits utilitaires, mais guère plus, essentiellement parce qu'il y a beaucoup mieux.
• Spark, qui permet de réaliser tout traitement conséquent. C'est un framework qui offre tout ce dont on a besoin : l'équivalent d'un SQL, de quoi faire du Machine Learning, du temps réel. Vous pouvez l'utiliser avec du Java, du Python, et du Scala. Le support de R est plus récent, et régalera les data scientists.

Assez vite va se poser la question de savoir comment réduire le temps d'exécution des traitements, voire arriver à faire du « temps réel » (disons, moins d'une seconde). D'un point de vue théorique, c'est la notion de lambda architecture qui va vous fournir une base de mise en place.

Le principe reste simple : on ne peut que réaliser un compromis via un stockage des derniers événements reçus. Ceux-ci sont stockés en attente d'un traitement qui va mettre à jour les données historiques. Par exemple, si les vues en vert sont mises à jour toutes les 24 heures, il va falloir stocker les données plus récentes dans un endroit spécifique, et calculer des vues sur celles-ci. Quand la vue de mise à jour des données en vert s'exécutera, elle prendra les données de la journée, stockées en orange.

Par contre, pour garantir une fraîcheur suffisante, il faut recalculer les vues en orange à une fréquence suffisante. Tout cela est bien, mais pose immédiatement la question des accès par les services extérieurs. À ce sujet, il va vous falloir réduire les données en des volumes acceptables, indexer (vous connaissez sûrement Apache SolR) et éventuellement stocker dans des vues, ou dans des bases NoSQL spécifiques. C'est plus un art qu'une science…

Alors, tout ne va pas bien se passer du premier coup. On vous invite à être vigilant sur un certain nombre de points :

• D'abord, sur certains outils, les technologies sont récentes, et avec ce constat, on veut dire que vous allez souvent solliciter le support pour la correction rapide de bogues assez triviaux. Par exemple, à l'heure où l'on écrit ces lignes, le support Hive de Parquet est encore loin d'être suffisant. Il va vous falloir être malin et trouver par vous-même de quoi avancer.
• Le fait que vous ayez du SQL ne veut pas dire l'application brutale des paradigmes relationnels. Vous n'avez pas particulièrement envie de faire des jointures à la volée sur une vingtaine de tables. Si les temps d'exécution sont longs sur une base relationnelle, ce sera bien pire sur de gros volumes.
• Les métadonnées vont vous donner du fil à retordre. D'une part, pour des raisons pratiques de récupérer ces métadonnées, et de les garder à jour. Et surtout, parce que les exports ne donnent pas de sémantique sur les noms de colonne. Faire le lien entre DTEECH et « la date d'échéance d'un contrat », par exemple, n'a rien d'automatique et va nécessiter une solide collaboration avec le métier (et donc, potentiellement, de l'agilité). Mentionnons le rôle de data manager, la personne qui se charge de collecter ce genre d'information, en général, un-e interne client.
• La sécurité, évidemment, la gouvernance et la supervision sont des aspects critiques. Ambari mérite un peu d'attention, pour ne citer que lui.
• Enfin, par sa nouveauté, le Data Lake va avoir toute l'attention des diverses directions, et vous aurez rapidement des dizaines, voire des centaines de cas d'utilisation, bien évidemment tous urgents et prioritaires, à mettre en œuvre. À vous bien évidemment de prioriser, mais ne sous-estimez en aucun cas la charge qui va tomber sur l'équipe. Équipe que vous devrez renforcer rapidement…

Un Data Lake est une structure particulière. Les composants qui en font partie forment un tout cohérent que des entreprises comme Cloudera ou Hortonworks proposent en un seul « package ». L'affaire n'est cependant pas à prendre à la légère tant par :

• La connaissance du SI qui est nécessaire pour le faire vivre. On peut connaitre au début du Data Lake une sorte de boulimie de données, qu'on ingère « au cas où ». En fait, cela n'a aucun sens si aucune vision métier ne vient l'étayer. Stocker n'est pas seulement stocker de la donnée, c'est aussi leur attacher une sémantique, donc, des métadonnées, et du savoir pour lui donner du sens. Concrètement, c'est avoir une sémantique par colonne utile (le fameux schema on read), une cartographie de votre SI, voire, un système de suivi des métadonnées. Aucune machine, a priori, ne va vous y aider dans l'immédiat, c'est du temps, une volonté de tous les instants, et un data manager patient.
• Le coût de la solution, que ce soit en support, de fait obligatoire, en machines, et enfin par la taille de l'équipe. Ne pensez pas que monter un Data Lake soit rentable dès ses balbutiements, il s'agit d'un investissement conséquent. À terme, cependant, Rajiv Tiwari donne la statistique suivante dans son livre : une telle solution permet par exemple de réduire de 90 % les coûts de stockage par an et par téraoctet. Statistique abrupte, qui dépend du contexte, mais qui a le mérite d'éclairer sur une tendance : le Data Lake est une option de stockage à long terme.
• Les possibilités, au-delà du cadre de la BI, qui s'offrent à vous. On en a peu parlé, mais l'intégration d'un Lake au reste du SI permet l'analyse et la classification de données en « temps quasi réel ». Par exemple, quand un client clique sur ses centres d'intérêt, en fonction de ses préférences, on peut lui proposer instantanément toute une série d'images ou de sujets liés et pertinents. L'imagination et votre budget sont vos deux seules limites. Vous aurez en conséquence le revers de la médaille et il vous faudra une équipe robuste, composée de data scientists, data engineers et autres data specialists, pour faire face au besoin.

Nous remercions la société Soat qui nous a autorisés à publier ce tutoriel.