Lakehouse

Durante anos, arquiteturas de dados corporativas viveram num dilema: data warehouses entregavam performance, governança e suporte a SQL maduro, mas eram caros para armazenar grandes volumes e inflexíveis para workloads de ML. Data lakes entregavam armazenamento barato e suporte a dados brutos não estruturados, mas viravam data swamps sem governança, e ferramentas de BI não conseguiam consultar o lake diretamente com performance aceitável. A solução comum era manter os dois — warehouse para BI, lake para ML — duplicando dados, multiplicando pipelines e criando inconsistências entre os dois mundos.

Lakehouse é uma arquitetura de dados que combina as melhores características do data lake e do data warehouse em uma única plataforma: armazenamento em formato aberto no object storage (S3, GCS, Azure Blob), com camada de metadados, suporte transacional (ACID), controle de esquema e qualidade de dados que antes existiam apenas em warehouses. O resultado é uma plataforma que suporta BI, ML, analytics e engenharia de dados sobre os mesmos dados, sem duplicação.

O conceito foi formalizado pela Databricks em 2020, mas a ideia emergiu da evolução prática de times que tentavam fazer data lakes funcionarem com a confiabilidade de warehouses. Formatos de tabela abertos como Delta Lake, Apache Iceberg e Apache Hudi são a tecnologia central que tornou o lakehouse viável.

O modelo tradicional de dois camadas — lake para ingestão/ML, warehouse para BI — tinha custos operacionais altos e problemas de consistência sistemáticos.

Duplicação de dados: o mesmo dado existia no lake (para ciência de dados) e no warehouse (para BI). Pipelines separados para mover dados entre os dois. Quando os dados divergiam — e divergiam — a discussão era sobre qual versão era a "verdade".

Latência de dados: dados processados no lake precisavam ser carregados no warehouse antes de ficarem disponíveis para BI. Dependendo do pipeline, essa latência variava de horas a um dia. Análises de dados recentes dependiam de quando o ETL rodou por último.

Custo de armazenamento: warehouses tradicionais cobram pelo armazenamento em formato proprietário. Armazenar terabytes de dados históricos em Snowflake ou BigQuery é significativamente mais caro do que S3 com parquet.

Rigidez de schema: warehouses exigem schema definido na entrada. Dados não estruturados, semi-estruturados (JSON aninhado, logs) ou de schema evolutivo eram difíceis de acomodar.

O lakehouse não elimina todos esses problemas, mas reduz sua severidade ao unificar o armazenamento e adicionar a camada de gestão que faltava nos lakes puros.

A tecnologia central do lakehouse são os formatos de tabela transacionais que transformam arquivos parquet no object storage em tabelas gerenciáveis.

Delta Lake (Databricks, open source): o formato mais adotado no ecossistema Spark/Databricks. Adiciona um transaction log (arquivos JSON) sobre arquivos parquet, habilitando ACID, time travel (consultar versões históricas dos dados), schema enforcement, schema evolution controlada e operações de upsert (MERGE). VACUUM remove versões antigas; OPTIMIZE consolida pequenos arquivos.

Apache Iceberg (Netflix, open source): adotado por AWS, Google, Apple. Suporte a evolução de schema sem quebrar queries existentes, particionamento escondido (o usuário não precisa saber como os dados estão particionados para consultar eficientemente), partitioning evolution e snapshots para time travel. Favorito em ambientes multi-engine (Spark, Flink, Trino, Snowflake, BigQuery podem ler o mesmo Iceberg).

Apache Hudi (Uber, open source): otimizado para casos de uso de streaming — upserts incrementais de alta frequência. Dois tipos de tabela: Copy-on-Write (melhor para leitura) e Merge-on-Read (melhor para ingestão de alta frequência). Forte em casos de CDC (Change Data Capture) direto para o lake.

A escolha entre os três depende do ecossistema: Databricks → Delta Lake natural. AWS com engines múltiplas → Iceberg. Streaming com CDC intenso → Hudi. Todos entregam as funcionalidades essenciais de ACID e time travel.

A Arquitetura Medallion — camadas Bronze, Silver e Gold — é o padrão de organização de dados dentro de um lakehouse. As três camadas existem no mesmo object storage, com formatos de tabela abertos, sem necessidade de mover dados para sistemas distintos.

Bronze (Raw): dados brutos como chegam das fontes — sem transformação, preservando erros, duplicatas e inconsistências originais. Histórico completo. Auditável. Se algo der errado no processamento downstream, os dados originais estão aqui.

Silver (Cleaned): dados limpos, validados, com duplicatas removidas, schemas padronizados, joins com tabelas de referência aplicados. O dado que analistas e cientistas de dados usam como ponto de partida. Estruturado, mas não ainda agregado para análises específicas.

Gold (Curated): datasets derivados otimizados para casos de uso específicos — tabelas de fatos e dimensões para BI, features pré-calculadas para modelos de ML, agregações de KPIs operacionais. Mais restrito em escopo, mas mais rápido para consumo.

A Medallion define a semântica das camadas; os formatos de tabela (Delta/Iceberg/Hudi) garantem que cada camada tem as propriedades transacionais necessárias.

Databricks Lakehouse Platform: a implementação mais completa do conceito. Delta Lake nativo, Spark para processamento, Unity Catalog para governança e metadados, MLflow integrado para MLOps, SQL Warehouse para analytics BI. Disponível em AWS, Azure e GCP. A plataforma que mais investiu em tornar o lakehouse operacional end-to-end.

Apache Spark + Delta/Iceberg (self-managed): para times que querem controlar a infraestrutura. Mais complexo de operar, mas sem lock-in de plataforma.

AWS Lake Formation + Glue + Athena + Iceberg: o stack lakehouse da AWS. Lake Formation para governança, Glue para ETL, Athena para SQL ad hoc, Iceberg como formato de tabela. Integrado com S3 nativo.

Google BigLake: extensão do BigQuery para suportar dados no Google Cloud Storage no formato Iceberg, com as capacidades de governança do BigQuery. Permite que o BigQuery consulte dados externos sem movê-los.

Snowflake (abordagem híbrida): tradicionalmente warehouse, Snowflake adicionou suporte a Iceberg external tables — permitindo que dados no S3/GCS em formato Iceberg sejam consultados via SQL do Snowflake, com custo de armazenamento do object storage. Não é lakehouse nativo, mas convergiu para o modelo.

Lakehouse é a resposta arquitetural correta para organizações que cresceram além do que um data warehouse consegue acomodar economicamente, mas ainda não sabem como fazer um data lake funcionar com confiabilidade. Para empresas com dados estruturados e não estruturados, com times de BI e ciência de dados trabalhando sobre os mesmos dados, ou com volumes que tornam o custo de warehouse proibitivo, o lakehouse resolve o dilema sem forçar escolha.

Para PMEs que estão começando a montar stack de dados, a avaliação pragmática é simples: se o volume de dados e a complexidade de workloads justificam a infraestrutura de um lakehouse, Databricks tem a curva de adoção mais suave e o conjunto de funcionalidades mais completo. Se o volume ainda cabe confortavelmente num data warehouse gerenciado (BigQuery, Snowflake, Redshift), o warehouse é mais simples de operar — e não há virtude em adotar lakehouse por antecipação.

O risco mais comum em lakehouse não é técnico — é organizacional. O lakehouse remove a fricção de armazenar qualquer dado, e isso facilita armazenar tudo sem disciplina. A Arquitetura Medallion e um Data Catalog ativo são os guardrails que transformam "lake com superpoderes" em ativo gerenciável em vez de data swamp sofisticado.