¿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.
¿Le suena familiar?
- Cambiar un filtro deja "Ejecutando consulta" en pantalla durante veinte segundos o más.
- La grabación de rendimiento muestra casi todo el tiempo en la ejecución de consultas y apenas nada en el renderizado.
- El dashboard va bien con un trimestre de datos y es inutilizable con tres años.
- Ha empezado a ocultar filtros para que la gente no active el camino lento.
Un dashboard de Tableau no es intrínsecamente lento. VizQL convierte cada interacción en SQL, y el tiempo de respuesta depende por completo de la estructura y el modelado de los datos subyacentes.
Qué se le pide a VizQL
- Frente a un star schema (esquema en estrella): una tabla de hechos y unos pocos joins con dimensiones sobre claves subrogadas reales. Responde en milisegundos.
- Frente a tablas operativas en 3NF o datos en bruto: joins costosos entre una docena de tablas, recalculados con cada marca visual, cada filtro y cada usuario.
- Nada sobre lo que indexar. Las tablas operativas están indexadas para transacciones, no para las columnas por las que agrupan los analistas.
- Se acumula. Cada hoja del dashboard lanza su propia consulta.
Por qué le toca a usted
- La fuente de datos que le dieron es la que existía, no una construida para el análisis.
- El SQL personalizado y los data blends fueron la única alternativa para salir del paso, pero vuelven cada consulta mucho más pesada.
- Puede optimizar el libro de trabajo. No puede volver a modelar el origen.
El trabajo está en el lugar equivocado
- Transformar y unir tablas en bruto para el análisis corresponde al data warehouse. VizQL se ve obligado a repetirlo con cada cambio de filtro.
- Deben resolverse en un único punto central: un data warehouse o data hub, procesados una sola vez y leídos por todos los libros de trabajo (workbooks).
- 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 hechos y dimensiones de forma nativa en Snowflake, Databricks, BigQuery, Synapse, SQL Server, Oracle, Exasol o PostgreSQL, pensados para el acceso analítico.
- Una tabla de hechos y dimensiones conformadas: VizQL genera consultas SQL compactas y eficientes por diseño.
- Claves reales, así que los joins son de una sola columna en lugar de comparaciones de cadenas entre varios campos.
- Una sola granularidad por tabla, lo que elimina las filas duplicadas que inflan los escaneos.
- Las conexiones en vivo siguen siendo utilizables, así que un extract es una elección y no una vía de escape.
- Los filtros responden lo bastante rápido como para volver a ponerlos en el dashboard.
Qué pedir
“VizQL ejecuta joins entre tablas normalizadas con cada clic en un filtro, por lo que el tiempo de consulta se dispara al crecer los datos. ¿Podemos disponer de un star schema al que se conecte este dashboard en lugar de apuntar a tablas operativas?”
Así nombra el mecanismo y señala la capa donde se puede solucionar.
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 consultar tanto el estado histórico como el actual, 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 archivo .tdsx publicado era una decisión razonable el día en que se creó. Juntos forman cientos de definiciones aisladas de la misma métrica, sin forma de saber cuál es la fidedigna.
-
¿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 data warehouse nunca resolvió la granularidad ni conservó el historial.
-
¿Sus extracts de Tableau fallan al actualizarse o terminan tarde?
El Backgrounder de Tableau 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.