Data lakehouse com DuckDB e DuckLake: do Parquet local à nuvem

Durante anos, armazenar grandes volumes de dados que pudessem ser consultados de forma sensata significava usar bancos como Oracle ou Postgres — ou sistemas de mainframe caros que prendiam você a um fabricante específico. A evolução seguinte foi o data warehouse: um repositório central projetado para relatórios e análise histórica, com consultas analíticas mais rápidas e definições de negócio consistentes, mas infraestrutura cara, pipelines de ETL complexos e a necessidade de modelar os dados antes de carregar.

Do data warehouse ao data lakehouse

O avanço mais recente é o data lake, que permite armazenar volumes muito maiores de dados brutos — estruturados, semiestruturados e não estruturados — a baixo custo. O problema é que empresas como Databricks, Snowflake e os grandes provedores de nuvem disputam para extrair o máximo possível de dinheiro de seus clientes na gestão desses lagos. A verdade é que dá para ir muito longe desenvolvendo um data lake eficaz com custo próximo de zero usando DuckDB e sua extensão DuckLake — ambos gratuitos e com licença MIT.

O termo lakehouse descreve justamente essa convergência: a flexibilidade e o baixo custo de armazenamento do data lake com a capacidade de consulta e a semântica de um warehouse. Em vez de manter dois sistemas separados, você consulta diretamente os arquivos do lake com um motor analítico embutido.

Prós e contras da abordagem DuckDB + DuckLake

• ✅ Custo próximo de zero: software aberto, sem taxa de licença e sem servidor dedicado para começar.
• ✅ Simplicidade radical: um único processo consulta arquivos locais e dados na nuvem com o mesmo SQL.
• ✅ Portabilidade: roda no seu notebook, no servidor e em pipelines; nada de cluster para administrar.
• ✅ Formato Parquet: armazenamento colunar, comprimido e interoperável com praticamente todo o ecossistema de dados.
• ✅ Curva de aprendizado baixa: quem conhece SQL começa a produzir em minutos.
• ⚠️ Não é um substituto de OLTP: para workloads transacionais concorrentes de alta escrita, um banco tradicional continua sendo a escolha certa.
• ⚠️ Escala limitada por máquina única: para petabytes e centenas de usuários simultâneos, soluções distribuídas (Spark, Trino) são necessárias.
• ⚠️ Concorrência de escrita: DuckDB brilha em leitura analítica; escrita concorrente em um único arquivo exige cuidado.

Requisitos

Entendendo os blocos de construção

Parquet: o formato que sustenta tudo

O Parquet é um formato de arquivo colunar e comprimido, otimizado para leitura analítica. Em vez de ler a linha inteira, uma consulta lê apenas as colunas relevantes — o que acelera agregações em milhões de registros e reduz drasticamente o armazenamento. É o formato padrão de interoperabilidade entre ferramentas de dados e funciona perfeitamente como camada de armazenamento do lakehouse.

DuckDB: o motor analítico embutido

O DuckDB é um banco de dados analítico que roda dentro do seu processo — como o SQLite, mas projetado para cargas de trabalho OLAP, não OLTP. Ele consulta arquivos Parquet, CSV e JSON diretamente, sem importação prévia, e é capaz de processar conjuntos de dados maiores que a memória disponível graças a execução vetorizada e spill para disco.

DuckLake: a ponte para o armazenamento em nuvem

A extensão DuckLake estende o DuckDB para ler dados diretamente de armazenamentos de objetos na nuvem. Isso significa que você pode manter um arquivo Parquet local e, com a mesma sessão, juntá-lo (join) a dados que vivem em um bucket na nuvem — sem baixar tudo para a máquina local e sem manter um warehouse separado.

Passo a passo: do Parquet local à nuvem

1. Comece com um arquivo Parquet local

O ponto de partida do guia é um único arquivo Parquet local. A ideia é simples: em vez de provisionar um banco, você aponta o DuckDB para o arquivo e consulta com SQL padrão. Essa etapa valida o modelo mental — dados como arquivos, consulta como banco — com custo zero de infraestrutura.

2. Ative a extensão DuckLake

Para alcançar dados na nuvem, você carrega a extensão DuckLake na sua sessão. Ela configura as credenciais e o protocolo de acesso ao armazenamento de objetos, permitindo que o DuckDB trate os arquivos remotos como se fossem locais.

3. Faça o join entre local e nuvem

O coração do exemplo é juntar o arquivo Parquet local a um conjunto de dados armazenado na nuvem. Como o DuckDB faz push-down de predicados e projeções, apenas as colunas e as partições necessárias são transferidas — o que mantém a consulta rápida mesmo com o dado remoto.

4. Valide o resultado

Para confirmar que funcionou, execute uma agregação simples sobre o resultado do join e compare com uma contagem de referência. Se os números baterem, você tem um lakehouse funcional: dados locais e remotos consultados de forma unificada, sem ETL dedicado.

Casos de uso reais

• Análise exploratória: carregar um Parquet de vendas e cruzar com dimensões de produto na nuvem para entender sazonalidade.
• Prototipagem antes de escalar: validar lógica de negócio em DuckDB antes de portar para um cluster distribuído.
• Pipelines de ciência de dados: feature engineering direto sobre arquivos, sem mover dados para um banco.
• Relatórios departamentais: um analista gera relatórios semanais juntando exportações locais a dados corporativos na nuvem.

Comparação de custo

Troubleshooting: erros comuns

• ❌ “Unrecognized extension DuckLake” → Causa: extensão não carregada. Solução: instale e carregue a extensão antes de consultar dados na nuvem.
• ❌ Consulta lenta sobre dados remotos → Causa: leitura de colunas desnecessárias. Solução: selecione apenas as colunas usadas e aplique filtros que permitam push-down.
• ❌ Erro de credencial no bucket → Causa: permissões de acesso não configuradas. Solução: configure as credenciais do armazenamento de objetos na sessão.
• ❌ Out of memory em arquivos grandes → Causa: operação que exige materializar tudo em memória. Solução: use agregações colunares e evite `ORDER BY` global em datasets enormes sem necessidade.
• ❌ Join produz resultado inesperado → Causa: chaves com tipos ou formatos diferentes entre local e nuvem. Solução: normalize as chaves (tipo, caixa, espaços) antes do join.

Perguntas frequentes

DuckDB substitui o Postgres? Não. São propósitos diferentes: o Postgres é OLTP (transacional), o DuckDB é OLAP (analítico). Eles se complementam, não se substituem.

Preciso de servidor para usar DuckDB? Não. Ele roda embutido no seu processo, como uma biblioteca. Não há servidor para administrar.

Parquet é obrigatório? Não, mas é altamente recomendado para workloads analíticos pelo formato colunar e pela compressão.

Dá para usar em produção? Sim, para cargas analíticas que cabem em uma máquina. Para escalas muito grandes, combine com soluções distribuídas.

O que é exatamente um lakehouse? É a unificação de data lake (armazenamento barato e flexível) com a capacidade de consulta e a semântica de um warehouse, sem manter dois sistemas separados.

O que vem pela frente

O movimento de análise “embarcada” — em que o motor analítico é uma biblioteca, não um serviço — ganha força à medida que o custo de armazenamento cai e os formatos abertos (Parquet, Iceberg) se consolidam como padrão. A tendência para os próximos anos é que a fronteira entre “arquivos” e “banco de dados” continue a se dissolver, com o DuckDB e ferramentas semelhantes ocupando o espaço que antes exigia infraestrutura pesada.