El patrón medallion no se trata de tener tres carpetas más ordenadas. Se trata de decidir una vez dónde vive cada responsabilidad: Bronze preserva la evidencia, Silver hace confiable el dato y Gold lo convierte en producto para el negocio. Cuando cada capa tiene un contrato explícito, la lógica deja de esconderse dentro del informe.
Muchos equipos tratan Bronze, Silver y Gold como tres proyectos casi idénticos: la misma tabla copiada tres veces con nombres distintos. El resultado es lógica duplicada, reglas que se contradicen y transformaciones que nadie puede rastrear. La arquitectura medallion resuelve esto cuando se piensa como una única decisión de diseño, no como tres etapas sueltas.
Las tres capas son una sola decisión, no tres proyectos
Microsoft recomienda el patrón medallion en Fabric sobre OneLake por una razón que no es estética: protege la confiabilidad del dato y hace visible dónde ocurre cada transformación. La limpieza deja de quedar escondida dentro de una medida o un filtro de informe.
En un proyecto ordenado, cada capa tiene una función, un criterio de calidad y un papel en el flujo de decisión. Bronze no es una carpeta de descargas. Silver no es un espacio indefinido para consultas sueltas. Gold no es una copia más presentable de la tabla original.
Una estructura clara del workspace ayuda a explicar y operar la solución:
- Bronze para los pipelines y el lakehouse de entrada.
- Silver para el lakehouse y las transformaciones.
- Gold para el lakehouse y el modelo semántico.
- Un espacio auxiliar para los elementos de soporte.
Las carpetas deben explicar el flujo, no la herramienta. Si el nombre de un elemento describe la tecnología en lugar del rol que cumple, la arquitectura pierde legibilidad.
Bronze: memoria y trazabilidad, no un vertedero de descargas
La capa Bronze captura el dato en su forma inicial o lo referencia mediante shortcuts cuando conviene. No busca resolver el negocio. Busca preservar evidencia. El tutorial de Lakehouse muestra la carga inicial y el recorrido hasta el análisis.
El valor de Bronze aparece cuando algo falla más adelante. Si una transformación se rompe, se puede volver al dato base sin pedir otro export. Eso solo funciona si Bronze respeta tres contratos.
Contrato de entrada. Qué fuente entra, con qué frecuencia, bajo qué credencial y con qué histórico mínimo.
Registro técnico. Fecha de ingesta, origen, lote, estado, esquema detectado y errores.
Recuperación. El dato original queda disponible para reconstruir estados anteriores.
| Lo que cuidamos | Por qué importa | Ejemplo de salida |
|---|---|---|
| Originalidad | Evita discutir si el dato se alteró antes del análisis | Tablas sin procesar, archivos de origen e instantánea por carga |
| Esquema | Detecta cambios de columnas, tipos o nombres antes de romper consumo | Control de cambios de esquema y alerta de ruptura |
| Histórico | Permite comparar períodos, auditar cierres y reconstruir estados | Particionado por fecha de extracción o período de negocio |
La decisión de usar copia física o shortcut no es universal. Depende de si necesitas una instantánea inmutable por carga o si basta con referenciar la fuente. Ese criterio de ingesta se cruza con otras decisiones de plataforma que revisamos en shortcut, mirroring y copy job en Fabric.
Silver: donde el dato empieza a ser confiable
Silver es la capa donde se resuelven los conflictos que normalmente terminan en medidas imposibles o filtros que no cuadran. Aquí se corrigen problemas de calidad, se homogeneizan reglas y se unen fuentes. La arquitectura medallion en OneLake ubica limpieza, deduplicación y estandarización precisamente en este punto.
El trabajo típico de Silver incluye:
- Estandarización de fechas, monedas, estados, categorías y claves.
- Eliminación de duplicados y definición de reglas de supervivencia.
- Unificación de clientes, productos, usuarios o entidades entre sistemas.
- Control de valores nulos, tipos incompatibles y registros de prueba.
Lo importante es lo que Silver todavía no hace: no agrega para un informe concreto. Son tablas limpias, no reportes. Si la agregación entra demasiado pronto, la lógica vuelve a quedar atrapada en una capa que ya no puede reutilizarse.
Aquí aparece la pregunta clave del patrón. Si dos áreas calculan el mismo indicador de forma distinta, casi nunca se arregla con una visual. La corrección pertenece a Silver junto con el modelo semántico: allí una definición única queda disponible para todos los consumos. Ese es el contrato de salida de Silver: entregar entidades confiables sobre las que cualquier consumo pueda construir sin volver a limpiar.
Gold: cuando el dato se vuelve producto
La capa Gold contiene el dato curado que alimenta el modelo semántico y los consumos. No es un vertedero de tablas agregadas. Es el punto donde el dato se vuelve producto. La documentación de ingeniería de datos en Fabric describe cómo estas capas encajan en el flujo completo de la plataforma.
Gold se organiza alrededor de tres elementos:
- Hechos. Eventos medibles: ventas, pedidos, pagos, oportunidades, sesiones, tickets, actividad.
- Dimensiones. Contexto para cortar y entender: fecha, cliente, producto, canal, equipo, zona, estado.
- Agregados. Se justifican únicamente si mejoran los tiempos de consulta o evitan repetir reglas complejas en cada consumo.
Tres criterios guían el diseño de esta capa. Primero, el modelo de estrella cuando corresponde: Fabric y Power BI trabajan mejor cuando los hechos y las dimensiones están claros, lo que mejora el rendimiento, la comprensión y la reutilización. Segundo, Gold no contiene lógica escondida de visual; si una regla afecta al negocio, debe vivir como regla documentada, no como expresión perdida en una página. Tercero, Gold sirve a varios consumos: el mismo producto puede alimentar Power BI, Excel, agentes, APIs o aplicaciones internas.
El efecto se nota en el lenguaje. El usuario ve Ingresos, Margen, Cliente activo y Pipeline, no columnas técnicas sin contexto. Una fórmula compartida evita que cada informe reinvente la verdad, y hechos y dimensiones se conectan con cardinalidad, direcciones de filtro y jerarquías correctas.
Los contratos de entrada y salida evitan tres artículos idénticos
La razón por la que Bronze, Silver y Gold terminan siendo tres tablas casi iguales es que nadie definió qué recibe y qué entrega cada capa. El contrato es lo que las diferencia.
- Bronze recibe fuentes crudas y entrega evidencia trazable.
- Silver recibe evidencia y entrega entidades confiables y estandarizadas.
- Gold recibe entidades confiables y entrega productos de datos gobernados.
Cuando estos contratos están escritos, una transformación no puede colarse en la capa equivocada. Una deduplicación no vive en Gold. Una agregación de informe no vive en Silver. Un cálculo de negocio no vive dentro de una visual. La decisión sobre dónde materializar cada transformación tiene matices que dependen de la herramienta; ese cruce entre Dataflow y notebook lo tratamos en Dataflow Gen2 frente a notebook en Fabric.
Límites y decisiones que conviene tener claras
El patrón medallion es una guía, no una regla rígida. Hay decisiones que dependen de tu contexto y que ninguna documentación puede tomar por ti.
No toda solución necesita las tres capas plenamente desarrolladas desde el primer día. Un proyecto pequeño puede empezar con Bronze y Gold, y hacer crecer Silver cuando los conflictos de calidad lo justifiquen. Forzar tres capas completas sin necesidad genera trabajo que no aporta confiabilidad.
Tampoco existe un número correcto de agregados en Gold. Un exceso de tablas precalculadas reintroduce el problema que el patrón buscaba evitar: lógica repetida y difícil de auditar. El criterio es simple de enunciar y exigente de sostener: cada capa cuida su responsabilidad y no invade la de al lado.
Un paso concreto para tu arquitectura actual
Abre tu solución de Fabric y toma una sola transformación crítica, por ejemplo una deduplicación o una estandarización de estados. Rastréala hasta encontrar en qué capa vive hoy y escribe en una línea qué recibe y qué entrega. Si esa transformación aparece repetida en más de una capa, o si vive dentro de una medida de Power BI, tienes el primer contrato que reescribir. Empieza por mover esa regla a Silver o al modelo semántico, documenta el contrato y verifica que ningún informe la vuelva a calcular por su cuenta. Si quieres ver cómo se diseñan y operan estos contratos sobre un caso real, mira la demo gratuita.
Preguntas relacionadas
¿Necesito siempre las tres capas Bronze, Silver y Gold?
No en todos los casos desde el primer día. Un proyecto pequeño puede empezar con Bronze y Gold, y desarrollar Silver cuando los conflictos de calidad entre fuentes lo justifiquen. Forzar tres capas completas sin necesidad agrega trabajo que no mejora la confiabilidad.
¿Dónde debe vivir un cálculo de negocio, en Silver o en Gold?
Las reglas de estandarización, deduplicación y unificación viven en Silver. Las métricas gobernadas del negocio viven en el modelo semántico de la capa Gold como reglas documentadas. Ninguna de las dos debe quedar escondida dentro de una medida o visual de un informe concreto.
¿Uso copia física o shortcut para Bronze?
Depende del contrato de entrada. Si necesitas una instantánea inmutable por cada carga para auditar y reconstruir estados, conviene una copia física. Si basta con referenciar la fuente sin duplicar almacenamiento, un shortcut cumple. La decisión se toma por fuente, no de forma global.
¿Cómo evito que Gold se llene de tablas agregadas repetidas?
Agrega solo cuando acelera un consumo real o simplifica una regla que no conviene repetir. Un exceso de agregados precalculados reintroduce lógica duplicada y difícil de auditar, que es justo lo que el patrón medallion busca evitar. El modelo semántico debe cargar la mayor parte de las reglas compartidas.
¿Qué diferencia un contrato de entrada de uno de salida en este patrón?
El contrato de entrada define qué recibe una capa: fuentes, frecuencia, credenciales e histórico mínimo. El contrato de salida define qué entrega a la siguiente: Bronze entrega evidencia trazable, Silver entrega entidades confiables y Gold entrega productos de datos gobernados. Escribir ambos evita que una transformación se cuele en la capa equivocada.