Arquitetura medalhão (bronze, silver, gold) na prática

O dado chega, mas ninguém confia no número que sai#

A cena se repete em quase todo projeto que herdamos: existe um lakehouse, existem dezenas de tabelas Delta, existe até um relatório de Power BI bonito no ar. E, mesmo assim, quando a diretoria pergunta "de onde veio esse número", ninguém consegue responder com segurança. Alguém transformou o dado bruto direto no relatório, outra pessoa reprocessou por cima, e agora não dá para saber o que é fonte, o que é regra de negócio e o que é gambiarra de última hora. É exatamente esse tipo de bagunça que a arquitetura medalhão (bronze, silver, gold) na prática existe para resolver, ao separar o dado em camadas com responsabilidades claras.

A ideia é simples de descrever e difícil de disciplinar: a arquitetura medalhão organiza o data lake em três camadas, bronze guarda o dado bruto exatamente como veio da origem, silver entrega o dado limpo, conformado e integrado, e gold entrega o modelo dimensional pronto para consumo. Não é uma tecnologia nova, é um padrão de organização adotado no Microsoft Fabric, no Databricks e em qualquer projeto sério baseado em Delta Lake. Neste artigo eu mostro o que fazer em cada camada, como implementar isso no Lakehouse do Fabric e onde os projetos costumam quebrar. Com honestidade, inclusive sobre quando o medalhão é excesso de engenharia.

Bronze guarda o dado bruto, sem transformação e sem opinião#

A camada bronze é a mais mal compreendida das três, porque a tentação de "já arrumar um pouquinho" é enorme. Resista. Bronze é a cópia fiel do que a origem entregou: o mesmo esquema, os mesmos nomes de coluna esquisitos, os mesmos nulos, os mesmos tipos errados. A única coisa que você adiciona são metadados de ingestão, como a data e hora da carga, o nome do arquivo ou tabela de origem e, quando faz sentido, um identificador de execução do pipeline.

Por que essa disciplina importa tanto? Porque bronze é o seu seguro. Quando uma regra de negócio muda seis meses depois, ou quando alguém descobre que a silver estava aplicando uma conversão de fuso horário errada desde o início, você precisa reprocessar tudo a partir de uma fonte confiável. Se a bronze já vier "meio limpa", você perdeu o original e não tem para onde voltar. Na maioria dos projetos, bronze é append-only e imutável: cada carga acrescenta, nada é sobrescrito nem deletado. Isso também sustenta auditoria e rastreabilidade, que costumam ser exigência de compliance antes de serem exigência técnica.

Um detalhe que gera confusão: bronze não precisa ser bonita nem consultável por analista. Ela existe para engenharia de dados e para reprocessamento. Se um analista está lendo direto da bronze, ou a silver não existe, ou tem algo errado no seu desenho.

Silver limpa, conforma e integra o que estava espalhado#

Se bronze é o depósito, silver é a fábrica. Aqui o dado deixa de ser um espelho da origem e passa a ser um ativo confiável. As transformações típicas da silver são as que dão trabalho de verdade e definem a qualidade de tudo que vem depois:

• Limpeza: tratamento de nulos, correção de tipos de dados, remoção de registros corrompidos e padronização de formatos de data, número e texto.
• Deduplicação: remoção de duplicatas reais e resolução de registros que representam a mesma entidade em fontes diferentes.
• Conformação: padronização de domínios, um "SP", "São Paulo" e "Sao Paulo" viram um único valor canônico. Códigos de status, moedas e unidades ficam consistentes.
• Integração: junção de fontes que falam da mesma coisa, o cliente do ERP com o cliente do CRM, por exemplo, resolvido por uma chave de negócio confiável.

A silver é onde mora a maior parte da lógica de qualidade de dados. É a camada que o cientista de dados e o analista avançado conseguem usar para exploração, porque o dado já é confiável, mesmo que ainda não esteja no formato ideal para um dashboard. Uma boa silver normaliza sem destruir granularidade: você limpa e integra, mas mantém o nível de detalhe transacional. Agregação é problema da gold, não da silver. Confundir isso é um dos erros mais caros que existem, porque agregar cedo demais joga fora informação que você vai precisar depois e não vai conseguir recuperar sem reprocessar.

Gold entrega o modelo dimensional pronto para o negócio#

A camada gold é a que o negócio efetivamente enxerga. Aqui o dado limpo e integrado da silver vira modelo dimensional: tabelas fato e tabelas dimensão, no bom e velho esquema estrela, com as métricas de negócio calculadas, os relacionamentos prontos e a granularidade certa para quem toma decisão. É a camada que alimenta o Power BI, os relatórios executivos e, no Fabric, os modelos semânticos em modo Direct Lake.

Gold é modelada para consumo, não para processamento. Isso muda tudo no desenho. Nomes de tabela e coluna são amigáveis ao negócio, não ao sistema de origem. As agregações que fazem sentido para o gestor já estão prontas. As regras de negócio que definem "faturamento líquido" ou "cliente ativo" já foram aplicadas de forma única e versionada, para que dois relatórios diferentes nunca mais mostrem números divergentes para a mesma métrica.

Um ponto que costuma passar batido: você quase sempre tem várias tabelas gold para o mesmo dado, cada uma servindo um caso de uso. Uma gold pode ser um fato de vendas na granularidade de item de pedido, outra pode ser uma visão agregada por mês e região para um painel executivo. Não há problema nisso, desde que todas descendam da mesma silver conformada. O pecado é criar gold a partir de gold, ou pior, gold a partir da bronze, pulando a silver. Aí você perdeu a rastreabilidade que era o motivo de existir do medalhão.

O que cada camada faz, lado a lado#

A tabela abaixo resume as responsabilidades. Ela é útil para alinhar o time antes de escrever a primeira linha de pipeline, porque a maioria das brigas de arquitetura nasce de gente colocando trabalho na camada errada.

Camada	O que contém	Transformação aplicada	Quem consome
Bronze	Dado bruto, idêntico à origem	Nenhuma, só metadados de ingestão (data, origem, execução)	Engenharia de dados, auditoria, reprocessamento
Silver	Dado limpo, conformado e integrado	Limpeza, deduplicação, padronização de domínios, integração de fontes	Cientistas de dados, analistas avançados
Gold	Modelo dimensional pronto para consumo	Modelagem estrela, métricas de negócio, agregações, nomes amigáveis	Power BI, relatórios executivos, áreas de negócio

O valor não está em cada camada isolada, está na fronteira entre elas. Separar bronze, silver e gold melhora a rastreabilidade, porque você sempre sabe em que camada uma regra foi aplicada, e melhora o reprocessamento, porque pode reconstruir gold a partir da silver, ou silver a partir da bronze, sem tocar na origem de novo.

Como implementar o medalhão no Lakehouse do Fabric#

No Microsoft Fabric, a arquitetura medalhão deixa de ser conceito e vira estrutura de itens dentro do workspace. Existem duas abordagens principais, e a escolha entre elas define a governança do projeto inteiro.

A primeira é usar um Lakehouse por camada: um Lakehouse Bronze, um Silver e um Gold, cada um como item separado no workspace. Isso dá isolamento forte, permissões distintas por camada e uma separação visual que qualquer pessoa nova no projeto entende em cinco minutos. A segunda é usar um único Lakehouse com schemas separados para bronze, silver e gold, apoiando-se no suporte a schemas do Fabric para organizar as tabelas Delta dentro do mesmo item. Isso simplifica a navegação e reduz o número de itens para gerenciar, ao custo de um isolamento de permissões menos rígido.

Não existe resposta única. Para clientes com exigência forte de segregação de acesso, geralmente vamos de Lakehouse por camada. Para times menores que querem menos itens para manter, o Lakehouse único com schemas resolve bem. Em ambos os casos, cada camada é composta por tabelas Delta, o formato nativo do OneLake, o que garante transações ACID, versionamento e leitura direta pelo Power BI. Se você ainda está avaliando a plataforma em si, vale ler o que é o Microsoft Fabric e se vale a pena antes de decidir a topologia.

Decisão	Lakehouse por camada	Lakehouse único com schemas
Isolamento de permissões	Forte, por item	Mais fraco, dentro do mesmo item
Navegação e manutenção	Mais itens no workspace	Um item, tudo organizado por schema
Melhor cenário	Governança rígida, times grandes	Times menores, menos overhead
Formato das tabelas	Delta no OneLake	Delta no OneLake

Sobre a orquestração: a ingestão para bronze costuma ser um pipeline de Data Factory ou uma cópia direta, praticamente um ELT puro, o dado entra bruto e só depois é transformado. As transformações para silver e gold são feitas com notebooks Spark (PySpark ou Spark SQL) ou com o próprio SQL do Fabric, dependendo do perfil do time. O ponto de atenção é a orquestração: cada camada deve ter seu próprio passo, com dependência explícita, para que a gold só rode depois que a silver terminou. Encadear isso num pipeline com dependências claras é o que transforma o medalhão de diagrama bonito em processo confiável. Se a sua base de engenharia de dados ainda não está madura para isso, é aí que vale um apoio de engenharia de dados especializado antes de escalar.

Os erros que a gente vê em quase todo projeto herdado#

Vou ser direto, porque a parte honesta deste artigo é essa. Os problemas de medalhão quase nunca são de ferramenta, são de disciplina. Os que mais aparecem:

Transformar demais na bronze. A pessoa "melhora" o dado na entrada e destrói a capacidade de reprocessar. Bronze suja é bronze correta. Guarde o original.

Pular a silver. Ir da bronze direto para a gold parece produtividade e é dívida técnica. Sem a camada de limpeza e conformação, cada gold reimplementa as mesmas regras de qualidade, com variações sutis, e é assim que dois relatórios passam a divergir.

Agregar cedo demais. Silver agregada perde granularidade que a gold precisaria. Quando o negócio pede uma nova visão, você descobre que jogou o detalhe fora e precisa reprocessar da bronze. Mantenha a silver no grão transacional.

Tratar gold como lixeira de conveniência. Cada pedido de relatório vira uma tabela gold nova, sem padrão, criada a partir de outra gold. Em pouco tempo você tem trinta tabelas gold e ninguém sabe qual é a oficial. Gold nasce da silver, sempre.

Ignorar governança e LGPD. Dado pessoal aparece na bronze, na silver e na gold. Se você não mapeou onde ele entra e como um pedido de exclusão de titular se propaga pelas três camadas, o medalhão vira um multiplicador de risco, não de organização. Governança não é etapa posterior, é parte do desenho. Vale tratar governança de dados desde o primeiro pipeline.

Adotar medalhão onde ele não cabe. Se a empresa tem dado cem por cento tabular, volume pequeno e um time que domina SQL, três camadas de lakehouse podem ser complexidade sem retorno. Nesses casos, um warehouse bem modelado resolve com menos gente. Medalhão brilha quando há volume, heterogeneidade de fontes e necessidade real de reprocessamento e auditoria. Não é troféu, é ferramenta.

Perguntas frequentes#

Preciso das três camadas em todo projeto? Não. As três camadas fazem sentido quando há volume, múltiplas fontes que precisam ser integradas e necessidade de reprocessamento ou auditoria. Em cenários pequenos e cem por cento tabulares, bronze e gold, ou até um warehouse tradicional, podem ser suficientes. Adotar três camadas por moda é adicionar complexidade sem retorno.

Bronze, silver e gold precisam ser três Lakehouses separados no Fabric? Não obrigatoriamente. Você pode usar um Lakehouse por camada, o que dá isolamento forte de permissões, ou um único Lakehouse com schemas separados para cada camada. A escolha depende da sua exigência de governança e do tamanho do time. Nos dois casos, as tabelas são Delta no OneLake.

Posso ler direto da bronze no Power BI? Tecnicamente sim, mas é sinal de problema. A bronze existe para reprocessamento e auditoria, não para consumo de negócio. Se um relatório está lendo da bronze, provavelmente a silver e a gold não estão bem estruturadas. O consumo de negócio deve vir da gold, que é onde está o modelo dimensional pronto.

Qual a diferença prática entre silver e gold? Silver é o dado limpo, conformado e integrado, ainda no grão transacional, servindo análise e ciência de dados. Gold é o modelo dimensional, com fatos e dimensões, métricas de negócio calculadas e agregações, pensado para dashboards e relatórios executivos. Silver é confiável, gold é consumível.

A arquitetura medalhão é exclusiva do Microsoft Fabric? Não. É um padrão de organização de lakehouse usado também no Databricks e em qualquer projeto baseado em Delta Lake ou formatos abertos similares. O Fabric implementa bem esse padrão com Lakehouse, tabelas Delta e OneLake, mas o conceito é independente de ferramenta.

O medalhão resolve sozinho a divergência de números entre relatórios? Ajuda, mas não sozinho. Ele cria o lugar certo para centralizar regras de negócio, a camada gold, o que reduz a divergência quando a disciplina é seguida. Se cada time continuar aplicando suas próprias regras em cópias paralelas, o problema persiste. A arquitetura habilita a consistência, a governança a garante.

O medalhão vale pela disciplina, não pelo diagrama#

A arquitetura medalhão não é difícil de desenhar, qualquer um consegue rabiscar três caixas chamadas bronze, silver e gold. O que separa um projeto confiável de um pântano organizado é a disciplina de respeitar a responsabilidade de cada camada: dado bruto intocado na bronze, limpeza e integração na silver, modelo dimensional pronto na gold. É essa separação que devolve rastreabilidade, reprocessamento seguro e, no fim, confiança no número que chega na diretoria.

Se você monta um lakehouse no Fabric do zero, ou herdou um que virou bagunça, fale com a gente. Já estruturamos medalhão em cenários parecidos e sabemos onde ele economiza tempo e onde só adiciona complexidade.