Integración de Microsoft Purview con Fabric: Catálogo, linaje y etiquetas

En proyectos de Business Intelligence de escala media y grande, el caos suele ser el estado natural si no se interviene a tiempo. La facilidad con la que Microsoft Fabric permite crear Lakehouses, Warehouses y modelos semánticos es un arma de doble filo: por un lado, acelera la entrega; por otro, genera una proliferación de artefactos que nadie sabe quién creó, de dónde vienen o si contienen datos sensibles. Aquí es donde Microsoft Purview deja de ser una opción de «seguridad teórica» para convertirse en la pieza central de la arquitectura.

La integración entre Microsoft Purview y Fabric no es un simple conector externo. Es una simbiosis nativa donde los metadatos fluyen automáticamente para ofrecer una visión de gobierno que el administrador de Power BI nunca tuvo por sí solo. Como consultor, mi prioridad no es solo que los informes funcionen, sino que el equipo de IT pueda certificar que los datos de ‘Ventas’ en el informe final provienen realmente de la tabla original de ‘Pedidos’ del ERP, tras pasar por las capas correspondientes de transformación.

En este artículo abordamos cómo Microsoft Purview escanea los artefactos de Fabric, cómo configurar el linaje cross-tenant y por qué las etiquetas de sensibilidad son la única forma real de evitar fugas de información en un ecosistema SaaS tan abierto como Microsoft Fabric: La convergencia analítica SaaS y el fin de la integración manual.

El ecosistema unificado: Purview como cerebro del gobierno en Fabric

Microsoft Purview actúa como el mapa de carreteras de toda la finca de datos (Data Estate). En Fabric, esto se traduce en el Purview Hub, un punto de control integrado directamente en el portal de Fabric que permite monitorizar el estado del inventario. Sin embargo, para obtener el valor real, debemos hablar del Data Map de Purview. El Data Map es el que ingiere los metadatos de los elementos de OneLake, incluyendo tablas Delta, archivos Parquet y estructuras de metadatos de los almacenes de datos.

Escaneo automático y metadatos dinámicos

A diferencia de otras soluciones donde hay que programar scripts de extracción de metadatos, Purview detecta automáticamente los cambios en el tenant de Fabric. Cuando un ingeniero de datos crea un nuevo Lakehouse en un espacio de trabajo, Purview lo identifica. Esto es vital para mantener la Calidad y Trazabilidad en el gobierno de datos para IA generativa, donde los modelos de lenguaje necesitan alimentarse de fuentes certificadas y no de réplicas obsoletas.

El proceso de escaneo captura:

• Esquema de tablas: Nombres de columnas, tipos de datos y restricciones.
• Clasificaciones: Identificación automática de datos personales (GDPR), tarjetas de crédito o direcciones de correo.
• Propiedades de los artefactos: Propietario del espacio de trabajo, fecha de última modificación y etiquetas de descripción.

Linaje de datos end-to-end: De la fuente externa al informe

El linaje es, sin duda, la característica más demandada. En un entorno típico de Fabric, los datos fluyen a través de múltiples etapas. Imagina este flujo: un Azure SQL Database es ingerido mediante un Pipeline hacia un Lakehouse (Bronze), luego transformado mediante un Notebook de Spark hacia otra capa (Silver) y finalmente servido en un Warehouse (Gold) para ser consumido por Power BI.

Sin Purview, verías el linaje dentro de cada espacio de trabajo de Power BI, pero perderías el rastro en cuanto el dato sale hacia un Notebook o cruza a otro workspace. Purview rompe estos silos. Al conectar ambos servicios, el gráfico de linaje muestra cada salto. Esto permite realizar un análisis de impacto: si modifico la columna ImporteNeto en la tabla de hechos del Warehouse, Purview me dirá exactamente qué informes de Power BI y qué modelos semánticos se verán afectados.

-- Ejemplo de consulta en el Warehouse para validar metadatos que Purview leerá
-- Identificamos tablas y sus últimas actualizaciones para el catálogo
SELECT 
 s.name AS Esquema, 
 t.name AS NombreTabla, 
 t.create_date AS FechaCreacion,
 t.modify_date AS FechaModificacion
FROM sys.tables t
JOIN sys.schemas s ON t.schema_id = s.schema_id
WHERE s.name = 'Sales_Gold';
-- Purview usará estos metadatos para indexar el catálogo

Arquitectura Medallón y Purview: Trazabilidad en cada capa

En mis proyectos, siempre implemento una arquitectura medallón en Fabric. Purview es el complemento perfecto para este patrón porque permite etiquetar cada capa con un propósito específico. No es lo mismo un dato en ‘Bronce’ que está en bruto (Raw), que un dato en ‘Oro’ que ya es una métrica de negocio lista para el CEO.

Clasificación de datos en el Lakehouse

Cuando los datos aterrizan en OneLake, Purview aplica reglas de clasificación. Por ejemplo, si una tabla en el Lakehouse contiene una columna con formatos de DNI español o números de la seguridad social, Purview la marcará automáticamente. Esto permite a los administradores de datos crear alertas o políticas de acceso restringido antes de que los datos lleguen siquiera a la capa de visualización.

Clasificación y Etiquetas de Sensibilidad (MIP)

La integración con Microsoft Information Protection (MIP) es el pilar de la seguridad. Las etiquetas de sensibilidad definidas en Purview (como «Altamente Confidencial») se propagan a lo largo de todo el ciclo de vida del dato en Fabric. Si etiquetas una tabla en el Warehouse como confidencial, el modelo semántico de Power BI que hereda de esa tabla mantendrá la etiqueta. Incluso si un usuario descarga el informe a un archivo .pbix o lo exporta a Excel, la protección (cifrado) viaja con el archivo.

Esto es crítico en sectores como el retail o la industria, donde los márgenes de beneficio o los datos de clientes no deben salir del ecosistema corporativo. En el ecosistema de OneLake de Microsoft Fabric, esta protección es nativa y no requiere configuraciones manuales complejas por cada informe.

# Ejemplo de cómo un Notebook de Fabric puede interactuar con datos etiquetados
# Purview rastrea la ejecución de este código para el linaje
from pyspark.sql import functions as F

# Cargamos tabla de Ventas desde el Lakehouse
df_ventas = spark.read.table("Sales_Silver.FactVentas")

# Realizamos una agregación crítica para el negocio
df_resumen = df_ventas.groupBy("ID_Producto").agg(
 F.sum("Importe").alias("Total_Ventas"),
 F.count("ID_Pedido").alias("Num_Pedidos")
)

# Guardamos en la capa Gold. Purview registrará este Notebook como 
# el puente de linaje entre Silver y Gold.
df_resumen.write.mode("overwrite").saveAsTable("Sales_Gold.ResumenProductos")

Errores frecuentes en la integración Purview-Fabric

Tras implementar esta solución en varios clientes, he detectado patrones de error que se repiten y que pueden arruinar la confianza en el catálogo:

1. Falta de permisos del Service Principal: Purview necesita permisos explícitos de lectura de metadatos en el tenant de Fabric. Si no se configuran correctamente en el portal de administración, los escaneos fallarán silenciosamente.
2. Ignorar el linaje manual: Purview es excelente capturando flujos automáticos, pero si haces movimientos de datos mediante APIs personalizadas o scripts fuera del ecosistema soportado, el linaje se romperá. Hay que usar el SDK de Purview para reportar estos saltos manuales.
3. Etiquetado excesivo: Aplicar etiquetas de «Confidencial» a todo el Lakehouse por miedo acaba provocando que los usuarios ignoren las advertencias. Hay que definir una política de clasificación clara.
4. No sincronizar el Purview Hub: A veces los cambios en Fabric tardan en reflejarse en el catálogo central de Purview. No entender los tiempos de latencia del escaneo genera reportes de inventario inconsistentes.
5. Descuidar los metadatos de Power Query: Aunque Purview lee el linaje, los pasos específicos dentro de una consulta de Power Query a veces quedan ocultos si no se usan conectores estándar.

Consideraciones de coste y rendimiento

Microsoft Purview no es gratuito y su modelo de precios se basa en unidades de capacidad (CUs) y en el volumen de metadatos escaneados. En proyectos de tamaño medio, el coste es asumible comparado con el riesgo de una brecha de datos o el coste de no encontrar la información (tiempo perdido por los analistas).

Sin embargo, para optimizar el gasto, recomiendo:

• Escaneos selectivos: No es necesario escanear cada hora espacios de trabajo de desarrollo o sandbox personales.
• Filtros de ámbito: Configura el escaneo para que solo incluya los espacios de trabajo de producción y pre-producción.
• Uso del Purview Hub: Aprovecha las vistas gratuitas dentro de Fabric antes de saltar a la consola completa de Purview para tareas básicas.

Conclusión y Checklist

La integración de Purview con Fabric no es solo una tarea de IT; es una decisión estratégica. Sin un catálogo claro y un linaje confiable, Fabric se convierte en un OneLake lleno de basura digital. La capacidad de ver cómo un dato fluye desde una tabla de SQL hasta un KPI en el móvil de un directivo es lo que separa un proyecto de BI maduro de un simple conjunto de dashboards.

Checklist de implementación:

• Habilitar la comunicación entre Purview y Fabric en el Tenant Settings de la consola de administración de Fabric.
• Asignar roles de «Data Reader» de Purview a la identidad que realizará los escaneos.
• Definir al menos 3 etiquetas de sensibilidad (Público, Interno, Confidencial) y configurar su propagación automática.
• Verificar que el linaje aparece correctamente tras ejecutar un Pipeline de datos de prueba.
• Capacitar a los Data Stewards en el uso del glosario de términos de Purview para enriquecer los metadatos técnicos.

Preguntas frecuentes

¿Necesito una licencia de Purview para cada usuario de Fabric?

No, el licenciamiento de Purview es a nivel de capacidad y escaneo de metadatos. Los usuarios que consultan el catálogo o el linaje no requieren una licencia individual de Purview, pero sí los permisos adecuados de RBAC dentro de la plataforma.

¿Puede Purview ver el código dentro de mis Notebooks de Fabric?

Purview analiza los metadatos de ejecución para determinar el linaje (qué tablas lee y escribe el Notebook), pero no realiza una auditoría de código línea por línea ni almacena la lógica de negocio interna del script de Python o Scala.

¿Qué pasa con el linaje si uso Direct Lake?

El linaje se mantiene perfectamente. Purview identifica que el modelo semántico está conectado mediante Direct Lake al Lakehouse original, manteniendo la trazabilidad sin necesidad de procesos de refresco intermedios que compliquen el gráfico de linaje.

¿Es compatible Purview con nubes híbridas en Fabric?

Sí, Purview puede escanear fuentes que están fuera de Azure (como AWS S3 o bases de datos on-premise) y conectarlas con el linaje de Fabric si se utilizan los Integration Runtimes adecuados, ofreciendo una visión híbrida real.