¿Sus expresiones LOD de Tableau son demasiado complejas para tocarlas?
FIXED, INCLUDE y EXCLUDE son herramientas precisas para preguntas genuinas con varias granularidades. La mayoría de las que hay en su libro de trabajo están ahí porque el warehouse nunca resolvió la granularidad ni guardó el historial.
¿Le suena familiar?
- Un libro de trabajo tiene una docena de expresiones FIXED y quitar cualquiera de ellas rompe una vista.
- Los cálculos se ralentizan de golpe en cuanto se combina una segunda fuente de datos.
- Usa LOD para reconstruir cuál era un valor en un momento determinado.
- Nadie salvo el autor original se atreve a tocar la pestaña de cálculos.
Las expresiones de nivel de detalle (LOD) son la respuesta correcta a una pregunta genuina con varias granularidades. También son el sitio donde acaba la solución cuando los datos llegan con la granularidad equivocada, y ese segundo tipo es el que vuelve frágil un libro de trabajo.
Qué están sustituyendo las expresiones LOD
- Un estado en un momento determinado.
FIXEDmás lógica de fechas, reconstruyendo el historial que el origen sobrescribió. - Una dimensión que falta.
FIXEDsobre una clave concatenada, porque no hay una real con la que hacer el join. - Dos granularidades en una tabla.
EXCLUDEpara deshacer una duplicación que una tabla de hechos bien diseñada nunca habría creado. - Una relación sin tabla puente.
INCLUDEhaciendo el trabajo de una tabla puente.
Cada una se evalúa en tiempo de consulta, por vista, y combinar fuentes multiplica el coste.
Por qué le toca a usted
- Cada una de ellas fue la ruta más rápida hacia una cifra correcta esa semana.
- Son invisibles para cualquiera fuera del libro de trabajo, así que no se pueden revisar ni reutilizar.
- Puede reestructurar el cálculo. No puede añadir la dimensión a la que está sustituyendo.
El trabajo está en el lugar equivocado
- Historial, claves y granularidad son trabajo del data warehouse. En las expresiones LOD se reconstruyen para cada vista.
- Debe hacerse en un único lugar central: un data warehouse o un data hub, construido una vez y leído por todos los libros de trabajo.
- 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 resuelve la granularidad, las claves y el historial en el warehouse, sobre Snowflake, Databricks, BigQuery, Synapse, SQL Server, Oracle, Exasol o PostgreSQL.
- Las tablas point in time responden “a fecha de marzo” con un join, no con una expresión.
- Las tablas puente resuelven las relaciones de muchos a muchos antes de que Tableau se conecte.
- Claves subrogadas explícitas, así que las relaciones sustituyen a la comparación de cadenas concatenadas.
- Una sola granularidad por tabla de hechos, lo que elimina directamente la mayor parte del trabajo de
EXCLUDE. - Lo que queda son preguntas LOD genuinas, y son lo bastante cortas para que un colega las lea.
Qué pedir
“Estas expresiones LOD reconstruyen el estado en un momento determinado y resuelven la granularidad en tiempo de consulta. ¿Puede el warehouse darnos una tabla PIT y una tabla de hechos con una sola granularidad, para que los cálculos sean agregaciones simples?”
Así distingue las LOD que realmente necesita de las LOD que usa como parche.
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.
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
-
¿Su Tableau Server tiene demasiadas versiones de la misma cifra?
Cada .tdsx publicado era razonable el día en que se creó. Juntos son cientos de definiciones privadas de la misma métrica, sin forma de saber cuál es la correcta.
-
¿Sus extracts de Tableau fallan al actualizarse o terminan tarde?
El backgrounder agota el tiempo de espera, el archivo .hyper no deja de crecer y el dashboard muestra los datos de ayer. El extract es grande porque arrastra filas en bruto que nunca se agregaron en el origen.
-
¿Su dashboard de Tableau va lento cada vez que cambia un filtro?
Veinte segundos de “Ejecutando consulta” con cada clic en un filtro. Tableau no está dibujando despacio. Está esperando a una base de datos a la que se le hizo una pregunta que no puede responder rápido.