Guia de plataforma de dados

Arquitetura Medallion

Bronze, Silver, Gold – o padrão para ingerir dados brutos rápido, limpá-los aos poucos e entregar datasets prontos para o negócio. Este guia mostra como aplicar a Arquitetura Medallion sem over-engineering.

22 min de leituraPara data & platform engineersCom exemplos de código

1. O que é a Arquitetura Medallion?

Arquitetura Medallion é um padrão que organiza o lakehouse em três camadas progressivas: Bronze (bruto), Silver (limpa) e Gold (pronta para o negócio). Cada camada aumenta a qualidade e aproxima do valor de negócio.

A ideia central

Bronze

Bruto, como veio

Silver

Limpa, conforme

Gold

Pronta para o negócio

Por que não limpar só uma vez?

Porque as regras mudam. Manter o bruto em Bronze permite reprocessar quando a lógica evolui. Quem pula Bronze acaba reingestando quando alguém pede “os dados antes daquele filtro”.

Quando usar a Arquitetura Medallion:

Múltiplas fontes

Ao ingerir 10+ fontes com formatos, esquemas e qualidades diferentes.

Consumidores distintos

Data scientists querem bruto, analistas querem limpo, dashboards querem agregados.

Requisitos mutáveis

Quando a lógica de negócio muda com frequência e você precisa reprocessar histórico.

Conformidade

Quando são necessários trilhas de auditoria, lineage e prova do estado dos dados em qualquer momento.

Da prática

Não é sobre o nome; é sobre o princípio: não perder o bruto, melhorar a qualidade em etapas e entregar a abstração certa para o público certo. Pode chamar de “raw/staging/marts” ou “landing/curated/consumption” – o padrão é o que importa.

2. As três camadas

Cada camada tem objetivo, responsável e nível de qualidade. Esse modelo mental faz a Medallion funcionar.

CamadaPropósitoQualidadeConsumidores
🥉 BronzeAterrissar o bruto exatamente como chegouNenhuma – manter tudoEngenheiros de dados, debug
🥈 SilverLimpar, deduplicar, conformar esquemasValidado, tipado, consistenteData scientists, analistas avançados
🥇 GoldAgregados e métricas de negócioAprovado pelo negócio, documentadoDashboards, relatórios, apps

Princípios-chave para cada transição:

🥉→🥈

De Bronze para Silver

Limpar e conformar

Remover duplicados, converter tipos, aplicar esquema, filtrar registros inválidos, padronizar formatos (datas, moedas, códigos).

🥈→🥇

De Silver para Gold

Agregar e enriquecer

Fazer joins, calcular métricas de negócio, aplicar lógica, criar modelos dimensionais, otimizar para padrões de consulta.

Dica

Não pule o Silver

É tentador ir direto de Bronze para Gold, mas o Silver é onde vive a qualidade. Sem ele, a limpeza vira cópia em cada tabela Gold e mudanças ficam caras e arriscadas.

3. Camada Bronze em detalhe

Bronze é o seu “data lake” puro: tudo cai aqui exatamente como veio. O objetivo é durabilidade e rastreabilidade, não limpeza.

O que deve ter Bronze

  • • Dados brutos exatamente como recebidos (JSON, CSV, Parquet)
  • • Metadados de ingestão (timestamp, arquivo fonte, batch ID)
  • • Escritas append-only (nunca update/delete)
  • • Particionamento por data de ingestão
  • • Retenção longa (meses a anos)

O que NÃO deve ter

  • • Enforcement de esquema (deixe o ruim entrar)
  • • Transformações
  • • Lógica de deduplicação
  • • Lógica de negócio ou cálculos
  • • Acesso para usuários de negócio

Estrutura de uma tabela Bronze:

Exemplo: schema da tabela Bronze orders

-- Bronze: raw_orders
CREATE TABLE bronze.raw_orders (
  -- Ingestion metadata
  _ingested_at      TIMESTAMP,
  _source_file      STRING,
  _batch_id         STRING,
  
  -- Raw payload (store as-is)
  raw_payload       STRING,  -- JSON string, unparsed
  
  -- Or if structured:
  order_id          STRING,  -- Not validated yet
  customer_id       STRING,
  order_date        STRING,  -- Could be any format
  amount            STRING,  -- Could have currency symbols
  status            STRING
)
PARTITIONED BY (_ingested_at::DATE)

Adicione metadados de ingestão

Timestamp, arquivo fonte, batch ID. Necessário para debug e reprocessamento.

Use apenas append

Nunca faça UPDATE ou DELETE em Bronze. Correção = novo registro com novo timestamp.

Particione por data de ingestão

Facilita reprocessar janelas específicas e gerir retenção.

Mantenha barato

Use formatos comprimidos (Parquet, ORC) e storage frio para partições antigas.

4. Camada Silver em detalhe

Silver é onde o trabalho pesado acontece. É a fonte de verdade enterprise para dados limpos e validados.

Responsabilidades do Silver:

1

Enforcement de esquema

Converter tipos, impor NOT NULL, validar formatos. Registros ruins vão para uma tabela de quarentena.

2

Deduplicação

Remover duplicados. Usar chaves de negócio + timestamp para manter a versão mais recente.

3

Padronização

Normalizar datas em ISO, moedas em base, códigos em valores padrão.

4

Checks de qualidade

Testes automáticos: taxas de null, unicidade, integridade referencial, faixas de valores.

Exemplo: transformação Silver orders (dbt)

-- models/silver/orders.sql
WITH source AS (
  SELECT * FROM {{ source('bronze', 'raw_orders') }}
  WHERE _ingested_at >= CURRENT_DATE - INTERVAL '7 days'
),

deduplicated AS (
  SELECT *,
    ROW_NUMBER() OVER (
      PARTITION BY order_id 
      ORDER BY _ingested_at DESC
    ) as row_num
  FROM source
),

cleaned AS (
  SELECT
    -- Cast and validate types
    CAST(order_id AS BIGINT) AS order_id,
    CAST(customer_id AS BIGINT) AS customer_id,
    
    -- Standardize date format
    TO_DATE(order_date, 'YYYY-MM-DD') AS order_date,
    
    -- Clean amount (remove currency symbols)
    CAST(REGEXP_REPLACE(amount, '[^0-9.]', '') AS DECIMAL(10,2)) AS amount,
    
    -- Normalize status to uppercase
    UPPER(TRIM(status)) AS status,
    
    -- Keep lineage
    _ingested_at,
    _batch_id
  FROM deduplicated
  WHERE row_num = 1
    AND order_id IS NOT NULL
)

SELECT * FROM cleaned

Da prática

Silver é onde muitos times investem pouco. Correm para o Gold e duplicam limpeza em todo lugar. Invista no Silver – o retorno aparece em cada modelo downstream.

5. Camada Gold em detalhe

Gold é onde vive o valor de negócio. São as tabelas realmente consultadas pelos stakeholders. Pense em modelos dimensionais, métricas e agregados específicos de uso.

Padrões comuns em Gold:

Modelos dimensionais (star schema)

Tabelas fato (eventos, transações) cercadas por dimensões (clientes, produtos, tempo). Otimizadas para BI e queries ad hoc.

Exemplo:

fact_orders ← dim_customers, dim_products, dim_date

Métricas pré-agregadas

Rollups diários/semanais/mensais para dashboards. Queries mais rápidas e menos custo de compute.

Exemplo:

daily_revenue_by_region, weekly_active_users, monthly_churn_rates

Feature tables (ML)

Features pré-computadas para modelos de ML. Correção point-in-time, versionadas.

Exemplo:

customer_features, product_embeddings, user_activity_signals

Exemplo: tabela fato Gold (dbt)

-- models/gold/fact_orders.sql
WITH orders AS (
  SELECT * FROM {{ ref('silver_orders') }}
),

customers AS (
  SELECT * FROM {{ ref('dim_customers') }}
),

products AS (
  SELECT * FROM {{ ref('dim_products') }}
)

SELECT
  -- Surrogate key
  {{ dbt_utils.generate_surrogate_key(['o.order_id']) }} AS order_key,
  
  -- Foreign keys to dimensions
  c.customer_key,
  p.product_key,
  d.date_key,
  
  -- Degenerate dimensions
  o.order_id,
  o.status,
  
  -- Measures
  o.quantity,
  o.unit_price,
  o.quantity * o.unit_price AS line_total,
  o.discount_amount,
  
  -- Audit columns
  o._ingested_at AS source_loaded_at,
  CURRENT_TIMESTAMP AS dbt_loaded_at

FROM orders o
LEFT JOIN customers c ON o.customer_id = c.customer_id
LEFT JOIN products p ON o.product_id = p.product_id
LEFT JOIN {{ ref('dim_date') }} d ON o.order_date = d.date_day

Princípio Gold

Otimizar para queries

Particione por colunas mais filtradas (data, região). Faça clustering nas chaves de join.

Princípio Gold

Documentar lógica de negócio

Cada tabela Gold deve ter definições claras das métricas.

Princípio Gold

Versionar com cuidado

Mudanças em Gold podem quebrar dashboards. Use versionamento semântico ou aliases.

6. Padrões de implementação

A Medallion funciona em qualquer plataforma moderna. Veja como implementá-la com os stacks mais comuns.

PlataformaBronzeSilver/GoldFormato
DatabricksUnity CatalogDelta Lake + dbtDelta
SnowflakeDatabase RAWdbt + SnowflakeTabelas nativas
BigQueryDataset raw_dbt + BQTabelas nativas
AWS (Open)S3 + GlueSpark + dbtIceberg/Hudi

Estrutura de pastas/bancos:

# Convenção típica
catalog/
├── bronze/
│   ├── raw_orders
│   ├── raw_customers
│   ├── raw_products
│   └── raw_events
├── silver/
│   ├── orders           # Pedidos limpos
│   ├── customers        # Clientes limpos
│   ├── products         # Produtos limpos
│   └── events           # Eventos limpos
├── gold/
│   ├── dim_customers    # Dimensão: clientes
│   ├── dim_products     # Dimensão: produtos
│   ├── dim_date         # Dimensão: data
│   ├── fact_orders      # Fato: pedidos
│   └── agg_daily_sales  # Agregado: vendas diárias
└── quarantine/
    ├── orders_failed    # Registros que falharam
    └── events_failed

Dica

Use bancos/esquemas separados

Não use só prefixos (raw_, silver_, gold_). Separe bancos ou esquemas para aplicar permissões, políticas de storage e retenção específicas por camada.

7. Checklist de boas práticas

Nunca delete em Bronze

Somente append. Correção = novo registro. Bronze é sua trilha de auditoria.

Invista pesado em Silver

Aqui vive a qualidade. Dedup, enforcement de schema e padronização precisam estar sólidos.

Mantenha Gold simples

Tabelas Gold devem ser fáceis de consultar. Pré-join, pré-agregue, otimize para o consumidor.

Documente tudo em Gold

Cada tabela Gold precisa de: owner, descrição, definições de colunas, frequência, SLA.

Procésse de forma incremental

Só dados novos/alterados. Full refresh é caro em escala.

Mande registros ruins para quarentena

Não descarte em silêncio. Roteie para investigar.

Teste em cada camada

Checks de qualidade em Bronze → Silver (esquema), Silver → Gold (regras de negócio), Gold (métricas).

Controle acesso por camada

Bronze: só engenheiros de dados. Silver: time de dados. Gold: usuários de negócio e dashboards.

Da prática

Times que sofrem com Medallion geralmente tratam como uma migração única, não uma arquitetura contínua. Cada camada precisa de dono, manutenção e melhoria constante.

8. Perguntas frequentes

O que é a Arquitetura Medallion?

Um padrão que organiza os dados em três camadas: Bronze (bruto), Silver (limpa e conforme) e Gold (agregados de negócio). Ele melhora a qualidade de forma incremental no lakehouse.

Qual a diferença entre Bronze, Silver e Gold?

Bronze: dados brutos. Silver: dados limpos, deduplicados, conformes. Gold: agregados e métricas para dashboards e ML.

Quando devo usar a Arquitetura Medallion?

Quando há várias fontes, necessidade de melhorar qualidade em etapas, suportar batch/streaming ou servir diferentes públicos.

É só para Databricks?

Não. Funciona em Snowflake, BigQuery, Redshift ou stacks open source com Delta Lake, Apache Iceberg ou Apache Hudi. Bruto → Limpo → Agregado vale em qualquer lugar.

Visualize sua Arquitetura Medallion

Crie diagramas claros com as camadas Bronze, Silver e Gold. Documente fluxos, transformações e ownership em minutos.