Lakehouse: a convergência entre data lake e data warehouse

Por muito tempo, organizações que trabalham com dados mantiveram duas infraestruturas paralelas. Uma guardava tudo em arquivos, barata e flexível, boa para volume e para dados sem formato definido. Outra guardava um recorte tratado em um banco analítico, cara e rígida, boa para consultas rápidas e confiáveis.

Manter as duas custa dinheiro e produz divergência. O mesmo indicador calculado nos dois lugares tende a dar resultados diferentes, e reconciliar isso vira trabalho permanente. A proposta que ficou conhecida como lakehouse tenta eliminar a duplicação levando as garantias do banco analítico para cima dos arquivos.

Apuração · o que é verificável

O que aconteceu

A base é um formato de arquivo colunar, como o Parquet, que armazena os valores agrupados por coluna. Isso permite ler apenas as colunas necessárias, comprimir melhor dados semelhantes e descartar blocos inteiros pela estatística guardada em cabeçalho. É o que torna a consulta sobre arquivos viável.

Acima do formato de arquivo entra o formato de tabela, papel ocupado por projetos como Apache Iceberg e Delta Lake. Eles mantêm um catálogo de quais arquivos compõem a tabela em cada momento, o que permite escrever novas versões sem que leituras em andamento enxerguem um estado incompleto.

Dessa estrutura decorrem as funções que faltavam: transações sobre arquivos, evolução de esquema sem reescrever tudo, exclusão e atualização de registros individuais, e leitura de um estado anterior da tabela. São recursos comuns em bancos relacionais, agora disponíveis sobre armazenamento de objetos barato e elástico.

Contexto

A separação entre armazenamento e processamento é o que sustenta a proposta. Os dados ficam em um repositório de objetos, e diferentes motores de consulta os leem sem precisar mantê-los internamente. Isso quebra o acoplamento que fazia a escolha do banco analítico ser uma decisão de década.

O ponto sensível passa a ser o catálogo. Ele é quem sabe quais tabelas existem, onde estão seus arquivos e quem pode lê-las. Como vários motores dependem dele, o catálogo se torna a peça central de governança - e o lugar onde a dependência de fornecedor pode voltar.

Há também um efeito sobre custo. Armazenamento de objetos é barato e permanente; capacidade de processamento é cara e pode ser ligada e desligada. Separar os dois transforma parte do gasto fixo em gasto sob demanda, com a contrapartida de latência maior quando o motor precisa ser iniciado.

O que os formatos de tabela resolvem de fato

O problema mais antigo dos repositórios de arquivos era a ausência de transação. Uma escrita interrompida deixava arquivos parciais visíveis, e uma leitura simultânea podia misturar versões. O catálogo versionado resolve isso ao trocar a referência da tabela apenas quando o conjunto novo está completo.

O segundo problema era a exclusão de registros específicos. Sem suporte a atualização, apagar o dado de uma pessoa exigia reescrever partições inteiras. Com registro de mudanças no nível da linha, obrigações legais de exclusão deixam de ser um processo caro e passam a ser operação normal.

O terceiro é a evolução de esquema. Acrescentar, renomear ou remover colunas sem quebrar consultas antigas exige que a identidade de cada coluna não dependa da posição no arquivo. Os formatos de tabela resolvem isso com identificadores estáveis, o que reduz um tipo frequente de quebra silenciosa.

O que continua difícil

Nada disso elimina a manutenção. Escritas frequentes produzem muitos arquivos pequenos, que degradam a leitura e precisam ser compactados. Versões antigas ocupam espaço e precisam ser expiradas. Estatísticas desatualizadas levam o planejador a escolhas ruins. São tarefas de rotina que alguém precisa executar de forma programada.

A latência também continua sendo um limite. Consultas sobre armazenamento remoto pagam custo de rede e de leitura de metadados, o que as torna adequadas a análise e pouco adequadas a respostas em milissegundos. Cargas interativas de aplicação continuam pedindo um banco desenhado para isso.

E há a governança, que o formato não resolve sozinho. Controle de acesso por coluna e por linha, linhagem, qualidade e definição compartilhada de indicadores continuam dependendo de processo e de ferramenta externa. Abrir o acesso a vários motores amplia a superfície que precisa ser controlada.

Interpretação editorial da sysINFO

Análise sysINFO

A leitura da sysINFO é que o ganho principal não é desempenho, e sim reversibilidade. Guardar os dados em formato aberto, com catálogo aberto, reduz o custo de trocar de motor de consulta. Isso muda a natureza da negociação com fornecedores mais do que qualquer comparação de velocidade.

O risco correspondente é acreditar que abertura de formato equivale a independência. Se o catálogo, a autenticação e as ferramentas de operação vierem de um único fornecedor, o acoplamento apenas mudou de lugar. A pergunta útil é quanto trabalho seria necessário para ler as mesmas tabelas em outro ambiente.

Esta seção é interpretação editorial da sysINFO, não relato de fato. Verificáveis são as capacidades técnicas descritas: transações, evolução de esquema, exclusão no nível da linha e leitura de versões anteriores. A avaliação sobre reversibilidade e sobre dependência de fornecedor é a leitura que fazemos delas.

Recorte brasileiro

Impacto para o Brasil

Para empresas brasileiras, o argumento de custo tem peso maior. Manter um banco analítico dimensionado para o pico é caro em qualquer lugar, e mais ainda quando cobrado em moeda estrangeira. Separar armazenamento de processamento permite pagar capacidade apenas durante as janelas em que ela é usada.

Há um ponto direto de proteção de dados. A obrigação de excluir informação pessoal a pedido do titular é difícil de cumprir em repositórios de arquivos imutáveis. Formatos que suportam exclusão no nível do registro tornam esse dever operacional, em vez de um projeto excepcional a cada solicitação.

O terceiro efeito é de soberania de dados. Guardar os arquivos em formato aberto, com catálogo próprio, facilita mudar de provedor ou de região sem reconstruir o histórico. Para organizações públicas e para setores regulados, essa portabilidade é requisito de contrato, não uma preferência técnica.

Agenda de acompanhamento

O que observar agora

A parte técnica está razoavelmente resolvida, e a disputa migrou para o catálogo e para a governança. É ali que se define, na prática, se a abertura do formato produz mesmo a portabilidade prometida ou apenas desloca a dependência para outra camada da pilha de dados.

• Se catálogos abertos se tornarão padrão comum entre motores concorrentes.
• Como a manutenção de arquivos e versões será automatizada por padrão.
• Se o controle de acesso por linha e coluna migrará para o próprio formato.
• Que cargas continuarão exigindo um banco analítico dedicado.