¿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.

¿Su dashboard de Tableau va lento cada vez que cambia un filtro?

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.

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

  1. Extraer la lógica existente

    Reúna los cálculos, joins y filtros que hoy viven en sus informes.

  2. 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.

  3. 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.

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

Matt Collett

Sales Director

¿Qué está buscando?

Al enviar acepta nuestra Política de Privacidad.

Otros problemas que cubre esta serie

  • Proliferación de fuentes de datos

    ¿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.

  • Expresiones LOD

    ¿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.

  • Fallos de actualización de extracts

    ¿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.