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.
