Ce que chacune fait, sans le vocabulaire
Un Data Lake stocke d'abord et structure ensuite. On y dépose les données dans leur format d'origine, sans imposer de modèle, en partant du principe que les usages futurs sont inconnus et qu'il serait dommage de les contraindre aujourd'hui. La structuration se fait au moment de la lecture, par celui qui exploite.
Un Data Hub structure à l'entrée. Les données sont nettoyées, harmonisées et rattachées à un modèle au moment où elles arrivent, en vue d'une circulation et d'une réutilisation. Ce qui en sort est directement exploitable, mais l'éventail des usages a été décidé plus tôt.
Formulé autrement : le Data Lake reporte l'effort sur celui qui lira, le Data Hub le concentre sur celui qui construit.
Pourquoi le Data Lake fonctionne si bien là où il est né
Le Data Lake a été popularisé par des organisations qui ont une caractéristique commune : un grand nombre de personnes capables de le lire. Des ingénieurs analytics, des scientifiques des données, des équipes qui écrivent du code, versionnent leurs transformations et savent reconstruire un modèle depuis des données brutes.
Dans ce contexte, reporter l'effort sur la lecture est rationnel. La lecture ne coûte pas cher, parce qu'il y a beaucoup de lecteurs compétents, et la souplesse gagnée est réelle.
Pourquoi il se dégrade ailleurs
Transposez la même architecture dans une entreprise de deux cents personnes qui compte un analyste et demi, et l'équation s'inverse.
L'effort reporté sur la lecture n'est jamais fourni, parce qu'il n'y a personne pour le fournir. Les données s'accumulent dans leur format d'origine. La connaissance de ce qu'elles contiennent reste dans la tête de la personne qui les a déposées, et cette personne finit par partir. Deux ans plus tard, le stockage coûte, plus rien n'est documenté, et chaque nouvelle question demande une exploration complète.
Ce n'est pas un échec de l'architecture. C'est un échec d'appariement entre une architecture et une organisation. Nous décrivons ici des situations que nous avons trouvées en place en arrivant, pas un scénario théorique.
La question qu'il faut poser à la place
Avant de choisir entre les deux, répondez à ces quatre questions. Elles décident plus sûrement que n'importe quel comparatif technique.
Combien de personnes chez vous savent lire une donnée brute et en reconstruire un indicateur ? Si la réponse est zéro, une ou deux, tout ce qui repose sur un effort de lecture échouera, quelle que soit la qualité de la mise en œuvre.
Que se passe-t-il si l'une de ces personnes part ? Une architecture dont la compréhension tient dans une seule tête n'est pas une architecture, c'est une dépendance. La parade ne tient pas au choix du stockage : elle tient à un socle où chaque jeu de données expose son emplacement, son origine et son propriétaire, sans que personne ait à s'en souvenir.
Vos questions sont-elles connues ou imprévisibles ? Si vos usages tournent autour d'un noyau stable de pilotage financier et commercial, l'argument de flexibilité du Data Lake porte sur un besoin que vous n'avez pas.
Qui répondra à « d'où vient ce chiffre » ? Aucune des deux architectures ne répond seule à cette question. Il faut pour cela une couche de définitions gouvernées, et c'est un sujet distinct du stockage.
Le point que les comparatifs oublient
Le débat entre les deux architectures porte sur la manière de stocker et de préparer. Il ne dit rien de la manière de décider.
Vous pouvez construire un Data Hub irréprochable et continuer à voir deux directions arriver en réunion avec deux chiffres pour le même indicateur, parce que la définition de cet indicateur n'a jamais été écrite ni attribuée à quelqu'un. Le stockage règle un problème de disponibilité de la donnée. Il ne règle pas le problème de confiance, qui se joue un étage au-dessus.
C'est la raison pour laquelle un choix d'architecture, seul, produit rarement le résultat attendu par la direction qui l'a financé.
Données de démonstration