Arquitectura Medallion en Fabric: Principios de diseño para pipelines limpios
La arquitectura Medallion en Microsoft Fabric no es una sugerencia estética; es un requisito operativo para evitar que el Lakehouse se convierta en un pantano de archivos inaccesibles. En proyectos de Business Intelligence para sectores como el retail o la industria, el problema rara vez es la herramienta. El fallo suele estar en una ingesta desordenada que arrastra errores de lógica desde el origen hasta el informe final.
Implementar Medallion en Fabric significa aplicar un proceso de refinamiento progresivo. Pasamos de datos crudos (Bronce) a datos validados y limpios (Plata) para terminar en modelos de negocio listos para el consumo (Oro). Esta estructura permite que, ante un fallo en un informe de Power BI, podamos rastrear el linaje de forma precisa y determinar si el error viene de una transformación en la capa Silver o de un dato corrupto en la ingesta inicial.
Antes de empezar a crear Lakehouses, hay que entender el coste de mantenimiento. Una arquitectura mal diseñada en Fabric implica un consumo innecesario de Unidades de Capacidad (CU) debido a procesos de transformación repetitivos o consultas SQL ineficientes sobre tablas no optimizadas. El objetivo es claro: mover la complejidad hacia las capas iniciales para que el consumo final sea lo más ligero posible.
Capa Bronze: La zona de aterrizaje inmutable
La capa Bronce es el punto de entrada. Aquí, el principio fundamental es la inmutabilidad. No se aplican reglas de negocio, no se cambian nombres de columnas y, bajo ninguna circunstancia, se filtran datos. Si el sistema de origen entrega un JSON mal formado o un CSV con cabeceras inconsistentes, eso es exactamente lo que debe almacenarse en Bronce.
En Microsoft Fabric, esta capa suele residir en un Lakehouse específico. Utilizamos Pipelines de Datos o Dataflows Gen2 para mover los datos desde el origen. La recomendación técnica es organizar esta capa mediante carpetas por sistema de origen y subcarpetas por fecha de ingesta (Partitioning). Esto facilita procesos de recarga histórica sin tener que leer todo el dataset.
Por qué no transformar en Bronce: Si descubres un error en tu lógica de limpieza meses después, necesitarás los datos originales para reprocesar la información. Si los modificaste al entrar, habrás perdido la trazabilidad y la capacidad de recuperación. En esta fase, el formato Delta es opcional pero recomendado, aunque a menudo guardamos los archivos en su formato nativo (Parquet, CSV, JSON) para auditoría externa.
Capa Silver: Validación, limpieza y conformación
En la capa Silver es donde ocurre la magia de la ingeniería de datos. Aquí transformamos los datos crudos en tablas Delta limpias y normalizadas. Es el momento de aplicar tipos de datos correctos, eliminar duplicados y manejar valores nulos. Para profundizar en esta fase, te recomiendo consultar nuestra Capa Silver en Fabric: Guía de Limpieza, Deduplicación y Conformación.
En mis proyectos de retail, esta capa es crítica para la «conformación». Si recibimos datos de ventas de tres sistemas TPV distintos, la capa Silver los unifica en una estructura común. Un campo ID_Cliente debe ser el mismo tipo de dato y longitud en todas las tablas de esta capa, independientemente de cómo venga del origen.
# Ejemplo de limpieza y deduplicación en capa Silver usando PySpark
from pyspark.sql.functions import col, current_timestamp, row_number
from pyspark.sql.window import Window
# 1. Carga de datos de Bronce
raw_sales = spark.read.format("delta").load("Tables/Bronze_Sales")
# 2. Definición de ventana para eliminar duplicados por ID de transacción
window_spec = Window.partitionBy("TransactionID").orderBy(col("IngestionTimestamp").desc())
# 3. Limpieza: Tipado, eliminación de duplicados y agregado de metadatos
cleaned_sales = raw_sales.withColumn("row_num", row_number().over(window_spec)) \
.filter(col("row_num") == 1) \
.drop("row_num") \
.withColumn("LoadDate", current_timestamp()) \
.select(
col("TransactionID").cast("string"),
col("CustomerID").cast("integer"),
col("TotalAmount").cast("decimal(18,2)"),
col("OrderDate").cast("date"),
col("LoadDate")
)
# 4. Escritura en capa Silver
cleaned_sales.write.format("delta").mode("overwrite").saveAsTable("Silver_Sales")Un error común que veo en consultorías es intentar crear el modelo en estrella directamente aquí. La capa Silver debe mantenerse, en la medida de lo posible, cercana a la estructura de la entidad de negocio, pero limpia. No es el lugar para grandes agregaciones, sino para datos atómicos de alta calidad.
Capa Gold: El dominio del negocio y el modelo en estrella
La capa Gold es la que consumen los informes de Power BI y los científicos de datos. Aquí es donde aplicamos el modelo de Kimball (Hechos y Dimensiones). En Microsoft Fabric, esta capa se beneficia enormemente del motor de SQL Warehouse o de un Lakehouse optimizado para Direct Lake.
En esta etapa, los datos ya están filtrados por reglas de negocio. Por ejemplo, si en Silver tenemos todas las transacciones, en Gold solo tendremos las transacciones confirmadas, excluyendo cancelaciones o pruebas internas. Es fundamental que el rendimiento aquí sea máximo. El uso de Lakehouse en Microsoft Fabric: Anatomía, ACID y Motores de Consulta es clave para entender cómo los motores de Fabric acceden a estas tablas.
| Característica | Bronze (Raw) | Silver (Cleansed) | Gold (Curated) |
|---|---|---|---|
| Propósito | Ingesta e historia | Calidad y consistencia | Consumo y Negocio |
| Esquema | Original del origen | Estructurado/Normalizado | En estrella (Kimball) |
| Usuarios | Ingenieros de datos | Ingenieros / Analistas | Usuarios finales / BI |
| Formato | Cualquiera (Parquet rec.) | Delta Table | Delta Table (V-Order) |
Para garantizar el rendimiento en Power BI, las tablas de la capa Gold deben estar optimizadas con V-Order. Esto reduce el tiempo de escaneo de columnas y mejora la compresión. Si decides usar un Data Warehouse para esta capa, podrás aplicar seguridad a nivel de fila de forma nativa mediante T-SQL, algo vital en entornos con datos sensibles. Puedes ver más sobre esto en RLS y CLS en Microsoft Fabric: Implementación de Seguridad Granular con T-SQL.
Gobernanza y mantenimiento de la arquitectura
No basta con separar los datos en tres capas; hay que gestionar su ciclo de vida. Fabric nos ofrece herramientas de linaje que muestran visualmente cómo fluye la información. Como consultor, insisto siempre en la importancia de la limpieza técnica. Con el tiempo, las tablas Delta acumulan versiones antiguas de los datos debido a su naturaleza ACID. Es imperativo ejecutar procesos de mantenimiento.
-- Ejecutar mantenimiento en el Warehouse o Lakehouse (vía SQL)
-- Esto elimina versiones antiguas de archivos que ya no son necesarios
VACUUM Sales_Gold RETAIN 168 HOURS;
-- El comando anterior mantiene solo los últimos 7 días de historial
-- para permitir el "Time Travel" si fuera necesario, ahorrando espacio en OneLake.La gestión de permisos también debe seguir la estructura Medallion. Los analistas de negocio solo deberían tener acceso de lectura a la capa Gold. El acceso a Silver y Bronze debe estar restringido a perfiles técnicos para evitar la creación de informes basados en datos no validados. Una buena práctica es utilizar Arquitectura de permisos quirúrgicos en OneLake: Implementación de Data Access Roles para segmentar quién ve qué en cada Lakehouse.
Errores frecuentes que destruyen tu arquitectura
- Saltarse la capa Silver: Cargar datos directamente de Bronce a Gold es una receta para el desastre. Cualquier cambio en el origen romperá tus medidas DAX y tus informes.
- Exceso de capas: No crees «Plata-V2» o «Bronce-Pre». Si necesitas más pasos, usa transformaciones dentro de la misma capa o particiona mejor tus datos.
- Lógica de negocio en Bronce: Nunca apliques filtros de «ventas mayores a 0» en Bronce. Esa lógica cambia con el tiempo y podrías necesitar esos datos en el futuro para auditorías.
- Ignorar el formato Delta: Usar archivos Parquet planos sin las capacidades de Delta Lake te hará perder el control de transacciones y dificultará las actualizaciones (Upserts).
- No usar el motor adecuado: Intentar hacer transformaciones masivas en Dataflows Gen2 cuando podrías usar Notebooks de Spark puede disparar el tiempo de ejecución y el coste.
Para elegir correctamente el componente donde residirán estas capas, revisa nuestra comparativa entre Lakehouse vs Data Warehouse en Microsoft Fabric: Guía de Arquitectura y Selección. La elección dependerá de si tu equipo se siente más cómodo con Spark (Python/Scala) o con T-SQL.
Checklist para una arquitectura Medallion exitosa
- Inmutabilidad: ¿Se guardan los datos originales en Bronce sin ninguna modificación?
- Esquema único: ¿Tienen las tablas Silver una estructura de tipos de datos consistente para entidades similares?
- Modelo en Estrella: ¿Está la capa Gold diseñada con dimensiones y hechos claros para facilitar el DAX en Power BI?
- Mantenimiento: ¿Se han programado tareas de VACUUM y OPTIMIZE para mantener el rendimiento del OneLake?
- Seguridad: ¿Están los permisos segmentados para que el usuario final solo acceda a la capa Gold?
Preguntas frecuentes
¿Es obligatorio usar tres Lakehouses distintos para Medallion?
No es obligatorio, pero sí recomendable para separar las responsabilidades y permisos. En entornos pequeños, puedes usar esquemas o carpetas dentro de un mismo Lakehouse, pero perderás granularidad en la seguridad de OneLake.
¿Puedo usar Dataflows Gen2 para todas las capas?
Puedes, pero no es lo óptimo para grandes volúmenes de datos. Los Notebooks de Spark ofrecen un control mucho mayor sobre el particionamiento y el rendimiento, especialmente para procesar la capa Silver y Gold en datasets de millones de filas.
¿Cuándo debería usar un Warehouse en lugar de un Lakehouse para la capa Gold?
Usa un Data Warehouse si tu equipo tiene fuertes conocimientos de SQL y necesitas características específicas como transacciones multi-tabla o seguridad a nivel de columna (CLS) de forma nativa.
¿Cómo afecta Medallion al rendimiento de Direct Lake?
Lo mejora sustancialmente. Al tener una capa Gold bien estructurada y optimizada con V-Order, Power BI puede cargar los datos directamente en memoria sin pasar por el motor de Analysis Services tradicional, eliminando la necesidad de refrescos programados.
