A arquitetura Medallion — com suas tradicionais camadas Bronze, Silver e Gold — é onipresente em apresentações de design de dados. Três caixas, três setas e a sensação de que o trabalho está feito. No entanto, essa simplicidade esconde um nível de complexidade que, se ignorado, pode transformar um pipeline promissor em um pesadelo de manutenção em menos de dois anos.
Na prática, o que chamamos de Medallion é um framework, não uma regra imutável. A mesma nomenclatura pode servir tanto para uma ingestão simples de 10 tabelas de marketing quanto para um enterprise lakehouse com 2.000 tabelas. A diferença entre um sistema robusto e um projeto fracassado mora nas decisões tomadas dentro de cada camada e nas fronteiras entre elas. Para times de engenharia, a maturidade na escolha desses padrões é o que garante que o onboarding da tabela número 200 seja tão fluido quanto o da segunda.
Abaixo, analisamos os pilares estratégicos que você deve considerar ao projetar seu ambiente. O objetivo não é seguir um manual, mas sim documentar explicitamente suas escolhas em seus design docs.
1. A Camada de Staging: Preciso dela?
Uma camada de Staging (stg_*) é uma área transiente que retém apenas os dados da execução corrente.
- Opções: Sem staging; staging como tabela temporária sobrescrita a cada run; ou como zona de checkpoints (usando, por exemplo, Auto Loader).
2. O nível de "pureza" da Bronze
O dogma diz "Bronze = raw bytes". A realidade do ambiente corporativo é outra. Quanto maior o número de fontes e consumidores, mais faz sentido aplicar alguma limpeza desde o início. Se você optar por normalizar nulls ou aplicar strong typing aqui, apenas garanta que a responsabilidade da Silver seja reajustada.
3. O Escopo da Silver
A Silver costuma ser a camada mais sobrecarregada. Se ela for a única camada consultada pelo negócio, ela acabará assumindo funções da Gold. Evite o antipadrão de ter uma tabela Silver para cada fonte; a Silver deve ser estruturada por entidades de negócio.
4. A Estrutura da Gold
Não trate a Gold como uma caixa única. Projetos maduros separam a Gold em zonas de reporting (desnormalizada, otimizada para alta performance) e zonas de histórico (SCD2, point-in-time).
5. Padronização de Carga e Metadados
Decidir entre FullLoad, DeltaLoad ou CDC impacta diretamente a lógica de merge e o gerenciamento de watermarks. O uso de um framework guiado por metadados é, muitas vezes, o divisor de águas entre um custo de manutenção linear ou exponencial. O ponto de equilíbrio para investir em automação costuma surgir após 30 a 50 tabelas.
Qual o seu cenário?
- Projetos Pequenos: Code-per-table, sem staging, Silver focada em entidades. Simples e direto.
- Plataformas de Médio Porte: Staging transiente, Silver de entidades com DAG orchestration, Gold dividida.
- Lakehouses em Escala: Auto Loader com checkpoints, framework 100% metadata-driven, contratos rígidos de schema.
Nada disso é "errado"; tudo é uma questão de calibração para o seu cenário. O segredo é documentar, ser explícito sobre os tradeoffs e estar pronto para revisitar essas definições à medida que o projeto evoluir.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
