Tableau dans le commerce de détail, vraiment ?

Le temps des rapports dans Excel disparaît rapidement - la tendance vers des outils pratiques pour présenter et analyser les informations est visible dans tous les domaines. Nous discutons depuis longtemps en interne de la numérisation du reporting et avons choisi le système de visualisation et d'analyse en libre-service Tableau. Alexander Bezugly, responsable du département de solutions analytiques et de reporting du groupe M.Video-Eldorado, a parlé de l'expérience et des résultats de la création d'un tableau de bord de combat.

Je dirai 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 utile aussi. Et si quelqu'un a des idées sur la façon dont cela pourrait être amélioré, je lui serais très reconnaissant pour vos conseils et vos idées.

Sous la coupe se trouvent ce que nous avons rencontré et 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 plus de détails cet article). À partir de ceux-ci, les analystes créent soit des tableaux croisés dynamiques, soit des newsletters formatées dans Excel, soit de superbes présentations PowerPoint pour les utilisateurs finaux.

Il y a environ deux ans, au lieu de rapports de forme fixe, nous avons commencé à créer des rapports analytiques dans SAP Analysis (un module complémentaire pour Excel, essentiellement 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 majorité a continué à utiliser des informations complémentaires traitées par les analystes.

Nos utilisateurs finaux se répartissent en trois catégories :

La haute direction. Demande des informations d’une manière bien présentée et clairement compréhensible.

Cadres intermédiaires, utilisateurs avancés. Intéressé par l'exploration de données et capable de créer des rapports de manière indépendante si des outils sont disponibles. Ils sont devenus les principaux utilisateurs des rapports analytiques dans SAP Analysis.

Utilisateurs de masse. Ils ne sont pas intéressés par l'analyse indépendante des données, ils utilisent des rapports avec un degré de liberté limité, sous forme de newsletters et de tableaux croisés dynamiques dans Excel.

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

Étant donné que les utilisateurs des tableaux de bord étaient la haute direction, un autre KPI supplémentaire du produit est apparu : la vitesse de réponse. Personne n'attendra 20 à 30 secondes pour que les données soient mises à jour. La navigation aurait dû être effectuée en 4 à 5 secondes, ou mieux encore, instantanément. Et nous, hélas, n’y sommes pas parvenus.

Voici à quoi ressemblait la présentation de notre tableau de bord principal :

L’idée clé est de regrouper les principaux pilotes KPI, au nombre de 19 au total, à gauche et de présenter leur dynamique et leur répartition par principaux attributs à droite. La tâche semble simple, la visualisation est logique et compréhensible, jusqu'à ce que vous plongiez dans les détails.

Détail 1. Volume de données

Notre tableau principal des ventes annuelles occupe environ 300 millions de lignes. Puisqu'il est nécessaire de refléter la dynamique de l'année dernière et de l'année précédente, le volume de données sur les ventes réelles à elles seules est d'environ 1 milliard de lignes. Les informations sur les données planifiées et le bloc 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 en colonnes SAP HANA, la vitesse de la requête avec la sélection de tous les indicateurs pour une semaine à partir du stockage actuel à la volée était d'environ 15 à 20 secondes. La solution à ce problème se suggère d'elle-même : une matérialisation supplémentaire des données. Mais il comporte aussi des pièges, dont nous parlerons plus loin ci-dessous.

Détail 2. Indicateurs non additifs

Beaucoup de nos KPI sont liés au nombre de reçus. Et cet indicateur représente le COUNT DISTINCT du nombre de lignes (vérifier les en-têtes) et affiche différents montants en fonction des attributs sélectionnés. Par exemple, comment cet indicateur et sa dérivée doivent être calculés :

Pour que vos calculs soient corrects, vous pouvez :

• Calculer ces indicateurs à la volée dans le stockage ;
• Effectuer des calculs sur l'ensemble du volume de données dans Tableau, c'est-à-dire sur demande dans Tableau, fournir toutes les données selon les filtres sélectionnés dans la granularité de la position du reçu ;
• Créez une vitrine matérialisée dans laquelle tous les indicateurs seront calculés dans toutes les options d'échantillon qui donnent 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 ; la gestion au sein de l'entreprise s'effectue à travers elle, car Différents responsables sont responsables de différents groupes de produits. Nous avons eu de nombreuses révisions globales de cette hiérarchie, lorsque tous les niveaux changeaient, lorsque les relations étaient révisées, et des changements de points constants, lorsqu'un groupe passait d'un nœud à un autre. Dans le reporting classique, tout cela est calculé à la volée à partir des attributs du matériau ; en cas de matérialisation de ces données, il est nécessaire de développer un mécanisme de suivi de ces modifications et de rechargement automatique des données historiques. Une tâche très non triviale.

Détail 3. Comparaison des données

Ce point est similaire au précédent. L'essentiel est que lors de l'analyse d'une entreprise, il est d'usage 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 qu'en fonction de la période sélectionnée par l'utilisateur (par exemple, la 33ème semaine de l'année), nous devrions afficher la dynamique à la 32ème semaine ; si nous avons sélectionné des données pour un mois, par exemple, mai , alors cette comparaison montrerait la dynamique d'ici avril.

Comparaison avec l'année dernière

La principale nuance ici 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 que vous comparez. Au contraire, lorsque vous comparez des mois, vous devez prendre exactement le même jour calendaire de l’année dernière. Il y a aussi des nuances avec les années bissextiles. Dans les référentiels d'origine, toutes les informations sont distribuées par jour ; il n'y a pas de champs séparés avec des semaines, des mois ou des années. Par conséquent, pour obtenir une coupe transversale analytique complète dans le panel, vous devez compter non pas une période, par exemple une semaine, mais 4 semaines, puis comparer ces données, refléter la dynamique, les écarts. Ainsi, cette logique de génération de comparaisons en dynamique peut également être implémentée soit dans Tableau, soit côté vitrine. Oui, et bien sûr, nous connaissions et réfléchissions à ces détails dès la conception, mais il était difficile de prédire leur impact sur les performances du tableau de bord final.

Lors de la mise en œuvre du tableau de bord, nous avons suivi le long chemin Agile. Notre tâche était de fournir le plus rapidement possible un outil de travail avec les données nécessaires aux tests. Par conséquent, nous nous sommes lancés dans des sprints et avons commencé par minimiser le travail du côté du stockage actuel.

Partie 1 : La confiance dans Tableau

Pour simplifier le support informatique et mettre en œuvre rapidement les changements, nous avons décidé de créer une logique de calcul d'indicateurs non additifs et de comparaison des périodes passées dans Tableau.

Étape 1. Tout est en direct, aucune modification de fenêtre.

À ce stade, nous avons connecté Tableau aux vitrines actuelles et avons décidé de voir comment serait calculé le nombre de reçus pour un an.

Résultat:

La réponse était déprimante : 20 minutes. Transfert de données sur le réseau, charge élevée sur Tableau. Nous avons réalisé qu'une logique avec des indicateurs non additifs devait être implémentée sur HANA. Cela ne nous a pas trop effrayé, nous avions déjà une expérience similaire avec BO et Analysis et nous savions construire des vitrines rapides dans HANA qui produisent des indicateurs non additifs correctement calculés. Il ne restait plus qu'à les adapter à Tableau.

Étape 2. Nous peaufinons les vitrines, pas de matérialisation, tout à la volée.

Nous avons créé une nouvelle vitrine distincte qui a produit les données requises pour TABLEAU à la volée. En général, nous avons obtenu un bon résultat : nous avons réduit le temps de génération 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 en raison du cache de 10 à 12, ce qui nous conviendrait en général.

Résultat:

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

Partie 2. Plongez dans Tableau

Étape 1. Analyse des performances de Tableau et réglage rapide

Nous avons commencé à analyser où Tableau passe la plupart de son temps. Et il existe de très bons outils pour cela, ce qui est bien sûr un plus de Tableau. Le principal problème que nous avons identifié était les requêtes SQL très complexes que Tableau était en train de créer. Ils étaient principalement associés à :

— la transposition des données. Comme Tableau ne dispose pas d'outils de transposition des jeux de données, pour construire le côté gauche du tableau de bord avec une représentation détaillée de tous les KPI, nous avons dû créer un tableau à l'aide d'un cas. La taille des requêtes SQL dans la base de données atteignait 120 000 caractères.

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

Ceux. traitement de la demande 12 secondes + 5 secondes d'exécution.

Nous avons décidé de simplifier la logique de calcul côté Tableau et de déplacer 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 fait la transposition à la volée, nous l'avons fait via une jointure externe complète à l'étape finale du calcul VIEW, selon cette approche décrite sur le wiki Transposer — Wikipédia, l'encyclopédie gratuite и Matrice élémentaire — Wikipédia, l'encyclopédie libre.

C'est-à-dire que nous avons créé un tableau de configuration - une matrice de transposition (21x21) et reçu tous les indicateurs ventilés ligne par ligne.

C'était:


C'est devenu:


Presque aucun temps n'est consacré à la transposition de la base de données elle-même. La demande de tous les indicateurs de la semaine a continué à être traitée en 10 secondes environ. Mais d’un autre côté, la flexibilité a été perdue dans la construction d’un tableau de bord basé sur un indicateur spécifique, à savoir : pour le côté droit du tableau de bord où sont présentées la dynamique et la répartition détaillée d'un indicateur spécifique, auparavant la vitrine fonctionnait en 1 à 3 secondes, car la demande était basée sur un indicateur, et désormais la base de données sélectionnait toujours tous les indicateurs et filtrait le résultat avant de renvoyer le résultat à Tableau.

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

Résultat:

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

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

Nous avons compris qu'il était impossible de construire un tableau de bord avec un temps de réponse de plusieurs secondes sur une vitrine qui s'exécute pendant 10 secondes, et nous avons envisagé des options de matérialisation des données côté base de données spécifiquement pour le tableau de bord requis. Mais nous avons rencontré un problème global décrit ci-dessus : les indicateurs non additifs. Nous n'avons pas pu garantir que lors de la modification des filtres ou des analyses, Tableau basculait de manière flexible entre différentes vitrines et niveaux prédéfinis pour différentes hiérarchies de produits (dans l'exemple, trois requêtes sans UTE, avec UTE1 et UTE2 génèrent 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 cela pourrait être dans une version simplifiée.

Ainsi, lors de cette dernière étape, nous avons constitué un référentiel séparé dans lequel nous avons ajouté tous les KPI sous forme transposée. Du côté de la base de données, toute demande vers un tel stockage est traitée en 0,1 à 0,3 seconde. Dans le tableau de bord, nous avons reçu les résultats suivants :

Première ouverture : 8-10 secondes
N'importe quel clic : 6-7 secondes

Le temps passé par Tableau est constitué de :

1. 0,3 s. — analyse du tableau de bord et compilation des requêtes SQL
2. 1,5 à 3 secondes. — exécution de requêtes SQL dans Hana pour les visualisations principales (s'exécute en parallèle avec l'étape 1)
3. 1,5 à 2 secondes. — rendu, recalcul des visualisations
4. 1,3 seconde. — exécution de requêtes SQL supplémentaires pour obtenir des valeurs de filtre pertinentes (Marque, Division, Ville, Magasin), analyse des résultats

Pour résumer brièvement

Nous avons apprécié l'outil Tableau du point de vue de la visualisation. Au stade du prototypage, nous avons pris en compte divers éléments de visualisation et les avons tous trouvés dans des bibliothèques, notamment une segmentation multi-niveaux complexe et une cascade multi-pilotes.

Lors de la mise en place de tableaux de bord avec des indicateurs clés de ventes, nous avons rencontré des difficultés de performances que nous n'avons pas encore pu surmonter. Nous avons passé plus de deux mois et avons reçu un tableau de bord fonctionnellement incomplet, dont la vitesse de réponse est à la limite de l'acceptable. Et nous avons tiré des conclusions par nous-mêmes :

1. Tableau ne peut pas fonctionner 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 X 50 lignes), le tableau de bord ralentira sérieusement - de 10 secondes à plusieurs minutes pour chaque clic. Nous avons expérimenté à la fois la connexion en direct et l'extraction. La vitesse de fonctionnement est comparable.
2. Limitation lors de l’utilisation de plusieurs stockages (ensembles de données). Il n'existe aucun moyen d'indiquer la relation entre les ensembles de données à l'aide de moyens standard. Si vous utilisez des solutions de contournement pour connecter des ensembles de données, cela aura un impact considérable sur les performances. Dans notre cas, nous avons envisagé la possibilité de matérialiser les données dans chaque section de vue requise et d'effectuer des commutations sur ces ensembles de données matérialisées tout en préservant les filtres précédemment sélectionnés - cela s'est avéré impossible à faire dans Tableau.
3. Il n'est pas possible de créer des paramètres dynamiques dans Tableau. Vous ne pouvez pas remplir un paramètre utilisé pour filtrer un ensemble de données dans un extrait ou lors d'une connexion en direct avec le résultat d'une autre sélection dans l'ensemble de données ou le résultat d'une autre requête SQL, uniquement avec une entrée utilisateur native ou une constante.
4. Limitations associées à la création d'un tableau de bord avec des éléments OLAP|PivotTable.
   Dans MSTR, SAP SAC, SAP Analysis, si vous ajoutez un ensemble de données à un rapport, tous les objets qu'il contient sont liés les uns aux autres par défaut. Tableau ne dispose pas de cela ; la connexion doit être configurée manuellement. C'est probablement plus flexible, mais pour tous nos tableaux de bord, il s'agit d'une exigence obligatoire pour les éléments - il s'agit donc de coûts de main-d'œuvre supplémentaires. De plus, si vous faites des filtres associés pour que, par exemple, lors du filtrage d'une région, la liste des villes se limite aux seules villes de cette région, vous vous retrouvez immédiatement avec des requêtes successives dans la base de données ou Extract, ce qui ralentit sensiblement le tableau de bord.
5. Limites des fonctions. Les transformations de masse ne peuvent être effectuées ni sur l'extrait ni, SURTOUT, sur le jeu de données de Live-connecta. Cela peut être fait via Tableau Prep, mais cela représente un travail supplémentaire et un autre outil à apprendre et à gérer. Par exemple, vous ne pouvez pas transposer des données ni les joindre à elles-mêmes. Ce qui est fermé grâce à des transformations sur des colonnes ou des champs individuels, qui doivent être sélectionnés via case ou if, et cela génère des requêtes SQL très complexes, dans lesquelles la base de données passe la plupart de son temps à compiler le texte de la requête. Ces manques de flexibilité de l'outil ont dû être résolus au niveau de la vitrine, ce qui entraîne un stockage plus complexe, des téléchargements et des transformations supplémentaires.

Nous n'avons pas abandonné Tableau. Mais nous ne considérons pas Tableau comme un outil capable de créer des tableaux de bord industriels et un outil permettant de remplacer et de numériser l’ensemble du système de reporting d’entreprise d’une entreprise.

Nous développons actuellement activement un tableau de bord similaire dans un autre outil et, en même temps, 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 ferons part des résultats.

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

Source: habr.com