¿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.
La plataforma de automatización de data warehouse en la que confían equipos de datos de todos los sectores
¿Le suena familiar?
- Las actualizaciones programadas fallan en Tableau Cloud o Server por un timeout del backgrounder.
- El archivo .hyper ha crecido hasta decenas de gigabytes y nadie lo había previsto.
- Las actualizaciones se mueven a las 02:00, luego a la 01:00, y aun así se alargan hasta la mañana.
- Alguien pregunta por qué el dashboard muestra los datos de ayer y la respuesta es complicada.
Un extract debería ser una copia rápida de una tabla terminada. Cuando falla, suele ser porque no está copiando una tabla terminada, sino construyéndola.
Por qué el extract es tan grande
- Arrastra columnas que nadie usa, porque era más fácil llevarse la tabla entera.
- La transformación ocurre durante la creación. Joins, campos calculados y blends se resuelven mientras se construye el extract, y eso es lo que agota el backgrounder.
- Crece sin parar. Una actualización completa de un origen que crece es más lenta cada mes, hasta que supera el timeout.
Por qué le toca a usted
- La vista optimizada que necesitaba no estaba disponible, así que el extract se convirtió en el paso de agregación.
- La capacidad del backgrounder no depende de usted, y la tabla de origen tampoco.
- Recibe la alerta o, peor aún, la pregunta sobre datos desactualizados.
El trabajo está en el lugar equivocado
- Hacer joins y agregar es trabajo del data warehouse. Dentro del extract se reconstruye en cada actualización.
- 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 construye la agregación en el warehouse y publica information marts que Tableau puede copiar tal cual.
- El extract copia, no calcula. El tiempo de creación cae de forma drástica.
- Los marts preagregados implican muchas menos filas y un archivo
.hypermucho más pequeño. - La carga incremental ocurre en el origen, en el warehouse, donde corresponde.
- Las actualizaciones terminan dentro de la ventana, y terminan de forma predecible.
- Con un extract pequeño, una conexión en vivo a menudo vuelve a ser viable.
Qué pedir
“Nuestro extract carga filas de transacciones en bruto y hace los joins durante la creación, por eso el backgrounder agota el tiempo de espera. ¿Podemos tener un information mart agregado en el warehouse para que el extract lo copie?”
Lo bastante concreto para dimensionarlo, y lleva el trabajo a donde están los datos.
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.
-
¿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.