DuckLake - Formato unificado de data lake e catálogo

• Nova solução que unifica um data lake e um formato de catálogo
• Funciona com base em arquivos Parquet e bancos de dados SQL, permitindo uma implementação de data lake mais simples do que um lakehouse tradicional
• Permite gerenciar o catálogo de metadados sobre vários bancos de dados, como PostgreSQL, SQLite, MySQL e DuckDB
• Oferece vários recursos, como snapshots, consultas com time travel, alterações de schema e particionamento, além de um processamento leve de snapshots que não exige compactação frequente
• Suporta o modelo multiplayer do DuckDB, no qual várias instâncias podem ler e gravar dados ao mesmo tempo, implementando um modelo de concorrência que o DuckDB padrão não oferece
• DuckLake é um conceito que abrange a especificação, a extensão do DuckDB e conjuntos de dados armazenados no formato DuckLake, e é disponibilizado sob a licença MIT

---

Introdução ao DuckLake

• DuckLake é um formato aberto criado pela equipe do DuckDB que oferece recursos avançados de data lake sem a complexidade de um lakehouse
• Com apenas um banco de dados SQL e arquivos Parquet, é possível construir seu próprio data warehouse.
• Usa um banco de dados para gerenciar metadados: PostgreSQL, SQLite, MySQL, DuckDB

Principais recursos do DuckLake

• Operações de data lake

  • Snapshots
  • Consulta por ponto no tempo (Time travel)
  • Evolução de schema
  • Particionamento

• Processamento leve de snapshots

  • É possível criar snapshots sem limite de quantidade
  • Pode operar sem necessidade de compactação frequente

• Transações ACID

  • Garante transações e acesso concorrente em operações com múltiplas tabelas

• Arquitetura orientada a desempenho

  • Uso de estatísticas para filter pushdown
  • Consultas rápidas mesmo em grandes conjuntos de dados

Perguntas frequentes

• Por que usar DuckLake?

  • É adequado quando você precisa de uma solução leve que unifica data lake e catálogo
  • Permite um ambiente multiplayer em que várias instâncias do DuckDB leem e gravam no mesmo conjunto de dados
    • Isso representa um modelo de concorrência não suportado no DuckDB tradicional
  • Mesmo usando apenas DuckDB, é possível aproveitar vantagens como consulta por ponto no tempo, particionamento e estrutura de armazenamento em múltiplos arquivos

• O que é DuckLake?

  • DuckLake pode se referir a três coisas:
    1. A especificação do formato DuckLake (specification)
    2. A extensão do DuckDB que oferece suporte ao DuckLake (ducklake extension)
    3. O próprio conjunto de dados armazenado no formato DuckLake

• Qual é a licença do DuckLake?

  • É disponibilizado sob a licença MIT

[GN⁺]

Comentários do Hacker News

• Sempre senti falta de uma coisa no Parquet: a parte de ranged partitioning, que vários “data lake / lakehouse” resolveram separadamente de forma incompatível entre si. Minha aplicação se encaixa quase perfeitamente no Parquet, mas lida com dados como logs de séries temporais, em que os timestamps não se distribuem de maneira uniforme. A coluna de partição segue o particionamento do Hive, mas ao mesmo tempo os dados se dividem naturalmente por timestamp. O problema é que o Hive partitioning não suporta isso, então as principais ferramentas de consulta não conseguem importar corretamente a estrutura dos meus dados. A alternativa é introduzir métodos desnecessários, como uma coluna baseada em data, ou simplesmente empilhar arquivos, o que traz problemas de desempenho e custo. Iceberg, Delta Lake e outros suportam ranged partitioning, mas eu não preciso dessa complexidade; queria que houvesse uma padronização de convenções mais simples para nomes de arquivos ou diretórios. Além disso, formatos como Parquet row, Arrow row, Thrift e protobuf são muito parecidos, mas não exatamente iguais; acho que, se existisse junto um formato binário para uma única row ou stream de rows, a interoperabilidade entre várias ferramentas seria melhor

  • Fico pensando se só o footer metadata dos arquivos Parquet já não basta para obter as informações necessárias. Os metadados incluem o timestamp mínimo/máximo daquela coluna, então na hora da consulta a ferramenta poderia ler só esses metadados e decidir se vale a pena ler o arquivo ou não, evitando leituras desnecessárias

  • Dados de tempo são difíceis de lidar, mas dependendo da abordagem dá para evitar isso. Em vez de consultar diretamente a série temporal bruta, pode ser útil normalizar e salvar os timestamps na etapa de processamento de eventos. Com base em uma sliding window, você encontra o ponto de início do evento e ajusta o offset, identificando onde a série temporal volta ao ponto de referência (0), e usa isso como unidade de evento

  • O Hive suporta dois tipos de particionamento: injected e dynamic. Dá para usar como chave de partição uma coluna de hora em tempo UNIX (um inteiro que cresce em passos de 3600 segundos desde a época). Pode ser que o mecanismo de consulta exija que você especifique o intervalo de partições a consultar, mas dá para usar isso na query na forma datepartition >= a AND datepartition < b. O Iceberg permite usar faixas de timestamp de forma muito mais simples e exclui automaticamente partições desnecessárias sem precisar de metadados

  • Nas bibliotecas de baixo nível de arrow/parquet, dá para controlar diretamente row groups e data pages. Já usei o crate arrow-rs e consegui melhorar em mais de 10x a velocidade de consulta de arquivos. Às vezes há poucos row groups, às vezes há muitos, mas dá para pular rapidamente só os row groups desejados, então o skew não vira problema. Só é preciso lembrar que há um limite de 2^15 row groups por arquivo

  • Esse problema parece mais uma limitação do Hive do que do Parquet. É preciso abrir o arquivo Parquet para olhar as informações de min e max da coluna, mas, se os dados não estiverem no intervalo, não há requisições adicionais. Seria eficiente usar esse tipo de metadado em um nível mais alto, por exemplo em algo como o DuckLake

• Uma das coisas mais incômodas no Iceberg (o Delta Lake é parecido, mas pessoalmente acho o Iceberg um pouco mais difícil) era como é complicado experimentar em notebook ou ambiente local. O Delta Lake tem várias implementações em Python, mas elas são fragmentadas, e o Iceberg traz bastante atrito com setup de cluster JVM e afins. Eu queria usar uma combinação de sqlite/postgres + duckdb + parquet, salvando em blob storage, mas deu bastante trabalho. Do lado do DuckDB, isso simplesmente funciona sem esse sofrimento e escala naturalmente até dados de tamanho razoável. A equipe do DuckDB entende muito bem essa área, e estou realmente empolgado

  • Você já testou o PyIceberg? É uma implementação em Python puro e funciona muito bem. Também oferece suporte a SQL Catalog e catálogo em memória baseado em SQLite
    https://py.iceberg.apache.org/

  • Existe um guia de setup passo a passo usando S3 e RDS. Não deve ser difícil adaptar para sqlite local
    https://www.definite.app/blog/cloud-iceberg-duckdb-aws

  • Dá para testar localmente com muita facilidade. No notebook do marimo, isso é possível com só algumas linhas de código (nota: eu sou desenvolvedor do marimo)
    https://www.youtube.com/watch?v=x6YtqvGcDBY

  • Estou pensando em fazer um chart Helm que funcione bem com k3s. Com datapains, também dá para subir o trino facilmente e, com alguns ajustes, levantar o hivemetastore. Testei o funcionamento completo conectando o Iceberg connector ao trino. A estrutura é carregar os dados no hive, apontar o trino para a mesma tabela e depois fazer select para inserir no iceberg. Se o lado do DuckDB lançar um ambiente que realmente funcione de forma simples, acho que pode até assumir a liderança do setor

  • O delta-io (baseado em deltalake-r) funciona muito facilmente no ambiente local. Você instala com pip e já consegue criar catálogo e escrever arquivos
    https://delta-io.github.io/delta-rs/

• Faz uma crítica certeira ao Iceberg — afinal, se você já está usando um banco de dados, por que colocar e gerenciar metadados em arquivos? Pode não ser fácil para o DuckLake ter sucesso amplo fora do DuckDB, mas imagino que, no fim, a estrutura caminhe para catálogos que também cuidam dos metadados, e o formato atual do Iceberg talvez acabe virando apenas um momento da história

• Os sistemas de lakehouse existentes (como Iceberg) espalham informações importantes da tabela, como esquema e lista de arquivos, em pequenos arquivos de metadados dentro de object storage como o S3. Isso gera muitas chamadas de rede em operações como planejamento de consulta e atualização de tabela, deixando tudo mais lento ou mais propenso a conflitos. O DuckLake coloca todos os metadados em um banco SQL rápido e transacional, de modo que uma única query pode buscar todas as informações necessárias, trazendo muito mais eficiência e confiabilidade

• Manifesto relacionado ao DuckLake: https://ducklake.select/manifesto/

• Aqui dentro da empresa, estou desenvolvendo uma “poor man’s datalake” usando os bindings Python do deltalake-rs com duck db. A estrutura salva arquivos parquet em blob storage. Porém, sempre aparecem problemas com escrita concorrente. Não há problema quando uma cloud function puxa dados da API em intervalos regulares. Mas, se eu rodar backfill várias vezes, existe o risco de ela executar ao mesmo tempo que a função baseada em timer e causar conflito. Isso fica ainda pior quando há centenas de jobs na fila de backfill e os workers ficam saturados

  • Uma opção é adicionar um suffix aleatório ao fim do nome do arquivo

  • Dá para evitar conflitos colocando um lease temporário em um arquivo json antes do write e gerenciando as solicitações de escrita por uma fila

• Uma solução concorrente que resolve limitações do Iceberg, especialmente os problemas de gerenciamento de metadados (por exemplo, a Snowflake usa FoundationDB para gerenciar metadados, enquanto o Iceberg vai até a blob storage)
  https://quesma.com/blog-detail/apache-iceberg-practical-limitations-2025

  • Tive impressão parecida, mas pelo vídeo o DuckLake não é um concorrente direto
    https://youtu.be/zeonmOO9jm4?t=4032
    O DuckLake escreve arquivos de manifest/metadata do Iceberg para sincronização apenas quando necessário, e já suporta leitura de dados Iceberg. Em vez de ser um produto concorrente separado, ele melhora os problemas centrais do Iceberg e se integra de forma limpa com ele nos dois sentidos

  • O crescimento exagerado de metadados pode ser administrado dependendo do caso

    • número de snapshots
    • mudanças grandes e frequentes de schema
    • atualizações frequentes em nível de row / muitos arquivos pequenos
    • informações estatísticas etc.
      Antigamente, o último item era um problema por causa de schemas grandes. A maioria dos engines oferece ferramentas como compaction e export de snapshots para ajudar nisso, embora parte da responsabilidade ainda fique com o usuário. As tabelas S3 oferecem alguns recursos de gerenciamento. Se os metadados tiverem entre 1 e 5 MB, na prática isso não é um problema. A velocidade de commit depende do tamanho dos metadados e da quantidade de writers. Já resolvi metadados com mais de 1 GB usando script manualmente — normalmente basta limpar snapshots sobrescritos (deixando a exclusão real dos arquivos para a bucket policy) ou remover versões antigas de schema

• No fim, para construir um banco de dados de verdade, é preciso estruturá-lo como um banco de dados de verdade. Impressionante o trabalho da equipe do DuckDB

• Fico curioso sobre a relação com a Mother Duck(https://motherduck.com/). É uma empresa que faz “DuckDB-powered data warehousing” e começou antes do DuckLake

  • MotherDuck e DuckLake devem se integrar muito bem. Os dados da MotherDuck serão armazenados no DuckLake, ganhando mais escalabilidade, concorrência e consistência, e ferramentas de terceiros também poderão acessar os dados subjacentes. Eles vêm desenvolvendo isso nos últimos meses e devem divulgar mais informações em breve

  • A MotherDuck organiza automaticamente os dados que você envia e fornece uma interface de dados com DuckDB. Se você quiser características mais de lakehouse, integração com blob storage, integração adicional com DuckLake ou manter os metadados no MotherDuck, pode usar o DuckLake

  • A MotherDuck é um serviço que hospeda duckdb na nuvem, enquanto o DuckLake é um sistema muito mais aberto. Com o DuckLake, dá para montar em S3, EC2 e outros ambientes warehouses em escala de petabytes, com várias instâncias e múltiplos leitores/escritores, tudo com transacionalidade. Na MotherDuck, só é possível ter um writer por vez, as réplicas de leitura têm latência de cerca de 1 minuto e não há transacionalidade. Não dá para várias instâncias escreverem simultaneamente em tabelas diferentes. O DuckLake também oferece separação entre storage e compute, além de uma camada de metadados altamente transacional

• Adoro o duckDB e também achei o DuckLake muito legal. Minha dúvida é: se eu começasse a usar isso agora, e a empresa já operasse com Snowflake, os analistas teriam que instalar localmente duckdb + extensões e apontar para o blob store e para o banco usado na extensão do datalake (por exemplo, um duckdb rodando em uma VM). Onde o processamento das queries acontece nesse cenário, e como isso funcionaria para trabalhos maiores? Todo mundo teria que entrar por ssh em uma VM gigante de duckdb para rodar queries? Queria uma explicação dessa parte

  • Se você rodar o duckdb localmente, o processamento acontece no PC de cada pessoa. Se precisar de mais compute, pode subir uma VM e usar lá. As duas opções existem — local para trabalhos pequenos e VM para escalar workloads maiores