Discussion :

[itachis]

Bonjour,

Débutant sur le sujet data lake, et ayant lu pas mal d'article, je suis plus que jamais, dans une confusion totale. Ci-dessous quelques questions pour m'aider à comprendre le mecanisme:
1-Dans un data lake, le stockage se fait dans une seule et unique table?
2-HBASE représente t-il l'interface du HDFS?
3-Quel type d'information doit être considérée comme famille de colonnes dans les bases noSQL en colonne (HBASE)? par exemple: l'entité client, commande peuvent être considérés comme des familles de colonnes?

Merci par avance .

[rouardg]

Bonjour,

1-Dans un data lake, le stockage se fait dans une seule et unique table?

Pour moi, et même si je n'ai pas d'expérience pratique sur le sujet, un DataLake, comme son nom l'indique, n'est qu'un énorme entrepôt de données.

Pour moi jusqu'à présent, les entreprises se montaient avant des Datawarehouses, ces énormes bases de données relationnelles qui stockaient et consolidaient les données de l'entreprise.
La partie alimentation d'un Datawarehouse était cruciale, puisqu'il fallait s'alimenter de différents systèmes hétérogènes de l'entreprise, et qu'il fallait donc collecter la donnée, mais aussi la contrôler, la purger, la mettre en forme, la dédoublonner, l'enrichir, etc, etc.

Le Datawarehouse pouvait conserver des données sur des années, voir des décennies (à moins d'archiver les données dans un système annexe). Pour cela on utilisait le partitionnement. Ensuite on en faisait des Datamarts, chaque Datamart étant censé répondre à des besoins métiers.

Le plus important dans tout cela, c'est qu'il ne faut pas oublier que, qui dit SGBDR, dit données structurées, même si avec les années les SGBDR gèrent maintenant des types de données non primitifs, comme le XML, le JSON, et à priori les graphes (sous Oracle par exemple, l'option Spatial est devenue Spatial and Graph).



Oui mais voilà, nous avons maintenant affaire avec des données qui sont maintenant non structurées ou partiellement structurées (variété des données), et avec du volume. De plus on a affaire à ce qu'on appelle un "déluge" des données, les données arrivant de plus en plus en vite, ou avec une périodicité très rapprochée, ce qui fait que l'on est amené à les consommer en "temps réel", en Streaming. C'est ce qu'on appelle la vélocité des données.

Et j'ai donc évoqué les fameux 3V du Big Data : volume, variété, vélocité. tout cela ne rentre plus dans les SGBDR classiques.


On a donc des fichiers texte, des fichiers de Log, du JSON, du XML, des fichiers au format Parquet ou Avro, ou d'autres formats plus exotiques je pense pour gérer des images ou bien des données en provenance des IOT.

Tout cela, il faut bien le stocker qq part, et le stockage se fait pour moi en grande partie dans un Datalake, le Datalake reposant techniquement sur le HDFS d'Hadoop, un File System distribué sur un cluster, donc un ensemble de machines (physiques ou virtuels) à "bas coût" (le fameux Commodity Hardware).

On peut aussi stocker des données dans une base NoSQL, sachant qu'il y a 4 types de bases de données NoSQL :
- orienté clé/valeur comme Riak, Redis, DynamoDB
- orienté documents comme MongoDB, CouchBase ou Apache CouchDB pour stocker du JSON
- orienté colonnes comme HBase ou Cassandra, pour stocker les données non plus en lignes, mais en colonnes (avec un regroupement de colonnes en famille)
- orienté graphes comme Neo4j

2-HBASE représente t-il l'interface du HDFS ?

HBase n'est pas l'interface du HDFS. HBase est une application, et plus particulièrement une bases de données NoSQL orientée colonne, faisant partie de l'écosystème Hadoop.

HBase est, comme bon nombre de logiciels de type BigData ou NoSQL, hautement scalable. C'est-à-dire que pour augmenter la puissance de calcul, on fait de la scalabilité horizontale : en clair, on rajoute des machines (physiques ou virtuels et que l'on appelle des noeuds) dans le cluster.

Aujourd'hui, il ne faut plus raisonner serveur (j'ai mon petit serveur et j'installe ma petite base de données relationnelles), mais cluster !

On a affaire à des architectures de type Shared Nothing, à savoir que les nœuds du cluster ne partagent aucune ressource, que soit CPU, mémoire et encore moins disque.
Cela s'appelle du Sharding en NoSQL, mais même Oracle en fait dans sa dernière version 12cR2 (jamais essayé).

3-Quel type d'information doit être considérée comme famille de colonnes dans les bases noSQL en colonne (HBASE)? par exemple: l'entité client, commande peuvent être considérés comme des familles de colonnes?

Il n'y a pas de réponse toute faite à cela.

Les familles de colonnes sont un regroupement de colonnes qui ont à la fois du sens fonctionnel pour toi, et sur lesquelles tu vas appliquer par exemple des agrégats. Aujourd'hui, on veut manipuler la donnée dans tous les sens et y appliquer pas mal de calcul. C'est ce qu'on appelle de l'Analytics, et même de l'Advanced Analytics.

En fait, le problème qui se posait avec les bases relationnelles, c'est que le stockage des données se faisait dans des blocs de données, et que ces blocs stockaient des lignes. Si tu as une table client qui dispose de 100 attributs, et que tu fais un SELECT sur 3 attributs pour faire un Group By par exemple, la base de données elle travaille sur des lignes entières et est obligée de faire des IO disques pour ramener les lignes avec leurs 100 attributs, alors que tu n'as que faire des 97 champs restants.

C'est pour cela que l'on a inventé le stockage en colonne, et même Oracle en fait pour sa base de données, mais pour cela il faut avoir soit un Exadata, soit une baie de stockage ZFS ou une baie de stockage Pillar Data System.

Le stockage en colonne, c'est aussi compresser la donnée. On faisait déjà de la compression de données avec des lignes, mais celui-ci est beaucoup plus performant en stockant des colonnes et non pas des lignes, car la répétition des données peut augmenter, et donc le taux de compression.

Et puis pour finir, en maintenant quelques statistiques descriptives sur les blocs de colonnes, on peut en éliminer un grand nombre à la lecture. Imagine que je gère dans une famille les noms, prénoms et âges des 67 millions de Français. Si je recherche la tranche d'âge 18-25 ans par exemple, et qu'au niveau des blocs, on connaît les âges min et max, il n'y a même pas besoin de lire le contenu d'un bloc de colonnes qui contiendrait des personnes ayant entre 40 et 45 ans, d'où une rapidité de lecture accrue.

Pour conclure, je dirai que l'on assiste aujourd'hui, et même depuis plusieurs années, à une rupture technologique, et que les technologies comme le stockage en colonnes des données, la compression de données, le traitement en mémoire (In-Memory), et les Frameworks tournant sur des clusters seront de plus en plus utilisées.

[itachis]

Rouardg, merci pour votre reponse.
Cependant, la première question reste toujours floue pour moi. Je comprends par data lake, une seule table en colonne dans laquelle on stocke toute les données (une grande table HBASE par exemple), est ce vrai?
-quel est le nombre raisonnable de familles de colonnes qu'une base en colonne (HBASE) peut prendre sans pour autant mettre en cause la perf?
-En ce qui concerne la deuxième question: si je comprends bien HDFS et HBASE sont complètement indépendantes, c'est à dire qu'on a le choix de stocker les données, soit sur HDFS, soit sur HBASE?

[rouardg]

Pour faire très simple : un Data Lake n'est qu'un immense espace de stockage sur lequel vous allez déposer vos fichiers de données. Point barre. On ne parle pas de HBase pour le moment.

Exemple : supposons que vous ayez un PC équipé de 3 disques durs de 2 To chacun. Réservons le premier disque dur à Linux et à ses Files Systems locaux, pour y stocker localement des données.
Il vous reste donc 2 disques durs de libre, soit 4 To au total.

Trouvez-vous une bande de 26 copains qui ont chacun le même PC que vous, et mettez vos 27 PC en réseau. Installez Hadoop et vous voilà à la tête d'un cluster Hadoop.

Si l'on considère que sur les 27 PC, 2 sont réservés à la gestion du cluster, il vous reste 25 PC ayant chacun 4 To de disque. En fait, vous allez avoir au final un File System distribué (que l'on appelle HDFS) d'une capacité totale de 25 * 4 = 100 To

Vous avez 100 To d'espace disque total, que vous organisez comme bon vous semble, et vous déposez dessus autant de fichiers que vous le souhaitez. Voilà, c'est ça grosso modo un Data Lake.

Attention tout de même au fait que par défaut, les fichiers déposés sous HDFS sont répliqués 3 fois au total. Du coup, ce n'est pas 100 To de capacité utile que vous avez, mais seulement 100 / 3 = 33 To

Par exemple, si vos fichiers font en moyenne 128 Mo, on peut en stocker au total 33 * 1024 * 1024 / 128 = 270.336 fichiers

Vous pouvez tous les stocker sous un même répertoire sous HDFS, mais avouez que vous n'allez pas vous en sortir pour les gérer.

Aussi vous allez faire une arborescence, avec des répertoires, pour les gérer et les stocker.

Avoir un DataLake, c'est comme avoir un disque dur local de 2 To bourrés de centaines de milliers de fichiers, voir de millions.

Il faut s'y retrouver, donc indexer ces fichiers, les sécuriser, les documenter pour savoir ce qu'ils contiennent et pour que les autres personnes s'y retrouvent.

Voilà pour la partie purement Data Lake qui n'est encore une fois qu'un immense espace de stockage. On peut aussi faire autrement car il n'y a pas que le HDFS qui peut servir d'espace de stockage. Certains se servent par exemple du service de stockage S3 d'AWS (Amazon Web Services), mais ce n'est encore qu'un immense espace de stockage.

[rouardg]

En ce qui concerne la deuxième question: si je comprends bien HDFS et HBASE sont complètement indépendantes, c'est à dire qu'on a le choix de stocker les données, soit sur HDFS, soit sur HBASE?

Oui. HDFS est juste un système de fichiers distribué. Tu stockes dessus tes fichiers de données, au format brut : du CSV, du texte, de la Log, du JSON, du XML, pour les traiter ultérieurement avec ce que tu veux : du MapReduce, du Spark, du développement Python...

Mais tu as aussi le choix de stocker ces données non pas dans des fichiers, mais en base.

HBase est une base de données NoSQL orientée colonnes, fait partie de l'écosystème Hadoop, fonctionne en cluster et stocke ses données sur HDFS. Pour fonctionner, et comme c'est un système distribué, elle a aussi besoin d'un orchestrateur qui s'appelle ZooKeeper et qui fait partie de la stack Hadoop.

Après je ne m'y connais pas assez pour te dire si HBase tourne sur autre chose que de l'HDFS, comme Spark qui tourner sur de l'HDFS, mais aussi sur S3.


Je ne suis pas non plus calé en HBase pour répondre à ton autre question :

-quel est le nombre raisonnable de familles de colonnes qu'une base en colonne (HBASE) peut prendre sans pour autant mettre en cause la perf?

Désolé

[itachis]

Ok d'accord merci qu'à même.

[jvc35]

Bonjour,

Débutant sur le sujet data lake, et ayant lu pas mal d'article, je suis plus que jamais, dans une confusion totale. Ci-dessous quelques questions pour m'aider à comprendre le mecanisme:
1-Dans un data lake, le stockage se fait dans une seule et unique table?
2-HBASE représente t-il l'interface du HDFS?
3-Quel type d'information doit être considérée comme famille de colonnes dans les bases noSQL en colonne (HBASE)? par exemple: l'entité client, commande peuvent être considérés comme des familles de colonnes?

Merci par avance .

Bonjour itachis,

j'espère que tu te portes bien.
Pour répondre ensemble à toutes tes questions, l'approche Data Lake est très similaire à l'approche Data Warehouse. Donc, l'idée c'est de centraliser le stockage du niveau de granularité le plus fin possible des données dans un cluster de noeuds commodes.
2 - Non. HBase n'est pas une interface, et encore moins celle du HDFS. HBase est un SGBD NoSQL orienté colonne. Pour plus de détails sur HBase, je te recommande le tuto suivant : https://juvenal-chokogoue.developpez.com/tutoriels/apprendre-travailler-hbase/
3- je te renvoie au tuto sur HBase.

J'espère que ma contribution répond à tes questions,

Juvénal