Data Lakehouse em produção: as camadas, a governança e os padrões que não falham (e os que falham o tempo todo)

A promessa do Data Lakehouse sempre foi sedutora: o melhor dos dois mundos. O armazenamento barato do data lake com a atomicidade e as transações do data warehouse. Mas promessa e produção são universos paralelos.

O que mata projetos de lakehouse (e como evitálos)

Nos últimos anos, avaliei e reestructurei arquiteturas lakehouse em pelo menos oito empresas diferentes. O padrão de fracasso é surrado:

Sem catálogo centralizado: schemas mudam, ninguém sabe qual versão é a "certa", pipelines quebram silenciosamente. Tabela como pasta: parquet em S3 com estrutura de diretórios "tabela/ano=2024/mes=03/" não é uma tabela. É um diretório com ilusão de estrutura. Governança póshoc: tentar adicionar qualidade, lineage e políticas de retenção depois que você tem 2.000 tabelas é como colocar o cinto de segurança depois da batida. Formato lockin sem motivo: escolher Delta Lake porque todo mundo usa, sem avaliar o ecossistema, te prende num fornecedor que pode não ser o melhor fit.

flowchart LR
    subgraph Sources["Source Systems"]
        BATCH["Batch"]
        STREAM["Streaming"]
    end
    subgraph Bronze["BRONZE - Raw Ingestion"]
        INGEST["Ingestion"]
    end
    subgraph Silver["SILVER - Cleansed & Processed"]
        PROCESS["Processing"]
    end
    subgraph Gold["GOLD - Business Ready"]
        SERVE["Serving"]
    end
    BATCH -->|Batch Ingest| INGEST
    STREAM -->|Stream Ingest| INGEST
    INGEST --> Bronze
    Bronze --> Silver
    Silver --> Gold
    subgraph CATALOG["Unity Catalog"]
        META["Metadata Catalog"]
    end
    INGEST -.->|Register| META
    PROCESS -.->|Register| META
    SERVE -.->|Register| META
    subgraph Consumers["Query Engines"]
        SPARK["Spark"]
        TRINO["Trino"]
        BI["Business Intelligence"]
        ML["ML Training"]
    end
    META -->|Discover| SPARK
    META -->|Discover| TRINO
    META -->|Discover| BI
    META -->|Discover| ML

A decisão fundamental: formato de tabela

Vou direto ao que importa. Antes de pensar em camadas ou governança, você precisa escolher o formato de tabela. Isso impacta tudo downstream.

Minha recomendação em produção real:

Apache Iceberg para a maioria dos casos. A combinação de formato aberto + suporte crossplatform + hidden partitions é o conjunto mais robusto. Você consegue ler a mesma tabela de Spark, Trino e DuckDB sem reescrever nada.

Delta Lake faz sentido se você já vive no ecossistema Databricks ou precisa de features específicas como Change Data Feed (CDF) com maturidade comprovada.

Hudi é a escolha correta quando você tem um caso de uso pesado de upserts incrementais (CDC, log append) e está em ambiente EMR ou Spark nativo.

As camadas que funcionam em produção

O modelo Bronze, Silver, Gold não é dogma. É uma convenção que sobreviveu porque facilita comunicação entre times e define contratos claros de qualidade. O que importa de verdade:

Bronze: raw, imutável, auditável

Dados exatamente como vieram da fonte. Sem transformações além do essencial (parsing de tipos, normalização de charset). Esta camada precisa ser:

Imutável por pipeline de negócio: uma vez escrita, não se sobrescreve. Corrections vão para Silver. Com lineage completa: você precisa saber, para cada linha, qual arquivo, qual job e qual timestamp a gerou. Armazenada no menor granularity possível: idealmente em nível de evento/registro, não em batch files diários.

 Exemplo: Query Bronze via Iceberg com lineage implícita
SELECT 
    _file,
    _snapshot_id,
    _spec_id,
    ingested_at,
    source_system,
    payload
FROM bronze.events
WHERE _snapshot_id = 1234567890
  AND source_system = 'erp_sap';

Silver: validada, enriquecida

Esta é a camada onde a mágica acontece. Aqui você:

Aplica regras de qualidade (null checks, range validation, referential integrity) Desnormaliza joins recorrentes (ex.: customers com endereços atuais) Adiciona chaves de negócio (surrogate keys, hash chaves naturais) Implementa slowly changing dimensions (SCD Tipo 2 quando necessário)

A Silver é a sua golden source para analytics e ML. Se alguém precisa de um dado confiável, vai aqui.

Gold: produto de dados, pronta para consumo

Agregações, métricas de negócio, tabelas dimensionais. Aqui você otimiza para query patterns específicos:

Aggregated tables: rollups diários, semanais, mensais por customer_id, region, product_category Wide tables: joins precomputados para BI tools que não fazem join bem (sim, Tableau, estou olhando para você) Feature stores: se você faz ML, a Gold pode alimentar sua feature store diretamente

Governança que escala

Lakehouse sem governança é só um lago mais caro. Os três pilares:

Catálogo centralizado (não é opcional)

Unity Catalog (Databricks) ou Hive Metastore + Iceberg REST Catalog API. A diferença entre ter e não ter catálogo é a diferença entre engineering e arqueologia de dados.

curl X POST http://catalog:8181/v1/catalogs/prod/namespaces/marketing/tables \
  H 'ContentType: application/json' \
  d '{
    "name": "silver.campaign_performance",
    "type": "ICEBERG",
    "schema": {
      "type": "struct",
      "fields": [
        {"name": "campaign_id", "type": "string", "required": true},
        {"name": "impressions", "type": "long"},
        {"name": "clicks", "type": "long"},
        {"name": "revenue", "type": "decimal(18,2)"}
      ]
    },
    "partitioning": [{"name": "dt", "transform": "day"}],
    "properties": {
      "owner": "data_team",
      "classification": "internal",
      "pii": "false"
    }
  }'

Data contracts (o que a maioria ignora)

Estabeleça contratos formais entre producers e consumers:

Schema registry com validação: Avro/Protobuf com Schema Registry, ou Iceberg schema validation on write SLO de qualidade: % de nulls, freshness, volume variance thresholds Breaking change protocol: 30 dias de deprecated notice antes de drop column

Lineage granular

Apache Iceberg com sua feature de metadata tables permite lineage em nível de coluna. Não é perfeito (precisa de integração com sua orchestrator para lineage crosssystem), mas é o ponto de partida.

 Lineage via Iceberg metadata tables
SELECT 
    manifest_path,
    added_files_count,
    deleted_files_count,
    partition_spec_id
FROM bronze.events.files
WHERE snapshot_id = (SELECT snapshot_id FROM bronze.events.metadata);

Os padrões que provaram funcionar

Ingestão em microbatches ou streaming: não faça batch diário de 80GB. Faça writes incrementais de minutos. Sua Silver agradece. Mergeonread vs copyonwrite: para tabelas com mais writes que reads, use MOR. Para tabelas analíticas com reads pesados, COW com compressão periódica. Compaction agendado: tabelas Iceberg com muitos small files degradam. Rode OPTIMIZE com frequência (a cada 14 horas em tabelas quentes). Expire snapshots regularmente: por padrão, Iceberg mantém histórico infinito. Configure write.metadata.deleteaftercommitduration e write.metadata.previousversionsmaxnum. Partition evolution, não repartition: se você particionou errado no início, use ALTER TABLE SET PARTITION SPEC para evoluir sem reescrever tudo.

O que não fazer

Não use múltiplos catálogos para o mesmo ambiente (splitbrain de metadados é um pesadelo operacional) Não pule a compactação: small files são o assassino silencioso de performance em S3/ADLS Não trate tabelas não versionadas como transacionais: se você precisa de ACID, o formato precisa suportar Não pule o data contract: o custo de um schema breaking change em produção é 10x o custo de documentar o contrato antes

Conclusão

Data Lakehouse funciona quando você trata as camadas como contratos de qualidade, escolhe o formato de tabela baseado no ecossistema e não no hype, e coloca governança no centro, não como layer no final. O formato open (Iceberg) te dá portabilidade, o catálogo centralizado te dá controle, e as camadas bem definidas te dão sanidade mental quando o volume de dados cresce 10x.

A decisão técnica não é qual tecnologia usar. É qual combinação de tecnologias forma um sistema coerente que seu time consegue operar, evoluir e debugar às 2h da manhã.

Se você está desenhando ou revisando uma arquitetura lakehouse e quer uma conversa sem compromisso sobre padrões, tabelas e governança que se encaixam no seu contexto, converse com a gente.

Fale com um especialista da Eficify