Escolher arquitetura de dados pela tendência é um padrão fácil de reconhecer. A empresa decide migrar tudo para a arquitetura que está em alta e descobre, no meio do caminho, três coisas. Os relatórios regulatórios funcionavam bem onde estavam. Os cientistas de dados precisavam dos dados brutos que a migração deixou para trás. E o problema era, na verdade, um time central sobrecarregado, não o formato das tabelas.

A pergunta correta não é qual arquitetura é a mais recente, e sim quais requisitos os dados e seus consumidores impõem. Três deles explicam a maior parte das decisões:

  • O tipo de dado: tabelas, JSON, logs, imagem, áudio, PDF.
  • Quem consome: dashboard, analista, cientista de dados, modelo em produção, LLM.
  • A escala: volume e frequência de chegada.
  • A estrutura da organização: um time central de dados ou vários domínios com autonomia.

Aplicações de IA costumam tocar vários desses requisitos ao mesmo tempo, o que torna a escolha menos óbvia do que parece.

Três formas de guardar dado analítico

Um data warehouse atende ao requisito de dados estruturados consumidos por SQL e BI. Ele consolida dados de sistemas como vendas, financeiro, RH e CRM em um modelo único, com dados limpos e definições acordadas. Funciona com schema-on-write: o schema é definido antes da carga, e o que não se encaixa é transformado ou rejeitado. O caminho clássico é o ETL (Extract, Transform, Load), em que a transformação acontece antes de o dado chegar ao destino. O ganho é consistência para relatórios e decisões e o custo é a rigidez, em que mudar o schema exige retrabalho nos pipelines. Warehouses em cloud aceitam semiestruturado, como JSON, mas imagem, áudio e vídeo seguem fora do escopo.

Um data lake atende os requisitos de variedade e volume a custo baixo. Ele guarda o dado no formato original, em object storage (S3, ADLS, GCS) ou HDFS: JSON, Parquet, logs, vídeo, PDF. Funciona com schema-on-read: a estrutura é interpretada no momento da leitura. Por isso, o caminho costuma ser ELT (Extract, Load, Transform), com carga primeiro e transformação depois. Isso dá liberdade a quem explora o dado e aceita fontes que um warehouse não aceitaria. O risco é o data swamp: o lake acumula tudo, ninguém acha nada, e quem acha não confia na qualidade. Esse risco vem da falta de catálogo, dono e controle de qualidade, não da arquitetura em si.

Um data lakehouse atende ao requisito de ter garantias de warehouse sobre o storage barato e flexível do lake. A peça central são formatos de tabela abertos, como Delta Lake e Apache Iceberg, que adicionam uma camada de metadados sobre arquivos Parquet em object storage. Essa camada traz três recursos:

  • Transações ACID: escritas atômicas, consistentes, isoladas e duráveis, que impedem um leitor de ver uma carga pela metade.
  • Evolução de schema.
  • Time travel: consulta da tabela como ela estava em uma versão ou data anterior.

A organização mais comum é a arquitetura medallion, em três camadas:

  • Bronze: o dado bruto como chegou.
  • Silver: o dado limpo e conformado.
  • Gold: tabelas modeladas para o negócio.

O termo lakehouse ganhou força por volta de 2020, mas os formatos que o sustentam são anteriores. O caso da Netflix mostra como lake e lakehouse se sobrepõem na prática. A empresa mantém em S3 os dados de eventos de reprodução e navegação e os snapshots usados para gerar features do seu sistema de recomendação (Netflix, SysML 2018). Foi sobre esse mesmo storage que ela criou o Apache Iceberg, para contornar as limitações das tabelas Hive (The Register; Data Engineering Podcast).

O que cada carga de IA exige

Machine Learning supervisionado tradicional

Churn, credit scoring, forecast e detecção de fraude têm requisitos parecidos: dados tabulares, histórico confiável, rótulos derivados de eventos de negócio e joins entre entidades como cliente, contrato e transação. E é exatamente isso que um warehouse já organiza para BI. Por isso ele costuma ser a primeira parada: as tabelas estão limpas, conformadas e com significado acordado.

Os trade-offs aparecem quando o uso deixa de ser exploratório.

O primeiro é custo. Feature engineering pesado, com janelas e agregações sobre anos de transações, consome compute do warehouse. Esse compute é cobrado por consulta ou por crédito e compete com as cargas de BI.

O segundo é a correção point-in-time. No treino, cada exemplo precisa das features como estavam no momento em que a predição teria sido feita, não como estão hoje. Tabelas que sobrescrevem o estado atual produzem vazamento de dados (data leakage) silencioso: o modelo vai bem na validação e mal em produção.

O terceiro é o atrito de ferramenta. Cientistas de dados trabalham em Python, e extrair grandes volumes do warehouse para um notebook é lento e caro.

O lakehouse atende à mesma carga com algumas diferenças. As tabelas gold servem tanto ao dashboard quanto ao treino. Engines como Spark leem os mesmos arquivos sem exportação. E o time travel permite recriar o dataset exato de um treino anterior, desde que a política de retenção de versões cubra o período, já que rotinas de limpeza como VACUUM ou a expiração de snapshots apagam versões antigas. Feature store e ferramentas de MLOps, quando existem, vêm da plataforma (como Databricks) ou de ferramentas separadas, não do formato de tabela. O iFood usa Delta Lake sobre a plataforma Databricks, com dados organizados em camadas medallion. A mesma base alimenta dashboards de BI usados em toda a empresa e o trabalho dos cientistas de dados, que vai de simulações de logística ao treino de modelos sobre a jornada dos usuários no app (Databricks, 2022; Databricks, 2025).

O data lake sozinho também atende, mas a qualidade e a semântica ficam por conta de cada time, o que tende a gerar features duplicadas com definições diferentes.

Para analistas, o ponto que mais pesa é a consistência de definições. Se "cliente ativo" significa uma coisa no dashboard e outra no modelo de churn, a discussão sobre o resultado vira discussão sobre a métrica. Para engenheiros de ML, o que mais importa é point-in-time e reprodutibilidade.

Treino de deep learning e modelos com dados não estruturados

Aqui os requisitos mudam de natureza. Visão computacional, áudio e NLP exigem:

  • volume grande de arquivos binários;
  • throughput de leitura suficiente para manter as GPUs ocupadas;
  • controle sobre qual versão do dataset e dos rótulos gerou cada modelo.

O warehouse não se enquadra nesse cenário porque não foi feito para armazenar imagem ou áudio. O data lake é o lugar mais natural, pois oferece object storage barato, aceita qualquer formato e escala sem planejamento de schema. Não é coincidência que deep learning e data lakes tenham ganhado escala na mesma época.

A escala varia muito conforme o objetivo. Pré-treino de LLM opera na ordem de trilhões de tokens, mas poucas organizações fazem isso. A maioria dos times faz fine-tuning ou treina modelos de visão e áudio menores, com datasets de gigabytes a poucos terabytes. Mesmo nessa faixa, alguns custos aparecem rápido:

  • Arquivos pequenos. Milhões de JPEGs de poucos kilobytes geram sobrecarga de listagem e de requisições. Formatos em shards, como WebDataset, TFRecord ou Parquet com colunas binárias, reduzem esse custo.
  • Localidade. Treinar em uma região ou cloud com o dado em outra gera custo de transferência (egress) e latência.
  • I/O. Ler diretamente do object storage durante o treino pode se transformar num gargalo. Cache local e prefetch fazem diferença.
  • Versionamento. Sem controle, ninguém consegue dizer com quais imagens e quais rótulos um modelo foi treinado.

O lakehouse entra como complemento, não como substituto. Os binários continuam como objetos no storage, mas os metadados vão para uma tabela Delta ou Iceberg, com ACID e time travel: caminho do arquivo, rótulo, split de treino e validação, origem, licença e versão. Isso dá auditoria e reprodutibilidade sem mover os binários.

Para engenheiros de ML, os requisitos dominantes são throughput e reprodutibilidade. Para engenheiros de dados, são catálogo e ciclo de vida: retenção, classes de storage e custo de manter versões antigas.

RAG e aplicações com LLM

RAG (retrieval-augmented generation) recupera trechos relevantes de uma base de documentos e os entrega ao LLM como contexto para a resposta. Os requisitos são:

  • um corpus de documentos (PDFs, manuais, transcrições, tickets);
  • um pipeline de extração de texto, divisão em trechos (chunking) e geração de embeddings;
  • um índice vetorial para busca por similaridade;
  • controle de acesso;
  • atualidade dos dados.

Os documentos originais costumam viver no data lake. O lakehouse acrescenta governança ao pipeline, e a medallion se aplica bem:

  • Bronze: o documento original.
  • Silver: o texto extraído e limpo.
  • Gold: os trechos com seus embeddings e metadados.

Com isso, cada trecho tem linhagem até a versão do documento de onde saiu.

Uma distinção precisa ficar clara: Delta Lake e Iceberg não fazem busca vetorial. O índice vetorial é recurso de plataforma, como o Vector Search do Databricks, que sincroniza com uma tabela Delta. Ou então é um banco vetorial separado. Em ambos os casos, o índice é uma cópia derivada do dado. O ganho do lakehouse não é evitar duplicação, e sim manter a origem e a governança em um só lugar. O lakehouse é uma base possível para RAG, não a única. Muitas arquiteturas usam banco vetorial dedicado com o lake como fonte.

O warehouse não guarda o corpus, mas tem papel em aplicações com LLM. Perguntas como "quanto vendemos no Sul no último trimestre" são respondidas com mais precisão por text-to-SQL sobre tabelas modeladas do que por busca vetorial em documentos. Alguns warehouses em cloud já oferecem funções vetoriais.

Os trade-offs dessa carga são menos visíveis do que os das outras:

  • Permissões. Se um usuário não pode abrir um documento na fonte, também não pode receber um trecho dele na resposta do assistente. As regras de acesso precisam ser levadas até o índice, e esse costuma ser o ponto mais negligenciado do pipeline.
  • Data freshness (atualidade dos dados). Um documento atualizado na fonte continua respondendo com o texto antigo até o pipeline rodar de novo.
  • Reindexação. Trocar o modelo de embedding obriga a reprocessar o corpus inteiro, e o custo cresce com o tamanho dele.

Para engenheiros de IA, o foco tende a ser qualidade de recuperação. Já para os engenheiros de dados, o foco está em permissões, data freshness e linhagem, que são justamente o que decide se o sistema pode ir para produção.

Resumo por carga

Carga Warehouse Data Lake Lakehouse
ML supervisionado tradicional Alta. Ressalva: custo de compute e correção point-in-time Média. Qualidade e definições ficam por conta de cada time Alta. Feature store depende da plataforma, não do formato
Deep learning e dado não estruturado Baixa. Não armazena binários Alta. Ressalva: arquivos pequenos, I/O e versionamento Alta para metadados e versões. Binários seguem no object storage
RAG e aplicações com LLM Média, como contexto estruturado via text-to-SQL. Não guarda o corpus Média. Guarda o corpus, mas sem linhagem nem governança por padrão Alta. Índice vetorial vem da plataforma ou de banco separado

Nenhuma delas foi aposentada

Warehouses legados continuam no centro da operação de grandes empresas. No Bradesco, o warehouse Teradata segue em produção, agora em um ambiente híbrido entre on-premise e Azure (Teradata), enquanto a iniciativa de open finance roda sobre Delta Lake na plataforma Databricks (Databricks). O warehouse continua lá porque o requisito que atende continua existindo, não por inércia. O mesmo vale para os data lakes que ganharam uma camada de lakehouse: a Netflix não descartou o storage em S3 para criar o Iceberg, construiu sobre ele.

Por isso, a pergunta do título tem uma resposta menos direta do que parece. Não existe uma arquitetura que seja a melhor para aplicações de IA, porque "aplicação de IA" não é um requisito só. Um modelo de churn, um classificador de imagens e um assistente com RAG pedem coisas diferentes, e é comum que convivam na mesma empresa, às vezes no mesmo produto.

Na prática, três combinações aparecem com frequência:

  • Warehouse e data lake lado a lado. O warehouse serve BI, relatórios regulatórios e o contexto estruturado para LLMs. O lake guarda logs, documentos e binários para ciência de dados e treino.
  • Data lake com uma camada de lakehouse por cima. Quem tem um lake maduro não o descarta. Adiciona Delta ou Iceberg e converte tabela por tabela, com as duas formas coexistindo por meses ou anos. Os binários continuam como objetos, e os metadados ganham ACID, versionamento e linhagem.
  • Lakehouse com um índice vetorial ao lado. As camadas medallion governam o pipeline de documentos, e a busca vetorial fica com a plataforma ou com um banco dedicado.

A pergunta que orienta a decisão, então, não é qual arquitetura escolher, e sim quais requisitos cada carga impõe e como combinar as arquiteturas que atendem a eles. Uma escolha feita assim continua fazendo sentido quando a próxima arquitetura em alta aparecer.