Arquitetura big data: lakes, lakehouses, formatos e processamento

Poucas áreas do software sofreram tanto com o vocabulário dos fornecedores quanto as plataformas de dados. O termo "big data" foi cunhado para descrever um problema real — conjuntos de dados que nenhuma máquina sozinha conseguia armazenar ou processar em tempo aceitável — e depois passou a ser aplicado a quase tudo. Resultado: muitas organizações mantêm clusters distribuídos rodando sobre dados que caberiam em um notebook.

Este guia leva a sério as decisões de arquitetura e trata o discurso de marketing com ceticismo. Ele cobre como os dados chegam, onde são armazenados, em que formato, quem pode alterá-los e como são processados — além da seção que a maioria dos guias do tipo omite: como perceber que você não precisa de nada disso. Os detalhes internos de HDFS, YARN e Spark estão no guia do ecossistema Hadoop; aqui o foco é o formato da plataforma.

Os três Vs, examinados

Volume, velocidade e variedade são um checklist útil e um péssimo procedimento de decisão. Cada um merece uma pergunta mais dura.

Volume. O número que importa não é quantos dados existem, mas quantos uma consulta toca. Um histórico de eventos de cem terabytes consultado um dia por vez é um problema de cem gigabytes, com um bom particionamento. Compressão e layout colunar costumam reduzir em uma ordem de grandeza os bytes escaneados antes que qualquer engine distribuída entre em cena.

Velocidade. Pergunte qual é a latência de decisão, não a de chegada. Eventos que chegam continuamente não exigem computação em streaming se ninguém age sobre o resultado antes da manhã seguinte. Os requisitos reais de streaming — score antifraude, precificação dinâmica, alertas operacionais — são aqueles em que uma resposta atrasada vale menos que uma rápida e aproximada.

Variedade. É o V que melhor resistiu ao tempo. Bancos relacionais sofrem quando o schema muda de fonte para fonte e se altera sem aviso, e isso de fato justifica um lake com schema-on-read.

Muitas vezes se acrescenta um quarto V, a veracidade, que importa mais do que os três primeiros. Um pipeline que entrega cem terabytes de números sutilmente errados é pior do que um que não entrega nada, porque as pessoas agem com base neles.

Lake, warehouse, lakehouse

Um data warehouse armazena dados curados, modelados e tipados, otimizados para SQL analítico. Os dados são transformados na entrada, o schema é imposto e o desempenho das consultas é excelente, porque o layout foi pensado para as perguntas. O custo é a rigidez: uma fonte nova exige trabalho de modelagem antes que alguém possa usá-la, e os dados rejeitados pelo modelo simplesmente se perdem. A modelagem dimensional para warehouses é tratada no guia de business intelligence.

Um data lake guarda arquivos em armazenamento de objetos — S3, Azure Blob, Google Cloud Storage — no formato em que chegaram, com o schema aplicado na leitura. É barato, aceita qualquer coisa e preserva os dados brutos para perguntas que ninguém fez ainda. Seu modo de falha tem nome: o data swamp, um bucket de arquivos sem documentação, sem dono, sem histórico de schema e sem como saber qual cópia é a atual. Lakes falham por motivos de governança, não técnicos.

Um lakehouse mantém os arquivos em formatos abertos no armazenamento de objetos, mas acrescenta uma camada de metadados que oferece transações ACID, evolução de schema, time travel e pruning eficiente de arquivos. Essa camada é um formato de tabela aberto: Apache Iceberg, Delta Lake ou Apache Hudi. O resultado se comporta como uma tabela — você pode fazer UPDATE, DELETE e MERGE e voltar atrás — sem deixar de ser legível por qualquer engine que entenda o formato.

Uma organização em camadas comum e sensata, seja qual for o nome que você der:

raw / bronze     immutable landing zone, source format, partitioned by ingest date
curated / silver cleaned, deduplicated, typed, conformed to a common schema
serving / gold   aggregated, modelled tables for dashboards, APIs and data science

Cada camada pode ser reconstruída a partir da anterior, e é isso que torna possível reprocessar depois de um bug.

Formatos de armazenamento e layout

A escolha do formato pesa mais no custo e na velocidade do que a engine de processamento.

Os formatos colunares vencem em analytics por três motivos que se somam. Uma consulta que lê três de oitenta colunas lê só essas três. Os valores de uma mesma coluna são parecidos, então a compressão é muito melhor do que por linha. E as estatísticas por row group permitem ao leitor pular blocos inteiros cuja faixa min/max não pode satisfazer o predicado. Juntos, esses fatores transformam um full scan em uma fração do I/O.

O particionamento é um pruning em nível de diretório: gravar em dt=2026-09-07/region=eu permite que uma consulta que filtra por essas colunas pule todo o resto. Duas regras o mantêm útil. Particione por colunas que aparecem em quase todo filtro, geralmente uma data. E mantenha a cardinalidade baixa: particionar por id de cliente gera milhões de diretórios e um problema de metadados muito pior do que o scan que você evitou.

O tamanho dos arquivos é a outra metade. Mire em arquivos de algumas centenas de megabytes. Gravações em streaming naturalmente produzem uma enxurrada de arquivos minúsculos, então agende compactação; todo formato de tabela oferece uma operação de manutenção para isso. Dentro de um arquivo, ordenar por uma coluna filtrada com frequência deixa as estatísticas dos row groups muito mais seletivas — o mesmo raciocínio do clustering em um banco relacional, discutido no guia de índices e planos de execução.

Os formatos de tabela abertos acrescentam o que diretórios simples não conseguem: commits atômicos, para que um leitor nunca veja uma atualização gravada pela metade; isolamento por snapshot e time travel, para consultar a tabela como estava ontem ou desfazer uma carga ruim; particionamento oculto, para que as consultas não precisem mencionar a coluna de partição; e evolução de schema por id de coluna em vez de posição, para que renomear uma coluna não corrompa os arquivos antigos.

Ingestão

As fontes se encaixam em poucos padrões recorrentes.

Extrações batch — dumps noturnos, arquivos de fornecedores, chamadas a APIs. Simples, bem conhecidas e a resposta certa com muito mais frequência do que se admite. Prefira a extração incremental sobre uma coluna de watermark a reler tudo.

A captura de dados de alteração (CDC) lê o log de transações de um banco e emite um stream de inserts, updates e deletes. É a forma menos intrusiva de espelhar um banco operacional na plataforma: nenhuma consulta contra a origem, nenhuma janela de batch e a ordenação que o log garante. É também onde surge a maioria dos problemas de corretude, principalmente em torno de mudanças de schema e de deletes.

Streams de eventos. Um broker baseado em log oferece um buffer durável, ordenado e com replay entre produtores e consumidores, e desacopla a disponibilidade e a velocidade de cada lado. É essa capacidade de replay que torna o reprocessamento possível — veja a arquitetura do Kafka para a mecânica de partições, offsets e retenção.

Seja qual for a fonte, grave o payload bruto sem alterações antes de transformá-lo. Armazenamento é barato; um bug de transformação irrecuperável, não.

A distinção ETL versus ELT também cabe aqui. O ETL tradicional transforma antes de carregar, então o warehouse só contém dados modelados. O ELT carrega os dados brutos e transforma usando o poder de processamento da própria engine de destino, o que é mais barato, preserva a cópia bruta e converte as transformações em SQL versionado. O ELT é o padrão moderno onde quer que a camada de armazenamento seja barata e a engine, elástica.

Processamento

O processamento batch recalcula sobre um conjunto de dados limitado. O Apache Spark domina esse terreno; Trino e Presto cobrem o SQL federado interativo, e as engines de warehouse na nuvem cobrem o resto. O batch é mais fácil de entender, simples de reexecutar e correto por construção, porque a entrada não muda enquanto você trabalha.

O processamento em streaming calcula continuamente sobre uma entrada ilimitada e introduz três conceitos de que o batch nunca precisa:

• Tempo de evento versus tempo de processamento. Os eventos chegam atrasados e fora de ordem. Resultados por janela precisam se basear em quando algo aconteceu, não em quando foi recebido.
• Watermarks. Um watermark é a afirmação da engine de que nenhum evento mais antigo que um dado timestamp ainda é esperado, e é o que permite que uma janela se feche e emita o resultado.
• Estado e exactly-once. As agregações mantêm um estado que precisa sobreviver a falhas, e os sinks precisam ser idempotentes ou transacionais para que os resultados não sejam duplicados em uma nova tentativa.

O Apache Flink é a implementação de referência para streaming stateful de baixa latência; o Spark Structured Streaming oferece o mesmo modelo de programação da sua API batch, com execução em micro-batch ou contínua, o que costuma ser decisivo para times que já usam Spark. O Kafka Streams serve para transformações que vivem dentro de um serviço, e não de um cluster.

A arquitetura lambda rodava uma camada batch para garantir a corretude ao lado de uma camada de velocidade para garantir o frescor dos dados, e juntava as duas no momento da consulta. Funciona, mas o custo é lógica de negócio duplicada em duas bases de código, com dois conjuntos de bugs. A arquitetura kappa mantém um único caminho de streaming e reprocessa o histórico reproduzindo o log retido, algo viável justamente porque os brokers e os formatos de tabela modernos suportam replay e escritas idempotentes. Comece com kappa se você realmente precisa de streaming; comece com batch puro se não precisa.

Governança, qualidade e custo

O trabalho de plataforma que determina se alguém confia nos dados não tem nada de glamoroso e é obrigatório.

• Um catálogo — Apache Hive Metastore, catálogos REST do Iceberg ou um equivalente na nuvem — registra quais tabelas existem, seus schemas e suas localizações. Sem ele, a descoberta de dados acontece perguntando aos colegas.
• A linhagem registra qual job produziu qual tabela a partir de quais entradas. Quando um número parece errado, a linhagem é a diferença entre uma hora e uma semana de investigação.
• Os contratos de dados transformam o schema que um produtor publica em um acordo explícito, versionado e com testes, de modo que uma mudança upstream quebre um build, e não um dashboard.
• As verificações de qualidade rodam como parte do pipeline: contagem de linhas dentro dos limites esperados, taxas de nulos, checagens referenciais, limites de frescor. Faça o job falhar ruidosamente em vez de publicar dados ruins em silêncio.
• Privacidade e retenção. Dados pessoais em um lake continuam sendo dados pessoais. Saiba onde estão, criptografe-os, restrinja o acesso e seja capaz de excluí-los — um requisito que arquivos simples não conseguem atender e os formatos de tabela conseguem.
• Custo. No armazenamento de objetos na nuvem, a conta é determinada pelos bytes escaneados e pelas requisições feitas, então pruning de partições, dimensionamento de arquivos e projeção de colunas são controles de custo tanto quanto de desempenho. Defina regras de ciclo de vida que movam as partições frias para camadas de armazenamento mais baratas.

Quando você não precisa de nada disso

Esteja disposto a concluir que uma plataforma distribuída é a resposta errada.

• Uma única instância de PostgreSQL dá conta de centenas de gigabytes de dados analíticos com particionamento e boa indexação, como descreve o guia de boas práticas de SQL.
• Uma engine colunar de nó único lê arquivos Parquet diretamente e supera um cluster Spark pequeno em conjuntos de dados de até centenas de gigabytes, sem nenhum cluster para operar.
• Logs e dados de observabilidade pertencem a uma plataforma feita para isso, não a um lake genérico — veja a gestão centralizada de logs.
• Se o requisito é "a área de negócio quer dashboards", a resposta pode ser um warehouse e uma ferramenta de BI, sem lake algum.

Os motivos mais fortes para construir uma plataforma de dados de verdade são dados vindos de muitos sistemas com modelos incompatíveis, consumidores numerosos e variados ou volumes que realmente ultrapassam uma máquina. Sem isso, a complexidade não compra nada e custa um time.

Principais conclusões

• Avalie o volume pelos bytes escaneados por consulta e a velocidade pela latência de decisão, e acrescente a veracidade à lista — dados errados em escala são piores do que nenhum dado.
• Warehouses oferecem schema e velocidade sobre dados curados, lakes oferecem armazenamento barato e flexível, e lakehouses usam formatos de tabela abertos para unir transações e controle de schema à economia do armazenamento de objetos.
• Formatos colunares com pruning de partições, tamanhos de arquivo sensatos e row groups ordenados entregam mais desempenho do que qualquer troca de engine de processamento.
• Grave os dados brutos sem alterações, organize as transformações em camadas para que cada etapa seja reproduzível e prefira ELT com transformações versionadas.
• Escolha streaming apenas quando uma decisão depender disso, e prefira um único caminho com replay a manter cópias batch e streaming da mesma lógica.
• Catálogo, linhagem, contratos de dados, verificações de qualidade e regras de retenção são o que torna uma plataforma confiável; sem eles, um lake vira um pântano.