Tableau dans le commerce de détail, vraiment ?

Le temps de reporting dans Excel s'échappe rapidement — la tendance vers des outils pratiques de présentation et d'analyse des informations est perceptible dans tous les domaines. Nous avons longtemps discuté de la numérisation de la construction de rapports et avons choisi le système de visualisation et d'analyse en libre-service Tableau. Alexandre Bezugly, responsable du département des solutions analytiques et des rapports du groupe « M.Video-Eldorado », a partagé son expérience et les résultats de la mise en place d'un tableau de bord opérationnel.

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

Ci-dessous, sur ce à quoi nous avons fait face et ce que nous avons appris.

Par quoi nous avons commencé

Chez « M.Video-Eldorado », il existe un modèle de données bien élaboré : des informations structurées avec la profondeur de stockage requise et un grand nombre de rapports à format fixe (voir plus en détail dans cet article). Les analystes en font soit des tableaux croisés dynamiques ou des envois formatés dans Excel, soit de belles présentations dans PowerPoint pour les utilisateurs finaux.

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

Nos utilisateurs finaux se divisent en trois catégories :

La direction supérieure. Elle demande des informations présentées de manière claire et facilement compréhensible.

La direction intermédiaire, utilisateurs avancés. Ils s'intéressent à l'exploration des données et sont capables de créer des rapports de manière autonome si les outils sont disponibles. Ce sont eux qui sont devenus les utilisateurs clés des rapports analytiques dans SAP Analysis.

Les utilisateurs de base. Ils ne sont pas intéressés par l'analyse autonome des données, utilisent des rapports avec une liberté d'action limitée, sous forme d'envois et de tableaux croisés dans Excel.

Notre idée était de répondre aux besoins de tous les utilisateurs et de leur fournir un outil unique et compact. Nous avons commencé avec la haute direction. Ils avaient besoin de panneaux pratiques pour analyser les principaux résultats commerciaux. Ainsi, nous avons démarré avec Tableau et avons d'abord choisi deux axes : les indicateurs de vente au détail et en ligne avec une profondeur et une largeur 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 la haute direction, un KPI supplémentaire du produit est apparu : la rapidité de réponse. Personne ne va attendre 20 à 30 secondes pour que les données se mettent à jour. La navigation devait se faire en 4 à 5 secondes, et idéalement instantanément. Malheureusement, nous n'avons pas réussi à atteindre cet objectif.

Voici à quoi ressemblait la maquette de notre tableau de bord principal :

L'idée clé était de rassembler les principaux KPI moteurs, qui en fin de compte en comprenaient 19, à gauche et de représenter leur dynamique ainsi que leur répartition selon les principaux attributs à droite. La tâche semble simple, la visualisation est logique et claire, jusqu'à ce que l'on se plonge dans les détails.

Détail 1. Volume des données

La table principale des ventes sur l'année compte environ 300 millions de lignes. Comme il est nécessaire de refléter également la dynamique par rapport à l'année précédente et l'année d'avant, le volume des données concernant les ventes réelles s'élève à environ 1 milliard de lignes. De plus, des informations sur les données prévisionnelles et un bloc de ventes en ligne sont conservées séparément. Par conséquent, même si nous avons utilisé une base de données in-memory en colonnes SAP HANA, la vitesse de traitement de la requête pour obtenir tous les indicateurs sur une semaine depuis les entrepôts actuels en temps réel était d'environ 15 à 20 secondes. La solution de ce problème semble évidente : une matérialisation supplémentaire des données. Mais cela comporte aussi des pièges, que nous aborderons ci-dessous.

Détail 2. Indicateurs non additives

Nos nombreux KPI sont liés au nombre de reçus. Cet indicateur représente un COUNT DISTINCT du nombre de lignes (en-têtes des reçus) et montre différentes sommes selon les attributs sélectionnés. Voici un exemple de la manière dont cet indicateur et ses dérivés doivent être calculés :

Pour l'exactitude des calculs, il est possible de :

• Calculer de tels indicateurs à la volée dans l'entrepôt ;
• Calculer sur l'ensemble des données dans Tableau, c'est-à-dire en demandant à Tableau de fournir toutes les données en fonction des filtres sélectionnés avec la granularité des lignes de reçus ;
• Créer une vitrine matérialisée qui calculera tous les indicateurs pour toutes les options d'échantillonnage, donnant des résultats non-additifs différents.

Il est évident que dans l'exemple, UTE1 et UTE2 sont des attributs du matériau représentant la hiérarchie des produits. Ce n'est pas une chose statique, elle gère l'intérieur de l'entreprise, car différentes catégories de produits sont gérées par différents responsables. Nous avons effectué de nombreuses révisions globales de cette hiérarchie, lorsque tous les niveaux étaient modifiés, les interconnexions réexaminées, ainsi que des modifications ponctuelles constantes, lorsque l'un des groupes passe d'un nœud à un autre. Dans les rapports ordinaires, tout cela est calculé en temps réel à partir des attributs du matériau. Dans le cas de la matérialisation de ces données, il est nécessaire de développer un mécanisme de suivi de telles modifications et un rechargement automatique des données historiques. C'est une tâche assez non triviale.

Détail 3. Comparaison des données

Ce point est similaire au précédent. L'idée est qu'au sein de l'entreprise, lors de l'analyse, il est courant de former plusieurs niveaux de comparaison avec la période précédente :

Comparaison avec la période précédente (jour après jour, semaine après semaine, mois après mois)

Dans cette comparaison, il est supposé qu'en fonction de la période choisie par l'utilisateur (par exemple, la 33e semaine de l'année), nous devons montrer la dynamique par rapport à la 32e semaine. Si nous avions choisi les données pour un mois, par exemple mai, cette comparaison montrerait la dynamique par rapport à avril.

Comparaison avec l'année précédente

Le point principal ici est que lors de la comparaison par jours et par semaines, vous ne prenez pas le même jour de l'année précédente, c'est-à-dire que vous ne pouvez pas simplement soustraire un an de l'année en cours. Vous devez examiner le jour de la semaine en question. En revanche, lors de la comparaison des mois, il faut prendre exactement le même jour du calendrier de l'année précédente. Il y a aussi des nuances avec les années bissextiles. Dans les bases de données d'origine, toutes les informations sont réparties par jour, il n'y a pas de champs séparés pour les semaines, les mois ou les années. Par conséquent, pour obtenir un aperçu analytique complet dans le tableau de bord, il est nécessaire de calculer non pas une période, par exemple une semaine, mais 4 semaines, puis de comparer ces données, de refléter la dynamique et les déviations. Ainsi, cette logique de formation de comparaison dynamique peut également être mise en œuvre soit dans Tableau, soit du côté de la vitrine. Oui, et nous connaissions bien sûr ces détails et y avons réfléchi dès la phase de conception, mais prévoir leur impact sur les performances du tableau de bord final était difficile.

Lors de l'implémentation du tableau de bord, nous avons suivi un long parcours Agile. Notre objectif était de fournir le plus rapidement possible un outil fonctionnel à tester avec les données nécessaires. Nous avons donc progressé par sprints en nous concentrant sur la minimisation des travaux du côté des bases de données actuelles.

Partie 1. La foi en Tableau

Pour simplifier le soutien informatique et faciliter la mise en œuvre rapide des modifications, nous avons décidé de faire la logique de calcul des indicateurs non-additifs et la comparaison des périodes précédentes dans Tableau.

Étape 1. Tout en direct, aucune modification des vitrines.

À cette étape, nous avons connecté Tableau aux vitrines existantes et décidé de voir comment le nombre de tickets serait calculé sur une année.

Résultat :

La réponse était décourageante : 20 minutes. La transmission des données via le réseau, une charge élevée sur Tableau. Nous avons compris que la logique des indicateurs non-additifs devait être mise en œuvre sur HANA. Cela ne nous effrayait pas trop, nous avions déjà une expérience similaire avec BO et Analysis et savions construire des vitrines rapides sur HANA qui fournissent des indicateurs non-additifs correctement calculés. Il ne restait plus qu'à les adapter à Tableau.

Étape 2. Nous optimisons les vitrines, aucune matérialisation, tout en temps réel.

Nous avons créé une nouvelle vitrine distincte qui génère à la volée les données requises pour TABLEAU. Dans l'ensemble, nous avons obtenu un bon résultat, réduisant le temps de création de tous les indicateurs d'une semaine à 9-10 secondes. Nous nous attendions honnêtement à ce qu'à l'ouverture initiale, le temps de réponse du tableau de bord dans Tableau soit de 20 à 30 secondes, puis grâce au cache entre 10 et 12 secondes, ce qui nous aurait convenu.

Résultat :

Premier ouverture des tableaux de bord : 4-5 minutes
Chaque clic : 3-4 minutes
Personne ne s'attendait à un tel ajout à l'efficacité de la vitrine.

Partie 2. Immersion dans Tableau

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

Nous avons commencé à analyser à quoi Tableau consacre principalement son temps. Pour cela, il existe des outils assez performants, ce qui est bien sûr un avantage pour Tableau. Le principal problème que nous avons identifié réside dans des requêtes SQL très complexes générées par Tableau. Celles-ci étaient principalement liées à :

— la transposition des données. Étant donné que Tableau ne dispose pas d'outils pour transposer des ensembles de données, nous avons dû créer un tableau via un case pour construire la partie gauche du tableau de bord avec une vue détaillée de tous les KPI. La taille des requêtes SQL dans la base de données atteignait 120 000 caractères.

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

C'est-à-dire, le traitement de la requête 12 secondes + 5 secondes d'exécution.

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

D'abord, nous avons effectué la transposition à la volée, en le faisant via un full outer join à la dernière étape du calcul de la VIEW, selon cette approche décrite sur wiki Transpose — Wikipédia, l'encyclopédie libre et Matrice élémentaire — Wikipédia, l'encyclopédie libre.

Nous avons donc créé un tableau de configuration – une matrice de transposition (21x21) et avons obtenu tous les indicateurs sous forme de lignes.

Avant :


Devenu:


La transposition de la base de données ne prend presque pas de temps. La requête pour tous les indicateurs de la semaine était toujours exécutée en environ 10 secondes. Cependant, nous avons perdu en flexibilité pour la création de tableaux de bord sur un indicateur précis, c'est-à-dire que pour la partie droite du tableau de bord, où la dynamique et le détail d'un indicateur spécifique sont présentés, le tableau de bord s'exécutait auparavant en 1-3 secondes, car la requête ne portait que sur un indicateur, alors qu'à présent la base de données sélectionne toujours tous les indicateurs et filtre le résultat avant de le renvoyer à Tableau.

En conséquence, la vitesse de fonctionnement du tableau de bord a diminué presque de trois fois.

Résultat :

1. 5 sec — parsing du tableau de bord, visualisations
2. 15-20 sec — préparation à la compilation des requêtes avec exécution des précalculs dans Tableau
3. 35-45 sec — compilation des requêtes SQL et exécution parallèle-séquentielle dans Hana
4. 5 sec — traitement des résultats, tri, recalcul des visualisations dans Tableau
5. Bien sûr, de tels résultats ne satisfaisaient pas l'entreprise, et nous avons poursuivi l'optimisation.

Étape 2. Minimum de logique dans Tableau, matérialisation complète

Nous savions qu'il était impossible de construire un tableau de bord avec un temps de réponse de quelques secondes sur une vitrine qui fonctionne en 10 secondes, et nous avons envisagé des options de matérialisation des données du côté de la base de données spécifiquement pour le tableau de bord requis. Mais nous avons été confrontés à un problème global, décrit ci-dessus - des indicateurs non-additifs. Nous n'avons pas pu faire en sorte que lors de changements de filtres ou de déploiements, Tableau puisse passer de manière flexible entre différentes vitrines et niveaux, pré-calculés 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, de renoncer à la hiérarchie des produits dans le tableau de bord et de voir à quelle vitesse il pourrait être dans une version simplifiée.

Ainsi, à cette dernière étape, nous avons créé un stockage séparé dans lequel nous avons accumulé, sous forme transposée, tous les KPI. Du côté de la base de données, toute requête vers ce stockage s'exécute en 0,1 - 0,3 secondes. Dans le tableau de bord, nous avons obtenu les résultats suivants :

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

Le temps consacré par Tableau se compose de :

1. 0,3 sec. — parsing du tableau de bord et compilation des requêtes SQL
2. 1,5-3 sec. — exécution des requêtes SQL dans Hana pour les principales visualisations (lancé en parallèle avec le p.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 pertinentes des filtres (marque, division, ville, magasin), analyse des résultats

Pour résumer brièvement

Nous avons apprécié l'outil Tableau en termes de visualisation. Lors de l'étape de conception, nous avons examiné différents éléments de visualisation et les avons tous trouvés dans les bibliothèques, y compris des segmentations complexes à plusieurs niveaux et des cascades multi-drivers.

En intégrant des tableaux de bord avec des indicateurs clés de vente, nous avons rencontré des difficultés de performance que nous n'avons pas pu surmonter. Nous avons passé plus de deux mois à développer un tableau de bord fonctionnellement incomplet, dont la vitesse de réponse était à la limite du tolérable. Nous en avons tiré les conclusions suivantes :

1. Tableau ne peut pas gérer de gros volumes de données. Si votre modèle de données d'origine contient plus de 10 Go de données (environ 200 millions de lignes x 50 colonnes), le tableau de bord ralentit sérieusement — de 10 secondes à plusieurs minutes par clic. Nous avons effectué des expériences avec une connexion en direct et des extractions. La vitesse de travail est comparable.
2. Limitation lors de l'utilisation de plusieurs entrepôts (ensembles de données). Il n'est pas possible d'indiquer les relations entre les ensembles de données avec des moyens standard. Si vous utilisez des solutions alternatives pour relier les ensembles de données, cela affectera considérablement la performance. Dans notre cas, nous avons envisagé de matérialiser les données dans chaque découpage de visualisation nécessaire et de faire des basculements sur ces ensembles de données matérialisés tout en conservant les filtres sélectionnés précédemment — cela s'est avéré impossible à réaliser 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 une extraction ou lors d'une connexion en direct avec le résultat d'une autre sélection de cet ensemble de données ou d'un autre résultat de requête SQL, seulement une saisie utilisateur native ou une constante.
4. Limitations liées à la création de tableaux de bord avec des éléments OLAP | Tableaux croisés dynamiques.
   Dans MSTR, SAP SAC, SAP Analysis, lorsque vous ajoutez un ensemble de données à un rapport, tous les objets qui en découlent sont liés entre eux par défaut. Ce n'est pas le cas dans Tableau, où les liens doivent être configurés manuellement. Cela offre probablement plus de flexibilité, mais pour tous nos tableaux de bord, c'est une exigence obligatoire pour les éléments — d'où des coûts supplémentaires en main-d'œuvre. De plus, si vous créez des filtres liés pour que, par exemple, lors de la filtration d'une région, la liste des villes soit limitée aux villes de cette région, vous vous retrouvez immédiatement avec des requêtes consécutives à la base de données ou à l'extrait, ce qui ralentit considérablement le tableau de bord.
5. Restrictions dans les fonctions. Ni sur l'extrait, ni SURTOUT sur l'ensemble de données issu de Live Connect, il n'est pas possible de procéder à des transformations massives. Cela peut être fait via Tableau Prep, mais cela représente des coûts supplémentaires en main-d'œuvre et un outil de plus qu'il faut apprendre et maintenir. Par exemple, vous ne pouvez pas transposer des données, ni effectuer un join dessus elles-mêmes. Cela se limite à des transformations sur des colonnes ou champs individuels, qui doivent être sélectionnés via case ou if, ce qui engendre des requêtes SQL très complexes, où la base passe le gros de son temps à compiler le texte de la requête. Ces rigidités de l'outil ont dû être résolues au niveau de la vitrine, ce qui entraîne une complexité accrue du stockage, des charges supplémentaires et des transformations.

Nous n'avons pas tiré un trait sur Tableau. Mais en tant qu'outil capable de construire des tableaux de bord industriels et comme moyen de remplacer et de numériser tout le système de reporting d'entreprise, Tableau n'est pas considéré.

Nous sommes actuellement en train de développer un tableau de bord similaire sur un autre outil et essayons parallèlement de revoir l'architecture du tableau de bord dans Tableau pour encore plus le simplifier. Si la communauté est intéressée, nous partagerons les résultats.

Nous attendons également vos idées ou conseils sur la manière de construire des tableaux de bord rapides dans Tableau avec de tels volumes de données, car nous avons aussi un site où les données sont bien plus nombreuses qu'en vente au détail.

Source : habr.com