Consumo de bases de datos espejadas en Fabric con Notebooks y SQL
El Mirroring en Microsoft Fabric ha cambiado la conversación sobre la ingesta de datos. Al eliminar la necesidad de construir tuberías complejas de replicación (ETL/ELT) para bases de datos externas como SQL Server, Azure SQL o Cosmos DB, Microsoft nos entrega los datos en OneLake en formato Delta Parquet casi en tiempo real. Sin embargo, tener los datos replicados es solo el 20% del trabajo. El verdadero reto para un consultor de Business Intelligence comienza cuando hay que transformar esa réplica técnica en un modelo de datos analítico (estrella) que sea eficiente para Power BI.
En proyectos de retail o industria, donde los volúmenes de transacciones son altos, no basta con conectar Power BI directamente a las tablas espejadas. El Mirroring crea una copia exacta del origen, lo que incluye esquemas transaccionales altamente normalizados que no son óptimos para el motor Vertipaq. Necesitamos una capa intermedia de semántica y limpieza. Aquí es donde entran en juego el SQL Analytics Endpoint y los Notebooks de Spark.
Antes de decidir qué herramienta usar, debemos entender que el Mirroring no es un almacén de datos (Warehouse) ni un Lakehouse al uso; es un ítem especializado cuya principal función es la sincronización. Para cualquier transformación pesada, unión de múltiples fuentes o aplicación de lógica de negocio compleja, debemos mover o referenciar esos datos desde otros ítems de Fabric.
La arquitectura de consumo: SQL vs. Notebooks
Cuando nos enfrentamos a una base de datos espejada, tenemos dos vías principales para procesar y consumir la información. La elección depende del volumen, la complejidad de las transformaciones y las habilidades del equipo. En mi experiencia, la mayoría de los problemas de rendimiento en Fabric no vienen de la herramienta en sí, sino de elegir el motor equivocado para la tarea equivocada.
Uso del SQL Analytics Endpoint
Cada base de datos espejada en Fabric expone automáticamente un punto de enlace SQL (SQL Analytics Endpoint). Es de solo lectura, pero nos permite realizar consultas directas sobre los archivos Delta que el proceso de Mirroring genera. Es la opción ideal cuando necesitamos crear vistas rápidas o cuando queremos unir los datos del Mirroring con tablas de un Warehouse existente mediante consultas cross-database.
Si ya has configurado el Mirroring de SQL Server en Fabric: Gateway y Gestión de Cambios, sabrás que la latencia es mínima. El uso de SQL es preferible si la lógica es principalmente relacional y el equipo se siente cómodo con T-SQL. No obstante, recuerda que al ser de solo lectura, no puedes crear tablas físicas dentro del ítem de Mirroring; debes hacerlo en un Warehouse o Lakehouse independiente.
Uso de Notebooks y Spark
Los Notebooks son la navaja suiza de Fabric. Son necesarios cuando la lógica de limpieza implica procesos que SQL no maneja bien, como el tratamiento de cadenas de texto complejo, llamadas a APIs externas para enriquecer datos o cuando el volumen de datos requiere el paralelismo masivo de Apache Spark. En sectores como la energía, donde manejamos series temporales de millones de registros por hora, Spark es la única forma viable de pre-agregar datos antes de llevarlos a Power BI.
Estrategia de unión de datos y creación de capas Gold
El objetivo final es crear una capa de consumo (Gold) que siga el modelo de Kimball. Para ello, debemos unir las tablas de dimensiones (que suelen estar en el Mirroring) con las tablas de hechos y, posiblemente, con datos externos como ficheros Excel de objetivos o presupuestos almacenados en un Lakehouse.
En el siguiente ejemplo de SQL, mostramos cómo realizar una consulta cross-database para unir una tabla de ventas replicada mediante Mirroring con una tabla de presupuestos que reside en un Warehouse corporativo. Es fundamental entender cómo Conectar SSMS, Azure Data Studio y sqlcmd a Microsoft Fabric Warehouse para validar estas consultas antes de implementarlas en producción.
-- Consulta en el Warehouse corporativo referenciando el Mirroring
-- El Mirroring se llama 'ERP_Mirror' y el Warehouse 'Finance_DW'
CREATE VIEW Gold.Fact_VentasVsPresupuesto AS
SELECT
v.ID_Venta,
v.Fecha,
v.ID_Producto,
v.Importe AS Importe_Real,
p.Importe_Presupuesto,
-- Calculamos la desviación en la misma vista
(v.Importe - p.Importe_Presupuesto) AS Desviacion
FROM [ERP_Mirror].[dbo].[Ventas] AS v
LEFT JOIN [Finance_DW].[dbo].[Presupuestos] AS p
ON v.ID_Producto = p.ID_Producto
AND FORMAT(v.Fecha, 'yyyy-MM') = p.Mes_Presupuesto
WHERE v.Fecha >= '2023-01-01';
-- Es vital filtrar por fecha para reducir el escaneo de datos en OneLakeTransformación avanzada con PySpark
A veces, la calidad del dato en el origen es deficiente. Por ejemplo, en el sector industrial, es común encontrar nombres de sensores con errores tipográficos o códigos de producto inconsistentes. Usar columnas condicionales y personalizadas en Power Query puede ser lento si la tabla tiene 100 millones de filas. En ese caso, lo resolvemos en el Notebook antes de que el dato llegue al informe.
El siguiente bloque de código muestra cómo leer una tabla del Mirroring, limpiar los datos y guardarlos como una tabla Delta optimizada en un Lakehouse, aplicando el motor de Spark.
# Leer tabla desde el ítem de Mirroring usando el catálogo de Fabric
df_ventas = spark.read.table("ERP_Mirror.dbo.Ventas")
# Transformaciones: limpieza de nulos y normalización de importes
from pyspark.sql.functions import col, when, round
df_limpio = df_ventas.filter(col("Importe").isNotNull()) \
.withColumn("Importe", round(col("Importe"), 2)) \
.withColumn("Segmento", when(col("Importe") > 1000, "Premium").otherwise("Estándar"))
# Escribir el resultado en el Lakehouse de destino (Capa Silver/Gold)
# Usamos overwrite para refrescar los datos en cada ejecución del pipeline
df_limpio.write.format("delta").mode("overwrite").saveAsTable("Sales_Analytics.Fact_Ventas_Limpia")Comparativa: ¿Cuándo usar cada enfoque?
La decisión técnica no debe basarse en la preferencia personal, sino en los requisitos del proyecto y las Pruebas de rendimiento en Fabric Warehouse que hayamos realizado previamente.
| Criterio | SQL Analytics Endpoint | Notebooks (Spark) |
|---|---|---|
| Facilidad de uso | Alta (T-SQL estándar) | Media (Requiere Python/Scala) |
| Transformaciones | Relacionales y simples | Complejas, ML, limpieza avanzada |
| Rendimiento en grandes volúmenes | Bueno para consultas puntuales | Excelente (Escalado horizontal) |
| Persistencia de datos | Solo lectura (requiere Warehouse externo) | Escritura directa en Lakehouse (Parquet/Delta) |
| Orquestación | Vistas y stored procedures | Jobs de Spark y Pipelines |
Errores comunes en proyectos de Mirroring
A lo largo de múltiples implementaciones, he observado patrones que degradan el rendimiento y complican el mantenimiento del linaje de datos:
- No usar el esquema ‘Gold’: Muchos equipos exponen las tablas del Mirroring directamente a Power BI. Esto crea una dependencia técnica con el origen que impide realizar cambios en el modelo sin romper los informes.
- Ignorar el V-Order: El Mirroring escribe archivos Delta, pero no siempre están optimizados con V-Order (el algoritmo de compresión de Microsoft). Es recomendable realizar una operación de
OPTIMIZEmediante un Notebook periódicamente si las tablas son muy grandes. - Falta de filtrado en el origen: Intentar procesar toda la historia de una base de datos espejada de 10 años en cada ejecución. Siempre debemos trabajar con lógica incremental, incluso si el Mirroring es automático.
- Confundir Mirroring con Backup: El Mirroring no es una estrategia de recuperación ante desastres. Es una herramienta de integración de datos. Si se borra un dato en el origen, se borrará en Fabric casi instantáneamente.
Checklist para una implementación exitosa
- Verificar que el SQL Analytics Endpoint del Mirroring sea accesible desde el Workspace de destino.
- Definir una nomenclatura clara para distinguir entre tablas replicadas (Mirror) y tablas transformadas (Analytics).
- Crear vistas en el Warehouse para desacoplar el modelo de Power BI de la estructura física del Mirroring.
- Configurar alertas de capacidad en Fabric para monitorizar el consumo de CU (Capacity Units) de los Notebooks.
- Validar el linaje de datos en la vista de diagrama de Fabric para asegurar que no hay saltos lógicos inexplicables.
Preguntas frecuentes
¿El Mirroring consume capacidad de mi instancia de Fabric?
La replicación en sí (el movimiento de datos desde el origen a OneLake) no suele consumir unidades de capacidad (CU) de Fabric, ya que Microsoft ofrece este servicio como «gratuito» para incentivar el uso de la plataforma. Sin embargo, las consultas SQL y la ejecución de Notebooks sobre esos datos sí consumen CU de tu capacidad contratada.
¿Puedo unir tablas de dos bases de datos espejadas diferentes?
Sí, puedes realizar joins entre diferentes ítems de Mirroring utilizando sus nombres de base de datos completos en una consulta SQL dentro de un Warehouse, o montando ambos como tablas en un Notebook de Spark. Esta es una de las grandes ventajas de OneLake.
¿Qué pasa si el esquema de la base de datos de origen cambia?
El Mirroring de Fabric soporta la evolución del esquema (Schema Drift). Si añades una columna en el SQL Server de origen, esta aparecerá automáticamente en el Delta Lake de Fabric. No obstante, tendrás que actualizar tus vistas SQL o tus Notebooks manualmente si quieres que esa nueva columna fluya hacia el modelo de Power BI.
¿Es mejor usar Mirroring o Shortcuts para bases de datos en Azure?
Los Shortcuts solo funcionan para orígenes que ya están en formato Delta/Parquet (como ADLS Gen2 o S3). Para bases de datos relacionales como Azure SQL, el Mirroring es la opción correcta porque realiza la conversión de filas a columnas (Delta) de forma automática y eficiente.
