Tableau im Einzelhandel, wirklich?

Die Berichtszeit in Excel geht schnell zur Neige - der Trend zu komfortablen Tools für die Darstellung und Analyse von Informationen ist in allen Bereichen sichtbar. Wir haben uns lange mit der Digitalisierung des Berichtsgebäudes befasst und uns für das Tableau-Visualisierungs- und Self-Service-Analysesystem entschieden. Alexander Bezugly, Leiter der Abteilung für analytische Lösungen und Berichterstellung der M. Video-Eldorado-Gruppe, sprach über die Erfahrungen und Ergebnisse der Erstellung eines Kampf-Dashboards.

Ich muss sofort sagen, dass nicht alles, was geplant war, realisiert wurde, aber die Erfahrung war interessant, ich hoffe, es wird auch für Sie von Nutzen sein. Und wenn jemand Ideen hat, wie man es besser machen kann, bin ich sehr dankbar für die Ratschläge und Ideen.



Unter dem Strich darüber, was uns begegnet ist und was wir gelernt haben.

Wo haben wir angefangen?

„M. Video-Eldorado“ verfügt über ein ausgereiftes Datenmodell: Strukturierte Informationen mit der erforderlichen Speichertiefe und einer Vielzahl von Berichten in fester Form (Details finden Sie in diesem Artikel ). Von diesen erstellen Analysten entweder Pivot-Tabellen oder formatierte Mailings in Excel oder ansprechende Präsentationen in PowerPoint für Endbenutzer.

Vor ungefähr zwei Jahren haben wir begonnen, in SAP Analysis (einem Add-In für Excel - eine Pivot-Tabelle über die OLAP-Engine) anstelle von Berichten in fester Form analytische Berichte zu erstellen. Dieses Tool war jedoch nicht in der Lage, die Anforderungen aller Benutzer zu erfüllen. Die meisten verwendeten weiterhin Informationen, die zusätzlich von Analysten verarbeitet wurden.

Unsere Endbenutzer sind in drei Kategorien unterteilt:

Top-Management . Fordert Informationen in übersichtlicher und verständlicher Form an.

Mittleres Management , fortgeschrittene Benutzer. Sie interessieren sich für die Erforschung von Daten und können Berichte mit Tools unabhängig erstellen. Sie wurden zu Hauptbenutzern von Analyseberichten in SAP Analysis.

Massenbenutzer . Da Sie nicht an der Selbstanalyse von Daten interessiert sind, verwenden Sie Berichte mit eingeschränktem Freiheitsgrad im Format von Newslettern und Pivot-Tabellen in Excel.

Unsere Idee war es, die Bedürfnisse aller Benutzer zu decken und ihnen ein einziges praktisches Werkzeug zu geben. Sie beschlossen, mit dem Top-Management zu beginnen. Sie benötigten praktische Dashboards, um die wichtigsten Geschäftsergebnisse zu analysieren. Wir haben also mit Tableau begonnen und uns zunächst für zwei Bereiche entschieden: Einzelhandelsumsätze und Online-Verkäufe mit begrenzter Tiefe und Breite der Analyse, die etwa 80% der vom Top-Management angeforderten Daten abdecken würden.

Da Benutzer von Dashboards das Top-Management waren, erschien ein weiterer zusätzlicher KPI des Produkts - die Reaktionsgeschwindigkeit. Niemand wird 20-30 Sekunden warten, bis die Daten aktualisiert sind. Die Navigation musste in 4-5 Sekunden passen und es war besser, sofort zu trainieren. Leider ist uns dies nicht gelungen.

So sah unser grundlegendes Dashboard-Layout aus:



Die Schlüsselidee besteht darin, die wichtigsten KPI-Treiber, von denen es am Ende 19 gibt, links zu kombinieren und ihre Dynamik und eine Aufschlüsselung der Hauptattribute rechts darzustellen. Die Aufgabe erscheint unkompliziert, die Visualisierung ist logisch und nachvollziehbar, bis Sie auf die Details eingehen.

Detail 1. Datenvolumen

Die Hauptverkaufstabelle für das Jahr belegt rund 300 Millionen Zeilen. Da die Dynamik des letzten und des vorletzten Jahres berücksichtigt werden muss, beläuft sich die Datenmenge allein für den tatsächlichen Umsatz auf etwa 1 Milliarde Zeilen. Außerdem werden Informationen zu geplanten Daten und eine Online-Verkaufseinheit separat gespeichert. Obwohl wir die speicherinterne SAP-HANA-Datenbank verwendet haben, betrug die Abfragegeschwindigkeit bei Auswahl aller Indikatoren für eine Woche aus dem aktuellen Speicher im laufenden Betrieb ungefähr 15 bis 20 Sekunden. Die Lösung dieses Problems bietet sich an - zusätzliche Datenmaterialisierung. Aber es hat auch Fallstricke, darunter.

Teil 2. Nichtadditive Indikatoren

Wir haben viele KPIs, die an die Anzahl der Schecks gebunden sind. Und dieser Indikator ist ein COUNT DISTINCT der Anzahl der Zeilen (Belegköpfe) und zeigt unterschiedliche Beträge in Abhängigkeit von den ausgewählten Attributen. Zum Beispiel, wie dieser Indikator und seine Ableitung zu betrachten sind:



Für die Richtigkeit der Berechnungen können Sie:

• Führen Sie die Berechnung solcher Indikatoren im laufenden Betrieb im Lager durch.
  
• Berechnen Sie die gesamte Datenmenge in Tableau, d. H. Geben Sie auf Anforderung in Tableau alle Daten für die ausgewählten Filter in der Granularität der Prüfposition an.
  
• Erstellung einer materialisierten Präsentation, in der alle Indikatoren in allen Varianten von Proben berechnet werden, die unterschiedliche, nicht additive Ergebnisse liefern.
  

Es ist klar, dass im Beispiel UTE1 und UTE2 Materialattribute sind, die die Produkthierarchie darstellen. Dies ist keine statische Sache, durch die das Management innerhalb des Unternehmens geht, weil Unterschiedliche Produktgruppen sind für unterschiedliche Manager verantwortlich. Wir hatten viele globale Überarbeitungen dieser Hierarchie, als sich alle Ebenen änderten, als Korrelationen überarbeitet wurden und konstante Punktänderungen, als sich eine Gruppe von einem Knoten zum anderen bewegte. Bei der normalen Berichterstellung wird all dies spontan anhand der Attribute des Materials berücksichtigt. Im Fall der Materialisierung dieser Daten ist es erforderlich, einen Mechanismus zur Verfolgung solcher Änderungen und zur automatischen Überladung historischer Daten zu entwickeln. Eine sehr nicht triviale Aufgabe.

Detail 3. Datenvergleich

Dieser Artikel ähnelt dem vorherigen. Unter dem Strich ist es bei der Analyse eines Unternehmens üblich, mehrere Vergleichsebenen mit der Vorperiode zu bilden:

Vergleich mit der Vorperiode (Tag zu Tag, Woche zu Woche, Monat zu Monat)

In diesem Vergleich wird davon ausgegangen, dass in Abhängigkeit von dem vom Benutzer ausgewählten Zeitraum (z. B. Woche 33 des Jahres) die Dynamik bis Woche 32 angezeigt werden muss. Wenn Sie Daten für den Monat, z. B. Mai, auswählen, wird bei diesem Vergleich die Dynamik bis April angezeigt.

Vergleich mit dem letzten Jahr

Die wichtigste Einschränkung besteht darin, dass Sie beim Vergleich nach Tag und Woche nicht denselben Tag des letzten Jahres einnehmen, d. H. Sie können nicht einfach das aktuelle Jahr minus eins setzen. Sie müssen den verglichenen Wochentag beobachten. Im Gegensatz dazu müssen Sie beim Vergleich der Monate genau denselben Kalendertag wie im letzten Jahr verwenden. Es gibt auch Nuancen mit Schaltjahren. In den Quellrepositorys werden alle Informationen nach Tag verteilt. Es gibt keine separaten Felder mit Wochen, Monaten und Jahren. Um eine vollständige analytische Schicht in dem Panel zu erhalten, ist es daher erforderlich, nicht einen Zeitraum, beispielsweise eine Woche, sondern 4 Wochen zu berücksichtigen, und dann sollten diese Daten verglichen werden, um die Dynamik und Abweichungen widerzuspiegeln. Dementsprechend kann diese Logik zum Bilden von Vergleichen in der Dynamik auch entweder in Tableau oder auf der Seite der Storefront implementiert werden. Ja, und natürlich haben wir diese Details in der Entwurfsphase gekannt und darüber nachgedacht, aber ihre Auswirkungen auf die Leistung des endgültigen Dashboards waren schwer vorherzusagen.

Mit der Einführung des Dashboards haben wir einen langen agilen Weg beschritten. Unsere Aufgabe war es, ein Arbeitswerkzeug mit den notwendigen Daten zum Testen so schnell wie möglich bereitzustellen. Aus diesem Grund sind wir Sprints gefahren und haben angefangen, die Arbeit auf der Seite des aktuellen Speichers zu minimieren.

Teil 1. Der Glaube an Tableau

Um den IT-Support zu vereinfachen und Änderungen schnell umzusetzen, haben wir beschlossen, die Logik für die Berechnung nichtadditiver Indikatoren zu erstellen und vergangene Zeiträume in Tableau zu vergleichen.

Stufe 1. Alles in Live, keine Verbesserung der Fensterdekoration.

Zu diesem Zeitpunkt haben wir Tableau mit den aktuellen Storefronts verbunden und entschieden, wie die Anzahl der Schecks in einem Jahr gezählt wird.

Ergebnis:

Die Antwort war bedrückend - 20 Minuten. Netzwerkdatendestillation, hohe Belastung von Tableau. Wir haben erkannt, dass Logik mit nichtadditiven Metriken in HANA implementiert werden muss. Dies hat uns nicht sonderlich erschreckt. Wir hatten bereits ähnliche Erfahrungen mit BO und Analysis und konnten in HANA schnelle Präsentationen erstellen, die korrekt berechnete nichtadditive Indikatoren liefern. Jetzt blieb es, sie unter Tableau zu optimieren.

Stufe 2. Wir stellen die Fenster ein, keine Materialisierung, alles ist im Fluge.

Wir haben einen separaten neuen Showcase erstellt, der im Handumdrehen die erforderlichen Daten für TABLEAU lieferte. Im Allgemeinen haben wir ein gutes Ergebnis erzielt und die Zeit für die Bildung aller Indikatoren in einer Woche auf 9-10 Sekunden verkürzt. Und wir haben ehrlich gesagt erwartet, dass in Tableau die Reaktionszeit des Dashboards beim ersten Öffnen 20 bis 30 Sekunden und dann aufgrund des Cache-Speichers von 10 bis 12 Sekunden beträgt, was im Allgemeinen zu uns passen würde.

Ergebnis:

Erstes offenes Dashboard: 4-5 Minuten
Beliebiger Klick: 3-4 Minuten
Niemand erwartete eine solche zusätzliche Steigerung der Arbeit des Schaufensters.

Teil 2. Eintauchen in Tableau

Phase 1. Tableau-Leistungsanalyse und schnelle Optimierung

Wir begannen zu analysieren, wofür Tableau die meiste Zeit verwendet. Und dafür gibt es ein ziemlich gutes Toolkit, das natürlich plus Tableau ist. Das Hauptproblem, das wir identifiziert haben, waren die sehr komplexen SQL-Abfragen, die Tableau erstellt hat. Sie waren in erster Linie verbunden mit:

- Übermittlung von Daten. Da Tableau über keine Tools zum Transponieren von Datasets verfügt, mussten wir eine Tabelle für den Fall erstellen, um die linke Seite des Dashboards mit einer detaillierten Ansicht aller KPIs zu erstellen. Die Größe der SQL-Abfragen in der Datenbank erreichte 120.000 Zeichen.



- die Wahl des Zeitraums. Die Kompilierung einer solchen Abfrage auf Datenbankebene dauerte länger als die Ausführung:



Das heißt Anforderungsverarbeitung 12 Sekunden + 5 Sekunden Ausführung.

Wir beschlossen, die Logik der Berechnungen auf Tableau-Seite zu vereinfachen und einen weiteren Teil der Berechnungen auf die Storefront- und Datenbankebene zu übertragen. Es brachte gute Ergebnisse.

Zuerst haben wir on the fly transponiert und es in der Endphase der VIEW-Berechnung durch einen vollständigen Outer Join geschafft. Dieser Ansatz wird im Wiki Transpose - Wikipedia, der freien Enzyklopädie, und in Elementary Matrix - Wikipedia, der freien Enzyklopädie, beschrieben .



Das heißt, wir haben eine Stimmtabelle erstellt - die Transponierungsmatrix (21x21) und alle Indikatoren in einer zeilenweisen Aufschlüsselung zusammengestellt.

Es war:


Es wurde:


Die DB selbst verbringt kaum Zeit damit, sich selbst zu transponieren. Die Anfrage nach allen Indikatoren für die Woche erfüllte sich nach wie vor in ca. 10 Sekunden. Auf der anderen Seite jedoch Flexibilität hinsichtlich der Erstellung eines Dashboards anhand eines bestimmten Indikators, d. H. Für die rechte Seite des Dashboards, auf der die Dynamik und eine detaillierte Aufschlüsselung eines bestimmten Indikators dargestellt werden, wurde das Schaufenster in 1-3 Sekunden zuvor ausgearbeitet, weil Die Abfrage wurde für einen Indikator ausgeführt, und jetzt hat die Datenbank immer alle Indikatoren ausgewählt und das Ergebnis gefiltert, bevor das Ergebnis an Tableau zurückgegeben wurde.

Infolgedessen wurde die Geschwindigkeit des Armaturenbretts um fast das Dreifache verringert.

Ergebnis:

1. 5 separate Dashboards, Visualisierungen
2. 15-20 Sek. - Vorbereitung für die Erstellung von Abfragen mit Durchführung von Vorberechnungen in Tableau
3. 35-45 sec - Zusammenstellung von SQL-Abfragen und deren parallele sequentielle Ausführung in Hana
4. 5 Sek. - Ergebnisse verarbeiten, sortieren, Visualisierungen neu berechnen in Tableau
5. Natürlich passten solche Ergebnisse nicht zum Geschäft, und wir haben weiter optimiert.

Stufe 2. Minimale Logik in Tableau, vollständige Materialisierung

Wir haben verstanden, dass es unmöglich ist, ein Dashboard mit einer Antwortzeit von mehreren Sekunden in einem Geschäftsfenster zu erstellen, das 10 Sekunden lang funktioniert, und wir haben Optionen für die Materialisierung datenbankseitiger Daten speziell für das erforderliche Dashboard in Betracht gezogen. Konfrontiert mit dem oben beschriebenen globalen Problem - nichtadditiven Indikatoren. Wir konnten es nicht so machen, dass Tableau beim Wechseln von Filtern oder Scans flexibel zwischen verschiedenen Storefronts und Ebenen umschaltete, die für verschiedene Produkthierarchien berechnet wurden (im Beispiel ergeben drei Abfragen ohne UTE mit UTE1 und UTE2 unterschiedliche Ergebnisse). Aus diesem Grund haben wir beschlossen, das Dashboard zu vereinfachen, die Produkthierarchie im Dashboard aufzugeben und zu sehen, wie schnell es in der vereinfachten Version sein kann.

In dieser letzten Phase haben wir ein separates Repository zusammengestellt, in dem alle KPIs umgesetzt wurden. Auf der Datenbankseite wird jede Anforderung an ein solches Repository in 0,1 bis 0,3 Sekunden erfüllt. Im Dashboard haben wir die folgenden Ergebnisse erhalten:

Erstes Öffnen: 8-10 Sekunden
Jeder Klick: 6-7 Sekunden

Die Zeit, die Tableau verbringt, besteht aus:

1. 0,3 sek - Analysieren von Dashboards und Kompilieren von SQL-Abfragen
   
2. 1,5-3 sek. - Ausführung von SQL-Abfragen in Hana für grundlegende Visualisierungen (beginnt parallel zu Punkt 1)
   
3. 1,5-2 sek. - Rendering, Neuberechnung von Visualisierungen
   
4. 1,3 Sek - Ausführung zusätzlicher SQL-Abfragen, um relevante Filterwerte (Marke, Division, Stadt, Geschäft) zu erhalten, Analyseergebnisse
   

Um es zusammenzufassen

In Bezug auf die Visualisierung hat uns das Tableau-Tool gefallen. In der Prototypenphase haben wir verschiedene Visualisierungselemente untersucht und alle in Bibliotheken gefunden, einschließlich komplexer mehrstufiger Segmentierungen und Wasserfälle mit mehreren Treibern.

Durch die Einführung von Dashboards mit wichtigen Verkaufsindikatoren stießen wir auf Leistungsschwierigkeiten, die wir noch nicht überwinden konnten. Wir verbrachten mehr als zwei Monate und erhielten ein funktionsunvollständiges Dashboard, dessen Reaktionsgeschwindigkeit kurz vor der Erlaubnis steht. Und für mich schlussfolgerten wir:

1. Tableau kann nicht mit großen Datenmengen arbeiten. Wenn Sie im ursprünglichen Datenmodell über mehr als 10 GB Daten (ca. 200 Millionen x 50 Zeilen) verfügen, wird das Dashboard erheblich verlangsamt - von 10 Sekunden auf mehrere Minuten pro Klick. Wir haben sowohl mit Live-Connect als auch mit Extract experimentiert. Die Arbeitsgeschwindigkeit ist vergleichbar.
   
2. Einschränkung bei Verwendung mehrerer Speicher (Datensätze). Es gibt keine Möglichkeit, die Beziehung von Datensätzen mit Standardwerkzeugen anzugeben. Wenn Sie Problemumgehungen zum Verbinden von Datasets verwenden, wirkt sich dies erheblich auf die Leistung aus. In unserem Fall haben wir die Option in Betracht gezogen, Daten in jedem gewünschten Abschnitt der Darstellungen zu materialisieren und auf diesen materialisierten Datensätzen zu wechseln, um die zuvor ausgewählten Filter zu speichern - dies war in Tableau nicht möglich.
   
3. In Tableau können keine dynamischen Parameter erstellt werden. Sie können den Parameter, der zum Filtern des Datasets im Extrakt verwendet wird, weder während der Live-Verbindung noch zum Ausfüllen des Ergebnisses einer anderen Auswahl aus dem Dataset oder des Ergebnisses einer anderen SQL-Abfrage verwenden, sondern nur native Benutzereingaben oder Konstanten.
   
4. Einschränkungen beim Erstellen eines Dashboards mit OLAP | PivotTable-Elementen.
   Wenn Sie in MSTR, SAP SAC, SAP Analysis einem Bericht ein Dataset hinzufügen, werden standardmäßig alle Objekte auf diesem Bericht miteinander verbunden. In Tableau ist dies nicht der Fall, die Verbindung muss manuell konfiguriert werden. Dies ist wahrscheinlich flexibler, aber für alle unsere Dashboards ist dies eine obligatorische Anforderung für die Elemente - dies ist also ein zusätzlicher Arbeitsaufwand. Wenn Sie verwandte Filter erstellen, sodass beispielsweise beim Filtern einer Region die Liste der Städte nur auf die Städte dieser Region beschränkt ist, werden sofort aufeinanderfolgende Abfragen an die Datenbank oder den Extrakt gesendet, wodurch das Dashboard spürbar verlangsamt wird.
5. Funktionseinschränkungen. Sowohl über den Auszug als auch MEHR ALS über den Datensatz von Live-connecta können Sie keine Massenkonvertierungen durchführen. Dies kann über Tableau Prep erfolgen, ist jedoch eine zusätzliche Arbeit und ein weiteres Werkzeug, das untersucht und gewartet werden muss. Sie können zum Beispiel keine Daten transponieren, sondern sie selbst zusammenfügen. Was schließt sich durch Transformationen einzelner Spalten oder Felder, die durch case oder if ausgewählt werden müssen, und dies erzeugt sehr komplexe SQL-Abfragen, in denen die Datenbank die meiste Zeit damit verbringt, den Abfragetext zu kompilieren. Diese Instrumentensteifigkeiten mussten auf der Storefront-Ebene gelöst werden, was zu einer komplizierteren Lagerung, zusätzlichen Lasten und Transformationen führte.
   

Wir haben Tableau kein Ende gesetzt. Tableau wird jedoch nicht als Tool zum Erstellen industrieller Dashboards und als Tool zum Ersetzen und Digitalisieren des gesamten Unternehmensberichtssystems des Unternehmens betrachtet.

Jetzt entwickeln wir aktiv ein ähnliches Dashboard für ein anderes Tool und versuchen gleichzeitig, die Architektur des Dashboards in Tableau zu überarbeiten, um es noch weiter zu vereinfachen. Wenn die Community interessiert ist, werden wir Sie über die Ergebnisse informieren.

Wir warten auch auf Ihre Ideen oder Ratschläge, wie Tabeau schnelle Dashboards für so große Datenmengen erstellen kann, da wir auch eine Website haben, auf der es viel mehr Daten als im Einzelhandel gibt.