6 Le terme « data lake » — un référentiel centralisé qui contient d’immenses volumes de données brutes dans leur format natif — n’existe que depuis une dizaine d’années. Malgré sa relative nouveauté, le marché des data lakes devrait atteindre 20,1 milliards de dollars par an d’ici 2025, selon Research and Markets. Un data lake héberge généralement des données de nombreuses sources, dans de multiples formats — qu’il faut analyser pour en tirer des enseignements métier. On entend de plus en plus parler de « data lake » et de « big data » d’un même souffle. C’est logique, car l’analyse big data exige une masse énorme de données pour en extraire des enseignements. Le besoin d’une gestion flexible et évolutive de tous les formats de données Parce qu’ils agrègent des données de sources variées, les data lakes peuvent rapidement atteindre l’échelle du pétaoctet et au-delà. Ce volume dépasse la capacité des technologies de bases de données traditionnelles, comme les systèmes de gestion de bases de données relationnelles (SGBDR), conçus avant tout pour les données structurées. Outre un problème potentiel de capacité, les data lakes accumulent des données structurées, semi-structurées et non structurées. Pour gérer ces différents types de données de manière flexible et évolutive, de nouveaux systèmes de stockage comme le système de fichiers distribué Hadoop (HDFS) ont été utilisés pour le stockage des data lakes. Mais, comme toute technologie, HDFS a ses limites. L’un des principaux inconvénients d’HDFS est que ses ressources de calcul et de stockage restent étroitement liées lorsqu’il évolue (car le système de fichiers est hébergé sur les mêmes machines que l’application). La capacité de calcul et la mémoire augmentent ensemble, ce qui peut finir par coûter très cher. Le stockage objet moderne offre des avantages fondamentaux pour les data lakes Pour tirer pleinement parti des enseignements métier que recèlent ces immenses data lakes, les organisations dépendent à la fois des outils d’analyse et du référentiel de stockage des données — ce dernier étant sans doute le plus important. Pourquoi ? Parce que le référentiel doit traiter des données de sources variées avec juste les performances nécessaires, et pouvoir évoluer en performances comme en capacité pour que les données restent largement accessibles aux applications, aux outils et aux utilisateurs. En quête d’évolutivité, de flexibilité et de coûts réduits, le stockage objet s’impose rapidement comme le standard de stockage des data lakes. Avec le stockage objet, le volume de données n’a pas de limite. Autre avantage clé : il accepte tous les types de données sans « schémas » prédéfinis (contrairement aux SGBDR, où la structure et les relations entre tables doivent être définies à l’avance pour les requêtes complexes) — ce qui accroît la flexibilité. De plus, les systèmes de stockage objet modernes comme Scality permettent de faire évoluer indépendamment la capacité et les performances — un atout majeur pour les grands projets d’analytique. Cette évolutivité indépendante fournit à la demande les performances de calcul adaptées à l’analyse des données, et réduit nettement le coût total d’une solution de data lake. Le stockage objet a aussi été adopté par les éditeurs d’applications pour répondre à la croissance des volumes de données de leurs clients. Des solutions comme Splunk prennent désormais en charge le stockage objet via l’interface SmartStore (qui s’appuie sur l’API Amazon S3), et Microfocus Vertica propose le mode EON (qui s’appuie aussi sur S3). Ces solutions dissocient le niveau de calcul (recherche) du niveau de capacité persistante, offrant plus de flexibilité et de rentabilité tout en permettant des volumes de données bien plus importants pour une analytique plus efficace. Par ailleurs, l’écosystème d’outils Apache Spark, qui utilisait traditionnellement HDFS pour le stockage, est aussi compatible avec le stockage objet S3 via l’interface de système de fichiers S3A compatible Hadoop, qui s’appuie sur l’API S3. Vous voulez en savoir plus sur les avantages du stockage objet pour les data lakes ? Lisez mon récent article pour Data Center Dynamics (en anglais).
