Como construir índices eficientes em lagos de dados dinâmicos com Apache Hudi

Hudi não é só uma biblioteca para upserts em data lakes, é um sistema construído desde 2017 com um modelo de mutação append-first como pedra angular. Isso permite algo que nenhum outro formato lakehouse (Iceberg, Delta) consegue no nível de especificação: adicionar índices novos, como bloom filters, índices de expressão ou estatísticas de coluna, em tabelas já em produção, sem parar escritas nem expor estado inconsistente. O segredo está em três primitivas arquitetônicas derivadas do Merge-On-Read: grupos de arquivos como contêineres lógicos estáveis, ações de indexação como eventos de primeira classe na linha do tempo (timeline), e um ciclo de vida de duas fases para partições de metadados (inflight → ativo). Essas peças não foram adicionadas depois; elas emergiram da decisão original de tratar mutação como um fluxo contínuo, não como reescritas.

O artigo atual detalha o 'catchup', a reconciliação entre o estado histórico que o índice inicializa e as escritas concorrentes que acontecem durante o bootstrap. Esse passo não é um workaround: é a materialização explícita da ideia de que o índice é um subproduto derivado, não uma cópia sincronizada. É por isso que Hudi pode oferecer indexação assíncrona em escala real, enquanto Iceberg e Delta ainda dependem de locks globais ou de indexação vinculada à escrita, o que bloqueia retroatividade e escalabilidade.

Em junho de 2026, a cobertura CEVIU já havia explicado por que os metadados precisam ser amigáveis à mutação documentação de Hudi, destacando a tabela de metadados (MDT) como um sistema append-first com compactação diferida. Agora, a nova postagem do Hudi mostra que essa arquitetura foi levada até o fim: não só os metadados são mutáveis, mas novos índices podem ser injetados *dinamicamente* em tabelas existentes. Antes, a MDT era vista como uma camada estática de otimização. Hoje, ela se revela um sistema evolutivo, onde cada novo índice (record_index, expression_index, bloom_filter) é uma extensão atômica da timeline, não uma operação de manutenção offline.

Para engenheiros de dados que operam pipelines de ingestão contínua em escala petabyte, interromper escritas para criar um índice não é apenas inconveniente, é inviável. A capacidade de adicionar um índice secundário para acelerar consultas de análise sem derrubar o pipeline muda a equação de governança: agora é possível iterar em estratégias de indexação conforme os padrões de leitura evoluem, não apenas no momento da criação da tabela. Isso também impacta diretamente a qualidade dos dados, índices de estatísticas de coluna ou sketches probabilísticos (como os citados em nossa cobertura anterior sobre data sketches documentação de Hudi) podem ser incorporados *após* a produção, sem exigir reprocessamento completo.

Repositório oficial: apache/hudi