- Le domaine de la gestion des données évolue rapidement, et avec la montée en puissance du stockage cloud et de la demande en analyse temps réel, le concept de Data Lakehouse s’impose
- Des projets comme Apache Iceberg, Apache Hudi et Delta Lake ont apporté à l’architecture Lakehouse des fonctions clés comme l’évolution de schéma, les transactions ACID et les mises à jour efficaces
- Le système interne de Google, Napa, propose une approche encore plus avancée que les solutions Lakehouse actuelles
- En y ajoutant des idées issues d’autres systèmes comme Apache Pinot, l’article propose LakeDB, une nouvelle génération de Lakehouse
Environnement Lakehouse actuel : Iceberg, Hudi, Delta Lake
- Apache Iceberg
- Prend en charge l’évolution de schéma, le time travel et une planification de requêtes efficace grâce à une gestion sophistiquée des métadonnées
- Fournit des garanties de cohérence pour les jeux de données analytiques à grande échelle
- Apache Hudi
- Utilise un stockage de type log-structured et l’indexation pour traiter efficacement les upserts, les suppressions et la CDC (capture des changements de données)
- Met l’accent sur les mutations de données et le traitement incrémental
- Delta Lake
- Fournit des transactions ACID pour Spark et les workloads big data
- Prend en charge la validation de schéma, le time travel et le traitement unifié batch/streaming
- Propose en partie des pipelines déclaratifs et des vues matérialisées via Delta Live Tables
Napa de Google : une approche macro
- Système complet de gestion de données analytiques, il prend en charge des requêtes à faible latence et une ingestion continue sur de très grands volumes de données
- Ingestion basée sur les LSM (Log-Structured Merge)-Tree
- Adopte une approche LSM-tree pour offrir un fort débit d’écriture, avec une structure qui fusionne les données existantes via compaction
- Utilisation de vues matérialisées
- Maintient et met à jour automatiquement des vues matérialisées pour accélérer les requêtes
- Queryable Timestamp (QT)
- Assure une gestion cohérente des points temporels à l’échelle du système
- Permet d’ajuster finement l’équilibre entre fraîcheur des données et performance des requêtes
- Intégration avec F1 Query
- Exploite le moteur F1 Query de Google pour traiter efficacement des requêtes analytiques complexes
- Grande configurabilité
- Permet d’ajuster la fraîcheur des données, les performances, les coûts, etc. selon les besoins des utilisateurs
Comparaison entre Napa, Iceberg, Hudi et Delta Lake
- Napa est un système global de gestion de données analytiques : il prend en charge des requêtes rapides grâce à des vues matérialisées basées sur LSM, et permet un contrôle fin de la fraîcheur des données grâce à une technique appelée Queryable Timestamp (QT). Il est utile quand on veut analyser et restituer rapidement de très grands volumes de données, et sa grande souplesse de configuration permet d’équilibrer correctement coûts, performances et fraîcheur.
- Iceberg est un projet centré sur le format de table : il gère de grands fichiers de données via des métadonnées et fournit des fonctions comme les mises à jour atomiques. Il est principalement utilisé dans des environnements de data lake qui ont besoin de fonctions de data warehousing, d’évolution de schéma ou de time travel, et ses options de configuration portent surtout sur le layout des tables et les métadonnées.
- Hudi est une plateforme qui ajoute aux data lakes des fonctions proches de celles d’une base de données : grâce à un stockage log-structured et à des techniques d’indexation, elle traite efficacement les opérations de mutation de données comme les upserts ou les suppressions. Elle a aussi été conçue pour bien répondre aux besoins d’ingestion temps réel, de CDC (capture des changements de données) et d’exigences réglementaires comme le RGPD, mais elle ne fournit pas nativement de vues matérialisées.
- Delta Lake est une couche de stockage qui prend en charge les transactions ACID : elle traite de façon unifiée les opérations batch et streaming, tout en fournissant aussi la schema enforcement et le time travel. Pour améliorer les performances des requêtes, elle s’intègre à Spark et exploite le data skipping ainsi que le caching, et prend également en charge des concepts proches des vues matérialisées via Delta Live Tables. Il est souvent utilisé lorsque l’on veut ajouter fiabilité et capacités transactionnelles à divers environnements de data lake.
L’argument en faveur de LakeDB : inspiré par Napa, enrichi ailleurs
- En combinant des idées innovantes de Napa et d’Apache Pinot, l’article propose le concept de LakeDB, plus intégré et plus flexible
- LakeDB vise une solution de gestion de données où l’utilisateur exprime de manière déclarative ses besoins (fraîcheur, coût, cohérence, utilisation des index, etc.) et où le système optimise automatiquement le reste
1. Intégration du stockage, de l’ingestion, des métadonnées et du traitement des requêtes
- Un seul système réunit le stockage, l’ingestion, les métadonnées et le traitement des requêtes
- L’utilisateur n’a qu’à définir la fraîcheur et la cohérence des données, et les opérations nécessaires sont ajustées automatiquement
- Iceberg, Hudi et Delta Lake exigent ici l’intégration d’outils séparés, ce qui accroît la complexité
2. Optimisation intelligente des vues matérialisées et du layout des données
- Bascule automatiquement entre les approches CoW (Copy-on-Write) et MoR (Merge-on-Read) selon le workload
- Crée et gère de manière appropriée snapshots et vues matérialisées selon les exigences de performance et de coût définies par l’utilisateur
- Avec Hudi, Delta Lake et Iceberg, ce processus doit le plus souvent être configuré manuellement
3. Contrôle fin de la fraîcheur des données
- Comme avec le QT de Napa, l’utilisateur peut définir le niveau de fraîcheur souhaité, et le système trouve alors le bon compromis entre performance et coût
- Dans les systèmes existants, il était difficile de garantir le temps réel, car ils reposaient sur des snapshots périodiques et du monitoring
4. Indexation et partitionnement avancés inspirés d’Apache Pinot
- Prend en charge des méthodes d’indexation avancées comme Star-Tree, rendant possible le traitement d’analyses à forte cardinalité
- Cherche des gains de performance au-delà du partitionnement simple et du data skipping d’Iceberg et de Delta Lake
5. Configuration flexible
- Plusieurs consommateurs d’une même table peuvent appliquer des réglages différents selon leurs exigences respectives en matière de performance, de coût et de fraîcheur
- Les systèmes existants offrent une plage de configuration limitée, ce qui impose souvent de nombreux réglages manuels pour répondre à des workloads variés
6. Prise en charge d’ACID et de l’évolution de schéma
- Reprend et étend les bases d’ACID et de l’évolution de schéma d’Iceberg et de Delta Lake
- Vise à automatiser les modifications de schéma concurrentes et les garanties de cohérence des données dans les environnements distribués
7. Ouverture et extensibilité
- Prend en charge les standards ouverts et l’intégration avec divers moteurs de requêtes, avec la possibilité d’étendre le système selon les besoins
- Évite la dépendance à un fournisseur ou à une plateforme spécifique, et permet d’appliquer les fonctions avec souplesse selon les besoins des utilisateurs
Pourquoi LakeDB serait la prochaine évolution
- Performance : se rapproche de vitesses de niveau OLAP grâce à des index avancés, des vues matérialisées et une optimisation dynamique du layout des données
- Simplicité : offre les fonctions de gestion dans un système unique, avec un ajustement automatique à partir des seuls besoins utilisateur (fraîcheur, performance, etc.)
- Efficacité : réduit l’utilisation des ressources et la charge opérationnelle, avec des avantages attendus aussi sur les coûts
- Flexibilité : peut répondre à des workloads variés grâce à un contrôle fin de la fraîcheur des données et à de riches options de configuration
- Analyse temps réel : adopte les techniques d’indexation d’Apache Pinot pour viser à la fois une faible latence et un haut débit
Conclusion
- Apache Iceberg, Apache Hudi et Delta Lake ont joué un rôle majeur dans l’évolution du concept de Lakehouse
- En combinant l’approche Napa de Google avec les idées venues d’Apache Pinot et d’autres projets, on peut envisager une vision de LakeDB plus intégrée et plus puissante
- LakeDB a un fort potentiel pour devenir une architecture de gestion des données de nouvelle génération, en tant que système intégré complet couvrant le stockage, l’ingestion, les métadonnées et le traitement des requêtes
Aucun commentaire pour le moment.