Medallion Architecture en Microsoft Fabric

Cómo pasar de datos crudos a listos para Power BI

Si llevas un tiempo trabajando con datos, habrás escuchado el término Medallion. Y si todavía no lo has implementado en Microsoft Fabric, este artículo es para ti. No te preocupes, también te digo cuándo no deberías implementarlo, porque sí, hay veces que no hace falta matar moscas a cañonazos.

GIF ¿Os he contado ya lo que me gusta esta serie?

Mala calidad de los datos, no puedes seguir donde se transforman, llegan de 12 fuentes distintas, nadie sabe qué versión es la correcta, y el equipo de negocio desconfía de lo que se pinta en Power BI porque “los números nunca cuadran” y una pila de motivos más pueden hacer que fracase tu proyecto de datos. La Medallion Architecture ayuda a resolver precisamente eso, es la Marie Kondo de la arquitectura de datos…antes de tener hijos, al menos.

El trastero de los datos, el problema que más cuesta admitir*

*Cualquier parecido con la realidad es pura coincidencia

Imagina una empresa mediana. Tiene datos en Salesforce, en un ERP legacy, en ficheros Excel que alguien actualiza cada lunes, y en una API de un proveedor externo que te cambia el esquema sin avisar.

¿Qué ocurre cuando intentas construir un informe de ventas? Alguien escribe una query que junta todo eso, le pone un WHERE que “más o menos funciona”, y el resultado vive en una pestaña de Excel que solo esa persona sabe interpretar. Cuando se va de vacaciones, el negocio para.

La arquitectura Medallion propone una solución, en lugar de transformar los datos de golpe, los vas ajustando en capas progresivas. Cada capa tiene una responsabilidad y un lugar dentro de Microsoft Fabric.

AFC Richmond y un entrenador de Kansas

Antes de entrar en código y Lakehouses, déjame llevarte a mi serie del momento. Porque resulta que Ted Lasso, sin saberlo, montó una arquitectura Medallion con su equipo de fútbol. Sin necesidad de saber qué era un Lakehouse ni entender como funcionaba un fuera de juego, solo con galletas.

GIF Qué maravilla de personaje

Fase 1. El fichaje y la llegada al vestuario. Primer día de pretemporada en un equipo de fútbol inglés. Ted acaba de aterrizar desde EEUU y se encuentra lo siguiente: un delantero estrella con ego de Champions League, un veterano que lleva tantos años en el club que ya forma parte del mobiliario, un jugador con un optimismo que desafía la física, y un chaval que nadie sabe por qué está en primera división. Ted no cambia a nadie. No le dice a nadie que deje de ser como son. Los registra tal cual: con sus egos, sus lesiones, sus manías, y esa actitud de “a mí qué me va a enseñar un americano”. Los acepta en crudo. Eso es Bronze.
Fase 2. Los entrenamientos y el vestuario. Aquí empieza el trabajo de verdad. Se diseñan las tácticas. Se pone las reglas del vestuario. La dinámica del equipo se limpia, se aprende que el pase existe, se descubre que puede ser líder sin necesidad de romperle la tibia a alguien, y se entiende que no todo se resuelve con entusiasmo. Ya no tienes un grupo de individuos caóticos. Tienes un equipo. Todavía no gana la Premier League, pero ya entrenan juntos, ya es algo fiable y reconocible. Eso es Silver.
Fase 3. El día del partido. Ahora sí, estadio lleno, todos los stakeholders pendientes. Se sale al campo con una formación clara, roles definidos, y jugadas entrenadas. Cada jugador sabe exactamente qué se espera de él. El equipo ya no necesita que el entrenador les explique la táctica, se la saben. El público ve el resultado final: goles, asistencias, victorias. No necesitan saber que un jugador se hizo 200 sprints en entrenamiento o que el estrés casi hace que un jugador se retire. Ven el producto terminado. Eso es Gold.

Lo bonito del proceso. Los fichajes originales siguen quedan registrados. Si algo sale mal en un partido, Ted vuelve al entrenamiento (Silver) o incluso revisa los informes de fichajes (Bronze). Puede reconstruir el proceso desde cualquier fase.

Y una cosa más, nadie en su sano juicio pone a un jugador recién fichado directamente en un partido de Premier League sin pasar por un solo entrenamiento. Un error que veo todos los días en proyectos de datos. Como diría Ted: “Eso es como poner ketchup en un biscuit. Técnicamente posible, fundamentalmente incorrecto.” ⚽

Bronze Layer. Bienvenidos al vestuario de fichajes (y por qué no debes tocar nada)

GIF Lo mismo que cuando te cae un proyecto nuevo donde todo está por hacer

La capa Bronze es tu zona de aterrizaje, tu punto de partida. Y aquí la clave está en NO TOCAR NADA.

Aquí ingestas los datos en su forma original: JSON de una API, CSVs de un sistema externo, tablas replicadas desde un SQL Server, ficheros de log. Todo entra, nada sale modificado. Como Ted recibiendo jugadores el primer día: los aceptas con sus defectos, sus contradicciones y esa columna que alguien llamó Fld_007 pensando que era temporal.

¿Por qué es importante no transformar en Bronze?

Porque cuando algo falla , y algo siempre falla, necesitas poder volver al origen. Si transformas en el momento de la ingesta y hay un error en tu lógica, has perdido los datos originales. Bronze es tu seguro, histórico, la copia de seguridad que nunca debería necesitarse pero que algún día salva la vida.

En Microsoft Fabric, Bronze vive en un Lakehouse. Habitualmente en la carpeta Files del Lakehouse, donde puedes almacenar cualquier formato de fichero sin imponer un esquema.

Lakehouse: Bronze
└── Files/
    ├── salesforce/
    │   ├── 2024-01-15/accounts.json
    │   └── 2024-01-15/opportunities.json
    ├── erp/
    │   └── 2024-01-15/ventas_export.csv
    └── api_proveedor/
        └── 2024-01-15/productos_raw.parquet

Como el ojeador que trae al jugador al club, su misión acaba en la puerta del vestuario. Un Data Pipeline o un Eventstream de Fabric se encarga de mover los datos, nada más. Su trabajo termina cuando el fichero está guardado.

Qué contiene Bronze

Datos sin limpiar, con duplicados, con nulos, con tipos incorrectos
Esquemas tal como los envió la fuente
Particionado por fecha de ingesta
Retención larga , esto es tu histórico

Silver Layer. Donde las cosas empiezan a tener sentido.

GIF

Aquí empieza la acción. La capa Silver toma los datos de Bronze y los convierte en algo con lo que se puede empezar a trabajar.

En Silver aplicas:

Limpieza de datos: eliminación de duplicados, manejo de nulos, corrección de tipos.
Estandarización: fechas en formato ISO, monedas en la misma divisa, nombres de columnas consistentes. Que todo el equipo use el mismo idioma táctico.
Enriquecimiento básico: joins entre tablas que tienen sentido a nivel técnico (no de negocio). Unir al jugador con su historial de goles, no decidir si es titular.
Validaciones: registros que no cumplen reglas de calidad se marcan o mueven a una tabla de cuarentena. Como cuando se aparta a un jugador del entrenamiento porque no ha dormido y huele sospechosamente a pub.

En Microsoft Fabric, Silver también vive en un Lakehouse, pero ahora en la sección Tables, datos estructurados en formato Delta Lake, con esquema definido y versionado.

Un Notebook de Fabric orquestado por un Pipeline es el arma perfecta para este trabajo. Si prefieres algo sin código, un Dataflow Gen2 hace la misma transformación con una interfaz visual.

Qué contiene Silver

Datos limpios y tipados correctamente
Modelos relacionales simples (sin lógica de negocio compleja, porfiplis)
Tablas reutilizables por múltiples casos de uso
Historial de cambios gracias a Delta Lake

Gold Layer. El día del partido (y para que el negocio tome decisiones)

GIF

La capa Gold es donde el negocio vive. Aquí las tablas dejan de ser importantes y lo empeizan a ser las preguntas que se resuelven.

¿Cuál es el revenue por región en Q4? ¿Qué clientes tienen riesgo de churn? ¿Cuál es el margen por línea de producto? Gold responde esas preguntas.

En Gold construyes

Tablas de hechos y dimensiones (modelo estrella o copo de nieve). La alineación titular y las estadísticas del partido.
Agregaciones pre-calculadas para mejorar el rendimiento de los dashboards. Los highlights del partido, ya montados.
Feature stores para modelos de Machine Learning. Los datos que el analista de rendimiento usa para predecir lesiones.
Vistas semánticas adaptadas a cada área de negocio.

En Microsoft Fabric, Gold puede vivir en un Lakehouse (para consumo con Spark o Direct Lake en Power BI) o directamente en un Warehouse de Fabric si el equipo prefiere SQL puro.

La capa Gold es la que conectas directamente a Power BI usando el modo Direct Lake, sin importación, sin duplicación de datos, con rendimiento de Analysis Services y frescura de Lakehouse. Esa combinación es una de las joyas de Microsoft Fabric.

Qué contiene Gold

Modelos dimensionales optimizados para consulta
Semántica de negocio aplicada (no IDs técnicos, sino nombres comprensibles)
Datos agregados o pre-calculados donde tiene sentido
Tablas específicas por dominio (gold_ventas, gold_finanzas, gold_rrhh)

Los 4 errores más comunes al implementar Medallion

En los que has caído tú, en los que hemos caído todas en algún momento.

GIF

1. Hacer transformaciones en Bronze

Este lo he visto en un montón de proyectos. Y siempre es la misma historia, alguien quería “ahorrar un paso”. Pero no lo ahorró, lo multiplicó por diez cuando algo falló tres meses después y no había forma de volver al dato original. Bronze es sagrado. Resístete la tentación.

2. Meter lógica de negocio en Silver

Silver estandariza, no decide. Si un campo tiene dos definiciones posibles según el departamento, y siempre las tiene, eso va en Gold o en la capa semántica de Power BI. Si metes esa discusión en Silver, estás eligiendo un bando en una guerra que no te corresponde.

3. Crear una sola capa Gold para toda la empresa

Un Gold monolítico que intenta servir a Ventas, Finanzas, RRHH y Operaciones al mismo tiempo acaba pareciendo un Frankenstein que no sirve a nadie. Lo más práctico son los Gold domains. gold_ventas, gold_finanzas, gold_operaciones. Cada equipo tiene su Gold, todos comparten el mismo Silver.

4. No versionar los datos de Bronze

Particiona siempre por fecha de ingesta. Dentro de 6 meses te alegrarás de haberlo hecho. Dentro de 12 meses harás que alguien que estaba a punto de cometer este error lea esto.

Cuándo NO usar Medallion Architecture (sí, existe ese momento)

Todo lo anterior asume que Medallion es la respuesta correcta. Y la mayoría de las veces lo es. Pero hay escenarios donde implementarla es matar moscas a cañonazos, y conviene reconocerlos antes de empezar a crear Lakehouses y Workspaces a lo loco.

Cuando el volumen de datos es pequeño y estable.
Si tu empresa tiene tres orígenes de datos, dos analistas y un Power BI que ya funciona, añadir tres capas de Lakehouse no te da estructura, te da burocracia. Medallion brilla cuando hay complejidad, múltiples fuentes, múltiples consumidores, múltiples equipos. Si no tienes eso todavía, un Dataflow Gen2 bien hecho y una semántica de Power BI limpia pueden ser suficientes.

Cuando necesitas resultados en días, no en semanas.
Medallion es una inversión a medio plazo. Si tienes un proyecto con entrega en dos semanas y el cliente quiere ver números, no es el momento de diseñar una arquitectura de tres capas. Haz el análisis exploratorio, entrega valor rápido, y deja la arquitectura para la fase de consolidación.

Es lo que hizo Ted, primero conoció a los jugadores y se ganó su confianza. No empezó el primer día dibujando una formación 4–3–3 en la pizarra. Medallion no es lo primero que se monta, es lo que aguanta cuando el proyecto crece.

Cuando los datos no van a reutilizarse.
El verdadero ROI de Silver está en que múltiples casos de uso consumen las mismas tablas limpias. Si estás construyendo un pipeline one-shot para una migración, un análisis puntual o un informe que se va a usar una vez y nunca más, el overhead de la arquitectura no se amortiza. Construye lo mínimo necesario y documenta bien. Ya está.

Cuando el equipo no tiene capacidad de mantenerlo.
Una arquitectura Medallion mal mantenida es peor que no tenerla. Si Bronze empieza a acumular ficheros sin particionar, Silver acaba con tablas que nadie sabe quién creó, y Gold tiene queries que “más o menos funcionan”, has construido el mismo trastero de datos de antes, pero con tres carpetas. Medallion requiere disciplina de equipo. Si esa disciplina no existe todavía, primero hay que crearla y luego escalar la arquitectura.

La regla práctica, si no puedes responder con claridad quién va a consumir Silver y para qué, probablemente todavía no necesitas Medallion. Empieza más pequeño y escala cuando el dolor lo justifique. La arquitectura perfecta que nadie mantiene vale exactamente lo mismo que el Excel de los lunes.

Conclusión

GIF

El fichaje original, con sus defectos y su potencial, es el punto de partida. En Microsoft Fabric tienes los Lakehouses, los Notebooks, los Dataflows y el Direct Lake de Power BI diseñados para funcionar exactamente así, capa a capa.

Como diría Ted: “Be curious, not judgmental.” Y eso aplica tanto a los datos como a las personas que trabajan con ellos. ⚽

¿Estás implementando Medallion Architecture en Microsoft Fabric? Cuéntame en los comentarios qué decisiones de diseño te resultaron más difíciles. os casos reales son los que más se aprenden. BELIEVE.

GIF