¿Su DAX de Power BI se está volviendo demasiado largo para mantenerlo?
Doscientas líneas de CALCULATE y FILTER no son señal de un DAX avanzado. Normalmente son señal de que el warehouse nunca le dio las claves, el historial o la granularidad que necesitaba.
La plataforma de automatización de data warehouse en la que confían equipos de datos de todos los sectores
¿Le suena familiar?
- Una sola medida supera ya las cien líneas y solo una persona la entiende.
- Los objetos visuales tardan de quince a cuarenta y cinco segundos, y siempre son las mismas tres medidas.
- Cambiar una medida rompe sin avisar cuatro objetos visuales de otra página.
- Escribe DAX para averiguar cuál era un valor el pasado marzo, no cuál es ahora.
Un DAX largo rara vez es un problema de DAX. Es estructura que faltaba en el origen, reconstruida en tiempo de consulta, con cada clic.
Qué hacen realmente las medidas largas
- Reconstruir el historial.
CALCULATEcon filtros de fecha, en lugar de una dimensión de cambio lento que el warehouse nunca guardó. - Resolver relaciones de muchos a muchos. Iteradores que resuelven una relación que no tiene tabla puente.
- Simular claves.
LOOKUPVALUEy columnas de texto concatenadas, porque no hay una clave subrogada con la que hacer el join. - Corregir la granularidad.
SUMXsobre una tabla filtrada, porque la tabla de hechos contiene dos granularidades a la vez.
Las cuatro se ejecutan por objeto visual, por filtro y por usuario. De ahí los quince a cuarenta y cinco segundos.
Por qué le toca a usted
- Nadie lo eligió. Cada medida fue el camino más corto hacia un objeto visual que funcionara esa semana.
- La lógica es invisible fuera del
.pbix, así que no se puede revisar ni reutilizar. - Puede reescribir la medida. No puede añadir la dimensión que necesita.
El trabajo está en el lugar equivocado
- Historial, claves, tablas puente y granularidad son trabajo del data warehouse. En DAX se reconstruyen con cada clic.
- Debe hacerse en un único lugar central: un data warehouse o un data hub, construido una vez y leído por todos los informes.
- Si eso le parece caro, probablemente la estimación parte de pipelines construidos a mano. Una plataforma de automatización especializada los genera a partir de un modelo, lo que cambia tanto el coste como el tiempo necesario.
Qué cambia cuando el modelo llega terminado
Datavault Builder genera las claves, el historial y la granularidad en el propio warehouse, sobre SQL Server, Azure SQL, Synapse, Fabric, Snowflake, Databricks o BigQuery.
- Las claves subrogadas son explícitas, así que las relaciones son reales y
LOOKUPVALUEdesaparece. - Las tablas point in time responden “cómo estaba en marzo” con un join, no con una medida.
- Las tablas puente resuelven las relaciones de muchos a muchos antes de que Power BI las vea.
- Una sola granularidad por tabla de hechos, así que
SUMsignifica lo que dice. - Las medidas se reducen a
SUM,AVERAGE,COUNT. Lo bastante cortas para que un colega pueda revisarlas.
Qué pedir
“Esta medida reconstruye el historial en tiempo de consulta porque la dimensión no está historizada. ¿Podemos tener una tabla point in time y claves subrogadas adecuadas en el warehouse, para que la medida sea un simple SUM?”
Así nombra lo que falta, en lugar de pedir que el informe sea más rápido.
Véalo funcionando con sus propios datos
Reserve una demo gratuita y traiga el informe que más problemas le da.
Tres pasos hacia cifras que cuadran
-
Extraer la lógica existente
Reúna los cálculos, joins y filtros que hoy viven en sus informes.
-
Centralizarla en un solo lugar
La lógica pasa una sola vez al modelo del warehouse, y todos los informes leen la misma definición.
-
Cifras que cuadran
Todos los informes muestran la misma cifra, y “de dónde sale esta cifra” tiene una respuesta visible.
Cómo Datavault Builder entrega a su informe un modelo terminado
-
El modelo llega terminado
Datavault Builder genera el vault y el star schema para que se ejecuten de forma nativa en la base de datos que ya tiene: SQL Server, Azure SQL, Synapse, Fabric, Snowflake, Databricks o BigQuery.
-
El trabajo sale del informe
Sin merge, sin parsing, sin fuzzy match. Ese trabajo desaparece del informe.
-
Las fuentes llegan integradas
Los clientes del ERP, el CRM y la tienda online se consolidan en un único conjunto de dimensiones conformadas. El join se hace una vez en el warehouse, no de nuevo en cada informe.
-
Historial que puede consultar
Cada cambio se conserva tal como llega, así que puede analizar tanto cómo era como cómo es, incluso cuando el sistema de origen sobrescribe sus propios registros.
-
Cada cifra tiene lineage
La lógica gana lineage, así que “de dónde sale esta cifra” tiene una respuesta visible.
-
Cambios gestionados en el origen
Las dimensiones de cambio lento se gestionan en el origen como satélites del vault, no por aproximación.
Caso de éxito: Porta
Reconocido por BARC en The Data Fabric Survey 26
Hable con nuestro experto
Veinte minutos con nuestro Sales Director y una respuesta honesta sobre si esto encaja con su situación.
Matt Collett
Sales Director
Perfecto, elija un horario que le venga bien:
Otros problemas que cubre esta serie
-
¿Sus informes de Power BI muestran cifras distintas para lo mismo?
Finanzas, Ventas y Operaciones construyeron cada uno su propio modelo semántico, y cada uno es coherente en sí mismo. Las definiciones nunca fueron erróneas en un lugar. Nunca se acordaron en ninguno.
-
¿Su informe DirectQuery de Power BI va lento con cada clic?
DirectQuery y Direct Lake prometen datos en vivo. Lo que obtiene es un objeto visual de treinta segundos y una factura de cómputo que nadie quiere explicar. El modo no es el problema. El esquema que tiene debajo sí lo es.
-
¿Su actualización de Power BI falla cada noche?
La actualización programada agota el tiempo de espera, Power Query se queda sin memoria y usted se entera cuando alguien abre el dashboard. La causa casi nunca es Power BI. Es lo que se le pide a Power BI que haga.