- Eine neue Lösung, die Data Lake und Katalogformat integriert
- Basiert auf Parquet-Dateien und SQL-Datenbanken und ermöglicht eine schlankere Data-Lake-Implementierung als herkömmliche Lakehouses
- Metadatenkataloge können über verschiedene Datenbanken hinweg verwaltet werden, darunter PostgreSQL, SQLite, MySQL und DuckDB
- Unterstützt verschiedene Funktionen wie Snapshots, Time-Travel-Abfragen, Schemaänderungen und Partitionierung und bietet zugleich eine leichtgewichtige Snapshot-Verarbeitung, die keine häufige Kompaktierung erfordert
- Unterstützt ein Multiplayer-DuckDB-Modell, in dem mehrere Instanzen gleichzeitig Daten lesen und schreiben, und implementiert ein Nebenläufigkeitsmodell, das von standardmäßigem DuckDB nicht unterstützt wird
- DuckLake ist ein Oberbegriff für die Spezifikation, die DuckDB-Erweiterung und im DuckLake-Format gespeicherte Datensätze und wird unter der MIT-Lizenz veröffentlicht
Einführung in DuckLake
- DuckLake ist ein offenes Format des DuckDB-Teams, das fortgeschrittene Data-Lake-Funktionen ohne komplexes Lakehouse bietet
- Mit nur einer SQL-Datenbank und Parquet-Dateien lässt sich ein eigenes Data Warehouse aufbauen.
- Verwendet Datenbanken für die Metadatenverwaltung: PostgreSQL, SQLite, MySQL, DuckDB
Hauptfunktionen von DuckLake
-
Data-Lake-Operationen
- Snapshots
- Zeitpunktabfragen (Time Travel)
- Schema-Evolution
- Partitionierung
-
Leichtgewichtige Snapshot-Verarbeitung
- Snapshots können ohne Begrenzung in ihrer Anzahl erstellt werden
- Funktioniert ohne die Notwendigkeit häufiger Kompaktierung
-
ACID-Transaktionen
- Garantiert gleichzeitigen Zugriff und Transaktionen für Multi-Table-Operationen
-
Leistungsorientiertes Design
- Nutzt Statistiken für Filter-Pushdown
- Schnelle Abfragen auch bei großen Datensätzen
Häufig gestellte Fragen
-
Warum sollte man DuckLake verwenden?
- Geeignet, wenn eine leichtgewichtige Lösung gefragt ist, die Data Lake und Katalog integriert
- Eine Multiplayer-Umgebung ist möglich, in der mehrere DuckDB-Instanzen denselben Datensatz lesen und schreiben
- Dies ist ein Nebenläufigkeitsmodell, das im bisherigen DuckDB nicht unterstützt wird
- Auch bei ausschließlicher Nutzung von DuckDB lassen sich Vorteile wie Zeitpunktabfragen, Partitionierung und eine Speicherstruktur mit mehreren Dateien nutzen
-
Was ist DuckLake?
- DuckLake bezeichnet die folgenden drei Dinge:
- Die Spezifikation des DuckLake-Formats
- Die DuckDB-Erweiterung, die DuckLake unterstützt (ducklake extension)
- Den Datensatz selbst, der im DuckLake-Format gespeichert ist
-
Welche Lizenz hat DuckLake?
- Wird unter der MIT-Lizenz veröffentlicht
1 Kommentare
Hacker-News-Kommentar
Was mich an Parquet immer gestört hat: der Teil rund um „ranged partitioning“, den die verschiedenen „data lake / lakehouse“-Systeme jeweils inkompatibel für sich gelöst haben. Meine Anwendung passt fast perfekt zu Parquet, verarbeitet aber Daten wie Zeitreihen-Logs, bei denen Timestamps nicht gleichmäßig verteilt sind. Die Partitionsspalte folgt dem Hive-Partitioning, ist gleichzeitig aber auch natürlich über den Timestamp aufgeteilt. Das Problem ist, dass Hive-Partitioning das nicht unterstützt, sodass wichtige Query-Tools meine Datenstruktur nicht korrekt importieren können. Man muss dann unnötige Methoden wie datumsbasierte Hilfsspalten einführen, oder einfach Dateien anhäufen, was Performance- und Kostenprobleme verursacht. Iceberg, Delta Lake usw. unterstützen ranged partitioning, aber ich brauche diese Komplexität nicht und würde mir eher wünschen, dass einfachere Regeln für Dateinamen oder Verzeichnisnamen standardisiert würden. Außerdem sind Formate wie Parquet row, Arrow row, Thrift, protobuf usw. fast ähnlich, aber nicht komplett identisch; ich denke, ein begleitendes Binärformat für einzelne Rows oder Row-Streams würde die Interoperabilität zwischen verschiedenen Tools verbessern.
Ich frage mich, ob die Footer-Metadaten einer Parquet-Datei nicht schon ausreichen, um die nötigen Informationen zu bekommen. Die Metadaten enthalten ja den minimalen/maximalen Timestamp der jeweiligen Spalte, also könnte ein Query-Tool beim Abfragen nur diese Metadaten lesen und dadurch entscheiden, ob es die Datei lesen soll oder nicht, um unnötige Lesevorgänge zu vermeiden.
Mit Zeitdaten umzugehen ist schwierig, aber je nach Ansatz lässt sich das vermeiden. Statt die ursprüngliche Zeitreihe direkt zu queryen, kann es nützlich sein, Timestamps im Event-Processing-Schritt normalisiert zu speichern. Mit einem Sliding-Window-Ansatz kann man den Startpunkt eines Events finden und den Offset anpassen, um die Stelle zu identifizieren, an der die Zeitreihe zu einem Bezugspunkt (0) zurückkehrt; das kann dann als Event-Einheit verwendet werden.
Hive unterstützt zwei Arten von Partitionierung: injected und dynamic. Als Partitionsschlüssel kann man eine hour-Spalte auf Basis der UNIX-Zeit verwenden, also einen Integer, der sich seit der Epoche jeweils um 3600 Sekunden erhöht. Möglicherweise muss man im Query-Engine den Bereich der abzurufenden Partitionen explizit angeben, aber in Queries kann man das in der Form
datepartition >= a AND datepartition < bnutzen. Iceberg macht das deutlich einfacher, indem es direkt mit Timestamp-Bereichen arbeitet und Partitionen ohne benötigte Metadaten automatisch ausschließt.In Low-Level-Bibliotheken für arrow/parquet kann man Row Groups und Datenseiten direkt steuern. Ich habe mit dem
arrow-rs-Crate die Abfragegeschwindigkeit von Dateien um mehr als das Zehnfache verbessert. Mal gibt es nur wenige Row Groups, mal sehr viele, aber man kann die gewünschten Row Groups schnell überspringen, sodass Skew kein Problem ist. Man sollte nur beachten, dass die Zahl der Row Groups pro Datei auf2^15begrenzt ist.Das ist weniger ein Problem von Parquet als eher eine Einschränkung von Hive. Man muss eine Parquet-Datei öffnen, um die Min-/Max-Werte einer Spalte zu sehen, aber wenn die Daten dann nicht im Bereich liegen, gibt es keine weiteren Requests. Es wäre effizient, solche Metadaten weiter oben zu nutzen, zum Beispiel an einer Stelle wie DuckLake.
Einer der unangenehmsten Punkte an Iceberg (Delta Lake ist ähnlich, aber persönlich finde ich Iceberg etwas schwieriger) war für mich immer, dass man es in Notebooks oder lokalen Umgebungen nur schwer ausprobieren kann. Für Delta Lake gibt es mehrere Python-Implementierungen, aber sie sind fragmentiert, und bei Iceberg kommt der Aufwand für JVM-Cluster-Setup usw. dazu. Ich wollte eine Kombination aus sqlite/postgres + duckdb + parquet nutzen und im Blob-Storage speichern, aber das war ziemlich umständlich. Auf DuckDB-Seite funktioniert das hier sofort und skaliert ganz natürlich bis zu vernünftig großen Datenmengen. Das DuckDB-Team versteht diesen Bereich wirklich gut, und ich bin sehr gespannt.
Hast du
PyIcebergschon ausprobiert? Das ist eine reine Python-Implementierung und funktioniert ziemlich gut. Sie unterstützt auch SQL Catalog sowie einen In-Memory-Katalog auf SQLite-Basis.https://py.iceberg.apache.org/
Es gibt eine schrittweise Setup-Anleitung mit S3 und RDS. Auf lokales sqlite umzustellen dürfte auch nicht schwer sein.
https://www.definite.app/blog/cloud-iceberg-duckdb-aws
Lokal kann man das wirklich sehr einfach ausprobieren. In einem marimo-Notebook geht das mit ein paar Zeilen Code (zur Einordnung: Ich bin marimo-Entwickler).
https://www.youtube.com/watch?v=x6YtqvGcDBY
Ich überlege, ein Helm-Chart zu bauen, das gut mit k3s funktioniert. Mit datapains kann man trino ebenfalls leicht hochfahren, und mit ein wenig Feintuning auch hivemetastore. Ich habe den Iceberg-Connector mit trino verbunden und das Gesamtsystem getestet. Die Struktur ist so, dass man Daten in hive lädt, trino auf dieselbe Tabelle zeigen lässt und dann per
selectin iceberginsertet. Wenn DuckDB eine Umgebung liefert, die auf seiner Seite wirklich einfach funktioniert, könnte es in diesem Bereich auch die Führungsrolle übernehmen.delta-io(auf Basis vondeltalake-r) funktioniert lokal sehr einfach. Perpipinstallieren und sofort Kataloge sowie Dateien schreiben.https://delta-io.github.io/delta-rs/
Das ist eine treffende, scharfe Kritik an Iceberg — wenn man am Ende ohnehin eine Datenbank verwendet, warum sollte man Metadaten dann in Dateien ablegen und so handhaben? Es ist zwar unwahrscheinlich, dass DuckLake außerhalb von DuckDB breit durchstartet, aber am Ende könnte sich eine Struktur durchsetzen, in der der Katalog auch die Metadaten übernimmt, und das bestehende Iceberg-Format könnte allmählich nur noch ein Moment der Geschichte sein.
Bestehende Lakehouse-Systeme (Iceberg usw.) speichern wichtige Tabelleninformationen wie Schema und Dateiliste verteilt in kleinen Metadatendateien auf Object Storage wie S3. Dadurch werden Query-Planung und Tabellenupdates langsam oder konfliktanfällig, weil viele Netzwerkaufrufe nötig sind. DuckLake speichert alle Metadaten in einer schnellen, transaktionalen SQL-Datenbank, sodass alle benötigten Informationen effizient und zuverlässig mit einer einzigen Query geholt werden können.
Manifest zu DuckLake: https://ducklake.select/manifesto/
Ich entwickle intern gerade mit den Python-Bindings von
deltalake-rsund duck db einen „poor man’s datalake“. Die Struktur speichert Parquet-Dateien in Blob-Storage. Allerdings habe ich bei Concurrent Writes ständig Probleme. Wenn in einem bestimmten Intervall eine Cloud-Funktion Daten aus einer API zieht, ist das kein Problem. Aber wenn ich mehrere Backfills laufen lasse, laufen sie gleichzeitig mit der Timer-Funktion und es besteht Kollisionsgefahr. Besonders dann, wenn hunderte Jobs in der Backfill-Queue liegen und die Worker ausgelastet sind.Eine Möglichkeit ist, am Ende des Dateinamens einen zufälligen Suffix anzuhängen.
Man kann vor dem Write ein temporäres Lease auf eine JSON-Datei setzen und die Write-Requests über eine Queue verwalten; so lassen sich Kollisionen vermeiden.
Eine konkurrierende Lösung, die die Grenzen von Iceberg — insbesondere beim Metadatenmanagement — adressiert (zum Beispiel nutzt Snowflake FoundationDB für das Metadatenmanagement, während Iceberg bis in den Blob-Storage hinein arbeitet).
https://quesma.com/blog-detail/apache-iceberg-practical-limitations-2025
Ich hatte einen ähnlichen Eindruck, aber wenn man sich das Video ansieht, ist DuckLake kein direkter Konkurrent.
https://youtu.be/zeonmOO9jm4?t=4032
DuckLake schreibt Manifest-/Metadatendateien für Iceberg nur bei Bedarf zur Synchronisierung und unterstützt bereits das Lesen vorhandener Iceberg-Daten. Es verbessert also die Kernprobleme von Iceberg und ist weniger ein separates Konkurrenzprodukt als vielmehr eine Struktur mit sauberer bidirektionaler Integration in Iceberg.
Aufgeblähte Metadaten lassen sich je nach Situation durchaus in den Griff bekommen.
Früher war vor allem der letzte Punkt bei großen Schemata problematisch. Die meisten Engines unterstützen die Verwaltung mit Tools wie Compaction oder Snapshot-Export, auch wenn die Verantwortung teilweise beim Nutzer liegt. S3-Tabellen bieten einige Verwaltungsfunktionen ebenfalls an. Wenn Metadaten 1–5 MB groß sind, ist das in Wirklichkeit kein Problem. Die Commit-Geschwindigkeit hängt von der Größe der Metadaten und der Zahl der Writer ab. Ich habe sogar schon Metadaten mit über 1 GB per Skript bereinigt — üblicherweise reicht es, überschriebene Snapshots aufzuräumen (das Löschen der eigentlichen Dateien wird einer Bucket-Policy überlassen) oder alte Schemaversionen zu entfernen.
Am Ende gilt: Wenn man eine Datenbank richtig bauen will, muss man sie auch wie eine echte Datenbank aufbauen. Beeindruckend, was das DuckDB-Team macht.
Ich frage mich, in welchem Verhältnis das zu Mother Duck(https://motherduck.com/) steht. Das ist ein Unternehmen für „DuckDB-powered data warehousing“ und war früher da als DuckLake.
MotherDuck und DuckLake werden sehr gut integriert sein. MotherDuck-Daten werden in DuckLake gespeichert, was Skalierbarkeit, Nebenläufigkeit und Konsistenz verbessert, und gleichzeitig können auch Dritttools auf die zugrunde liegenden Daten zugreifen. Daran wurde in den letzten Monaten gearbeitet, und bald sollen mehr Informationen dazu kommen.
MotherDuck räumt automatisch auf, wenn man Daten hochlädt, und bietet über DuckDB die Datenschnittstelle an. Wenn man mehr Lakehouse-artige Eigenschaften, Blob-Storage-Anbindung, zusätzliche Integration mit DuckLake oder die Ablage der Metadaten in MotherDuck möchte, kann man DuckLake verwenden.
MotherDuck ist ein Dienst, der duckdb in der Cloud hostet, während DuckLake ein viel offeneres System ist. Mit DuckLake kann man in Umgebungen wie S3 oder EC2 mit mehreren Instanzen und Warehouse-Größen im Petabyte-Bereich arbeiten, mit mehreren Readern und Writern und allem transaktional. Bei MotherDuck ist jeweils nur ein Writer gleichzeitig möglich, Read Replicas haben etwa eine Minute Latenz und sind nicht transaktional. Mehrere Instanzen können nicht gleichzeitig in unterschiedliche Tabellen schreiben. DuckLake bietet außerdem die Trennung von Storage und Compute sowie eine transaktionale Metadatenebene.
Ich liebe duckDB und finde DuckLake ebenfalls wirklich großartig. Eine Frage dazu: Wenn ich das heute einsetzen würde und mein Unternehmen bereits Snowflake nutzt, müssten Analysten dann lokal duckdb plus Erweiterungen installieren und auf den Blob-Store sowie auf die Datenbank für die Datalake-Erweiterung zeigen, etwa auf duckdb auf einer VM? Wo findet dann die Compute-Ausführung statt, und wie würde man größere Jobs abwickeln? Müssten dann alle Nutzer sich per SSH auf eine riesige duckdb-VM einloggen und dort Queries ausführen? Dazu hätte ich gern eine Erklärung.