Votre Tableau Server contient-il trop de versions du même chiffre ?
Chaque .tdsx publié était raisonnable le jour de sa création. Ensemble, ils forment des centaines de définitions privées du même indicateur, sans aucun moyen de savoir laquelle est la bonne.
Cela vous semble familier ?
- Vous cherchez un indicateur sur Tableau Server et quatre sources de données publiées apparaissent.
- Deux services citent des chiffres différents pour le même mois, et tous deux s'appuient sur Tableau.
- Personne ne sait quel .tdsx peut être supprimé sans risque, donc aucun ne l'est.
- Le même extrait est stocké plusieurs fois, et le stockage ne cesse de croître.
Chaque source de données publiée était une décision raisonnable le jour où elle a été prise. Le problème, c’est que chacune contient aussi une réponse privée à ce que signifie un indicateur.
Comment la prolifération s’installe
- Dupliquer est le chemin rapide. Copier une source de données et l’ajuster permet de livrer demain, alors que modifier une source partagée demande un accord.
- La logique voyage avec la copie. Filtres, exclusions et champs calculés sont figés dans
le
.tdsx. - Les différences ne se voient pas. Deux sources nommées « Sales » se ressemblent parfaitement dans le catalogue.
- Rien ne peut être retiré, parce que personne ne peut prouver quels classeurs dépendent de quelle source.
La certification aide, mais seulement après que quelqu’un a décidé ce qu’est le chiffre. Cette décision n’est pas une fonctionnalité de Tableau.
Pourquoi cela retombe sur vous
- On vous demande de rapprocher des chiffres produits par des choix faits dans d’autres services.
- Le rapprochement est un travail invisible, remarqué seulement lorsqu’il n’a pas été fait.
- Vous pouvez certifier votre propre source. Vous ne pouvez pas amener quatre équipes à s’accorder sur une définition.
Le travail se fait au mauvais endroit
- Définir un indicateur est un travail de warehouse. Fait séparément dans chaque
.tdsx, il produit plusieurs réponses. - Ce travail a sa place dans un endroit central : un data warehouse ou un data hub, construit une fois et lu par chaque classeur.
- Si cela semble coûteux, l’estimation suppose probablement des pipelines construits à la main. Une plateforme d’automatisation spécialisée les génère à partir d’un modèle, ce qui change à la fois le coût et le délai.
Ce qui change quand le modèle arrive prêt à l’emploi
Datavault Builder conserve les règles métier dans le warehouse et génère les vues dimensionnelles auxquelles chaque classeur se connecte.
- L’indicateur est calculé une seule fois, et chaque classeur lit le même chiffre.
- La règle est visible et versionnée, au lieu d’être scellée dans un extrait publié.
- Le lineage montre la dérivation, donc un désaccord se règle en ouvrant le graphe.
- Les nouvelles questions réutilisent le modèle, et c’est ce qui empêche les cent prochaines copies.
- Le stockage cesse de se multiplier, parce que le même mart sert de nombreux classeurs.
Ce qu’il faut demander
« Nous avons quatre sources publiées qui calculent le chiffre d’affaires différemment, et la logique se trouve dans les fichiers .tdsx. La règle peut-elle vivre dans le warehouse, pour que chaque classeur se connecte à une seule vue dimensionnelle gouvernée ? »
Cela déplace la discussion : il ne s’agit plus de savoir quelle source de données est correcte, mais où la définition doit se trouver.
Voyez-le fonctionner sur vos propres données
Réservez une démo gratuite et apportez le rapport qui vous pose le plus de problèmes.
Trois étapes vers des chiffres qui concordent
-
Extraire la logique existante
Rassemblez les calculs, jointures et filtres qui vivent aujourd’hui dans vos rapports.
-
La centraliser en un seul endroit
La logique passe une seule fois dans le modèle du warehouse, et chaque rapport lit la même définition.
-
Des chiffres qui concordent
Chaque rapport affiche le même chiffre, et « d’où vient ce chiffre » a une réponse visible.
Comment Datavault Builder fournit à votre rapport un modèle prêt à l'emploi
-
Le modèle arrive prêt à l'emploi
Datavault Builder génère le vault et le schéma en étoile pour qu’ils s’exécutent nativement dans la base de données dont vous disposez déjà : SQL Server, Azure SQL, Synapse, Fabric, Snowflake, Databricks ou BigQuery.
-
Le travail quitte le rapport
Pas de fusion, pas de parsing, pas de correspondance approximative. Ce travail a disparu du rapport.
-
Les sources arrivent intégrées
Les clients de l’ERP, du CRM et de la boutique en ligne sont rapprochés en un seul ensemble de dimensions conformes. La jointure a lieu une fois dans le warehouse, et non à nouveau dans chaque rapport.
-
Un historique interrogeable
Chaque modification est conservée à son arrivée, vous pouvez donc produire des rapports sur l’état passé comme sur l’état actuel, même lorsque le système source écrase ses propres enregistrements.
-
Chaque chiffre a son lineage
La logique gagne un lineage, donc « d’où vient ce chiffre » a une réponse visible.
-
Évolutions gérées en amont
Les dimensions à évolution lente sont gérées en amont sous forme de satellites du vault, pas approximées.
Rencontrez notre expert
Vingt minutes avec notre Sales Director, et une réponse honnête sur l’adéquation avec votre situation.
Matt Collett
Sales Director
Parfait, choisissez un créneau qui vous convient :
Autres problèmes traités dans cette série
-
Vos expressions LOD Tableau sont-elles trop complexes pour y toucher ?
FIXED, INCLUDE et EXCLUDE sont des outils précis pour de véritables questions à plusieurs granularités. La plupart de celles de votre classeur sont là parce que le warehouse n’a jamais résolu la granularité ni conservé l’historique.
-
Vos actualisations d'extraits Tableau échouent-elles ou prennent-elles du retard ?
Le backgrounder expire, le fichier .hyper ne cesse de grossir, et le dashboard affiche les données de la veille. L’extrait est volumineux parce qu’il transporte des lignes brutes qui n’ont jamais été agrégées en amont.
-
Votre dashboard Tableau est-il lent à chaque changement de filtre ?
Vingt secondes de « Exécution de la requête » à chaque clic sur un filtre. Tableau n’affiche pas lentement. Il attend une base de données à qui l’on a posé une question à laquelle elle ne peut pas répondre rapidement.