Data lake : Présentation et atouts

Un data lake est un type de référentiel de stockage qui ingère rapidement de grandes quantités de données brutes et hétérogènes dans leur format natif. En conséquence, les utilisateurs métier peuvent y accéder rapidement en cas de besoin et les data scientists peuvent les préparer et les analyser. Contrairement à son cousin plus ancien – le data warehouse – un data lake est idéal pour stocker des big data non structurées telles que des tweets, des images, des voix et des flux de données. Mais il peut être utilisé pour stocker tous les types de données – quelle que soit leur source, leur taille, leur fréquence d'alimentation ou leur structure.

Voici quelques formats possibles pour les informations stockées dans les data lakes :

• Les données structurées, telles que les lignes et les colonnes des tables de bases de données relationnelles.
• Les données semi-structurées, comme les fichiers texte délimités et les fichiers avec un schéma intégré.
• Les données non structurées – notamment le contenu des réseaux sociaux et les données de l'Internet des objets (IoT) – ainsi que les documents, les images, les voix et les vidéos.

Histoire du data lake : Les débuts

Les premières versions de ce que nous appelons aujourd'hui des data lakes sont liés aux prémices de l'éléphant jaune – Hadoop. Lors de son lancement, Hadoop était un ensemble de logiciels open source utilisés pour le stockage distribué, le traitement et l'analytise de big data. Il était particulièrement utile pour les sources émergentes de données semi-structurées et non structurées qui devenaient de plus en plus répandues à l'époque. Les data lakes étaient également utilisés pour faire évoluer les données structurées dont les volumes augmentaient rapidement.

Malheureusement, l'engouement initial pour Hadoop laissait entendre qu'il était possible de jeter arbitrairement n'importe quelle quantité de données dans un data lake, puis de laisser les utilisateurs se débrouiller seuls. Plusieurs échecs médiatisés ont prouvé que cette approche était erronée. Certains utilisateurs hâtifs ont vu leurs data lakes se transformer rapidement en décharges mal gérées et non gouvernées, surnommées "marécages de données". Cela s'est traduit par :

• La redondance, qui a faussé les résultats analytiques.
• Des données non auditables, auxquelles personne ne pouvait faire confiance.
• Des performances de requêtes médiocres, qui ont tué les premiers objectifs du data lake – exploration et découverte des données à haute-performance.

Ces premiers data lakes non documentés et désorganisés étaient presque impossibles à naviguer. Le tagging des métadonnées a évolué pour devenir l'une des pratiques de gestion des data lakes les plus essentielles, pour faciliter la recherche des données. La gouvernance des data lakes a amélioré leur auditabilité et leur fiabilité, ce qui a permis de vérifier leur utilité pour un plus grand nombre d'applications d'entreprise.

Les technologies et méthodologies utilisées pour mettre en œuvre un data lake ont mûri au fil du temps. Elles incluent désormais non seulement Hadoop mais aussi d'autres technologies traditionnelles et de big data.  

Après l'enthousiasme initial

Lorsque l'enthousiasme pour les premiers data lakes s'est estompé, le data lake a cessé d'être confondu avec une plate-forme de données. Au lieu de cela, il a été reconnu comme un conteneur pour faire coexister au même endroit toute sorte de données issues de sources variées.

Aujourd'hui, les data lakes font officiellement part des stratégies de la donnée et de l'analytique des entreprises. Les organisations reconnaissent que le terme de data lake ne désigne qu'une partie de l'écosystème data et analytique de l'entreprise, qui comprend :

• Les systèmes source.
• Les pipelines d'alimentation
• Les technologies d'intégration et de traitement des données.
• Les bases de données.
• Les métadonnées.
• Les moteurs analytiques.
• Les couches d'accès aux données.

Pour être une plate-forme de business intelligence complète qui génère une forte valeur pour l'entreprise, un data lake nécessite de capacités d'intégration et nettoyage de données, une gestion des métadonnées et une gouvernance. Les organisations de premier plan adoptent désormais cette approche globale de la gestion des data lakes. Ils peuvent ainsi utiliser l'analytique pour corréler diverses données provenant de diverses sources dans diverses structures. Cela signifie que l'entreprise dispose d'informations plus complètes sur lesquelles elle peut s'appuyer pour prendre des décisions.

Pourquoi les data lakes sont-ils importants ?

Parce qu'un data lake peut rapidement ingérer tous les types de nouvelles données – tout en fournissant un accès, une exploration et une visualisation en libre-service – les entreprises peuvent voir et analyser de nouvelles informations plus rapidement. De plus, elles ont accès à des données qu'elles ne pouvaient pas obtenir par le passé.

Ces nouveaux types et sources de données sont disponibles pour la découverte de données, le prototypage, la data visualisation et l'analytique avancée. Par exemple, un data lake est la source de données la plus courante pour le machine learning – une technique qui est souvent appliquée aux fichiers log, aux données de navigation des sites web, au contenu des réseaux sociaux, aux capteurs en continu et aux données émanant d'autres appareils connectés à internet.

De nombreuses entreprises souhaitent depuis longtemps pouvoir effectuer de l'exploration de données, de l'analytique avancée et du reporting. Un data lake fournit rapidement l'échelle et la diversité de données nécessaires à cet effet. Il peut également constituer un point de consolidation pour les big data et les données traditionnelles, permettant des corrélations analytiques sur l'ensemble des données.

Bien qu'il soit généralement utilisé pour stocker des données brutes, un data lake peut également stocker certaines des données intermédiaires ou entièrement transformées, restructurées ou agrégées qui sont produites par un data warehouse et ses processus en aval. Cela est souvent mis en oeuvre pour réduire le temps que les data scientists doivent consacrer aux tâches courantes de préparation des données.

La même approche est parfois utilisée pour masquer ou anonymiser les informations d'identification personnelle ou d'autres données sensibles qui ne sont pas nécessaires pour l'analytique. Cela permet aux entreprises de se conformer aux politiques de sécurité des données et de protection de la vie privée. Les contrôles d'accès sont une autre méthode que les entreprises peuvent utiliser pour maintenir la sécurité.

Data lake vs data warehouse

Vous vous demandez ce que vous devez regarder pour comparer un data lake et un data warehouse ? L'un des principaux éléments concerne la conception, ou le schéma du stockage de données.

Les bases de données relationnelles et autres stockages de données structurés utilisent une conception axée sur les schémas. Cela signifie que toute donnée ajoutée doit se conformer à la structure prédéfinie par leur schéma ou être transformée en cette structure. Le schéma est aligné sur les exigences correspondantes à des utilisations spécifiques. L'exemple le plus simple de ce type de conception est le data warehouse.

Un data lake, quant à lui, utilise une conception axée sur les données. Cela permet d'ingérer rapidement de nouvelles données, avant même que les structures de données et les besoin métier ne soient définies pour leur utilisation. Parfois, les data lakes et les data warehouses sont différenciés par les termes "schéma en écriture" (data warehouse) et "schéma en lecture" (data lake).

• Le "schéma en écriture (data warehouse) limite ou ralentit l'ingestion de nouvelles données. Il est conçu en fonction d'un objectif spécifique associé aux données, ainsi que de métadonnées associées spécifiques. Toutefois, la plupart des données peuvent servir à plusieurs fins.
• Le "schéma en lecture" (data lake) retient les données brutes, ce qui permet de les réutiliser facilement. Il permet également d'attribuer plusieurs balises de métadonnées pour les mêmes données.

Comme il n'est pas limité à une structure unique, un data lake peut accueillir des données multistructurées pour un même domaine. Par exemple, les data lakes peuvent mélanger des transactions commerciales structurées avec des sentiments non structurés des clients. Et comme il est axé sur le stockage, un data lake nécessite moins de puissance de traitement qu'un data warehouse. Les data lakes sont également beaucoup plus faciles, plus rapides et moins coûteux à faire évoluer dans le temps.

L'un des inconvénients d'un data lake est que ses données ne sont ni normalisées, ni non dupliquées, ni contrôlées en termes de qualité, ni transformées. En réaction, certaines personnes ont adopté une tendance à utiliser les data lakes différemment. Les data lake peuvent fournir une nouvelle zone de transit améliorée pour la mise à disposition des données avant qu'elles ne soient préparées, intégrées, transformées et chargées dans le data warehouse.

Ces exemples illustrent pourquoi un data lake ne remplace pas un data warehouse – il le complète. En plus d'être utilisés comme zones de transit, les data lakes peuvent également servir d'archives. Dans ce cas de figure, les données périmées sont archivées mais restent facilement accessibles pour l'audit et l'analyse historique.

Les débuts du data lake : Approfondissement

Les premiers data lakes utilisaient le système open source Hadoop Distributed File System (HDFS) comme cadre pour stocker les données sur de nombreux périphériques de stockage différents comme s'il s'agissait d'un seul fichier. HDFS a fonctionné en tandem avec MapReduce en tant que cadre de traitement des données et de gestion des ressources qui divise les grandes tâches de calcul – telles que les agrégations analytiques – en tâches plus petites. Ces petites tâches s'exécutent en parallèle sur des clusters de calcul constituées de matériel de base.

Dans sa deuxième version, Hadoop a apporté une amélioration en découplant le cadre de gestion des ressources de MapReduce et en le remplaçant par Yet Another Resource Negotiator (YARN). En résumé cela est devenu le système d'exploitation d'Hadoop. Plus important encore, YARN supporte des cadres de traitement alternatifs à MapReduce. Cela a considérablement élargi les applications (ainsi que les fonctions de gestion des données et de gouvernance) pouvant être exécutées en mode natif dans Hadoop.

Comment fonctionne un data lake aujourd'hui

L'ingestion rapide et la possibilité de stocker des données brutes dans leur format natif ont toujours été des avantages clés des data lakes. Mais qu'est-ce que cela signifie exactement ? Et comment ça marche ?

• Le terme données brutes signifie que les données n'ont pas été traitées ou préparées pour un usage particulier. Toutefois, certaines sources de données ont déjà subi un certain traitement ou une certaine préparation. Ainsi, un data lake stocke des données brutes en ce sens qu'il ne traite ni ne prépare les données avant de les stocker. A l'exception notable du formatage.
• Le terme format natif signifie que les données restent dans le format du système ou de l'application source qui les a créées. Cependant, ce n'est pas toujours la meilleure option pour le stockage dans un data lake. En effet, il est rare que l'ingestion rapide consiste simplement à copier les données telles quelles dans un répertoire du système de fichiers utilisé par le data lake.

Par exemple, une feuille de calcul Microsoft Excel est, par défaut, dans son format natif XLS. Mais la plupart des data lakes préfèrent les stocker dans un fichier texte non hiérarchique délimité au format CSV (valeurs séparées par des virgules). Les données transactionnelles des bases de données relationnelles sont également souvent converties en fichiers CSV pour être stockées dans le data lake.

Schéma intégré et données granulaires

Une autre solution courante consiste à utiliser un format de fichier contenant des informations de schéma intégrées, comme JavaScript Object Notation (JSON). Par exemple, les données de parcours de navigation, le contenu des réseaux sociaux et les données des capteurs de l'IoT sont généralement convertis en fichiers JSON pour le stockage dans un data lake. Les fichiers JSON sont également un bon exemple pour illustrer que l'ingestion dans un data lake implique souvent de convertir les données de leur format natif en un format plus granulaire.

Les données granulaires, en particulier avec des informations de schéma intégrées telles que les paires clé-valeur (KVP), permettent des opérations de lecture et d'écriture plus rapides. Cela signifie qu'elles :

• Ne gaspillent pas de stockage sur des espaces réservés pour des clés ou des valeurs facultatives, par défaut ou manquantes.
• Peuvent être agrégées et désagrégées pour répondre aux besoins de différentes situations.
• Facilitent la récupération des seules données applicables à une utilisation spécifique.
  
  

D'autres formats de stockage, plus optimisés pour les data lakes, sont également disponibles. Certains de ces formats de stockage permettent une meilleure extensibilité et un traitement parallèle, tout en intégrant des informations sur les schémas. Les données peuvent être converties en :

• Stockages en colonnes (par exemple, Redshift, Vertica, Snowflake).
• Formats compressés en colonnes (par exemple, Parquet pour Spark ou ORC pour Hive).
• Formats conventionnels en lignes (par exemple, PostgreSQL, MySQL ou d'autres bases de données relationnelles).
• Formats compressés en lignes (par exemple, Avro pour Kafka).
• Stockage en mémoire (par exemple, SingleStore, Redis, VoltDB).
• Stockage NoSQL (par exemple, MongoDB, Elasticsearch, Cassandra).

Quand utiliser les différentes options de stockage des données

La plupart des data lakes utilisent diverses options de stockage, en fonction des sources de données et des business cases. Cela est particulièrement vrai pour les business cases liés à l'accès aux données et à l'analytique. Par exemple :

• Le stockage en colonnes est idéal lorsqu'on veut surtout une récupération rapide et une agrégation accélérée.
• Le stockage en lignes est idéal lorsqu'il y a beaucoup de variabilité dans les schémas, comme c'est souvent le cas avec les applications de streaming. C'est également idéal lorsque le data lake est utilisé comme zone de transit pour un data warehouse.
• Le stockage en mémoire est idéal pour les cas d'utilisation analytique en temps réel.
• Le stockage NoSQL est idéal pour les scénarios analytiques qui nécessitent une génération rapide de métriques sur de grands ensembles de données.

Les data lakes et l'importance de l'architecture

En résumé, un data lake n'est pas qu'un énorme entrepôt – il nécessite une architecture de données bien conçue. Il est possible d'utiliser un large éventail d'outils pour mettre en œuvre l'ingestion rapide de données brutes dans un data lake. Ces outils comprennent les outils d'intégration de données et d'ETL (extraction, transformation, chargement) dont votre entreprise dispose probablement déjà. Certaines nouvelles technologies de big data (y compris certains des exemples ci-dessus) offrent également cette fonctionnalité.

Indépendamment de la manière dont vous choisissez de mettre en œuvre l'ingestion et le stockage, les data lakes peuvent impliquer le déploiement de technologies back-end avec lesquelles vous êtes moins familier – notamment les systèmes de gestion de bases de données non relationnelles (non RDBMS). Heureusement, bon nombre de ces technologies comportent des interfaces front-end conviviales. Par exemple, certaines offrent une fonctionnalité de requête de type SQL que de nombreux utilisateurs savent déjà utiliser.

Data lake et cloud

Un data lake peut être utilisé comme un référentiel centralisé par lequel transitent toutes les données de l'entreprise. En tant que tel, il devient une zone de transit facilement accessible où toutes les données de l'entreprise peuvent être trouvées. Cela inclut les données consommées par les applications on-site ainsi que les applications basées sur le cloud qui peuvent s'adapter à la taille, à la vitesse et à la complexité du big data. Tout cela nous amène à la question du data lake par rapport au cloud : Où le data lake doit-il être situé ?

Data lake sur le cloud

Pour certaines entreprises, le cloud peut être la meilleure option pour le stockage des data lakes. En effet, le cloud offre des avantages complémentaires – extensibilité élastique, services plus rapide et performance informatique – ainsi qu'un modèle de comptabilité par abonnement.

Data lake on-site

Les entreprises peuvent décider de baser leur data lake au sein de leurs murs (on-site). Les raisons avancées sont souvent similaires aux arguments en faveur de la gestion d'un cloud privé sur site. Cette approche offre un maximum de sécurité et de contrôle tout en protégeant la propriété intellectuelle et les applications critiques pour l'entreprise. Elle peut également sauvegarder les données sensibles en conformité avec les réglementations gouvernementales.

Mais les inconvénients de la gestion d'un cloud privé on-site s'appliquent également à un data lake. Tous deux peuvent nécessiter plus de maintenance interne de l'architecture du data lake, de l'infrastructure matérielle et des logiciels et services connexes. 

Data lake hybride

Parfois, les entreprises optent pour un data lake hybride, qui répartit leur data lake entre leur site et le cloud. Dans ces architectures, le data lake sur le cloud ne stocke généralement pas les données critiques pour l'entreprise. Et si il contient des informations d'identification personnelle ou d'autres données sensibles, celles-ci sont masquées ou anonymisées. Cela aide les entreprises à se conformer aux politiques de sécurité des données et de protection de la vie privée. Pour minimiser les coûts de stockage du cloud, les données stockées sur le cloud peuvent être purgées périodiquement ou après la fin des projets pilotes.