o problema
A primeira geração de plataformas analíticas era o warehouse clássico: dado vindo dos bancos operacionais, schema-on-write, modelo otimizado para BI. Funcionava até dois limites aparecerem juntos. Compute e storage vinham acoplados num appliance on-premise, o que obrigava a empresa a provisionar e pagar pelo pico de carga e de volume. E o warehouse simplesmente não sabia guardar vídeo, áudio e documento — a fatia dos dados que mais crescia.
A resposta foi o data lake: jogar tudo cru num storage barato com API de arquivo, em formato aberto como Parquet e ORC. Primeiro HDFS, depois S3, ADLS e GCS. Barato, durável, aberto — e schema-on-read, o que quer dizer que o problema de qualidade e governança foi empurrado para baixo, não resolvido. Como BI continuava precisando de warehouse, um subconjunto do lake era ETLado de novo para um Redshift, um Teradata, um Snowflake. Essa arquitetura de dois andares, dizem os autores a partir da própria experiência, é hoje a norma em praticamente toda a Fortune 500. E cobra caro em quatro frentes: confiabilidade, porque dois motores com dialetos e tipos diferentes multiplicam os modos de falha; atualidade, porque o dado no warehouse chega dias depois; analytics avançado, porque nenhuma biblioteca de ML lê formato proprietário de warehouse; e custo total, porque se paga armazenamento em dobro mais o lock-in do formato fechado. O paper chama isso de complexidade acidental.
a ideia
Inverter quem é dono do formato. Em vez de o warehouse guardar os dados num formato interno que só ele lê, o dado fica em Parquet no object store — acessível direto por qualquer engine — e as funções de warehouse são construídas por cima: transação ACID, versionamento, auditoria, índice, cache, otimização de consulta. Isso é o lakehouse.
O preço da inversão está explícito: abrir mão de parte da data independence. O formato de armazenamento vira API pública do sistema. A pergunta técnica do paper é se ainda dá para ser rápido nessas condições. A alternativa óbvia — matar o lake e colocar tudo num warehouse com compute e storage separados — os autores descartam pela baixa adoção: continua sem resolver vídeo, áudio e texto, nem acesso direto para ML.
como funciona
Três peças. A primeira é a camada de metadados transacional. O Delta Lake, que a Databricks começou em 2016, guarda no próprio object store um log em Parquet dizendo quais objetos compõem cada versão da tabela; o Iceberg, saído da Netflix, faz desenho parecido sobre Parquet e ORC; o Hudi, saído da Uber, foca em ingestão streaming e não suportava escritores concorrentes. Converter um diretório Parquet existente em tabela Delta é zero-copy: escreve-se um log inicial referenciando os arquivos que já estão lá. A mesma camada é o lugar natural para schema enforcement, constraints de ingestão e controle de acesso.
A segunda é performance sem tocar no formato. Cache: com transação, o sistema sabe quando um arquivo em SSD ou RAM ainda vale, e pode guardá-lo transcodificado — o cache da Databricks descomprime parcialmente o Parquet. Dados auxiliares: estatísticas min-max por arquivo, guardadas junto do log de transações, permitem data skipping; um índice por Bloom filter estava em construção. Layout: ordenar registros por dimensão ou por curva espacial como Z-order e Hilbert aproxima o que é lido junto. Dado quente resolve no cache, dado frio resolve lendo menos.
A terceira é a API para ML. Em vez de entregar a lista de arquivos Parquet para a biblioteca, o DataFrame declarativo do Spark avalia as transformações preguiçosamente, vira plano de consulta e empurra seleções e projeções para o data source do Delta Lake — que então aplica cache, skipping e layout. MLlib, GraphFrames, SparkR e Koalas herdam isso de graça.
No TPC-DS em scale factor 30.000, com clusters de 960 vCPUs em AWS, Azure e Google Cloud, o Delta Engine roda as 99 queries em 3.302 segundos; os quatro warehouses comerciais comparados ficam entre 2.996 e 37.283 segundos, a um custo maior.
o que isso custou
O benchmark é do fabricante, e todos os sistemas começaram com dado em cache no SSD — porque alguns dos warehouses comparados só suportavam storage local. Com cache frio, o Delta Engine ficou 18% mais lento, o que o paper reporta em nota de rodapé.
Os limites de projeto são mais interessantes. Guardar o log de transações no mesmo object store simplifica a operação e dá alta disponibilidade, mas a latência do S3 limita o número de transações por segundo; um storage rápido só para metadados seria melhor em alguns casos. Delta, Iceberg e Hudi transacionavam uma tabela por vez. O formato dos arquivos continua congelado: as otimizações são todas ao redor dele, e desenhar um formato aberto melhor fica como problema em aberto. E as APIs de ML que não empurram semântica de consulta para o storage, como tf.data, ficam de fora do ganho.
onde isso aparece hoje
O paper não descreve um sistema pronto, descreve uma aposta — e o próprio texto já traz a evidência de adoção: o Delta Lake passou a responder por cerca de metade das compute-hours da Databricks em três anos. O termo virou categoria de produto, e a briga entre camadas de metadados abertas sobre Parquet — Delta Lake de um lado, Iceberg do outro — é hoje a briga central do mercado de dados analíticos.
O contexto imediato é o The Snowflake Elastic Data Warehouse, que separou compute de storage mantendo o formato fechado, e o Amazon Redshift Re-invented, que foi pelo mesmo caminho e, como os autores notam, acabou adicionando tabelas externas em Parquet. A infraestrutura que torna o desenho viável vem do Resilient Distributed Datasets e do Spark SQL. E a leitura de longo prazo desse vaivém entre motor fechado e formato aberto está em What Goes Around Comes Around… And Around….