Diagrama de arquitetura medalhão: camadas bronze, prata e ouro

Toda plataforma de dados acaba virando um pântano: cinco tabelas chamadas orders, ninguém sabe ao certo qual o financeiro usa, e um dashboard quebrou porque alguém corrigiu um bug lá na origem. A arquitetura medalhão é uma resposta simples a essa bagunça. Ela organiza um lakehouse em três camadas, bronze, prata e ouro, cada uma com um contrato claro sobre o quanto os seus dados são confiáveis e quem pode usá-los.

A ideia é popular porque é fácil de explicar, e é aplicada errado com frequência pelo mesmo motivo. Este post cobre o que cada camada guarda e o que não deve guardar, como os dados passam entre elas, verificações de qualidade, reprocessamento, governança, as armadilhas comuns e quando você nem precisa do padrão, com um diagrama que você pode adaptar.

As três camadas de relance

O nome vem da Databricks, cuja documentação descreve as camadas como bruta, validada e enriquecida. Na prática:

Leia as camadas como um contrato de qualidade, e não como uma contagem de etapas de processamento. O bronze promete completude, a prata promete correção e o ouro promete utilidade para um público definido.

Bronze: guarde tudo, não mude nada

O bronze é onde os dados brutos chegam: arquivos do armazenamento de objetos, tópicos do Kafka, fluxos de change data capture dos bancos operacionais, exportações de ferramentas SaaS. As regras:

• Só inserção. Nunca atualize nem apague registros do bronze como parte do processamento normal.
• Análise mínima. A Databricks recomenda guardar a maioria dos campos no bronze como strings, variant ou valores binários, para que uma mudança de esquema inesperada na origem não descarte dados.
• Adicione metadados: horário de ingestão, sistema de origem, nome do arquivo ou offset do tópico. Você vai precisar deles para depurar e para reprocessar.
• Guarde por tempo suficiente para reconstruir. A retenção do bronze define até quando você consegue recalcular a prata e o ouro depois de corrigir um bug.

O bronze contém tudo, inclusive dados pessoais que você talvez se arrependa de ter copiado. Restrinja o acesso aos pipelines e considere tokenizar ou criptografar campos sensíveis na ingestão. O diagrama de mapeamento de dados do GDPR ajuda a acompanhar por onde os dados pessoais passam.

Prata: deixe correto

É na prata que vai a maior parte do esforço de engenharia:

• Analise e tipe os campos, normalize os timestamps para UTC e padronize unidades e códigos.
• Deduplique registros que chegaram duas vezes, o que acontece com toda fonte de entrega pelo menos uma vez.
• Aplique as mudanças. Para fontes de change data capture, faça merge de inserções, atualizações e exclusões em uma tabela de estado atual.
• Padronize as chaves para que um cliente tenha o mesmo identificador, venha ele do CRM ou do sistema de cobrança.
• Coloque em quarentena em vez de descartar. Linhas que falham na validação vão para uma tabela de quarentena com o motivo, onde alguém consegue vê-las.

Um merge típico da prata com Delta Lake ou Apache Iceberg em Spark SQL mantém só a versão mais recente de cada pedido:

MERGE INTO silver.orders AS t
USING (
  SELECT * FROM (
    SELECT *, ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY updated_at DESC) AS rn
    FROM bronze.orders_raw
    WHERE _ingested_at > '2026-11-01T00:00:00Z'
  ) WHERE rn = 1
) AS s
ON t.order_id = s.order_id
WHEN MATCHED AND s.updated_at > t.updated_at THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;

As regras de qualidade de dados ficam nessa fronteira. Os pipelines da Databricks, por exemplo, as declaram como expectations que alertam, descartam as linhas problemáticas ou fazem a atualização falhar:

CREATE OR REFRESH STREAMING TABLE silver_payments (
  CONSTRAINT positive_amount EXPECT (amount > 0) ON VIOLATION DROP ROW,
  CONSTRAINT known_currency EXPECT (currency IN ('USD', 'EUR', 'GBP')) ON VIOLATION DROP ROW
)
AS SELECT * FROM STREAM(bronze_payments);

Seja qual for a ferramenta, deixe as regras visíveis e conte as linhas que elas rejeitam.

Ouro: deixe útil

As tabelas do ouro são feitas para os consumidores: um esquema estrela para os relatórios financeiros, a receita diária por região para o dashboard da diretoria, features de clientes para um modelo de churn. Toda tabela do ouro deve ter um dono, uma definição documentada e uma meta de atualização. Definições de métricas como “cliente ativo” ou “receita líquida” ficam aqui, escritas uma vez, e não reimplementadas em cada dashboard.

O ouro também é onde você desnormaliza e agrega para ganhar velocidade. A prata guarda o detalhe; o ouro responde perguntas.

Batch, streaming ou os dois

As camadas não ditam a latência. Cada etapa pode rodar como um batch noturno, um job incremental de hora em hora ou um fluxo contínuo com checkpoints. Muitos times fazem streaming das fontes para o bronze e a prata, para que os dados fiquem atualizados em minutos, e atualizam os agregados do ouro em uma frequência que combina com a frequência com que alguém olha para eles. Processe de forma incremental sempre que puder: ler só os dados novos do bronze desde a última execução é o que mantém os custos estáveis enquanto os dados crescem.

Reprocessamento e histórico

Como o bronze é imutável, um bug na lógica da prata tem conserto: corrija o código, reconstrua a partir do bronze as partições da prata afetadas e depois reconstrua o ouro. Formatos de tabela como Delta Lake e Iceberg acrescentam snapshots, então você consegue consultar uma tabela como ela estava ontem, auditar uma mudança ou desfazer uma carga ruim. Planeje isso desde o início: mantenha as transformações determinísticas e particione as tabelas para que reconstruir um mês não signifique reconstruir tudo.

Governança por camada

Coloque cada camada em um esquema próprio no catálogo, por exemplo ops.bronze, ops.silver e ops.gold, que é a organização que a Databricks usa no próprio exemplo. Depois conceda acesso por camada: pipelines gravam no bronze, engenheiros e analistas leem a prata e a maior parte da empresa lê só o ouro. A linhagem entre camadas responde à pergunta que todo mundo faz durante um incidente: quais dashboards dependem desta fonte quebrada?

Armadilhas

• Tratar o três como regra. Algumas fontes precisam de mais etapas, outras de menos. O que importa é o contrato, não o número de etapas.
• Lógica de negócio na prata. A prata deve ser reutilizável por muitos consumidores. Lógica que atende um único relatório pertence ao ouro.
• O ouro como depósito de entulho. Sem donos, o ouro se enche de tabelas pontuais que ninguém mantém. Revise-as e aposente-as.
• Copiar tudo três vezes. Grandes conjuntos de dados brutos guardados em três formatos custam dinheiro de verdade. Mantenha na prata só as colunas e o histórico de que as pessoas realmente precisam.
• Pular a quarentena. Linhas descartadas em silêncio são o jeito de os números se desviarem sem ninguém perceber.

Quando o medalhão é exagero

Se os seus dados cabem com folga em um data warehouse na nuvem e vêm de poucas fontes, talvez você nem precise de um lakehouse. A convenção comum do dbt de staging, intermediate e marts expressa a mesma ideia de refinamento crescente dentro de um único warehouse:

Os nomes importam menos que a disciplina: dados brutos mantidos intactos, uma versão limpa de cada entidade e tabelas com finalidade definida e com dono.

O diagrama medalhão

Como ler:

• Fontes à esquerda: dados de mudança do Postgres, eventos do Kafka e uma exportação do CRM.
• Três molduras coloridas são as camadas. O bronze guarda arquivos brutos, a prata guarda tabelas limpas e um depósito de quarentena, o ouro guarda tabelas de negócio.
• As arestas entre as molduras são etapas do pipeline, rotuladas com o que fazem: analisar, deduplicar, fazer merge, agregar.
• Consumidores à direita: dashboards de BI e um feature store para machine learning leem só do ouro.
• O bloco Markdown lista o contrato de cada camada.

Desenhar plataformas de dados em que as pessoas se encontram

• Pinte as camadas. Bronze, prata e ouro são fáceis de lembrar justamente por serem visuais; use as cores.
• Rotule cada etapa com a sua operação, e não só com uma seta. “Deduplicar e fazer merge” diz ao revisor onde procurar um bug.
• Mostre quem lê o quê. Acesso por camada é uma decisão de projeto, e o diagrama deve deixar claro que dashboards nunca leem o bronze.
• Inclua o caminho da quarentena. Ele mostra aos revisores para onde vão os dados rejeitados.

O pipeline mais amplo em torno do lakehouse está no diagrama de arquitetura de pipeline de dados, as fontes de streaming no diagrama de arquitetura do Kafka e os consumidores de ML no diagrama de arquitetura de MLOps.

Monte no Archboard

1. Entre com Google ou GitHub e crie um diagrama.
2. Adicione como fontes um nó Postgres e um nó Kafka do pack Dados, e um Sistema externo do pack Modelo C4 para o CRM.
3. Adicione três nós Moldura do pack Básico chamados Bronze, Silver e Gold, com as cores correspondentes.
4. Dentro do bronze, adicione um Repositório de objetos do pack Dados para os arquivos brutos. Dentro da prata, adicione um nó Armazém de dados para as tabelas limpas e um Repositório de objetos para a quarentena. Dentro do ouro, adicione outro nó Armazém de dados para as tabelas de negócio.
5. Adicione como consumidores uma Caixa do pack Básico para os dashboards de BI e um Repositório de features do pack ML.
6. Rotule as arestas com cada etapa e adicione um bloco Markdown do pack Básico com as regras das camadas.

O exemplo usa 13 nós de diagrama e fica dentro do plano Free.

Perguntas frequentes

O que é a arquitetura medalhão? Um jeito de organizar um lakehouse em três camadas de qualidade crescente: bronze para os dados brutos como chegaram, prata para os dados limpos e padronizados, e ouro para tabelas prontas para o negócio, construídas para usos específicos.

Qual é a diferença entre prata e ouro? A prata guarda dados corretos e reutilizáveis no nível de detalhe, uma tabela por entidade ou tipo de evento. O ouro guarda tabelas moldadas para uma finalidade, como agregados, esquemas estrela ou features de ML, com dono e definições.

Os dados do bronze devem ser alterados em algum momento? Não como parte do processamento normal. O bronze é só de inserção para que você consiga reconstruir tudo o que vem depois. As exceções são pedidos legais de exclusão e limites de retenção, que precisam de um processo próprio.

A arquitetura medalhão é só para Databricks? Não. O nome vem da Databricks, mas o padrão funciona com qualquer lakehouse ou warehouse: Delta Lake, Apache Iceberg, Snowflake ou BigQuery, com Spark, dbt ou outras ferramentas.

Eu sempre preciso de três camadas? Não. Use quantas etapas as suas fontes exigirem. O importante é uma cópia bruta intocada, uma versão limpa de cada entidade e tabelas com finalidade definida e com dono.

Comece grátis — um assento, sem cartão de crédito.