La technique d'un Data Lake

En général, je diviserais les options de stockage des données en trois catégories. Files : les données sont stockées sous forme de fichiers simples et utilisées comme des tableaux.

Ces fichiers devraient avoir des informations sur la structure et devraient également être indexés en eux-mêmes. Le format de fichier parquet est un représentant de cette catégorie.

Processus de base de données : au lieu de travailler directement avec les fichiers, un service actif se trouve par-dessus et il se sent comme une base de données. Il s'occupe de la mise en cache des données souvent utilisées et peut être interrogé via ODBC/JDBC. Un représentant typique de ce genre dans le monde des Big Data est Apache Hive.

In-memory : pour une performance maximale, on place toutes les données en mémoire, on les indexe et on construit ainsi quelque chose de similaire à Hana. Exasol et SAP Vora fonctionnent selon ce principe.

Le monde des Big Data vit uniquement du fait que de nombreux petits serveurs (et donc bon marché) forment un système global. On peut ainsi évoluer à l'infini, les coûts de matériel n'augmentant que de manière linéaire.

Mais plus il y a de nœuds dans le système global, plus leur synchronisation est coûteuse. Une jointure de trois tables, voire plus, peut signifier que chaque nœud doit aller chercher les résultats intermédiaires appropriés de la jointure précédente et que la requête dure des heures.

Ce problème s'appelle le "reshuffle". Le fait que les données soient en mémoire n'aide évidemment pas non plus à la redistribution des résultats intermédiaires sur le réseau.

Hana, quant à elle, est une véritable base de données. Elle est extrêmement rapide pour les recherches. Les performances de jointure sont excellentes, on a une cohérence transactionnelle totale en lecture et en écriture. Tout cela demande beaucoup de synchronisation.

En revanche, une telle base de données ne s'adapte pas indéfiniment. De nombreux projets résolvent le dilemme du "reshuffle" en stockant les données de manière optimisée pour certaines requêtes. Cela réduit à nouveau la flexibilité et augmente les coûts, c'est-à-dire précisément les points que l'on souhaitait avoir comme avantage d'un Data Lake.

Le coût de synchronisation de la cohérence des transactions est un problème logique. Il ne peut pas être résolu sans imposer des exigences plus souples, telles que la "cohérence éventuelle".

Ce problème est appelé théorème CAP. Parmi les trois exigences Consistency-Availability-Partitioning, tous les points ne peuvent jamais être atteints, en particulier en cas d'erreur.

Un système hautement disponible et distribué doit faire des concessions sur la cohérence des données, un système de base de données transactionnel doit faire des concessions sur la disponibilité ou l'évolutivité.

Les données présentes dans les Big Data sont des données brutes qui se transforment en informations par des transformations non-SQL - ainsi, un entrepôt de données basé sur les Big Data avec des requêtes SQL n'a pas de sens.

Le Data Lake est le terrain de jeu du Data Scientist. Cette personne peut y accéder facilement à des données qui ont été supprimées auparavant ou auxquelles on ne pouvait accéder que difficilement.

Le data scientist peut gérer tous les problèmes liés aux techniques de big data : La sémantique des données ; la lenteur des performances ; et quelles données il y a. Mélanger des données Big Data et des données commerciales ? Pas de problème pour lui.

Coupler Hana avec Vora n'a pas beaucoup de sens selon ce raisonnement. Tous deux stockent les données en mémoire et permettent des recherches rapides - à un coût correspondant. Les deux ont un stockage à chaud sur disque (base de données Sybase), les deux se concentrent sur les requêtes SQL. Vora n'est d'ailleurs plus un produit autonome sur la liste de prix de SAP.

En revanche, les fichiers parquet et une base de données se complètent parfaitement. Les fichiers parquet dans un Data Lake ne coûtent pratiquement rien en termes de stockage, alors que dans une base de données, l'espace de stockage coûte cher.

Une base de données comme Hana est excellente pour les jointures et les requêtes SQL compliquées, mais pour un cluster de calcul, ce sont précisément ces opérations qui sont les plus coûteuses.

La combinaison des deux donne donc des requêtes rapides de Business Intelligence et un accès confortable à toutes les données brutes. Les deux apportent leurs points forts.