¿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.
La plataforma de automatización de data warehouse en la que confían equipos de datos de todos los sectores
¿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.
Tableau no es la parte lenta. VizQL convierte cada interacción en SQL, y lo que tarda depende por completo de la forma de lo que consulta.
Qué se le pide a VizQL
- Contra un star schema: una tabla de hechos y unos pocos joins con dimensiones sobre claves reales. Responde en milisegundos.
- Contra tablas en 3NF o en bruto: joins entre una docena de tablas, reconstruidos en cada marca, 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 blends eran la única forma de que funcionara, y hacen cada consulta más pesada.
- Puede optimizar el libro de trabajo. No puede volver a modelar el origen.
El trabajo está en el lugar equivocado
- Unir tablas en bruto en algo analizable es trabajo del data warehouse. VizQL lo repite con cada cambio de filtro.
- 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 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, dimensiones conformadas. VizQL emite SQL corto por construcción.
- 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 hace joins entre tablas normalizadas con cada clic en un filtro, así que el tiempo de consulta crece con los datos. ¿Podemos tener un star schema al que se conecte este dashboard en lugar de las 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 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.
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
-
¿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 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.
-
¿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.