Camada Medalhão (Medallion Architecture)

“Medalhão” é um padrão de camadas para organizar dados no data lake/warehouse.

As três camadas clássicas são Bronze → Silver → Gold.

Elas também são chamadas de Raw/Trusted/Refined ou Stage/ODS/DM.

A ideia é separar ingestão, padronização e consumo para ganhar qualidade, rastreabilidade e velocidade. Separação clara entre ingestão → padronização → consumo

A regra prática: Bronze = entra tudo; Silver = fica confiável; Gold = fica útil.

O conceito funciona tanto no data warehouse e para o data lake.

Em lake, os arquivos vivem em pastas com os nomes das camadas; em DW, você mapeia para schemas e tabelas.

Você pode ter mais de três camadas, mas essas três são essenciais para qualquer negócio.

Fluxo típico

1. Ingestão → Bronze• Arquivos CSV/JSON/Parquet, dumps SQL, logs e APIs.• Particionado por data de chegada (ex.: YYYY=2025/MM=09/DD=08).

2. Tratamento → Silver/ODS• Padronização de tipos, normalização de nomes, remoção de duplicidades.• Join entre entidades, chaves substitutas, CDC e SCD.

3. Modelagem → Gold/DM• Tabelas em estrela (fato/dimensões), agregações por período e por negócio.• Controles de qualidade finais e contratos de schema para consumo.

Por que usar a arquitetura em camadas?

• Qualidade: cada etapa melhora a confiabilidade (limpeza, padronização, regras de negócio).

• Rastreabilidade: você consegue explicar “de onde veio” qualquer métrica (linhagem).

• Evolução segura: mudanças são absorvidas na camada certa, reduzindo impactos.

• Performance: dados prontos para consumo (Gold/DM) atendem BI, APIs e ciência de dados com rapidez.

• Governança: facilita contratos de dados, versionamento de esquemas e controles de acesso.

Camadas extras

Transient / Landing

O que é: zona efêmera de aterrissagem antes da Bronze/Raw.Para quê: garantir ingestão atômica e higienizar o mínimo (nome/estrutura/checagem). Tarefas típicas: validação de checksum/tamanho; antivírus; verificação de cabeçalho; renomear; datar; mover; rejeitar o que está ruim. Retenção: horas ou poucos dias; não é fonte de verdade.Boas práticas: escrever em nome temporário e depois rename/commit; só move para Bronze se passar nos checks. Evite: aplicar regra de negócio aqui; deixar dado “morar” no transient.

Quarantine

O que é: estacionamento separado para arquivos/registros inválidos.

Para quê: isolar ruído sem contaminar Bronze/Silver; permitir triagem e auditoria.

Como usar: etiqueta motivo (ex.: schema_mismatch, checksum_fail, duplicado); manter contadores e alertas; abrir ticket automático.Retenção: maior que Transient (dias/semanas) com auto-clean.

Evite: “consertar” manualmente sem registrar correção/causa-raiz.

Sandbox (Exploração)

O que é: área controlada para analistas explorarem dados (amostras ou cópias controladas).

Para quê: prototipar métricas, SQL, notebooks, sem arriscar Silver/Gold.

Fontes: geralmente leitura de Silver/Gold; às vezes amostras mascaradas de Bronze.

Governança: quotas de compute/armazenamento; tempo de vida curto; IaC para recriar; acesso restrito; PII mascarada.

Evite: virar “produção paralela”; copiar dataset inteiro sem necessidade

Experiment (ML)

O que é: ambiente para treino/validação de modelos.

Para quê: testar features, algoritmos e hiperparâmetros com rastreamento.Pilares: versionar dados/seed/código; MLflow/DAGs; registrar resultados; separar offline (treino) de online (serving).

Fontes: Silver (trusted) + Feature Store; às vezes Bronze para POCs.

Evite: usar dados “do futuro” (leakage); não registrar metadados (irreprodutível).

Feature Store

O que é: catálogo de features calculadas e versionadas para reuso por múltiplos modelos.

Partes:

• Offline store (lake/DW) para treino e backfills;

• Online store (KV/DB de baixa latência) para servir em produção.Requisitos: keys claras (ex.: entity_id, event_timestamp), point-in-time correctness (sem olhar o futuro), time travel, linhagem, documentação de semântica.Operação: pipelines que materializam/atualizam features; backfills por janela; políticas de TTL no online.

  Evite: duplicar lógica de feature em cada projeto; divergência offline/online (training–serving skew).

Serving / Apps / APIs

O que é: a fronteira de consumo (batch e/ou tempo real).

Para quê: expor Gold/DM e/ou predições como relatórios, dashboards, microserviços, streams, exports. SLO/SLA: latência, frescor, disponibilidade; cache; filas/retries.

Evite: servir diretamente de Bronze; quebrar contratos de schema sem versionar.