Tableau au détail, vraiment?

Le temps de rapport dans Excel s'épuise rapidement - la tendance des outils pratiques pour présenter et analyser les informations est visible dans tous les domaines. Nous avons longtemps discuté de la numérisation du bâtiment de génération de rapports et avons choisi le système de visualisation et d'analyse en libre-service Tableau. Alexander Bezugly, chef du département des solutions analytiques et des rapports du groupe M. Video-Eldorado, a parlé de l'expérience et des résultats de la construction d'un tableau de bord de combat.

Je dois dire tout de suite que tout ce qui était prévu n'a pas été réalisé, mais l'expérience a été intéressante, j'espère qu'elle vous sera également utile. Et si quelqu'un arrive avec des idées sur la façon de faire mieux, je serai très reconnaissant pour les conseils et les idées.



Sous la coupe de ce que nous avons rencontré et de ce que nous avons appris.

Par où avons-nous commencé

«M. Video-Eldorado» dispose d'un modèle de données bien développé: des informations structurées avec la profondeur de stockage requise et un grand nombre de rapports de forme fixe (voir cet article pour plus de détails). Parmi ceux-ci, les analystes créent des tableaux croisés dynamiques ou des mailings formatés dans Excel, ou de belles présentations dans PowerPoint pour les utilisateurs finaux.

Il y a environ deux ans, au lieu de rapports d'un formulaire fixe, nous avons commencé à créer des rapports analytiques dans SAP Analysis (un complément pour Excel, en fait - un tableau croisé dynamique sur le moteur OLAP). Mais cet outil n'a pas été en mesure de répondre aux besoins de tous les utilisateurs, la plupart d'entre eux ont continué à utiliser des informations supplémentaires traitées par les analystes.

Nos utilisateurs finaux sont divisés en trois catégories:

Top management . Demande des informations sous une forme bien présentée et clairement compréhensible.

Gestion intermédiaire , utilisateurs avancés. Intéressé par la recherche de données et capable de créer indépendamment des rapports avec des outils. Ils sont devenus les principaux utilisateurs des rapports analytiques dans SAP Analysis.

Utilisateurs de masse . Pas intéressé par l'auto-analyse des données, utilisez des rapports avec un degré de liberté limité, au format des newsletters et des tableaux croisés dynamiques dans Excel.

Notre idée était de couvrir les besoins de tous les utilisateurs et de leur donner un outil pratique unique. Ils ont décidé de commencer par la haute direction. Ils avaient besoin de tableaux de bord pratiques pour analyser les résultats commerciaux clés. Nous avons donc commencé avec Tableau et pour commencer, nous avons choisi deux domaines: les ventes au détail et les ventes en ligne avec une profondeur et une étendue d'analyse limitées, qui couvriraient environ 80% des données demandées par la direction.

Étant donné que les utilisateurs des tableaux de bord étaient des cadres supérieurs, un autre KPI supplémentaire du produit est apparu: la vitesse de réponse. Personne n'attendra 20 à 30 secondes jusqu'à ce que les données soient mises à jour. La navigation devait tenir en 4-5 secondes, et il valait mieux s'entraîner instantanément. Et nous, hélas, n'y sommes pas parvenus.

Voici à quoi ressemblait notre disposition de base du tableau de bord:



L'idée clé est de combiner les principaux pilotes KPI, qui sont au final 19, à gauche et de présenter leur dynamique et une répartition des principaux attributs à droite. La tâche semble simple, la visualisation est logique et compréhensible, jusqu'à ce que vous entriez dans les détails.

Détail 1. Volume de données

Le principal tableau des ventes de l'année occupe environ 300 millions de lignes. Puisqu'il est nécessaire de refléter la dynamique de la dernière et de l'année précédente, la quantité de données sur les ventes réelles représente à elle seule environ 1 milliard de lignes. Et les informations sur les données planifiées et une unité de vente en ligne sont également stockées séparément. Par conséquent, même si nous avons utilisé la base de données en mémoire SAP HANA en mémoire, la vitesse de requête avec la sélection de tous les indicateurs pendant une semaine à partir du stockage actuel à la volée était d'environ 15 à 20 secondes. La solution à ce problème se suggère: une matérialisation supplémentaire des données. Mais il y a aussi des pièges, à leur sujet ci-dessous.

Partie 2. Indicateurs non additifs

Nous avons de nombreux KPI liés au nombre de contrôles. Et cet indicateur est un COUNT DISTINCT du nombre de lignes (en-têtes de réception) et affiche des montants différents en fonction des attributs sélectionnés. Par exemple, comment cet indicateur et son dérivé doivent être considérés:



Pour l'exactitude des calculs, vous pouvez:

• Effectuer le calcul de ces indicateurs à la volée dans le stockage;
  
• Calculez la quantité totale de données dans Tableau, c'est-à-dire sur demande, dans Tableau, donnez toutes les données pour les filtres sélectionnés dans la granularité de la position de contrôle;
  
• Faire une vitrine matérialisée dans laquelle tous les indicateurs seront calculés dans toutes les variantes d'échantillons donnant différents résultats non additifs.
  

Il est clair que dans l'exemple UTE1 et UTE2 sont des attributs matériels représentant la hiérarchie des produits. Ce n'est pas une chose statique, à travers elle va la gestion au sein de l'entreprise, car différents groupes de produits sont responsables de différents gestionnaires. Nous avons eu de nombreuses révisions globales de cette hiérarchie, lorsque tous les niveaux ont changé, lorsque les corrélations ont été révisées et des changements de points constants, lorsqu'un groupe se déplace d'un nœud à un autre. Dans le reporting ordinaire, tout cela est considéré à la volée à partir des attributs du matériel, en cas de matérialisation de ces données, il est nécessaire de développer un mécanisme de suivi de ces changements et de surcharge automatique des données historiques. Une tâche très simple.

Détail 3. Comparaison des données

Cet article est similaire au précédent. L'essentiel est que lors de l'analyse d'une entreprise, il est habituel de former plusieurs niveaux de comparaison avec la période précédente:

Comparaison avec la période précédente (au jour le jour, de semaine en semaine, de mois en mois)

Dans cette comparaison, on suppose que, selon la période sélectionnée par l'utilisateur (par exemple, semaine 33 de l'année), nous devons montrer la dynamique à la semaine 32, si nous avons sélectionné des données pour le mois, par exemple, mai, cette comparaison montrerait la dynamique d'ici avril.

Comparaison avec l'année dernière

Ici, la principale mise en garde est que lorsque vous comparez par jour et par semaine, vous ne prenez pas le même jour de l'année dernière, c'est-à-dire vous ne pouvez pas simplement mettre l'année en cours moins un. Vous devez regarder le jour de la semaine comparé. Et lorsque vous comparez des mois, au contraire, vous devez prendre exactement le même jour civil l'année dernière. Il existe également des nuances avec les années bissextiles. Dans les référentiels source, toutes les informations sont distribuées par jour, il n'y a pas de champs séparés avec des semaines, des mois, des années. Par conséquent, pour obtenir une tranche analytique complète dans le panel, il est nécessaire de considérer non pas une période, par exemple une semaine, mais 4 semaines, puis ces données doivent être comparées, refléter la dynamique, les écarts. En conséquence, cette logique de formation de comparaisons en dynamique peut également être implémentée soit dans Tableau, soit du côté de la vitrine. Oui, et bien sûr, nous connaissions et pensions à ces détails au stade de la conception, mais leur impact sur les performances du tableau de bord final était difficile à prévoir.

Avec l'introduction du tableau de bord, nous avons suivi un long chemin Agile. Notre tâche était de fournir un outil de travail avec les données nécessaires pour les tests le plus rapidement possible. Par conséquent, nous sommes allés sprints et avons commencé à minimiser le travail du côté du stockage actuel.

Partie 1. La foi dans Tableau

Pour simplifier le support informatique et implémenter rapidement les changements, nous avons décidé de faire la logique du calcul des indicateurs non additifs et de comparer les périodes passées dans Tableau.

Étape 1. Tout dans Live, aucune amélioration de l'habillage des fenêtres.

À ce stade, nous avons connecté Tableau aux vitrines actuelles et décidé de voir comment le nombre de chèques sera compté dans un an.

Résultat:

La réponse était déprimante - 20 minutes. Distillation des données réseau, charge élevée sur Tableau. Nous avons réalisé que la logique avec des métriques non additives doit être implémentée sur HANA. Cela ne nous a pas beaucoup fait peur, nous avions déjà une expérience similaire avec BO et Analysis et nous avons pu créer des vitrines rapides dans HANA qui produisent des indicateurs non additifs calculés correctement. Restait maintenant à les modifier sous Tableau.

Étape 2. Nous réglons les fenêtres, pas de matérialisation, tout est à la volée.

Nous avons créé une nouvelle vitrine distincte, qui a produit à la volée les données requises pour TABLEAU. En général, nous avons obtenu un bon résultat, nous avons réduit le temps de formation de tous les indicateurs en une semaine à 9-10 secondes. Et nous nous attendions honnêtement à ce que dans Tableau, le temps de réponse du tableau de bord soit de 20 à 30 secondes à la première ouverture, puis à cause du cache de 10 à 12, ce qui nous conviendrait en général.

Résultat:

Premier tableau de bord ouvert: 4-5 minutes
Tout clic: 3-4 minutes
Personne ne s'attendait à une telle augmentation supplémentaire du travail de la vitrine.

Partie 2. Immersion dans Tableau

Étape 1. Analyse des performances de Tableau et optimisation rapide

Nous avons commencé à analyser les dépenses de Tableau la plupart du temps. Et pour cela, il existe une bonne boîte à outils, qui, bien sûr, est en plus de Tableau. Le principal problème que nous avons identifié était les requêtes SQL très complexes créées par Tableau. Ils étaient principalement associés à:

- transposition de données. Étant donné que Tableau ne dispose d'aucun outil pour transposer les ensembles de données, pour créer le côté gauche du tableau de bord avec une vue détaillée de tous les indicateurs de performance clés, nous avons dû créer un tableau à travers le cas. La taille des requêtes SQL dans la base de données a atteint 120 000 caractères.



- le choix de la période. Une telle requête au niveau de la base de données a pris plus de temps à compiler qu'à exécuter:



C'est-à-dire traitement des requêtes 12 secondes + 5 secondes d'exécution.

Nous avons décidé de simplifier la logique des calculs côté Tableau et de transférer une autre partie des calculs au niveau de la vitrine et de la base de données. Cela a donné de bons résultats.

Tout d'abord, nous avons effectué la transposition à la volée, effectué une jointure externe complète au stade final du calcul VIEW, selon cette approche décrite sur le wiki Transpose - Wikipedia, l'encyclopédie gratuite et Elementary matrix - Wikipedia, l'encyclopédie gratuite .



Autrement dit, nous avons créé un tableau de réglage - la matrice de transposition (21x21) et obtenu tous les indicateurs dans une ventilation ligne par ligne.

C'était:


C'est devenu:


La DB elle-même ne passe guère de temps à se transposer. La demande pour tous les indicateurs de la semaine a été satisfaite comme auparavant en 10 secondes environ. Mais d'autre part, la flexibilité en termes de construction d'un tableau de bord par un indicateur spécifique, c'est-à-dire pour le côté droit du tableau de bord où la dynamique et une ventilation détaillée d'un indicateur spécifique sont présentées, la vitrine a fonctionné en 1 à 3 secondes avant, car la requête est allée sur un indicateur, et maintenant la base de données a toujours sélectionné tous les indicateurs et filtré le résultat avant de renvoyer le résultat à Tableau.

En conséquence, la vitesse du tableau de bord a été réduite de près de 3 fois.

Résultat:

1. 5 secondes - analyse des tableaux de bord, visualisations
2. 15-20 sec - préparation pour la compilation des requêtes avec exécution des précalculs dans Tableau
3. 35-45 sec - compilation de requêtes SQL et leur exécution séquentielle parallèle dans Hana
4. 5 sec - traitement des résultats, tri, recalcul des visualisations dans Tableau
5. Bien sûr, ces résultats ne convenaient pas à l'entreprise et nous avons continué à optimiser.

Étape 2. Logique minimale dans Tableau, matérialisation complète

Nous avons compris qu'il était impossible de créer un tableau de bord avec un temps de réponse de plusieurs secondes dans une fenêtre de magasin qui a fonctionné pendant 10 secondes, et nous avons envisagé des options pour matérialiser les données côté base de données spécifiquement pour le tableau de bord requis. Mais face au problème global décrit ci-dessus - des indicateurs non additifs. Nous ne pouvions pas faire en sorte que lors du changement de filtres ou d'analyses, Tableau bascule de manière flexible entre différentes vitrines et niveaux calculés pour différentes hiérarchies de produits (dans l'exemple, trois requêtes sans UTE, avec UTE1 et UTE2 forment des résultats différents). Par conséquent, nous avons décidé de simplifier le tableau de bord, d'abandonner la hiérarchie des produits dans le tableau de bord et de voir à quelle vitesse il peut être dans la version simplifiée.

Ainsi, à cette dernière étape, nous avons constitué un référentiel séparé dans lequel tous les KPI ont été transposés. Du côté de la base de données, toute demande adressée à un tel référentiel est satisfaite en 0,1 à 0,3 seconde. Dans le tableau de bord, nous avons obtenu les résultats suivants:

Première ouverture: 8-10 secondes
Tout clic: 6-7 secondes

Le temps que Tableau passe comprend:

1. 0,3 sec - analyser les tableaux de bord et compiler les requêtes SQL
   
2. 1,5-3 sec. - exécution de requêtes SQL dans Hana pour les visualisations de base (elle démarre en parallèle avec le point 1)
   
3. 1,5-2 sec. - rendu, recalcul des visualisations
   
4. 1,3 s - exécution de requêtes SQL supplémentaires pour obtenir des valeurs de filtre pertinentes (marque, division, ville, boutique), analyse des résultats
   

Pour résumer

Nous avons aimé l'outil Tableau en termes de visualisation. Au stade du prototypage, nous avons examiné divers éléments de visualisation et les avons tous trouvés dans des bibliothèques, y compris des segmentations complexes à plusieurs niveaux et une cascade multi-pilotes.

En présentant des tableaux de bord avec des indicateurs de vente clés, nous avons rencontré des difficultés de performance que nous n'avons pas encore pu surmonter. Nous avons passé plus de deux mois et obtenu un tableau de bord fonctionnellement incomplet, dont la vitesse de réponse est sur le point d'être admissible. Et pour moi, nous avons conclu:

1. Tableau ne sait pas comment travailler avec de grandes quantités de données. Si, dans le modèle de données d'origine, vous disposez de plus de 10 Go de données (environ 200 millions de lignes X 50), le tableau de bord est sérieusement ralenti - de 10 secondes à plusieurs minutes par clic. Nous avons expérimenté à la fois la connexion en direct et l'extrait. La vitesse de travail est comparable.
   
2. Restriction lors de l'utilisation de plusieurs stockages (jeux de données). Il n'y a aucun moyen d'indiquer la relation des ensembles de données à l'aide d'outils standard. Si vous utilisez des solutions de contournement pour connecter des ensembles de données, cela affectera considérablement les performances. Dans notre cas, nous avons envisagé la possibilité de matérialiser les données dans chaque section souhaitée des représentations, et sur ces ensembles de données matérialisées pour effectuer la commutation en enregistrant les filtres précédemment sélectionnés - cela s'est avéré impossible à faire dans Tableau.
   
3. Dans Tableau, il n'est pas possible de créer des paramètres dynamiques. Vous ne pouvez pas utiliser le paramètre utilisé pour filtrer l'ensemble de données dans l'extrait, ni pendant la connexion en direct, pour remplir le résultat d'une autre sélection à partir de l'ensemble de données ou le résultat d'une autre requête SQL, uniquement une entrée utilisateur native ou constante.
   
4. Limitations associées à la création d'un tableau de bord avec des éléments OLAP | Tableau croisé dynamique.
   Dans MSTR, SAP SAC, SAP Analysis, si vous ajoutez un jeu de données à un rapport, tous les objets qu'il contient sont connectés par défaut les uns aux autres. Dans Tableau, ce n'est pas le cas, la connexion doit être configurée manuellement. C'est probablement plus flexible, mais pour tous nos tableaux de bord, c'est une exigence obligatoire pour les éléments - c'est donc un coût de main-d'œuvre supplémentaire. De plus, si vous effectuez des filtres associés afin que, par exemple, lors du filtrage d'une région, la liste des villes soit limitée uniquement aux villes de cette région, vous obtiendrez immédiatement des requêtes consécutives dans la base de données ou extrairez, ce qui ralentit sensiblement le tableau de bord.
5. Restrictions de fonctionnalités. Tant sur l'extrait que sur l'ensemble de données de Live-connecta, vous ne pouvez pas effectuer de conversions en masse. Cela peut être fait via Tableau Prep, mais c'est un travail supplémentaire et un autre outil qui doit être étudié et entretenu. Par exemple, vous ne pouvez pas transposer des données, faites-les rejoindre vous-même. Ce qui se termine par des transformations sur des colonnes ou des champs individuels qui doivent être sélectionnés via la casse ou si et cela génère des requêtes SQL très complexes, dans lesquelles la base de données passe la plupart du temps à compiler le texte de la requête. Ces raideurs des instruments ont dû être résolues au niveau de la devanture, ce qui conduit à un stockage plus compliqué, des charges et des transformations supplémentaires.
   

Nous n'avons pas mis fin à Tableau. Mais en tant qu'outil capable de créer des tableaux de bord industriels et un outil avec lequel vous pouvez remplacer et numériser l'intégralité du système de reporting d'entreprise de l'entreprise, Tableau n'est pas considéré.

Maintenant, nous développons activement un tableau de bord similaire sur un autre outil et en parallèle, nous essayons de réviser l'architecture du tableau de bord dans Tableau afin de le simplifier encore plus. Si la communauté est intéressée, nous vous informerons des résultats.

Nous attendons également vos idées ou vos conseils sur la façon dont Tabeau peut créer des tableaux de bord rapides sur des volumes de données aussi importants, car nous avons également un site Web où il y a beaucoup plus de données que dans le commerce de détail.