Resposta direta: a arquitetura medalhão separa os dados em três camadas: bronze para o dado bruto, prata para o dado tratado e ouro para o dado pronto para o negócio. No Microsoft Fabric, ela é o padrão de desenho recomendado pela própria Microsoft, e a decisão mais importante é como separar workspaces por camada, por domínio de negócio e por ambiente.
Quem busca Fabric medallion architecture normalmente já entendeu o conceito e quer um modelo pronto para organizar o ambiente. Este guia vai direto à parte prática: o que vai em cada camada no Fabric, três formas de organizar workspaces, a convenção de nomes que usamos e os erros mais comuns. Para o conceito geral, fora do Fabric, veja o guia de arquitetura medalhão com bronze, prata e ouro.
O que é a arquitetura medalhão no Fabric?
A arquitetura medalhão é um padrão que melhora a estrutura e a qualidade dos dados em três etapas: bronze (bruto), prata (enriquecido) e ouro (curado). O guia oficial de arquitetura medalhão no Fabric a descreve como a abordagem de desenho recomendada para o Fabric, implementada com lakehouses no OneLake.
A Microsoft resume as camadas assim:
- Bronze: guardar tudo exatamente como chegou, sem alterações.
- Prata: corrigir erros, padronizar formatos e remover duplicidades.
- Ouro: organizar para relatórios e painéis.
O que vai em cada camada?
| Camada | Objetivo | Formato no Fabric | Quem acessa | Retenção sugerida (beAnalytic) |
|---|---|---|---|---|
| Bronze | Preservar o dado original como fonte de verdade | Formato original ou Delta; atalhos para fontes no OneLake, ADLS, S3 ou Google | Engenharia de dados | Histórico completo, com política de arquivamento |
| Prata | Dado limpo, padronizado e integrado entre fontes | Tabelas Delta | Engenharia de dados e analistas avançados | Histórico necessário para reprocessar o ouro |
| Ouro | Fatos e dimensões prontos para o negócio | Tabelas Delta em Lakehouse ou Warehouse | Time de BI, Power BI, usuários de negócio | Conforme a necessidade de análise |
Duas recomendações oficiais que vale seguir: no bronze, quando a fonte já está em OneLake, ADLS Gen2, Amazon S3 ou Google, crie um atalho em vez de copiar. Nas camadas prata e ouro, use tabelas Delta, que recebem a otimização V-Order para leitura rápida.
Para decidir se o ouro fica em Lakehouse ou Warehouse, veja Lakehouse ou Warehouse no Fabric: como decidir.
Como organizar os workspaces no Fabric?
A Microsoft recomenda criar cada camada em um workspace separado, para ter mais controle e governança por camada. A partir daí, há três modelos de organização:
Modelo 1: por camada. Um workspace para bronze, um para prata, um para ouro.
ws-bronze ws-prata ws-ouro
- Prós: simples, permissões claras por camada.
- Contras: com muitas áreas, o workspace ouro fica grande e mistura donos.
Modelo 2: por domínio de negócio e camada. Cada domínio (vendas, financeiro, suprimentos) tem seus três workspaces, agrupados em um domínio do Fabric.
Domínio Vendas: ws-vendas-bronze ws-vendas-prata ws-vendas-ouro
Domínio Financeiro: ws-fin-bronze ws-fin-prata ws-fin-ouro
- Prós: cada área tem dono claro; combina com a abordagem de data mesh que a Microsoft cita.
- Contras: mais workspaces para governar; fontes compartilhadas (como o ERP) precisam de um bronze comum.
Modelo 3: por camada e ambiente. Cada camada existe em desenvolvimento, teste e produção.
ws-bronze-dev ws-bronze-prd
ws-prata-dev ws-prata-prd
ws-ouro-dev ws-ouro-prd
- Prós: separa testes de produção e facilita pipelines de implantação.
- Contras: multiplica o número de workspaces.
O que mais usamos: um bronze compartilhado por fonte (o ERP entra uma vez só), prata e ouro por domínio, e separação entre desenvolvimento e produção em todos. Desenvolvimento fica em uma capacidade menor, que pode ser pausada fora do horário.
Qual convenção de nomes usar?
Uma convenção boa é curta, previsível e diz camada, domínio e ambiente sem abrir o item. O padrão que usamos:
| Item | Padrão | Exemplo |
|---|---|---|
| Workspace | ws-{domínio}-{camada}-{ambiente} | ws-vendas-ouro-prd |
| Lakehouse | lh_{camada}_{domínio ou fonte} | lh_bronze_erp, lh_prata_vendas |
| Warehouse | wh_{camada}_{domínio} | wh_ouro_vendas |
| Tabela bronze | {fonte}_{tabela original} | erp_pedidos_cabecalho |
| Tabela prata | {entidade} | pedido_venda, cliente |
| Tabela ouro | fato_{processo} ou dim_{entidade} | fato_vendas, dim_cliente, dim_calendario |
| Pipeline | pl_{origem}_{destino}_{frequência} | pl_erp_bronze_diario |
| Notebook | nb_{camada}_{assunto} | nb_prata_pedidos |
| Modelo semântico | sm_{domínio} | sm_vendas |
Três regras que evitam retrabalho: tudo em minúsculas, sem acento e sem espaço; o mesmo idioma em todo o ambiente; e o prefixo do tipo de item sempre no início, para ordenar bem na lista do workspace.
Como os dados passam entre as camadas?
Por cargas incrementais orquestradas, com regras de qualidade na passagem para a prata.
- Fonte para bronze: pipelines do Data Factory, Copy Jobs, espelhamento ou atalhos. Sempre incremental quando a fonte permitir.
- Bronze para prata: notebooks Spark ou visões materializadas do lakehouse. É aqui que entram padronização, deduplicação e validações.
- Prata para ouro: notebooks, T SQL no Warehouse ou visões materializadas, montando fatos e dimensões.
- Ouro para Power BI: modelos semânticos em Direct Lake.
A Microsoft documenta as visões materializadas do lakehouse como uma forma declarativa de montar as camadas: você define as transformações em SQL, e o Fabric cuida da ordem de execução, das regras de qualidade e de decidir entre atualização incremental ou completa.
Como fica a governança e o acesso por camada?
Cada camada tem um público diferente, e as permissões devem refletir isso.
| Camada | Quem tem acesso | Papel sugerido no workspace |
|---|---|---|
| Bronze | Só engenharia de dados | Admin e Member para engenharia; ninguém de negócio |
| Prata | Engenharia e analistas avançados | Contributor para engenharia; Viewer para analistas |
| Ouro | Time de BI e consumidores | Contributor para BI; acesso ao modelo semântico para o negócio |
Dado sensível (dados pessoais, salários, informações de pacientes) deve ser tratado na prata, com mascaramento ou separação, antes de chegar ao ouro.
Quais erros vemos em projetos?
- Tudo em um workspace só. Funciona no piloto e vira problema de permissão e organização no terceiro mês.
- Pular a prata. Levar dado do bronze direto para o ouro espalha regras de limpeza por vários relatórios.
- Bronze alterado. Corrigir dado no bronze apaga a fonte de verdade e impede reprocessar.
- Nomes inconsistentes. “Vendas”, “vendas_v2” e “tbl_vendas_final” no mesmo ambiente.
- Desenvolvimento em produção. Testes consumindo a mesma capacidade dos relatórios da diretoria.
- Sem retenção. O histórico do Delta cresce sem limite. A Microsoft recomenda definir retenção e usar VACUUM.
Caso ilustrativo: reorganização de um ambiente Fabric que cresceu sem padrão
Cenário ilustrativo, montado a partir de situações comuns em projetos de dados. A empresa e os números são hipotéticos; as recomendações citadas são as oficiais da Microsoft.
Antes. Uma empresa de logística começou no Fabric com um piloto e, em um ano, tinha 1 workspace com 47 itens: lakehouses, notebooks, pipelines e relatórios misturados, com nomes como “Teste_final2”. Engenharia, BI e áreas de negócio tinham o mesmo nível de acesso.
Depois. A reorganização adotou o modelo misto:
ws-erp-bronze-prd ws-tms-bronze-prd (bronze por fonte)
ws-operacao-prata-prd ws-operacao-ouro-prd (domínio operação)
ws-financeiro-prata-prd ws-financeiro-ouro-prd (domínio financeiro)
ws-*-dev (espelho de desenvolvimento em capacidade F2 pausável)
| Indicador | Antes | Depois |
|---|---|---|
| Workspaces de produção | 1 | 6 |
| Itens sem dono definido | 19 | 0 |
| Tempo para achar a tabela certa (relato do time) | Perguntar no chat | Pelo nome, na lista do workspace |
| Acesso de negócio ao bronze | Sim | Não |
O que esse cenário ensina: a convenção de nomes e a separação de workspaces custam pouco no começo e muito depois. Reorganizar exigiu recriar conexões e permissões; começar com o padrão teria evitado esse retrabalho.
Resumo para encaminhar à diretoria
- Problema: o ambiente Fabric precisa de uma organização que aguente crescer sem virar bagunça.
- Opções: workspaces por camada, por domínio e camada, ou por camada e ambiente.
- Custo ou risco: sem padrão, cada nova área aumenta o retrabalho e o risco de acesso indevido.
- Recomendação: bronze por fonte, prata e ouro por domínio, desenvolvimento separado de produção e convenção de nomes desde o primeiro dia.
- Próximo passo: revisão de arquitetura Fabric e adoção do template de convenção de nomes.
Perguntas frequentes sobre arquitetura medalhão no Fabric
Preciso das três camadas sempre?
Não obrigatoriamente, mas a Microsoft recomenda o padrão. Projetos muito pequenos podem juntar prata e ouro no começo, desde que o bronze seja preservado como fonte de verdade.
Cada camada deve ter um workspace?
É a recomendação oficial da Microsoft, por dar mais controle e governança por camada. Em projetos maiores, combinamos isso com separação por domínio e por ambiente.
Onde aplicar regras de qualidade?
Principalmente na passagem do bronze para a prata. As visões materializadas do lakehouse permitem declarar regras de qualidade junto com as transformações.
A camada ouro deve ser Lakehouse ou Warehouse?
Depende do time. Times fortes em SQL tendem ao Warehouse; times de engenharia em Python tendem ao Lakehouse. Os dois são padrões documentados pela Microsoft.
Como separar desenvolvimento e produção?
Com workspaces separados por ambiente, pipelines de implantação entre eles e, de preferência, uma capacidade menor e pausável para desenvolvimento.
Vai estruturar ou reorganizar o seu ambiente Fabric? A beAnalytic é consultoria de dados e implementa arquitetura medalhão no Fabric de ponta a ponta. Peça o template de convenção de nomes para Fabric e uma revisão de arquitetura com a nossa consultoria de engenharia de dados ou escreva para [email protected].
Daniel Luz
CEO da beAnalytic. Na liderança da empresa há mais de 6 anos, minha missão é transformar a forma como as organizações enxergam e utilizam dados para tomar decisões estratégicas. Ajudo empresas a destravar insights valiosos, impulsionar eficiência operacional e gerar impacto financeiro real, com uma equipe especializada em Business Intelligence, Engenharia de Dados e Machine Learning.
- Daniel Luz
- Daniel Luz
- Daniel Luz
- Daniel Luz
