¿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.
La plataforma de automatización de data warehouse en la que confían equipos de datos de todos los sectores
¿Le suena familiar?
- Busca una métrica en Tableau Server y aparecen cuatro fuentes de datos publicadas.
- Dos departamentos dan cifras distintas para el mismo mes y ambos citan Tableau.
- Nadie sabe qué .tdsx se puede borrar sin riesgo, así que no se borra ninguno.
- El mismo extract se almacena varias veces, y el almacenamiento no deja de crecer.
Cada fuente de datos publicada fue una decisión razonable en su día. El problema es que cada una contiene además una respuesta privada a lo que significa una métrica.
Cómo se acumula la proliferación
- Duplicar es el camino rápido. Copiar una fuente de datos y ajustarla se entrega mañana; cambiar una compartida requiere un acuerdo.
- La lógica viaja con la copia. Filtros, exclusiones y campos calculados quedan incrustados
en el
.tdsx. - Las diferencias no se ven. Dos fuentes llamadas “Sales” parecen idénticas en el catálogo.
- No se puede retirar nada, porque nadie puede demostrar qué libros de trabajo dependen de qué fuente.
La certificación ayuda, pero solo después de que alguien decida cuál es la cifra. Esa decisión no es una función de Tableau.
Por qué le toca a usted
- Le piden conciliar cifras producidas por decisiones tomadas en otros departamentos.
- La conciliación es trabajo invisible, que solo se nota cuando no se ha hecho.
- Puede certificar su propia fuente. No puede hacer que cuatro equipos acuerden una definición.
El trabajo está en el lugar equivocado
- Definir una métrica es trabajo del data warehouse. Hecho por separado en cada
.tdsx, produce varias respuestas. - 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 mantiene las reglas de negocio en el warehouse y genera las vistas dimensionales a las que se conecta cada libro de trabajo.
- La métrica se calcula una sola vez, y todos los libros de trabajo leen la misma cifra.
- La regla es visible y está versionada, en lugar de quedar sellada dentro de un extract publicado.
- El lineage muestra la derivación, así que un desacuerdo se resuelve abriendo el grafo.
- Las nuevas preguntas reutilizan el modelo, y eso es lo que frena las próximas cien copias.
- El almacenamiento deja de multiplicarse, porque el mismo mart sirve a muchos libros de trabajo.
Qué pedir
“Tenemos cuatro fuentes publicadas que calculan los ingresos de forma distinta, y la lógica está dentro de los archivos .tdsx. ¿Puede la regla vivir en el warehouse para que todos los libros de trabajo se conecten a una única vista dimensional gobernada?”
Así la discusión deja de ser qué fuente de datos es la correcta y pasa a ser dónde debe estar la definición.
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
-
¿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.
-
¿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.