Guía - DP-600 Microsoft Fabric Analytics Engineer Associate

Consultar una tabla Delta masiva (más de 500 millones de filas) en un lakehouse de Fabric con un rendimiento óptimo y acceso a datos casi en tiempo real.

Usar un modelo semántico en modo Direct Lake.

Por qué: Direct Lake lee archivos Parquet directamente desde OneLake, evitando la importación de datos o la traducción de consultas. Proporciona un rendimiento similar al de la importación sin duplicación de datos ni latencia de actualización. DirectQuery es más lento; el modo Importar introduce latencia.

Aplicar cálculos comunes de inteligencia de tiempo (YTD, QTD, MTD) a docenas de medidas base (Ventas, Ganancia, Cantidad) sin crear cientos de medidas DAX.

Implementar un grupo de cálculo con elementos de cálculo para YTD, QTD y MTD.

Por qué: Los grupos de cálculo eliminan la proliferación de medidas. Definen un conjunto de cálculos genéricos que se pueden aplicar dinámicamente a cualquier medida seleccionada, simplificando drásticamente el mantenimiento del modelo.

Varios modelos semánticos en un espacio de trabajo necesitan compartir tablas de dimensiones comunes (por ejemplo, Fecha, Cliente) para asegurar la coherencia y reducir la duplicación de datos.

Crear un modelo semántico "central" que contenga las dimensiones compartidas. Construir otros modelos "compuestos" que se conecten al modelo central a través de DirectQuery y a las tablas de hechos a través de Direct Lake/Import.

Por qué: Esta arquitectura de "hub and spoke" promueve una única fuente de verdad para las dimensiones. Los modelos compuestos permiten combinar datos de diferentes fuentes y modos de almacenamiento en un modelo unificado.

Una tabla de hechos tiene varias columnas de fecha (por ejemplo, OrderDate, ShipDate) que deben relacionarse con una única tabla de dimensiones de Fecha.

Crear una relación activa y varias relaciones inactivas entre la tabla de hechos y las tablas de fecha. Usar la función DAX `USERELATIONSHIP()` en las medidas para activar la relación inactiva apropiada.

Por qué: Power BI solo permite una relación activa entre dos tablas. Este patrón permite el análisis por diferentes roles de fecha sin duplicar la tabla de dimensiones.

Un modelo semántico con una tabla de hechos grande (miles de millones de filas) tarda demasiado en actualizarse. Solo los últimos 30 días de datos cambian con frecuencia.

Configurar la actualización incremental en la tabla de hechos. Establecer los parámetros `RangeStart` y `RangeEnd`. Definir una política para archivar datos antiguos (por ejemplo, almacenar los últimos 5 años) y actualizar datos recientes (por ejemplo, actualizar los últimos 30 días).

Por qué: Esto reduce drásticamente el tiempo de actualización y el consumo de recursos al procesar solo las particiones que contienen datos nuevos o modificados, en lugar de recargar la tabla completa.

Una medida DAX compleja es lenta porque calcula repetidamente el mismo valor intermedio dentro de su fórmula.

Usar variables (`VAR`) para almacenar el resultado del cálculo intermedio una vez, luego referenciar la variable varias veces en la declaración `RETURN`.

Por qué: Las variables evitan que el motor reevalúe la misma lógica varias veces dentro de una única ejecución de medida, lo que mejora significativamente el rendimiento, especialmente en contextos iterativos.

Crear una medida para calcular el porcentaje de contribución de un valor (por ejemplo, ventas de productos) a un total mayor (por ejemplo, todas las ventas de productos), respetando otros filtros (como la fecha).

Usar `DIVIDE([Sales], CALCULATE([Sales], ALLEXCEPT(Product, Product[Category])))` para el porcentaje de la categoría o `CALCULATE([Sales], ALL(Product))` para el porcentaje del total general.

Por qué: `CALCULATE` combinado con `ALL`, `ALLEXCEPT` o `REMOVEFILTERS` permite modificar el contexto de filtro para obtener el denominador correcto para el cálculo del porcentaje.

Un informe necesita una segmentación que permita a los usuarios elegir qué métrica (por ejemplo, "Ingresos", "Costo", "Beneficio") debe mostrar un visual.

Crear una tabla desconectada con los nombres de las métricas. Crear una única medida DAX usando `SWITCH(SELECTEDVALUE(MetricTable[Metric]), "Revenue", [Total Revenue], "Cost", [Total Cost], ...)`

Por qué: Este patrón, a menudo usando un Parámetro de Campo, proporciona una forma dinámica y fácil de usar para cambiar cálculos sin necesidad de marcadores o múltiples visuales, haciendo los informes más interactivos y concisos.

Un equipo de BI empresarial necesita usar herramientas profesionales (como Visual Studio, Tabular Editor, SQL Profiler) para gestionar, implementar y solucionar problemas de un modelo semántico de Fabric.

Habilitar el endpoint XMLA de lectura/escritura para el espacio de trabajo.

Por qué: El endpoint XMLA expone el modelo semántico como una instancia estándar de Analysis Services, habilitando la conectividad desde un amplio ecosistema de herramientas avanzadas de BI y ALM para acceso programático y tareas de modelado complejas.

Un modelo Direct Lake está funcionando lentamente. La investigación revela que está volviendo al modo DirectQuery.

Usar DAX Studio o Performance Analyzer para identificar la consulta que causa el fallback. Las causas comunes incluyen funciones DAX no compatibles, RLS complejo o un lakehouse no optimizado/obsoleto.

Por qué: Direct Lake tiene limitaciones. Cuando una consulta utiliza una característica no compatible, recurre silenciosamente al motor DirectQuery más lento. Identificar y corregir la causa raíz (por ejemplo, optimizar DAX, ejecutar OPTIMIZE en la tabla Delta) es clave para restaurar el rendimiento.

Un modelo tiene una relación de muchos a muchos (por ejemplo, Ventas y Promociones a través de una tabla puente). Las medidas devuelven totales incorrectos al filtrar por el lado "muchos".

Asegurar que la dirección del filtro cruzado en las relaciones (Dimensión -> Puente -> Hecho) esté configurada correctamente (típicamente unidireccional). Usar funciones DAX como `TREATAS` o `INTERSECT` para cálculos M2M más complejos si es necesario.

Por qué: Una dirección de filtro cruzado incorrecta es una causa común de resultados incorrectos en los modelos M2M. Si bien el filtrado bidireccional puede parecer que funciona, a menudo conduce a ambigüedad y doble conteo. Un modelo bien definido con patrones DAX explícitos es más robusto.

Un modelo compuesto que utiliza DirectQuery contra una tabla de hechos masiva es lento. La mayoría de las consultas de los usuarios están a un nivel agregado (por ejemplo, ventas mensuales por categoría).

Crear una tabla de agregación definida por el usuario en modo Importar. La tabla de agregación debe contener datos pre-resumidos al nivel de las consultas comunes (Mes, Categoría).

Por qué: El motor de consultas redirigirá automáticamente las consultas a la tabla de agregación más pequeña y en memoria cuando sea posible, proporcionando enormes ganancias de rendimiento. Solo accederá a la fuente de DirectQuery para consultas que requieran un nivel de detalle inferior.

Calcular totales acumulados complejos o promedios móviles en DAX que están funcionando mal con enfoques tradicionales basados en filtros.

Usar funciones de ventana DAX como `WINDOW` o `OFFSET`.

Por qué: Estas funciones están específicamente optimizadas para cálculos posicionales sobre un conjunto ordenado de filas. A menudo son más eficientes y sintácticamente más simples que los patrones antiguos que dependen de un filtrado intensivo y transiciones de contexto.

Calcular totales de Año hasta la Fecha (YTD) para una empresa con un año fiscal que comienza el 1 de julio.

Usar las funciones `TOTALYTD` o `DATESYTD` con el parámetro opcional `YearEndDate`. Ejemplo: `TOTALYTD([Sales], 'Date'[Date], "6/30")`

Por qué: Especificar el parámetro de fecha de fin de año es la forma correcta y más sencilla de hacer que las funciones de inteligencia de tiempo DAX sean conscientes del calendario fiscal personalizado.

Promover un modelo semántico a través de las etapas de Desarrollo, Prueba y Producción donde cada etapa tiene una cadena de conexión de base de datos diferente.

Usar pipelines de implementación de Fabric con reglas de implementación.

Por qué: Las reglas de implementación automatizan la modificación de las conexiones a fuentes de datos, parámetros y otras configuraciones para cada entorno. Esto evita cambios manuales y propensos a errores después de la implementación.

Referencia

Implementar una arquitectura de malla de datos descentralizada donde los dominios de negocio poseen y gestionan sus propios productos de datos.

Crear espacios de trabajo específicos del dominio. Usar accesos directos de OneLake para habilitar el intercambio y consumo de datos entre dominios sin centralizar la propiedad de los datos.

Por qué: Este patrón se alinea con los principios de la malla de datos de propiedad del dominio y datos como producto. Los espacios de trabajo proporcionan el límite de propiedad, mientras que los accesos directos proporcionan la capa de interoperabilidad.

Un equipo de desarrolladores necesita colaborar en elementos de Fabric (modelos semánticos, informes, notebooks) con control de código fuente e historial de versiones.

Configurar la integración de Git para el espacio de trabajo de Fabric, conectándolo a un repositorio de Azure DevOps o GitHub.

Por qué: La integración de Git almacena las definiciones de los elementos de Fabric como archivos de texto (JSON, TMDL), lo que permite prácticas DevOps estándar como branching, pull requests y seguimiento de versiones. Esto es esencial para la Gestión del Ciclo de Vida de las Aplicaciones (ALM) a nivel empresarial.

Antes de cambiar una tabla de lakehouse, un ingeniero debe identificar todos los informes y modelos semánticos descendentes que se verán afectados.

Usar la Vista de Linaje y seleccionar "Análisis de impacto" en el elemento del lakehouse.

Por qué: Esta característica proporciona una vista completa y automatizada de todas las dependencias. Es una herramienta de gobernanza crítica para gestionar cambios en un entorno de análisis complejo, previniendo interrupciones inesperadas.

Un equipo necesita controlar la versión de un modelo semántico en un formato basado en texto, legible para humanos, que sea fácil de comparar y fusionar.

Guardar el archivo de Power BI como un Proyecto de Power BI (.pbip). Esto almacena la definición del modelo en el formato Tabular Model Definition Language (TMDL).

Por qué: TMDL es un formato amigable para desarrolladores que representa el modelo como una estructura de carpetas con archivos de texto individuales para tablas, medidas, etc. Esto es muy superior al archivo binario .bim para la colaboración basada en Git y CI/CD.

Implementar una arquitectura de medallón (Bronze, Silver, Gold) y necesitar acceder a los datos a través de las capas sin duplicación física de datos.

Usar accesos directos de OneLake para referenciar datos en otros lakehouses o capas.

Por qué: Los accesos directos son enlaces simbólicos en OneLake. Proporcionan un espacio de nombres unificado y permiten el acceso a los datos sin copiarlos, lo que es ideal para una malla de datos lógica o una arquitectura de medallón.

Referencia

Migrar una carga de trabajo analítica existente con gran cantidad de T-SQL de Azure Synapse a Fabric.

Usar un Fabric Data Warehouse.

Por qué: Fabric Warehouse ofrece compatibilidad total con T-SQL, lo que lo convierte en el objetivo ideal para migrar scripts SQL existentes, procedimientos almacenados y consultas de analistas con cambios mínimos. El punto de conexión SQL de Lakehouse tiene acceso T-SQL de solo lectura y utiliza Spark SQL para las escrituras.

Ingerir y consultar datos de streaming de alto volumen y alta velocidad (por ejemplo, telemetría de IoT) con latencia inferior a un segundo.

Usar Fabric Eventstream para la ingesta y una Base de Datos KQL para el almacenamiento y análisis.

Por qué: Esta es la pila de análisis de streaming creada específicamente en Fabric. KQL (Kusto Query Language) está optimizado para el análisis de series de tiempo en datos de streaming, ofreciendo una latencia mucho menor que los lakehouses o warehouses orientados a lotes.

Implementar Dimensión de Cambio Lento (SCD) Tipo 2 para mantener un historial completo de cambios de dimensión en un lakehouse.

Usar una declaración `MERGE INTO` en un notebook o pipeline de Spark. Coincidir con la clave de negocio; `WHEN MATCHED` actualiza el registro antiguo (establece `IsCurrent` en falso, `EndDate` a la fecha actual); `WHEN NOT MATCHED` inserta el nuevo registro.

Por qué: La operación `MERGE` de Delta Lake proporciona capacidades atómicas de upsert, lo que la convierte en la forma estándar y más eficiente de implementar la lógica SCD en un lakehouse de Fabric.

Replicar datos casi en tiempo real desde una base de datos operativa (por ejemplo, Azure SQL DB) a un lakehouse de Fabric para análisis.

Usar Fabric Mirroring.

Por qué: Mirroring es una solución de captura de datos modificados (CDC) de baja latencia y bajo impacto integrada en Fabric. Replica automáticamente los cambios de datos y esquema en OneLake como tablas Delta, eliminando la necesidad de pipelines ETL complejos.

Ingerir y transformar datos JSON complejos y anidados de una API en una tabla Delta aplanada y estructurada.

Usar un notebook de PySpark. Usar funciones como `from_json` para analizar el esquema, y `explode` para aplanar arrays en filas.

Por qué: PySpark proporciona las herramientas más potentes y flexibles para manejar estructuras JSON complejas y cambiantes de forma programática, mucho más allá de las capacidades de una actividad de copia estándar.

Ingerir datos en Fabric desde una base de datos SQL Server local que está detrás de un firewall corporativo.

Instalar y configurar una puerta de enlace de datos local en un servidor dentro de la red local. Añadir la puerta de enlace como fuente de datos en Fabric.

Por qué: La puerta de enlace actúa como un puente seguro, retransmitiendo consultas y datos entre los servicios en la nube de Fabric y las fuentes de datos locales sin requerir que se abran puertos de firewall de entrada.

El rendimiento de las consultas en una tabla Delta grande y frecuentemente actualizada se ha degradado debido a la acumulación de muchos archivos de datos pequeños.

Ejecutar el comando `OPTIMIZE` para compactar archivos pequeños en archivos más grandes. Opcionalmente, usar `ZORDER BY` en columnas frecuentemente filtradas para co-localizar datos relacionados.

Por qué: Menos archivos y más grandes son significativamente más eficientes para que Spark los lea. La ordenación Z mejora la omisión de datos, permitiendo que las consultas lean aún menos datos. Esta es una tarea de mantenimiento crítica para las tablas Delta.

Agregando datos de series de tiempo en streaming en intervalos de tiempo fijos y no superpuestos (por ejemplo, temperatura promedio por sensor cada 5 minutos).

Usar una consulta KQL con el operador `summarize` y la función `bin()`. Ejemplo: `SensorData | summarize avg(temperature) by sensor_id, bin(timestamp, 5m)`

Por qué: La función `bin()` es la forma estándar y altamente optimizada en KQL para agrupar eventos en cubos de tiempo fijos (ventanas de tiempo discretas) para la agregación.

Una actualización de Dataflow Gen2 es lenta. La fuente de datos es una base de datos relacional como Azure SQL.

Revisar los pasos de transformación en el editor de Power Query para asegurar que el plegado de consultas (query folding) esté activo. Reordenar o modificar pasos para maximizar el plegado.

Por qué: El plegado de consultas (query folding) empuja la lógica de transformación de vuelta a la base de datos de origen para ser ejecutada como una única consulta nativa. Esto es mucho más eficiente que extraer todos los datos brutos al motor del dataflow y transformarlos en memoria.

Un notebook de Spark está realizando una unión lenta entre una tabla de hechos muy grande (miles de millones de filas) y una tabla de dimensiones pequeña (miles de filas).

Usar una unión de broadcast (difusión) proporcionando una sugerencia (`spark.sql.functions.broadcast`) o dejando que el optimizador elija basándose en estadísticas.

Por qué: La difusión envía la tabla pequeña completa a cada nodo ejecutor. Esto evita una costosa operación de "shuffle" donde los datos de la tabla grande deben ser reparticionados y enviados a través de la red, mejorando drásticamente el rendimiento.

Un pipeline de datos orquesta múltiples actividades. Una actividad podría fallar, pero las actividades subsiguientes e independientes aún deberían ejecutarse, y el fallo general debería registrarse.

Configurar dependencias de actividad. Las actividades que deben ejecutarse independientemente del resultado deben depender de la actividad anterior con la condición "Finalización".

Por qué: Esto permite construir rutas de ejecución robustas y paralelas. Se pueden crear ramas separadas para las condiciones "Correcto" y "Fallido" para implementar lógica de registro o notificación personalizada.

Un pipeline para cargar datos incrementalmente desde una fuente con una marca de tiempo `last_modified`.

Implementar un patrón de marca de agua. Almacenar el `max(last_modified)` de la última ejecución exitosa. En la siguiente ejecución, consultar la fuente para registros donde `last_modified` sea mayor que la marca de agua almacenada.

Por qué: Este es el patrón más eficiente para cargas incrementales desde fuentes que proporcionan una marca de tiempo de modificación, asegurando que solo se procesen datos nuevos o actualizados, minimizando la transferencia de datos y el cómputo.

Analizar un flujo de datos IoT en tiempo real para detectar picos o caídas inusuales en las lecturas de los sensores.

Usar la función `series_decompose_anomalies()` en una consulta KQL dentro de un Eventhouse/KQL Database.

Por qué: Esta función KQL integrada está diseñada específicamente para la detección de anomalías en series de tiempo. Descompone automáticamente la serie en componentes estacionales, de tendencia y residuales para identificar valores atípicos estadísticamente significativos, requiriendo una configuración manual mínima.

Necesidad de unir datos de un Warehouse, un Lakehouse y una base de datos Azure SQL replicada en una única consulta T-SQL sin mover datos.

Usar convenciones de nomenclatura de tres partes (`database.schema.table`) en una consulta ejecutada desde el endpoint SQL del Warehouse o Lakehouse. Usar accesos directos para referenciar la base de datos replicada.

Por qué: Fabric proporciona un motor de consultas unificado que puede acceder a datos de diferentes elementos de Fabric dentro del mismo espacio de trabajo utilizando una única declaración SQL, habilitando la virtualización de datos.

Un dataflow necesita procesar un archivo donde algunas filas pueden ser inválidas. El flujo completo no debe fallar; las filas válidas deben cargarse y las filas inválidas deben registrarse.

En Power Query, añadir un paso para validar filas y crear una columna "IsValid". Luego, crear dos consultas de referencia a partir de ese punto: una que filtre por `IsValid = true` para cargar al destino, y otra que filtre por `IsValid = false` para cargar a un registro de errores.

Por qué: Este patrón proporciona un manejo robusto de errores al dividir el flujo de datos. Evita que unas pocas filas incorrectas detengan todo el proceso y proporciona un mecanismo claro para auditar problemas de calidad de datos.

Implementar seguridad a nivel de fila (RLS) donde los usuarios solo deben ver los datos correspondientes a su identidad (por ejemplo, un gerente de ventas solo ve sus tiendas).

Crear una tabla de seguridad que mapee usuarios a entidades de datos. En el rol RLS, usar una expresión de filtro DAX como `[ManagerEmail] = USERPRINCIPALNAME()`

Por qué: RLS dinámico es escalable. Utiliza un enfoque basado en datos en lugar de crear un rol estático para cada persona o entidad. `USERPRINCIPALNAME()` resuelve correctamente la identidad de Azure AD.

Ocultar columnas sensibles o tablas completas (por ejemplo, Salario) a un grupo específico de usuarios mientras se les permite acceder al resto del modelo semántico.

Definir roles de seguridad y configurar la Seguridad a Nivel de Objeto (OLS) usando una herramienta externa como Tabular Editor para establecer los permisos de tabla/columna en "Ninguno".

Por qué: OLS proporciona un control granular sobre la visibilidad de los metadatos del modelo. A diferencia de RLS que filtra filas, OLS oculta el objeto completo. Debe configurarse a través del endpoint XMLA.

Los usuarios reportan un rendimiento lento y estrangulamiento en Fabric. El administrador necesita identificar la causa raíz.

Usar la aplicación Fabric Capacity Metrics.

Por qué: Esta aplicación proporciona información detallada sobre el consumo de unidades de capacidad (CU), eventos de estrangulamiento y uso de recursos por tipo de carga de trabajo (por ejemplo, consulta de modelo semántico, actualización de dataflow). Es la herramienta principal para la monitorización del rendimiento y la planificación de la capacidad.

Hacer cumplir una política de clasificación de datos donde los informes y paneles heredan automáticamente la etiqueta de sensibilidad del modelo semántico al que se conectan.

Habilitar la configuración del inquilino para la herencia descendente de las etiquetas de sensibilidad.

Por qué: Esto automatiza la gobernanza de datos, asegurando que las protecciones aplicadas a la fuente de datos (por ejemplo, "Altamente Confidencial") se apliquen consistentemente en todo el contenido descendente, reduciendo el riesgo de fuga de datos.

En un Fabric Warehouse, los usuarios generales deben ver datos PII enmascarados (por ejemplo, `XXX-XX-1234`), mientras que los usuarios privilegiados ven los datos completos y sin enmascarar.

Aplicar Dynamic Data Masking (DDM) en las columnas sensibles en el Warehouse. Otorgar permisos `UNMASK` a los roles de usuario privilegiados.

Por qué: DDM es una característica de seguridad a nivel de base de datos que redacta datos sobre la marcha según los permisos del usuario. Protege los datos sensibles en su lugar sin requerir vistas separadas o copias de los datos.