La centralisation des données (jusqu’à sa déclinaison technique de co-localisation) a été un concept de base de la gestion des Big Data en entreprise. Les datalakes ou les datawarehouses tentent de regrouper les données de systèmes dispersés en un point d’accès central, afin que toutes les données puissent être facilement recherchées, explorées, récupérées et normalisées.
Cependant, cela présente des failles. Notamment au vu de l’augmentation des volumes à stocker et à utiliser. En effet, la démultiplication des cas d’utilisation induit une complexité dans la création et le maintien en conditions opérationnelles des traitements, n’allant pas dans le principe de simplification des accès voulu au départ.
Si nous résumons, les entrepôts de données ont permis aux entreprises de prendre de l’avance dans les années 90- 2000, et cela reste encore le cas. Puis les datalakes ont été nécessaires avec les besoins Big Data (Volume, Vitesse, Variété, etc…). Mais il faut faire très attention à ne pas faire évoluer les « lacs » en « marécages » non utilisables.
Qu’est-ce que le Data Mesh ?
C’est le principe de voir la donnée comme un produit, gouverné et fédéré par une logique de propriété (et d’architecture) décentralisée, et accessible aisément via une plateforme en libre-service.
Ce principe oblige à inverser la façon dont nous pensons la donnée, et à la gérer de façon décentralisée par « domaine ». Un domaine est déterminé par les domaines métiers qu’il sert, et contient une réponse à tous les besoins des consommateurs de données. Cela implique de faire coexister les données opérationnelles ainsi que des données analytiques plus raffinées (contrairement au schéma datalake/dataware/datamart).
Cependant même si cette nouvelle approche semble très alléchante, et désormais possible techniquement via l’edge computing, elle a elle aussi une faille déjà visible, notamment dans la gouvernance des données. Déjà complexe à mettre en place dans un environnement centralisé, elle doit ici être réalisée en interne au niveau de chaque domaine, puis dans une version plus haut niveau pour fédérer l’ensemble. Or la maturité des entreprises n’est pas forcément assez forte sur les sujets data pour permettre cette mise en place
La conclusion de cet article est simple (et somme toute assez classique) : pour traiter les Big Data, il n’y a jamais un seul principe, et il faut choisir son implémentation en fonction de la maturité de son entreprise, de ses données et de sa stratégie data actuelle et future.