Arquitetura de Medalhão: Guia Completo de Implementação

Resumo

A arquitetura de medalhão (medallion architecture) é um padrão de design de dados para organizar logicamente as informações em um lakehouse, incrementando e melhorando progressivamente a estrutura e a qualidade dos dados conforme eles fluem das camadas Bronze → Silver → Gold. Este guia técnico percorre seus conceitos fundamentais, detalha as três camadas, apresenta um checklist prático de 12 passos de implementação, explica por que o Delta Lake é a fundação recomendada e mostra como o Microsoft Fabric implementa o padrão nativamente sobre o OneLake — tudo sustentado pela documentação oficial de Databricks, Microsoft e Delta Lake.

1. Introdução

A arquitetura de medalhão é um padrão de design de dados utilizado para organizar logicamente os dados em um lakehouse, com o objetivo de incrementar e progressivamente melhorar a estrutura e a qualidade dos dados conforme eles fluem por cada camada — da camada Bronze para a Silver e desta para a Gold (Databricks, 2026). O termo foi cunhado pela Databricks e é também referido como arquitetura multi-hop, pois os dados passam por múltiplos estágios de refinamento antes de chegarem ao consumidor final.

A Microsoft adotou oficialmente este padrão como a abordagem de design recomendada para o Microsoft Fabric, descrevendo-o como uma série de camadas de dados que denotam a qualidade dos dados armazenados no lakehouse, garantindo atomicidade, consistência, isolamento e durabilidade (ACID) conforme os dados passam por múltiplas camadas de validações e transformações (Microsoft Learn, 2026).

Embora tenha se popularizado no contexto do Databricks e do Delta Lake, a arquitetura de medalhão é um padrão lógico de organização, não vinculado a uma plataforma específica. O mesmo padrão de três camadas pode ser implementado em Snowflake, BigQuery, ou em tabelas Iceberg no S3, e em um projeto dbt ele corresponde a sources, staging/intermediate models e marts (DataForest, 2026).

2. Conceitos Fundamentais

2.1 O conceito de Lakehouse

Um lakehouse é um paradigma de arquitetura de plataforma de dados que combina as melhores características de data lakes e data warehouses. Ele oferece armazenamento de baixo custo e flexibilidade para dados estruturados e não estruturados (como em um data lake), juntamente com transações ACID, governança e performance de consulta (como em um data warehouse) (Databricks, 2026).

2.2 Por que a organização em camadas importa

A arquitetura de medalhão impõe um contrato claro sobre o que cada zona de armazenamento contém. Trata-se de um acordo compartilhado entre equipes sobre quem é responsável pela qualidade dos dados em cada estágio e quais garantias os consumidores downstream podem confiar. Isso torna a governança, o rastreamento de linhagem e a reutilização gerenciáveis em escala (DataForest, 2026).

2.3 Metodologia ELT, não ETL

No paradigma de engenharia de dados do lakehouse, tipicamente segue-se a metodologia ELT (Extract, Load, Transform) em vez de ETL (Extract, Transform, Load). Isso significa que apenas transformações mínimas ou "justo o suficiente" são aplicadas ao carregar a camada Silver. A velocidade e agilidade para ingerir e entregar dados no data lake são priorizadas, enquanto transformações complexas e regras de negócio específicas de projetos são aplicadas ao carregar os dados da camada Silver para a Gold (Databricks, 2026).

2.4 Compatibilidade com Data Mesh

A arquitetura de medalhão é compatível com o conceito de data mesh. Tabelas Bronze e Silver podem ser unidas em uma relação "um-para-muitos", significando que os dados em uma única tabela upstream podem ser usados para gerar múltiplas tabelas downstream (Databricks, 2026).

3. As Três Camadas da Arquitetura de Medalhão

3.1 Camada Bronze — Dados Brutos

A camada Bronze é onde todos os dados de sistemas externos são armazenados em seu estado original ("as-is"). As estruturas das tabelas nesta camada correspondem às estruturas de tabela do sistema fonte, junto com quaisquer colunas de metadados adicionais que capturem a data/hora de carregamento, ID do processo, etc. (Databricks, 2026).

Características principais:

• Fonte da verdade: contém e mantém o estado bruto dos dados fonte em seus formatos originais.
• Imutável: os dados são append-only — apenas acrescentados, nunca atualizados ou deletados. Nunca permita atualizações in-place.
• Schema-on-read: tratamento flexível de esquema para diversos sistemas fonte.
• Trilha de auditoria: preserva a fidelidade dos dados e habilita reprocessamento e auditoria retendo todos os dados históricos.
• Pode ser qualquer combinação de transações de streaming e batch de fontes, incluindo armazenamento de objetos na nuvem (S3, GCS, ADLS), barramentos de mensagens (Kafka, Kinesis) e sistemas federados (Lakehouse Federation).

O foco nesta camada é o Change Data Capture (CDC) rápido e a capacidade de fornecer um arquivo histórico da fonte (cold storage), linhagem de dados, auditabilidade e reprocessamento, se necessário, sem reler os dados do sistema fonte (Databricks, 2026).

Práticas recomendadas:

• Preservar todos os campos de dados fonte para auditabilidade completa.
• Usar Unity Catalog volumes para aterrissar arquivos brutos.
• Implementar ingestão incremental para evitar reprocessamento total.
• Particionar por data de ingestão para gerenciamento eficiente de dados.
• Documentar fontes de dados e agendamentos de ingestão.
• Armazenar a maioria dos campos como string, VARIANT ou binário para proteger contra mudanças inesperadas de esquema.
• Adicionar colunas de metadados como _metadata.file_name para proveniência.
• No Microsoft Fabric: se os dados fonte forem do OneLake, ADLS Gen2, Amazon S3 ou Google, crie um shortcut na camada Bronze em vez de copiar os dados (Microsoft Learn, 2026).

Políticas de retenção devem ser alinhadas ao ambiente regulatório antes de escrever um único registro. Muitas indústrias exigem que dados brutos sejam retidos por períodos prolongados (DataForest, 2026).

Usuários-alvo: engenheiros de dados, operações de dados, equipes de conformidade e auditoria.

3.2 Camada Silver — Dados Limpos e Conformados

A camada Silver é onde a limpeza, validação, deduplicação e enriquecimento dos dados ocorrem. Ela é construída lendo dados de uma ou mais tabelas Bronze (ou outras Silver) e escrevendo em tabelas Silver. A Azure Databricks não recomenda escrever diretamente da ingestão para tabelas Silver, pois isso introduz falhas devido a mudanças de esquema ou registros corrompidos nas fontes de dados (Microsoft Learn, 2026).

Operações realizadas na camada Silver:

• Schema enforcement (aplicação de esquema)
• Tratamento de valores nulos e ausentes
• Deduplicação de dados
• Resolução de dados fora de ordem e com chegada tardia
• Verificações e aplicação de qualidade de dados
• Schema evolution (evolução de esquema)
• Type casting (conversão de tipos)
• Joins (junções de múltiplas fontes)

Regras de qualidade por categoria:

A camada Silver deve sempre incluir pelo menos uma representação validada e não agregada de cada registro. Se representações agregadas impulsionam muitos workloads downstream, essas representações podem estar na camada Silver, mas tipicamente ficam na Gold (Microsoft Learn, 2026).

A Azure Databricks recomenda configurar a maioria das leituras da camada Bronze como streaming reads. Leituras em batch devem ser reservadas para pequenos conjuntos de dados, como tabelas dimensionais pequenas.

Do ponto de vista de modelagem de dados, a camada Silver tem modelos mais próximos da 3ª Forma Normal. Modelos write-performant no estilo Data Vault também podem ser usados nesta camada (Databricks, 2026).

Práticas recomendadas:

• Implementar verificações de qualidade de dados e monitoramento.
• Usar tabelas gerenciadas do Unity Catalog.
• Particionar por dimensões de negócio (data, região, produto).
• Documentar lógica de transformação e regras de negócio.
• Estabelecer SLAs para frescor dos dados.

Usuários-alvo: engenheiros de dados, analistas de dados (análises aprofundadas), cientistas de dados (construção de modelos e análises avançadas).

3.3 Camada Gold — Dados Curados para Negócios

A camada Gold representa visões altamente refinadas dos dados que impulsionam análises downstream, dashboards, ML e aplicações. Os dados da camada Gold são frequentemente altamente agregados e filtrados para períodos específicos ou regiões geográficas (Microsoft Learn, 2026).

Características principais:

• Específica para negócios: adaptada a casos de uso e consumidores específicos.
• Otimizada para performance: pré-agregada e desnormalizada para consultas rápidas.
• Controle de acesso: implementa segurança em nível de linha (row-level security) e mascaramento de colunas (column masking).
• Pronta para consumo: estruturada para ferramentas de BI, aplicações e modelos de ML.
• Produtos de dados: publicada como conjuntos de dados reutilizáveis em toda a organização.

Modelos de dados no estilo star schema Kimball ou data marts estilo Inmon se encaixam nesta camada Gold, com modelos mais desnormalizados e otimizados para leitura com menos joins (Databricks, 2026).

Como a camada Gold modela um domínio de negócio, alguns clientes criam múltiplas camadas Gold para atender diferentes necessidades de negócio, como RH, finanças e TI (Microsoft Learn, 2026).

Exemplo de SQL — Materialized View na camada Gold:

CREATE OR REPLACE MATERIALIZED VIEW main.example_output.weekly_bookings AS
SELECT date_trunc('week', check_in) AS week,
       property_id,
       status,
       count(*) AS total_bookings,
       sum(total_amount) AS total_revenue
FROM samples.wanderbricks.bookings
GROUP BY week, property_id, status;

Otimizar tabelas da camada Gold para performance é uma melhor prática, pois estes conjuntos de dados são frequentemente consultados. Grandes quantidades de dados históricos são tipicamente acessados na camada Silver e não materializados na Gold (Microsoft Learn, 2026).

Práticas recomendadas:

• Criar tabelas Gold separadas para diferentes unidades de negócio ou casos de uso.
• Usar dynamic views para segurança em nível de linha e coluna.
• Implementar otimização preditiva para tabelas frequentemente consultadas.
• Documentar linhagem de dados do Bronze ao Gold.
• Publicar produtos de dados através do Unity Catalog com propriedade clara.

Usuários-alvo: analistas de negócio e desenvolvedores de BI, cientistas de dados, engenheiros de ML, executivos e tomadores de decisão, equipes operacionais.

4. Implementação Prática: Checklist de 12 Passos

Passo 1: Definir limites de camadas e locais de armazenamento. Comece mapeando cada camada para um caminho de armazenamento ou namespace distinto — por exemplo, contêineres separados no Azure Data Lake Storage, schemas separados no Snowflake, ou lakehouses separados no OneLake do Microsoft Fabric (DataForest, 2026).

Passo 2: Escolher o formato de tabela. A escolha do formato molda tudo o que vem a seguir. Delta Lake é o padrão no Databricks e no Fabric porque suporta transações ACID, time travel e evolução de esquema nativamente. Apache Iceberg é uma forte alternativa quando se precisa de compatibilidade entre múltiplos motores (DataForest, 2026).

Passo 3: Configurar escritas append-only para a camada Bronze. Configure escritas exclusivamente de acréscimo e nunca permita atualizações in-place. Dados brutos são sua trilha de auditoria. Sobrescrevê-los remove a capacidade de reprocessar o histórico quando um bug de transformação aparece meses depois.

Passo 4: Aplicar esquema na leitura ou escrita na camada Silver. A aplicação de esquema é onde a qualidade de dados se torna estrutural em vez de aspiracional. O schema-on-write captura registros malformados na ingestão; o schema-on-read oferece mais flexibilidade, mas empurra a validação para downstream. Na prática, equipes com requisitos de SLA estritos aplicam schema-on-write na Silver e usam schema-on-read apenas em zonas Bronze exploratórias.

Passo 5: Projetar estratégia de particionamento alinhada aos padrões de consulta. O particionamento deve refletir como os consumidores consultam os dados, não como as fontes os produzem. O particionamento por data de ingestão serve para o Bronze. As camadas Silver e Gold tipicamente se beneficiam de particionamento por data de negócio, região ou tipo de entidade — qualquer coluna que apareça com mais frequência em cláusulas WHERE. No Microsoft Fabric, use Liquid Clustering em vez de particionamento para Silver e Gold (Microsoft Learn, 2026).

Passo 6: Implementar carga incremental usando watermarks ou CDC. Carga incremental é inegociável em escala. Use timestamps de high-watermark quando as fontes expõem uma coluna confiável de updated_at. Use CDC quando precisar de captura de mudanças em nível de linha sem full table scans. O Change Data Feed (CDF) do Delta Lake permite que sistemas downstream executem atualizações incrementais eficientes (Delta Lake, 2026).

Passo 7: Definir regras de qualidade de dados por camada. Bronze valida apenas que registros chegaram e são parseáveis. Silver impõe null checks, integridade referencial e restrições de faixa. Gold valida a consistência dos agregados contra as expectativas do consumidor de negócio.

Passo 8: Aplicar controles de acesso em nível de linha e coluna. Bronze é tipicamente restrito a contas de serviço de pipeline e engenheiros de dados. Silver abre para cientistas de dados e analistas com row-level security aplicada onde há PII. Gold é a camada de acesso mais amplo — ferramentas de BI, dashboards e consumidores externos leem dela —, logo, column masking de campos sensíveis é essencial.

Passo 9: Definir políticas de retenção para a camada Bronze. As políticas de retenção precisam se alinhar com o ambiente regulatório antes de escrever um único registro. Aplique políticas de armazenamento em camadas (tiered storage) para que dados do Bronze sejam movidos para armazenamento frio mais barato após uma janela de retenção definida. Configure a propriedade da tabela delta.deletedFileRetentionDuration = "interval <interval>" (Microsoft Learn, 2026).

Passo 10: Construir observabilidade de pipeline com verificações de contagem de linhas e frescor. Construa verificações de contagem de linhas (row-count checks) e de frescor (freshness checks) em cada estágio do pipeline desde o primeiro dia. Muitas equipes deferem isso até algo quebrar em produção.

Passo 11: Documentar linhagem de dados da fonte ao Gold. A documentação de linhagem permite responder rapidamente a duas perguntas: quais relatórios downstream são afetados quando uma fonte upstream muda, e quais registros fonte contribuíram para um agregado Gold específico.

Passo 12: Agendar e testar ciclos de refresh total e incremental. Teste ciclos de refresh completo e incremental antes de ir para produção. Refreshes completos expõem schema drift e incompatibilidades de partição que cargas incrementais mascaram.

5. Delta Lake e a Arquitetura de Medalhão

O Delta Lake é o formato de armazenamento otimizado que fornece a base para armazenar dados e tabelas no lakehouse. Ele suporta transações ACID para workloads de big data e, por isso, é o formato de armazenamento padrão em um Fabric lakehouse (Microsoft Learn, 2026).

Internamente, o Delta Lake armazena dados no formato Parquet, mas também mantém logs de transações e estatísticas que fornecem recursos e melhoria de performance sobre o formato Parquet padrão.

Recursos do Delta Lake que habilitam a arquitetura de medalhão:

• Transações confiáveis (ACID): suporte a atomicidade, consistência, isolamento e durabilidade. Data lakes tradicionais não suportam transações e são menos confiáveis — carecem de consistência (aplicação de esquema), atomicidade (transação completa ou falha total) e isolamento (transações sequenciais garantidas) (Delta Lake, 2026).
• Compactação de arquivos pequenos (OPTIMIZE): pipelines que escrevem dados a cada minuto podem criar muitos arquivos pequenos. O OPTIMIZE compacta arquivos pequenos em arquivos de tamanho adequado.
• Change Data Feed (CDF): permite que sistemas downstream executem atualizações incrementais eficientes. Por exemplo, pode-se habilitar o CDF na tabela Silver e usá-lo para incrementar inteligentemente os agregados de negócio na tabela Gold, sem fazer um refresh completo toda vez que o pipeline é executado.
• Deletion vectors: permitem que operações de delete, update e merge (DML) sejam executadas mais rapidamente do que em data lakes. Isto habilita o padrão ELT — ingerir dados no Bronze e então limpar registros e deduplicar linhas.
• Liquid Clustering: co-localiza dados semelhantes nos mesmos arquivos para que consultas downstream sejam mais rápidas. É superior ao particionamento estilo Hive e ao Z-ordering, que têm desvantagens. Excelente para tabelas Gold onde a ferramenta de BI precisa oferecer uma experiência de baixa latência.
• Time travel: suporta rollback de dados usando o histórico de versões do Delta Lake.
• Schema evolution e enforcement: permite que o esquema evolua ao mesmo tempo que impõe integridade.
• Multi-engine support: o Delta Lake suporta Spark, Flink e muitos outros motores, oferecendo flexibilidade para escolher o melhor motor para cada estágio do pipeline.

Organização de namespaces com Unity Catalog. O Unity Catalog tem um namespace de três níveis útil para organizar as tabelas da arquitetura de medalhão: catalog_name.schema_name.table_name.

something_cool.bronze.raw_transactions
something_cool.silver.user_transactions
something_cool.gold.user_transactions

Quando se vê something_cool.bronze.raw_transactions, identifica-se facilmente que a tabela contém dados ingeridos brutos. something_cool.gold.user_transactions dá a mensagem clara de que a tabela contém agregados em nível de negócio (Delta Lake, 2026).

6. Implementação em Microsoft Fabric

6.1 OneLake como fundação

O OneLake é o data lake unificado, lógico e único para toda a organização. Ele vem provisionado automaticamente com cada tenant do Fabric e é o local único para todos os seus dados de análise. Para armazenar dados no OneLake, cria-se um lakehouse no Fabric — uma plataforma de arquitetura de dados para armazenar, gerenciar e analisar dados estruturados e não estruturados em um único local (Microsoft Learn, 2026).

6.2 Padrões de deployment

Existem dois padrões principais para implementar a arquitetura de medalhão no Fabric:

Embora seja possível criar todos os lakehouses em um único workspace do Fabric, recomenda-se que cada lakehouse esteja em seu próprio workspace separado. Esta abordagem oferece mais controle e melhor governança no nível da camada.

6.3 Formatos de armazenamento por camada

O Fabric padroniza no formato Delta Lake e, por padrão, todo motor no Fabric escreve dados neste formato.

6.4 Materialized Lake Views

As materialized lake views no Fabric ajudam a implementar a arquitetura de medalhão declarativamente. Em vez de construir pipelines complexos para transformar dados entre as camadas, pode-se definir materialized lake views que gerenciam automaticamente as transformações (Microsoft Learn, 2026).

Principais benefícios:

• Pipelines declarativos: defina transformações de dados usando instruções SQL em vez de construir pipelines manuais entre camadas.
• Gerenciamento automático de dependências: o Fabric determina automaticamente a ordem de execução correta com base nas dependências de view.
• Regras de qualidade de dados: suporte integrado para definir e impor restrições de qualidade de dados conforme os dados se movem entre camadas.
• Refresh ótimo: o sistema determina automaticamente se deve executar refresh incremental, completo ou nenhum para cada view.
• Visualização e monitoramento: visualize a linhagem em todas as camadas e acompanhe o progresso da execução.

6.5 Otimização de tabelas Delta por camada

Diferentes camadas têm requisitos diferentes de tamanho de arquivo baseados no motor de consumo:

Para Silver e Gold, use Liquid Clustering em vez de particionamento. Para retenção histórica, configure delta.deletedFileRetentionDuration (Microsoft Learn, 2026).

6.6 Design Hub-and-Spoke para enterprise

O padrão hub-and-spoke pode ser combinado com a arquitetura de medalhão para deployments empresariais, centralizando ativos de dados compartilhados enquanto permite processamento de dados específico por domínio (Databricks, 2026).

Data Hub (Central)
 ├── Bronze: Dados brutos organizacionais (SAP, financeiros, clima)
 ├── Silver: Datasets compartilhados curados
 └── Gold:   Produtos de dados enterprise-wide

Sales Domain
 ├── Bronze: Dados brutos de vendas + dados compartilhados do hub
 ├── Silver: Datasets de análise de vendas
 └── Gold:   Produtos de dados de vendas

Engineering Domain
 ├── Bronze: Telemetria de engenharia + dados compartilhados do hub
 ├── Silver: Métricas de engenharia
 └── Gold:   Dashboards de engenharia

7. Padrões de Ingestão de Dados

7.1 Ingestão em Batch

• Agendamento regular de cargas de dados (ex.: horário, diário, semanal).
• Melhor para grandes volumes de dados históricos.
• Menor custo comparado a streaming.
• Latência aceitável para workloads analíticos.

7.2 Ingestão em Streaming

• Ingestão contínua de dados com baixa latência.
• Use Lakeflow pipelines com Auto Loader para ingestão de arquivos em streaming.
• Melhor para análises em tempo real e casos de uso operacional.
• Custos de computação mais altos, mas dados sempre frescos.

7.3 Change Data Capture (CDC)

• Captura de mudanças em nível de linha sem full table scans.
• Ideal para fontes transacionais onde apenas registros modificados precisam ser processados.

7.4 Exemplo de pipeline completo

Um exemplo prático de pipeline de medalhão (Delta Lake, 2026):

1. Kafka + Flink → ingerem dados de transação em tabelas Delta Bronze.
2. Spark → junta datasets, limpa dados e cria tabelas Delta Silver. Na camada Silver, as transações são deduplicadas e unidas com a tabela de clientes.
3. Spark → computa sketches HyperLogLog (HLL) com agregados em nível de cliente, persistidos em tabelas Delta Gold.
4. Ferramenta de BI → consulta as tabelas Gold para construir dashboards.

7.5 Melhores práticas de ingestão

• Usar volumes do Unity Catalog para aterrissar dados brutos antes da ingestão no Bronze.
• Implementar ingestão idempotente para lidar com retries de forma segura.
• Usar Auto Loader para ingestão eficiente de arquivos do armazenamento na nuvem.
• Configurar políticas de retenção para dados da landing zone.

8. Governança e Qualidade de Dados

8.1 Princípio fundamental

A qualidade dos dados deve melhorar progressivamente conforme os dados avançam pelas camadas. Consequentemente, a confiança nos dados aumentará de uma perspectiva de negócio (Databricks, 2026).

8.2 Ferramentas de qualidade de dados

8.3 Melhores práticas de qualidade

• Implementar verificações de qualidade na ingestão do Bronze (validação de esquema, null checks).
• Impor regras de qualidade mais estritas conforme os dados avançam para Silver e Gold.
• Monitorar métricas de qualidade de dados e tendências ao longo do tempo.
• Definir SLAs de qualidade de dados para datasets críticos.
• Automatizar alertas para violações de qualidade de dados.

8.4 Controle de acesso por camada

8.5 O que NÃO fazer

• Não criar silos de dados duplicando dados operacionais entre domínios.
• Não usar tabelas externas a menos que os dados devam permanecer em caminhos de armazenamento específicos.
• Não pular a camada Bronze — sempre preserve dados brutos como fonte da verdade.
• Não ignorar verificações de qualidade de dados para cumprir prazos de entrega.

9. Quando Usar (e Quando NÃO Usar)

9.1 Quando usar

• Enterprise lakehouse com múltiplas fontes de dados e necessidade de progressão de qualidade.
• Workloads combinados de BI e ML que exigem diferentes níveis de refinamento.
• Organizações que precisam de auditabilidade, linhagem e governança rigorosas.
• Cenários com data mesh onde múltiplos domínios consomem dados compartilhados.

9.2 Cinco modos de falha a avaliar antes de adotar

1. Lacunas de governança: sem contratos de propriedade explícitos entre equipes de engenharia e analytics, as camadas derivam para zonas não gerenciadas e as garantias de qualidade entram em colapso.
2. Over-engineering para pipelines simples: equipes pequenas podem não precisar de três camadas formais.
3. Custo dos passos extras de validação para equipes pequenas.
4. Falta de documentação de linhagem: sem rastreamento claro, a depuração se torna impossível.
5. Políticas de retenção ausentes no Bronze: aplicar retrospectivamente é operacionalmente doloroso.

9.3 Alternativas para equipes pequenas

• Definir janelas de retenção do Bronze alinhadas aos mínimos regulatórios.
• Usar Z-ordering ou clustering em tabelas Silver para reduzir custos de scan.
• Particionar tabelas Gold pela dimensão de filtro mais comum.
• Agendar refreshes de Silver e Gold na frequência mais baixa que os consumidores aceitam.

9.4 Flexibilidade do padrão

A arquitetura de medalhão deve ser seguida de maneira flexível. Por exemplo, pode-se construir uma tabela Gold unindo uma tabela Bronze e uma Silver — não é obrigatório consumir apenas tabelas Silver ao construir tabelas Gold. Como destaca a documentação do Delta Lake: "Use qualquer arquitetura que faça mais sentido para o seu negócio" (Delta Lake, 2026).

10. Conclusão e Próximos Passos

A arquitetura de medalhão é um padrão poderoso e flexível para organizar dados em um lakehouse, oferecendo progressão de qualidade, governança clara e pontos de entrada distintos para diferentes equipes. As três camadas — Bronze, Silver e Gold — estabelecem um contrato compartilhado sobre confiabilidade de dados, desde a ingestão bruta até agregados prontos para consumo de negócio.

Principais takeaways:

• A qualidade dos dados melhora progressivamente camada por camada.
• O Delta Lake é o formato padrão recomendado, fornecendo ACID, time travel, schema evolution e change data feed.
• O Microsoft Fabric com OneLake oferece implementação nativa com materialized lake views, shortcuts e Liquid Clustering.
• O padrão é flexível e compatível com data mesh, hub-and-spoke e múltiplas plataformas.

Recomendação para começar: inicie com um único sistema fonte. Mapeie seu esquema bruto para uma tabela Bronze, defina cinco regras concretas de qualidade de dados para a camada Silver e construa um agregado Gold que um stakeholder de negócio realmente utilize. Entregue isso antes de projetar a arquitetura completa (DataForest, 2026).

Referências

1. Microsoft Learn — Azure Databricks. What is the medallion lakehouse architecture? Link

2. Microsoft Learn — Fabric OneLake. Implement Medallion Lakehouse Architecture in Fabric. Link

3. Microsoft Learn — Training Module. Organize a Fabric Lakehouse Using Medallion Architecture Design. Link

4. Databricks Glossary. What is Medallion Architecture? Link

5. Databricks AWS Docs — Deployment Guide. Phase 6: Design Delta Lake architecture. Link

6. Delta Lake Blog. Building the Medallion Architecture with Delta Lake. Link

7. DataForest. (2026). Medallion Architecture: Bronze, Silver & Gold Layers Explained (2026 Guide). Link