DuckLake - formato unificado de data lake y catálogo

• Una nueva solución que integra un formato de catálogo con un data lake
• Funciona sobre archivos Parquet y bases de datos SQL, y permite una implementación de data lake más simple que un lakehouse tradicional
• Permite la gestión del catálogo de metadatos sobre varias bases de datos como PostgreSQL, SQLite, MySQL y DuckDB
• Admite varias funciones como snapshots, consultas de viaje en el tiempo, cambios de esquema y particionamiento, y al mismo tiempo ofrece un manejo liviano de snapshots que no requiere compactación frecuente
• Admite un modelo multijugador de DuckDB en el que varias instancias pueden leer y escribir datos al mismo tiempo, e implementa un modelo de concurrencia que DuckDB base no admite
• DuckLake es un concepto que abarca la especificación, la extensión de DuckDB y los datasets almacenados en formato DuckLake, y se publica bajo licencia MIT

---

Introducción a DuckLake

• DuckLake es un formato abierto creado por el equipo de DuckDB que ofrece funciones avanzadas de data lake sin necesidad de un lakehouse complejo
• Con solo una base de datos SQL y archivos Parquet, se puede construir un data warehouse propio.
• Usa una base de datos para la gestión de metadatos: PostgreSQL, SQLite, MySQL, DuckDB

Funciones principales de DuckLake

• Operaciones de data lake

  • Snapshots
  • Consulta de un punto en el tiempo (Time travel)
  • Evolución de esquema
  • Particionamiento

• Manejo liviano de snapshots

  • Se pueden crear sin límite en la cantidad de snapshots
  • Puede funcionar sin necesidad de compactar con frecuencia

• Transacciones ACID

  • Garantiza concurrencia y transacciones para operaciones sobre múltiples tablas

• Diseño orientado al rendimiento

  • Uso de estadísticas para filter pushdown
  • Consultas rápidas incluso en datasets de gran tamaño

Preguntas frecuentes

• ¿Por qué usar DuckLake?

  • Es adecuado cuando se necesita una solución liviana que integre data lake y catálogo
  • Permite un entorno multijugador donde varias instancias de DuckDB leen y escriben sobre el mismo dataset
    • Este es un modelo de concurrencia que no está disponible en DuckDB tradicional
  • Incluso usando solo DuckDB, se pueden obtener ventajas como consulta de puntos en el tiempo, particionamiento y una estructura de almacenamiento de múltiples archivos

• ¿Qué es DuckLake?

  • DuckLake se refiere a estas tres cosas:
    1. La especificación del formato DuckLake (specification)
    2. La extensión de DuckDB compatible con DuckLake (ducklake extension)
    3. El dataset en sí almacenado en formato DuckLake

• ¿Cuál es la licencia de DuckLake?

  • Se publica bajo licencia MIT

[GN⁺]

Comentario en Hacker News

• Siempre sentí que a Parquet le faltaba algo, especialmente en torno a ranged partitioning, que los distintos “data lake / lakehouse” resolvieron cada uno por su lado y de forma incompatible. Mi aplicación encaja casi perfectamente con Parquet, pero trabaja con datos como logs de series de tiempo, donde los timestamps no están distribuidos de manera uniforme. La columna de partición sigue el particionamiento de Hive, pero al mismo tiempo se divide naturalmente por timestamp. El problema es que Hive partitioning no soporta esto, así que las herramientas de consulta principales no pueden importar bien la estructura de mis datos. La alternativa es introducir métodos inútiles, como una columna basada en fecha, o simplemente acumular archivos, lo que tiene costos altos y problemas de rendimiento. Iceberg, Delta Lake y otros sí permiten ranged partitioning, pero yo no necesito toda esa complejidad; me gustaría que se estandarizara algo más simple, como una convención de nombres de archivo o directorios. Además, aunque formatos como Parquet row, Arrow row, Thrift y protobuf son muy parecidos, no son exactamente iguales, así que creo que sería mucho mejor para la interoperabilidad entre herramientas si existiera también un formato binario complementario para una sola row o para un stream de rows

  • Me pregunto si no basta con la metadata del footer del archivo Parquet para obtener la información necesaria. La metadata ya incluye el timestamp mínimo y máximo de esa columna, así que al consultar, la herramienta podría leer solo esa metadata y decidir si debe leer el archivo o no, evitando lecturas innecesarias

  • Los datos de tiempo son difíciles de manejar, pero según el enfoque, se pueden evitar. En vez de consultar directamente la serie temporal original, puede ser útil normalizar y guardar los timestamps en la etapa de procesamiento de eventos. Usando una ventana deslizante para encontrar el punto de inicio del evento y ajustar el offset, puedes identificar dónde la serie vuelve al punto de referencia (0) y usar eso como unidad de evento

  • Hive soporta dos tipos de particionamiento: injected y dynamic. Puedes usar como clave de partición una columna hour basada en tiempo UNIX (un entero que aumenta cada 3600 segundos desde la época). Puede que tengas que especificar en el motor de consultas el rango de particiones que quieres consultar, pero se puede usar en queries con algo como datepartition >= a AND datepartition < b. Iceberg permite usar rangos de timestamp de forma mucho más simple y excluye automáticamente particiones que no necesitan metadata

  • En las librerías de bajo nivel de arrow/parquet puedes controlar directamente row groups y data pages. Usando el crate arrow-rs, tuve una mejora de más de 10x en la velocidad de consulta de archivos. A veces hay pocos row groups y a veces muchísimos, pero puedes saltarte rápido solo los que quieres, así que el skew no se vuelve un problema. Eso sí, hay que tener en cuenta que el número de row groups por archivo está limitado a 2^15

  • Esto parece más una limitación de Hive que un problema de Parquet. Hay que abrir el archivo Parquet para ver la información min/max de las columnas, pero si no hay datos en el rango, entonces ya no hay más requests. Sería eficiente usar esta metadata en una capa superior, por ejemplo en algo como DuckLake

• Una de las cosas más incómodas de Iceberg (Delta Lake es parecido, aunque personalmente Iceberg me parece un poco más difícil) es que cuesta probarlo en notebooks o en un entorno local. Delta Lake tiene varias implementaciones en Python, pero están fragmentadas, e Iceberg implica molestias como montar un clúster JVM. Yo quería guardar datos en blob storage con una combinación de sqlite/postgres + duckdb + parquet, pero resultó bastante engorroso. En cambio, con DuckDB todo funciona directo sin ese sufrimiento y escala de forma natural hasta datos de tamaño razonable. Se nota que el equipo de DuckDB entiende muy bien este espacio, y la verdad me entusiasma mucho

  • ¿Has probado PyIceberg? Es una implementación pura en Python y funciona bastante bien. También soporta SQL Catalog y un catálogo en memoria basado en SQLite
    https://py.iceberg.apache.org/

  • Hay una guía de configuración paso a paso usando S3 y RDS. Tampoco debería ser difícil cambiarlo a sqlite local
    https://www.definite.app/blog/cloud-iceberg-duckdb-aws

  • De verdad se puede probar muy fácil en local. En un notebook de marimo se puede con unas cuantas líneas de código (aclaración: soy desarrollador de marimo)
    https://www.youtube.com/watch?v=x6YtqvGcDBY

  • Estoy pensando en crear un chart de Helm que funcione bien con k3s. Si usas datapains, también puedes levantar trino fácilmente y, con unos pequeños ajustes, hasta un hivemetastore. Probé el funcionamiento completo conectando el connector de Iceberg con trino. La idea es cargar los datos en hive, hacer que trino apunte a la misma tabla y luego hacer insert a iceberg mediante select. Si DuckDB logra sacar un entorno donde esto funcione de forma realmente simple, creo que hasta podría quedarse con el liderazgo del sector

  • delta-io (basado en deltalake-r) funciona muy fácil en local. Lo instalas con pip y enseguida puedes crear el catálogo y escribir archivos
    https://delta-io.github.io/delta-rs/

• Señala muy bien una crítica aguda a Iceberg: si de todos modos ya estás usando una base de datos, ¿por qué manejar y guardar la metadata en archivos? Tal vez no sea fácil que DuckLake tenga un éxito amplio más allá de DuckDB, pero al final podría terminar imponiéndose una estructura donde el catálogo también se encargue de la metadata, y el formato actual de Iceberg quede poco a poco como un momento pasajero en la historia

• Los sistemas lakehouse actuales (como Iceberg) guardan información importante de las tablas, como el esquema o la lista de archivos, repartida en pequeños archivos de metadata dentro de object storage como S3. Eso hace que la planificación de queries y las actualizaciones de tablas sean lentas o choquen con frecuencia, porque requieren muchas llamadas de red. DuckLake guarda toda la metadata en una base de datos SQL rápida y transaccional, de modo que obtiene toda la información necesaria con una sola query y mejora muchísimo tanto la eficiencia como la confiabilidad

• Manifiesto relacionado con DuckLake: https://ducklake.select/manifesto/

• En mi empresa estoy desarrollando un “poor man’s datalake” usando los bindings de Python de deltalake-rs y duck db. La estructura guarda archivos parquet en blob storage. Pero siempre me topo con problemas de escritura concurrente. No hay problema cuando una cloud function baja datos periódicamente desde una API. Pero si corro varios backfills, pueden ejecutarse al mismo tiempo que la función con temporizador y existe riesgo de conflicto. Peor aún si acumulo cientos de trabajos en la cola de backfill y los workers se saturan

  • Hay una forma: agregar un sufijo aleatorio al final del nombre del archivo

  • También puedes evitar conflictos poniendo un lease temporal en un archivo json antes de escribir y administrando las solicitudes de escritura en una cola

• Una solución competidora que resuelve las limitaciones de Iceberg, especialmente los problemas de gestión de metadata (por ejemplo, Snowflake usa FoundationDB para gestionar metadata, mientras Iceberg la deja hasta en blob storage)
  https://quesma.com/blog-detail/apache-iceberg-practical-limitations-2025

  • Yo tuve una impresión parecida, pero viendo el video, DuckLake no parece ser un competidor directo
    https://youtu.be/zeonmOO9jm4?t=4032
    DuckLake escribe archivos manifest/metadata para Iceberg y sincroniza solo cuando hace falta, y además ya soporta lectura de datos Iceberg. Más que un producto competidor aparte, parece una estructura que mejora los problemas clave de Iceberg y se integra limpiamente con Iceberg en ambos sentidos

  • El crecimiento excesivo de la metadata se puede manejar bastante según el caso

    • cantidad de snapshots
    • cambios de esquema grandes y frecuentes
    • actualizaciones frecuentes a nivel row / muchos archivos pequeños
    • información estadística, etc.
      Antes, con esquemas grandes, el último punto era problemático. La mayoría de los motores ofrecen herramientas como compaction y export de snapshots para administrarlo, aunque parte de la responsabilidad sigue recayendo en el usuario. S3 tables también ofrece algunas funciones de gestión. Si la metadata pesa entre 1 y 5 MB, en realidad no es problema. La velocidad de commit depende del tamaño de la metadata y del número de writers. Incluso llegué a resolver metadata de más de 1 GB con scripts propios; normalmente basta con limpiar snapshots sobreescritos (dejando el borrado real de archivos a la bucket policy) o eliminar versiones antiguas del esquema

• Al final, si quieres construir bien una base de datos, tienes que hacerlo como una base de datos de verdad. Impresionante el equipo de DuckDB

• Me pregunto cuál es la relación con Mother Duck(https://motherduck.com/). Es una empresa que hace "DuckDB-powered data warehousing" y empezó antes que DuckLake

  • MotherDuck y DuckLake se van a integrar muy bien. Los datos de MotherDuck se almacenarán en DuckLake para mejorar escalabilidad, concurrencia y consistencia, y herramientas de terceros también podrán acceder a los datos subyacentes. Llevan varios meses trabajando en esto y pronto compartirán más información

  • MotherDuck es un servicio que ordena automáticamente los datos que subes y te da una interfaz de datos con DuckDB. Si quieres características más tipo lakehouse, integración con blob storage, integración adicional con DuckLake o guardar la metadata en MotherDuck, entonces puedes usar DuckLake

  • MotherDuck es un servicio que aloja duckdb en la nube, mientras que DuckLake es un sistema mucho más abierto. Con DuckLake puedes construir en S3, EC2 y otros entornos un warehouse de escala petabyte con múltiples instancias, múltiples readers/writers y todo con transaccionalidad. En MotherDuck solo puede haber un writer a la vez, las réplicas de lectura tienen una latencia de alrededor de 1 minuto y no hay transaccionalidad. Tampoco varias instancias pueden escribir al mismo tiempo en tablas distintas. DuckLake además ofrece separación entre storage y compute, junto con una capa de metadata altamente transaccional

• Me encanta duckDB y DuckLake también me parece increíble. Tengo una duda: si empezara a usarlo ahora, en una empresa que ya opera con Snowflake, los analistas tendrían que instalar localmente duckdb + extensiones y apuntar al blob store y a la base de datos para extender el datalake (por ejemplo, un duckdb corriendo en una VM). En ese caso, ¿dónde ocurre el cómputo al ejecutar las queries? ¿Y qué habría que hacer para trabajos más grandes? Me gustaría entender esa parte. ¿Todos tendrían que hacer ssh a una VM gigante con duckdb para correr queries o cómo sería el modelo?

  • Si ejecutas duckdb en local, el cómputo ocurre en la PC de cada quien. Si necesitas más cómputo, puedes levantar una VM y usarla. Se pueden hacer ambas cosas: local para trabajos pequeños y VM para escalar cargas de trabajo grandes