DuckLake - Un format unifié de data lake et de catalogue

• Une nouvelle solution qui unifie le data lake et le format de catalogue
• Fonctionne sur la base de fichiers Parquet et d’une base de données SQL, et permet une implémentation de data lake plus simple qu’un lakehouse traditionnel
• Permet la gestion d’un catalogue de métadonnées au-dessus de plusieurs bases de données comme PostgreSQL, SQLite, MySQL, DuckDB
• Prend en charge diverses fonctionnalités comme les snapshots, requêtes time travel, évolutions de schéma, partitionnement, tout en offrant une gestion légère des snapshots qui ne nécessite pas de compaction fréquente
• Prend en charge le modèle DuckDB multijoueur, où plusieurs instances peuvent lire et écrire les données simultanément, avec un modèle de concurrence que DuckDB de base ne prend pas en charge
• DuckLake désigne un ensemble couvrant la spécification, l’extension DuckDB et les jeux de données stockés au format DuckLake, et est publié sous licence MIT

---

Présentation de DuckLake

• DuckLake est un format ouvert créé par l’équipe DuckDB, qui fournit des fonctionnalités avancées de data lake sans lakehouse complexe
• Avec seulement une base de données SQL et des fichiers Parquet, il est possible de construire son propre data warehouse.
• Utilise une base de données pour la gestion des métadonnées : PostgreSQL, SQLite, MySQL, DuckDB

Principales fonctionnalités de DuckLake

• Opérations de data lake

  • Snapshots
  • Consultation à un instant donné (Time travel)
  • Évolution du schéma
  • Partitionnement

• Gestion légère des snapshots

  • Possibilité d’en créer un nombre illimité
  • Fonctionne sans nécessiter de compaction fréquente

• Transactions ACID

  • Garantit l’accès concurrent et les transactions pour les opérations multi-tables

• Conception orientée performances

  • Utilisation de statistiques pour le filter pushdown
  • Requêtes rapides même sur de grands jeux de données

Questions fréquentes

• Pourquoi utiliser DuckLake ?

  • Convient si l’on a besoin d’une solution légère unifiant data lake et catalogue
  • Permet un environnement multijoueur où plusieurs instances DuckDB lisent et écrivent sur le même jeu de données
    • Il s’agit d’un modèle de concurrence non pris en charge par DuckDB classique
  • Même avec DuckDB seul, on peut bénéficier d’avantages comme la consultation à un instant donné, le partitionnement et une structure de stockage multi-fichiers

• Qu’est-ce que DuckLake ?

  • DuckLake désigne les trois éléments suivants :
    1. La spécification du format DuckLake (specification)
    2. L’extension DuckDB prenant en charge DuckLake (ducklake extension)
    3. Le jeu de données lui-même stocké au format DuckLake

• Quelle est la licence de DuckLake ?

  • Publié sous licence MIT

[GN⁺]

Commentaires Hacker News

• Il y a toujours un point qui m’a laissé sur ma faim avec Parquet : tout ce qui touche au « ranged partitioning », que les différents « data lake / lakehouse » ont résolu chacun de leur côté de manière incompatible. Mon application correspond presque parfaitement à Parquet, mais elle traite des données comme des logs de séries temporelles où les timestamps ne sont pas répartis uniformément. Les colonnes de partition suivent le partitionnement Hive, tout en étant naturellement découpées selon les timestamps. Le problème, c’est que le partitionnement Hive ne prend pas cela en charge, donc les principaux outils de requête n’importent pas correctement la structure de mes données. On peut introduire des méthodes inutiles comme une colonne basée sur la date, ou simplement empiler les fichiers, mais cela pose des problèmes de performances et de coût. Iceberg, Delta Lake, etc. permettent le ranged partitioning, mais je n’ai pas besoin de toute cette complexité ; j’aimerais plutôt qu’une convention plus simple de nommage de fichiers ou de répertoires soit standardisée. Et puis, même si les formats Parquet row, Arrow row, Thrift, protobuf, etc. se ressemblent beaucoup, ils ne sont pas totalement identiques ; je pense qu’un format binaire compagnon pour une ligne unique ou un flux de lignes améliorerait l’interopérabilité entre les différents outils

  • Je me demande si les seules métadonnées de footer d’un fichier Parquet ne suffisent pas déjà à obtenir les informations nécessaires. Les métadonnées contiennent les timestamps min/max de la colonne concernée, donc au moment de la requête, l’outil pourrait lire uniquement ces métadonnées pour décider s’il faut lire le fichier ou non, et éviter ainsi des lectures inutiles

  • Les données temporelles sont difficiles à manipuler, mais selon la méthode utilisée, on peut parfois contourner le problème. Au lieu d’interroger directement la série temporelle brute, il peut être utile de normaliser et stocker les timestamps au stade du traitement des événements. En s’appuyant sur une fenêtre glissante pour trouver le point de départ de l’événement et ajuster l’offset, on peut identifier l’endroit où la série revient au point de référence (0) et s’en servir comme unité d’événement

  • Hive prend en charge deux types de partitionnement : injected et dynamic. On peut utiliser comme clé de partition une colonne hour basée sur le temps UNIX (un entier qui augmente de 3600 secondes depuis l’époque). Il faut parfois préciser dans le moteur de requête la plage de partitions à interroger, mais on peut l’utiliser dans une requête sous la forme datepartition >= a AND datepartition < b. Iceberg permet cela de façon beaucoup plus simple avec des plages de timestamps, et exclut automatiquement les partitions sans intérêt sans nécessiter de métadonnées

  • Dans les bibliothèques bas niveau arrow/parquet, on peut contrôler directement les row groups et les pages de données. J’ai déjà utilisé la crate arrow-rs pour améliorer de plus de 10x la vitesse de requête sur des fichiers. Il y a parfois peu de row groups, parfois énormément, mais comme on peut ignorer très rapidement uniquement ceux qu’on veut, le skew ne pose pas problème. Il faut toutefois faire attention à la limite de 2^15 row groups par fichier

  • Ce problème tient moins à Parquet qu’aux limites de Hive. Il faut ouvrir le fichier Parquet pour consulter les informations min/max des colonnes, mais ensuite, s’il n’y a pas de données dans la plage visée, il n’y a pas de requête supplémentaire. Il serait plus efficace d’exploiter ce type de métadonnées à un niveau supérieur, par exemple dans quelque chose comme DuckLake

• L’un des aspects les plus gênants avec Iceberg (Delta Lake est similaire, mais personnellement je trouve Iceberg un peu plus difficile), c’est qu’il est compliqué à essayer dans un notebook ou en local. Delta Lake a plusieurs implémentations Python, mais elles sont fragmentées, et Iceberg impose souvent des contraintes pénibles comme la mise en place d’un cluster JVM. J’essayais d’utiliser une combinaison sqlite/postgres + duckdb + parquet, stockée sur du blob storage, mais c’était assez fastidieux. Du côté de DuckDB, au contraire, cela fonctionne directement sans tous ces efforts, et ça monte naturellement en charge jusqu’à des volumes de données raisonnables. L’équipe DuckDB comprend vraiment bien ce domaine, et j’en attends beaucoup

  • Je me demande si tu as déjà essayé PyIceberg. C’est une implémentation pure Python, et ça fonctionne plutôt bien. Il prend aussi en charge un SQL Catalog et un catalogue en mémoire basé sur SQLite
    https://py.iceberg.apache.org/

  • Il existe un guide d’installation étape par étape avec S3 et RDS. Le remplacer par un sqlite local ne devrait pas être difficile
    https://www.definite.app/blog/cloud-iceberg-duckdb-aws

  • On peut vraiment l’essayer très facilement en local. Dans un notebook marimo, cela tient en quelques lignes de code (à noter : je suis développeur de marimo)
    https://www.youtube.com/watch?v=x6YtqvGcDBY

  • Je réfléchis à faire un chart Helm qui fonctionne bien avec k3s. Avec datapains, on peut aussi déployer trino facilement et, avec un peu d’ajustement, lancer aussi hivemetastore. J’ai expérimenté l’ensemble en reliant le connecteur Iceberg à trino. La structure consiste à charger les données dans hive, faire pointer trino vers la même table, puis faire un select pour insérer dans iceberg. Si DuckDB propose un environnement qui fonctionne vraiment simplement, il pourrait aussi prendre la main sur le marché

  • delta-io (basé sur deltalake-r) fonctionne très facilement en local. On l’installe via pip et on peut immédiatement écrire dans le catalogue et les fichiers
    https://delta-io.github.io/delta-rs/

• Cette critique d’Iceberg touche juste — puisqu’on utilise de toute façon une base de données, pourquoi faut-il stocker et gérer les métadonnées dans des fichiers ? DuckLake aura sans doute du mal à réussir largement au-delà de DuckDB, mais au final, on pourrait se retrouver avec une architecture où le catalogue prend aussi en charge les métadonnées, et où le format Iceberg actuel ne serait plus qu’un moment de l’histoire

• Les systèmes Lakehouse existants (Iceberg, etc.) répartissent des informations cruciales sur les tables, comme le schéma ou la liste des fichiers, dans de petits fichiers de métadonnées stockés sur de l’object storage comme S3. Cela entraîne beaucoup d’appels réseau pour la planification des requêtes ou les mises à jour de table, ce qui les rend plus lents et plus sujets aux conflits. DuckLake place toutes les métadonnées dans une base SQL rapide et transactionnelle, ce qui permet de récupérer toutes les informations nécessaires en une seule requête, avec une efficacité et une fiabilité bien supérieures

• Manifeste lié à DuckLake : https://ducklake.select/manifesto/

• En interne, je suis en train de développer un « poor man’s datalake » en utilisant les bindings Python de deltalake-rs et duck db. L’architecture repose sur le stockage de fichiers parquet dans du blob storage. Mais j’ai toujours des problèmes lors des écritures concurrentes. Qu’une fonction cloud récupère périodiquement des données via une API ne pose pas de problème. Mais si je lance plusieurs backfills, ils risquent de s’exécuter en même temps que la fonction timer et d’entrer en conflit. C’est encore pire quand on empile des centaines de tâches dans la file de backfill et que les workers sont saturés

  • Il y a la méthode qui consiste à ajouter un suffixe aléatoire à la fin des noms de fichiers

  • On peut aussi poser un lease temporaire sur un fichier json avant l’écriture et gérer les requêtes d’écriture via une file d’attente pour éviter les conflits

• Une solution concurrente qui cherche à résoudre les limites d’Iceberg, notamment sur la gestion des métadonnées (par exemple, Snowflake utilise FoundationDB pour gérer ses métadonnées, alors qu’Iceberg va jusqu’au blob storage)
  https://quesma.com/blog-detail/apache-iceberg-practical-limitations-2025

  • J’ai eu une impression similaire, mais si on regarde la vidéo, DuckLake n’est pas un concurrent direct
    https://youtu.be/zeonmOO9jm4?t=4032
    DuckLake n’écrit les fichiers manifest/metadata pour Iceberg et ne synchronise que lorsque c’est nécessaire, et il prend déjà en charge la lecture de données Iceberg. Il améliore le problème central d’Iceberg plutôt que de proposer un produit concurrent séparé ; c’est plutôt une architecture proprement interopérable avec Iceberg dans les deux sens

  • Le gonflement des métadonnées peut être géré dans bien des cas selon la situation

    • nombre de snapshots
    • changements fréquents et massifs de schéma
    • mises à jour fréquentes au niveau ligne / grand nombre de petits fichiers
    • informations statistiques, etc.
      Autrefois, avec les gros schémas, le dernier point posait problème. La plupart des moteurs fournissent des outils comme la compaction ou l’export de snapshots pour gérer cela, même si cela reste aussi de la responsabilité de l’utilisateur. Les S3 tables offrent certaines fonctions de gestion. Si les métadonnées font entre 1 et 5 MB, ce n’est franchement pas un problème. La vitesse de commit dépend de la taille des métadonnées et du nombre de writers. J’ai déjà résolu moi-même, par script, des métadonnées de plus de 1 GB — en général, il suffit de nettoyer les snapshots écrasés (et de déléguer la suppression réelle des fichiers à la bucket policy), ou de purger les anciennes versions de schéma

• Au final, pour construire correctement une base de données, il faut la construire comme une vraie base de données. Impressionné par l’équipe DuckDB

• Je me demande quelle est la relation avec Mother Duck(https://motherduck.com/). C’est une entreprise qui fait du « DuckDB-powered data warehousing » et qui a démarré avant DuckLake

  • MotherDuck et DuckLake devraient être très bien intégrés. Les données MotherDuck seront stockées dans DuckLake, ce qui améliorera la scalabilité, la concurrence et la cohérence, tout en permettant à des outils tiers d’accéder aux données sous-jacentes. Nous travaillons là-dessus depuis quelques mois et nous partagerons bientôt davantage d’informations

  • MotherDuck est un service qui nettoie automatiquement les données que vous chargez et fournit une interface de données via DuckDB. Si vous voulez des caractéristiques plus lakehouse, une intégration avec le blob storage, davantage d’intégration avec DuckLake ou stocker les métadonnées dans MotherDuck, vous pouvez utiliser DuckLake

  • MotherDuck est un service qui héberge duckdb dans le cloud, tandis que DuckLake est un système beaucoup plus ouvert. Avec DuckLake, on peut construire sur S3, EC2 et d’autres environnements un data warehouse à l’échelle du pétaoctet, avec plusieurs instances, plusieurs readers/writers, le tout de manière transactionnelle. Dans MotherDuck, un seul writer est possible à la fois, les read replicas ont environ une minute de latence et ne sont pas transactionnels. Plusieurs instances ne peuvent pas écrire simultanément dans des tables différentes. DuckLake fournit aussi la séparation du stockage et du calcul, ainsi qu’une couche de métadonnées fortement transactionnelle

• J’adore duckDB et DuckLake me semble aussi vraiment génial. Une question : si je commençais à l’utiliser maintenant, dans une entreprise qui exploite déjà Snowflake, les analystes devraient chacun installer duckdb + les extensions en local, puis pointer vers le blob store et la base utilisée pour l’extension datalake (par exemple un duckdb lancé sur une VM). Où le calcul a-t-il lieu au moment d’exécuter les requêtes, et comment faire pour des traitements plus lourds ? Est-ce que cela veut dire que tous les utilisateurs doivent se connecter en ssh à une énorme VM duckdb pour lancer leurs requêtes ? J’aimerais avoir des explications sur ce point

  • Si on exécute duckdb en local, le calcul a lieu sur le PC de chacun. Si davantage de calcul est nécessaire, on peut lancer une VM pour cela. Les deux sont possibles — en local pour les petits travaux, et sur VM pour monter en charge sur des workloads plus lourds