DuckLake è un open table format per lakehouse che riparte da una scelta di design precisa: conservare catalog e metadata insieme in un database SQL, invece di distribuire i metadata su file nell’object storage. È questa decisione a spiegare la maggiore semplicità rispetto ad Apache Iceberg o Delta Lake, e conta perché incide direttamente su latenza delle query, numero di writer concorrenti e manutenzione quotidiana.
Il confronto con Iceberg rende chiaro il punto. Per rispondere a una query, Iceberg richiede una chiamata al REST catalog e poi la lettura sequenziale di tre livelli di metadata su object storage (metadata file, manifest list, manifest file). Ogni richiesta all’object storage costa circa 100 millisecondi: messe in fila, servono circa mezzo secondo solo per capire quali data file leggere. DuckLake riduce tutto a una singola query con una clausola WHERE sul database di metadata: un round trip, pochi millisecondi. Il data layer resta identico, perché DuckLake usa gli stessi file Parquet di Iceberg e la migrazione da Iceberg è una copia di soli metadata, senza spostare un solo file.
I tre componenti
DuckLake si articola in tre parti pluggabili: storage (i file Parquet su S3, Azure Blob, GCS, R2 o simili), catalog (il database SQL con catalog e metadata, tipicamente Postgres in produzione self-hosted) e compute (il motore di query, di norma DuckDB, ma anche Trino, Spark e DataFusion possono leggere DuckLake). Ognuno scala in modo indipendente. In locale bastano tre comandi dopo aver installato DuckDB: nessun Docker, nessuna configurazione. DuckLake è MIT-licensed.
Inlining e concorrenza
Il problema classico dei lakehouse è la moltiplicazione di small file: negli incumbent ogni insert produce tre o quattro file (JSON, Avro, Parquet), con un tetto pratico attorno a una transazione al secondo. DuckLake usa l’inlining: gli insert sotto una soglia configurabile (ad esempio 1000 righe) finiscono direttamente in una tabella del catalog database e vengono poi scritti su Parquet quando conviene. Secondo MotherDuck, questo porta il sistema a circa 100 transazioni al secondo, sufficienti per trattarlo come un vero system of record e non come un archivio.
La concorrenza usa optimistic concurrency control: il writer scrive prima l’intero file Parquet su object storage (in parallelo, senza coordinarsi), poi apre una transazione brevissima sul catalog per verificare se lo snapshot ID globale è cambiato. In caso di conflitto senza modifiche di schema, DuckLake ritenta in automatico; interrompe solo se lo schema è cambiato.
Per chi progetta una data platform, le leve pratiche sono chiare:
- Partitioning a livello di catalog per far scartare più file prima ancora del compute; sorting a livello di compute per letture contigue.
- Manutenzione periodica con un unico comando CHECKPOINT, che effettua flush degli inlined, compaction degli small file e vacuum di quelli scaduti.
- Compatibilità Iceberg del data layer, che rende la migrazione da Iceberg un’operazione di soli metadata.
Fonte: DuckLake Architecture Deep Dive — https://motherduck.com/blog/ducklake-architecture-deep-dive
Hai qualcosa da aggiungere? Unisciti alla discussione.