Arquitectura medallón en Fabric: Bronce, Plata y Oro con Lakehouses y Warehouses

La arquitectura medallón no es un estándar rígido de Microsoft, sino una propuesta lógica para organizar el ciclo de vida del dato. En Microsoft Fabric, esta estructura cobra un sentido especial gracias a la unificación en OneLake. El error más común que veo en proyectos de retail o industria no es la elección de la herramienta, sino la falta de una frontera clara entre lo que es un dato bruto y lo que es un modelo dimensional preparado para el negocio.

Implementar Bronce, Plata y Oro en Fabric requiere decidir dónde termina el Lakehouse y dónde empieza el Warehouse. No se trata solo de mover datos, sino de garantizar la trazabilidad y el rendimiento. Antes de entrar en el código, hay que entender que cada capa resuelve un problema de confianza: Bronce nos da fidelidad, Plata nos da consistencia y Oro nos da utilidad. Si intentas saltarte la consistencia para llegar antes a la utilidad, acabarás con un informe de Power BI que arrastra errores de lógica imposibles de auditar.

En este artículo analizaremos cómo estructurar estos niveles utilizando las capacidades de cómputo de Fabric, diferenciando cuándo usar Notebooks de PySpark y cuándo apoyarnos en el motor de SQL para la capa final de entrega.

Capa Bronce: El aterrizaje sin fricciones

La capa Bronce es el punto de entrada. Aquí la regla de oro es: no tocar nada. El objetivo es persistir el dato tal cual viene del origen (ERP, CRM, logs de sensores). En Fabric, el ítem ideal para esta capa es el Lakehouse. Nos permite almacenar tanto archivos estructurados como semiestructurados (JSON, Parquet, CSV) manteniendo la estructura de carpetas original.

En esta fase, la clave es la velocidad de ingesta. No perdemos tiempo en renombrar columnas ni en corregir tipos de datos. Sin embargo, para que esta capa sea útil, debemos organizar los datos por carpetas de origen y fecha de carga. Un error recurrente es sobrescribir los datos de Bronce; siempre debemos trabajar con un enfoque de append o particionamiento por fecha para permitir la re-ejecución de procesos si la lógica de negocio cambia en el futuro.

Desde el punto de vista del acceso, la capa Bronce debe estar restringida a los ingenieros de datos. Nadie que consuma Power BI debería ver esta capa. Para entender cómo se gestionan estas rutas de acceso, es fundamental conocer bien OneLake: Entender rutas y acceso externo en Microsoft Fabric.

Capa Plata: Estandarización y calidad

En la capa Plata es donde ocurre la magia técnica. Aquí transformamos los archivos de Bronce en tablas Delta. Es el momento de aplicar esquemas, corregir tipos de datos y, sobre todo, normalizar nombres. Si en tu origen el campo se llama CUST_ID_01, aquí pasa a llamarse ID_Cliente.

Criterios obligatorios para la capa Plata:

• Deduplicación: Eliminamos registros duplicados que vienen de los sistemas transaccionales.
• Casting de tipos: Aseguramos que las fechas sean Date y los importes Decimal.
• Limpieza básica: Gestión de nulos (sustituir por valores por defecto si aplica) y eliminación de caracteres extraños.
• Enriquecimiento técnico: Añadimos columnas de auditoría como FechaCarga_UTC o NombreOrigen.

Para esta capa, los Notebooks de Fabric son la herramienta más potente. Nos permiten manejar grandes volúmenes de datos con Spark y optimizar la escritura. Es vital vigilar la salud de estas tablas; procesos como los Checkpoints de Delta en Fabric aseguran que la lectura de estos metadatos no penalice el rendimiento de los procesos posteriores.

# Ejemplo de transformación de Bronce a Plata en un Notebook de Fabric
from pyspark.sql.functions import col, current_timestamp, when

# Lectura del dato bruto en Bronce
df_bronce = spark.read.format("parquet").load("Files/Bronce/Ventas_2023_10.parquet")

# Limpieza y estandarización
df_plata = df_bronce.select(
 col("SALE_ID").cast("integer").alias("ID_Venta"),
 col("PROD_CODE").alias("ID_Producto"),
 col("CUST_NAME").alias("Nombre_Cliente"),
 col("AMOUNT").cast("decimal(18,2)").alias("Importe"),
 col("SALE_DATE").cast("date").alias("Fecha_Venta")
).withColumn("Procesado_At", current_timestamp())

# Escritura en formato Delta (Plata)
df_plata.write.format("delta").mode("overwrite").saveAsTable("Plata_Ventas")

Capa Oro: El modelo en estrella (Star Schema)

La capa Oro es la única que debe consumir el usuario de negocio o el desarrollador de informes. Aquí no hablamos de tablas sueltas, sino de un modelo dimensional de Kimball. Tablas de hechos (Ventas, Pedidos, Movimientos) y tablas de dimensiones (Producto, Cliente, Geografía, Calendario).

¿Lakehouse o Warehouse para la capa Oro? Mi criterio como consultor es claro: si tu equipo domina SQL y necesitas aplicar seguridad a nivel de fila (RLS) de forma nativa o realizar consultas cruzadas entre diferentes bases de datos con facilidad, el Fabric Warehouse es la opción ganadora. El Warehouse ofrece un endpoint de T-SQL completo y un motor de ejecución optimizado para consultas analíticas.

En esta capa, la optimización es crítica. Debemos evitar la fragmentación de archivos pequeños que degrada las consultas. Si decides usar el Warehouse, ten en cuenta la fragmentación en Microsoft Fabric Warehouse y cómo el motor gestiona la compactación automática.

-- Creación de una Dimensión en la capa Oro (Warehouse)
CREATE TABLE Oro.Dim_Producto AS
SELECT 
 DISTINCT ID_Producto,
 Nombre_Producto,
 Categoria,
 Subcategoria,
 GETDATE() AS Fecha_Alta
FROM Plata.Productos
WHERE EsActivo = 1;

Comparativa de capas y herramientas

Para decidir qué tecnología usar en cada paso, esta tabla resume la arquitectura recomendada basada en proyectos reales de tamaño medio:

Distribución de Workspaces y Gobierno

Uno de los errores más graves es meter todo en un único Workspace. Esto rompe cualquier principio de seguridad y ciclo de vida de desarrollo (ALM). La recomendación profesional es separar las capas por Workspaces si la organización es suficientemente grande:

1. WS_Ingestion (Bronce): Acceso restringido. Solo procesos de carga (Pipelines) y administradores de datos.
2. WS_Transformation (Plata): Donde viven los Notebooks de ingeniería de datos.
3. WS_Reporting (Oro): Donde residen los Warehouses y los modelos semánticos de Power BI.

Esta separación permite aplicar Seguridad en Microsoft Fabric: Roles, Workspaces y Permisos sin Agujeros de forma granular. Por ejemplo, los analistas de negocio solo tendrán permisos de lectura en el Workspace Oro, evitando que puedan ver datos sensibles o inacabados de las capas previas.

Para la orquestación entre estos niveles, no lances los Notebooks uno a uno manualmente. Utiliza el potencial de notebookutils para crear flujos lógicos. Consulta este artículo sobre notebookutils.notebook.run frente a runMultiple para entender cómo paralelizar la carga de tus dimensiones en la capa Oro.

Errores frecuentes en arquitectura medallón

• Transformar en Bronce: Si aplicas lógica de negocio al ingerir y el origen cambia, pierdes la capacidad de auditar qué pasó realmente.
• No usar Delta: En Fabric, todo lo que no sea Delta Lake es, por definición, menos eficiente. Delta permite el time travel, fundamental para depurar errores en la capa Plata.
• Ignorar el Modelo en Estrella: Muchos equipos intentan conectar Power BI directamente a tablas planas de la capa Plata. Esto destruye el rendimiento del motor VertiPaq en DAX. El modelo en estrella no es opcional.
• Abuso de Data Flows Gen2: Para volúmenes pequeños están bien, pero en arquitecturas empresariales, los Notebooks ofrecen un control de errores y un rendimiento que los Data Flows aún no alcanzan.

Checklist de implementación

• [ ] ¿Están los datos de Bronce almacenados en su formato original sin transformaciones destructivas?
• [ ] ¿Se han eliminado duplicados y estandarizado tipos de datos en la capa Plata?
• [ ] ¿La capa Oro sigue un modelo dimensional (Hechos y Dimensiones)?
• [ ] ¿Se han separado los permisos de modo que el usuario final solo acceda a la capa Oro?
• [ ] ¿Se ha medido el rendimiento de las consultas (v-order, estadísticas) antes de pasar a producción?

Preguntas frecuentes

¿Es obligatorio usar un Warehouse para la capa Oro?

No, puedes usar un Lakehouse y servir los datos a Power BI a través del SQL Analytics Endpoint. Sin embargo, el Warehouse es preferible si necesitas soporte completo de DDL/DML de SQL o si vienes de un entorno tradicional de SQL Server, ya que facilita la gestión de transacciones.

¿Puedo saltarme la capa Plata si los datos vienen limpios?

En teoría sí, pero en la práctica es un riesgo. La capa Plata actúa como un contrato de calidad. Si el origen cambia levemente, la capa Plata absorbe el impacto y evita que el modelo de Oro (y por tanto los informes) se rompa.

¿Cómo gestiono la actualización de las capas?

Lo ideal es utilizar Fabric Pipelines que disparen Notebooks en cadena. Primero Ingesta (Bronce), luego Transformación (Plata) y finalmente Carga Dimensional (Oro). Asegúrate de gestionar las dependencias para que Oro no se cargue si Plata ha fallado.

¿Influye la región de Fabric en el diseño medallón?

No influye en la lógica, pero sí en el rendimiento. Todos los ítems (Lakehouses, Warehouses) deben residir en la misma capacidad y región para minimizar la latencia de red al mover datos a través de OneLake.