Tableau im Einzelhandel, wirklich?

Die Zeit für die Berichterstellung in Excel verschwindet rasant – der Trend zu komfortablen Tools zur Darstellung und Analyse von Informationen ist in allen Bereichen sichtbar. Wir diskutieren intern schon lange über die Digitalisierung des Reportings und haben uns für das Visualisierungs- und Self-Service-Analysesystem Tableau entschieden. Alexander Bezugly, Leiter der Abteilung für analytische Lösungen und Reporting der M.Video-Eldorado Group, sprach über die Erfahrungen und Ergebnisse beim Aufbau eines Kampf-Dashboards.

Ich sage gleich, dass nicht alles, was geplant war, verwirklicht wurde, aber die Erfahrung war interessant und ich hoffe, dass sie auch für Sie nützlich sein wird. Und wenn jemand eine Idee hat, wie man es besser machen könnte, wäre ich für Ratschläge und Ideen sehr dankbar.

Im Folgenden erfahren Sie, was uns begegnet ist und was wir gelernt haben.

Wo haben wir angefangen?

M.Video-Eldorado verfügt über ein gut entwickeltes Datenmodell: strukturierte Informationen mit der erforderlichen Speichertiefe und eine große Anzahl fester Berichte (siehe weitere Details). Dieser Artikel). Daraus erstellen Analysten entweder Pivot-Tabellen oder formatierte Newsletter in Excel oder schöne PowerPoint-Präsentationen für Endbenutzer.

Vor etwa zwei Jahren haben wir begonnen, analytische Berichte anstelle von Berichten in fester Form in SAP Analysis zu erstellen (ein Excel-Add-on, im Wesentlichen eine Pivot-Tabelle über der OLAP-Engine). Allerdings konnte dieses Tool nicht den Bedürfnissen aller Nutzer gerecht werden; die Mehrheit nutzte weiterhin zusätzlich von Analysten aufbereitete Informationen.

Unsere Endbenutzer lassen sich in drei Kategorien einteilen:

Top-Management. Fordert Informationen auf gut präsentierte und klar verständliche Weise an.

Mittlere Führungsebene, fortgeschrittene Benutzer. Interessiert an der Datenexploration und in der Lage, selbstständig Berichte zu erstellen, sofern Tools verfügbar sind. Sie wurden zu den Hauptnutzern von Analyseberichten in SAP Analysis.

Massenbenutzer. Sie sind nicht daran interessiert, Daten selbstständig zu analysieren; sie nutzen Berichte mit eingeschränktem Freiheitsgrad, im Format von Newslettern und Pivot-Tabellen in Excel.

Unsere Idee war es, die Bedürfnisse aller Benutzer abzudecken und ihnen ein einziges, praktisches Tool zur Verfügung zu stellen. Wir haben uns entschieden, beim Top-Management zu beginnen. Sie benötigten benutzerfreundliche Dashboards, um wichtige Geschäftsergebnisse zu analysieren. Also begannen wir mit Tableau und wählten zunächst zwei Richtungen: Einzelhandels- und Online-Verkaufsindikatoren mit begrenzter Analysetiefe und -breite, die etwa 80 % der vom Top-Management angeforderten Daten abdecken würden.

Da es sich bei den Nutzern der Dashboards um das Top-Management handelte, tauchte ein weiterer zusätzlicher KPI des Produkts auf – die Reaktionsgeschwindigkeit. Niemand wird 20 bis 30 Sekunden warten, bis die Daten aktualisiert werden. Die Navigation sollte innerhalb von 4–5 Sekunden oder besser noch sofort erfolgen. Und das ist uns leider nicht gelungen.

So sah das Layout unseres Haupt-Dashboards aus:

Die Kernidee besteht darin, die wichtigsten KPI-Treiber, von denen es insgesamt 19 gab, auf der linken Seite zusammenzufassen und auf der rechten Seite ihre Dynamik und Aufschlüsselung nach Hauptattributen darzustellen. Die Aufgabe erscheint einfach, die Visualisierung ist logisch und verständlich, bis man in die Details eintaucht.

Detail 1. Datenvolumen

Unsere Haupttabelle für den Jahresumsatz umfasst etwa 300 Millionen Zeilen. Da es notwendig ist, die Dynamik des letzten Jahres und des Vorjahres abzubilden, beträgt allein das Datenvolumen zu den tatsächlichen Verkäufen etwa 1 Milliarde Zeilen. Informationen zu Plandaten und zur Online-Verkaufssperre werden ebenfalls separat gespeichert. Daher betrug die Geschwindigkeit der Abfrage mit der Auswahl aller Indikatoren für eine Woche aus dem aktuellen Speicher im laufenden Betrieb, obwohl wir die spaltenbasierte In-Memory-DB SAP HANA verwendeten, etwa 15–20 Sekunden. Die Lösung dieses Problems liegt auf der Hand: zusätzliche Materialisierung von Daten. Aber es gibt auch Fallstricke, mehr dazu weiter unten.

Detail 2. Nicht-additive Indikatoren

Viele unserer KPIs sind an die Anzahl der Belege gebunden. Und dieser Indikator stellt COUNT DISTINCT der Anzahl der Zeilen dar (Prüfkopfzeilen) und zeigt abhängig von den ausgewählten Attributen unterschiedliche Beträge an. Wie dieser Indikator und seine Ableitung beispielsweise berechnet werden sollten:

Um Ihre Berechnungen korrekt zu machen, können Sie:

• Berechnen Sie solche Indikatoren im Handumdrehen im Speicher;
• Führen Sie Berechnungen über das gesamte Datenvolumen in Tableau durch, d. h. auf Wunsch in Tableau alle Daten nach ausgewählten Filtern in der Granularität der Belegposition bereitstellen;
• Erstellen Sie eine materialisierte Vitrine, in der alle Indikatoren in allen Beispieloptionen berechnet werden, die unterschiedliche nichtadditive Ergebnisse liefern.

Es ist klar, dass es sich bei UTE1 und UTE2 im Beispiel um Materialattribute handelt, die die Produkthierarchie repräsentieren. Das ist keine statische Sache, die Steuerung innerhalb des Unternehmens erfolgt dadurch, denn Für unterschiedliche Produktgruppen sind unterschiedliche Manager zuständig. Wir hatten viele globale Überarbeitungen dieser Hierarchie, bei denen sich alle Ebenen änderten, wenn Beziehungen überarbeitet wurden, und ständige Punktänderungen, wenn eine Gruppe von einem Knoten zum anderen wechselte. Im herkömmlichen Reporting wird all dies im Handumdrehen aus den Attributen des Materials berechnet; im Falle der Materialisierung dieser Daten ist es notwendig, einen Mechanismus zu entwickeln, um solche Änderungen zu verfolgen und historische Daten automatisch neu zu laden. Eine sehr nicht triviale Aufgabe.

Detail 3. Datenvergleich

Dieser Punkt ähnelt dem vorherigen. Unterm 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)

Bei diesem Vergleich wird davon ausgegangen, dass wir je nach dem vom Benutzer ausgewählten Zeitraum (z. B. der 33. Woche des Jahres) die Dynamik bis zur 32. Woche anzeigen sollten; wenn wir Daten für einen Monat ausgewählt haben, z. B. Mai , dann würde dieser Vergleich die Dynamik bis April zeigen.

Vergleich mit letztem Jahr

Die wichtigste Nuance besteht darin, dass Sie beim Vergleich nach Tag und Woche nicht denselben Tag des letzten Jahres verwenden, d. h. Sie können das aktuelle Jahr nicht einfach minus eins setzen. Sie müssen auf den Wochentag achten, den Sie vergleichen. Beim Vergleich von Monaten hingegen müssen Sie genau den gleichen Kalendertag des letzten Jahres heranziehen. Auch bei Schaltjahren gibt es Nuancen. In den ursprünglichen Repositories sind alle Informationen nach Tagen verteilt; es gibt keine separaten Felder mit Wochen, Monaten oder Jahren. Um einen vollständigen analytischen Querschnitt im Panel zu erhalten, müssen Sie daher nicht einen Zeitraum, beispielsweise eine Woche, sondern 4 Wochen zählen und diese Daten dann vergleichen, um die Dynamik und Abweichungen widerzuspiegeln. Dementsprechend kann diese Logik zur Generierung von Vergleichen in der Dynamik auch entweder in Tableau oder auf der Storefront-Seite implementiert werden. Ja, und natürlich kannten wir diese Details in der Entwurfsphase und haben darüber nachgedacht, aber es war schwierig, ihre Auswirkungen auf die Leistung des endgültigen Dashboards vorherzusagen.

Bei der Implementierung des Dashboards sind wir den langen agilen Weg gegangen. Unsere Aufgabe bestand darin, schnellstmöglich ein funktionsfähiges Tool mit den notwendigen Daten zum Testen bereitzustellen. Deshalb sind wir in Sprints vorgegangen und haben mit der Minimierung der Arbeit auf der Seite des aktuellen Speichers begonnen.

Teil 1: Glaube an Tableau

Um den IT-Support zu vereinfachen und Änderungen schnell umzusetzen, haben wir uns entschieden, die Logik zur Berechnung nichtadditiver Indikatoren und zum Vergleich vergangener Zeiträume in Tableau zu erstellen.

Stufe 1. Alles ist Live, keine Fensteränderungen.

Zu diesem Zeitpunkt haben wir Tableau mit den aktuellen Storefronts verbunden und beschlossen, zu prüfen, wie die Anzahl der Belege für ein Jahr berechnet werden würde.

Ergebnis:

Die Antwort war deprimierend – 20 Minuten. Datenübertragung über das Netzwerk, hohe Belastung von Tableau. Wir haben erkannt, dass Logik mit nicht-additiven Indikatoren auf HANA implementiert werden muss. Das machte uns keine große Angst, wir hatten bereits ähnliche Erfahrungen mit BO und Analysis und wussten, wie man in HANA schnelle Showcases erstellt, die korrekt berechnete nicht-additive Indikatoren erzeugen. Jetzt mussten sie nur noch an Tableau angepasst werden.

Stufe 2. Wir stimmen die Vitrinen ab, keine Materialisierung, alles im laufenden Betrieb.

Wir haben einen separaten neuen Showcase erstellt, der die erforderlichen Daten für TABLEAU im Handumdrehen produzierte. Im Allgemeinen haben wir ein gutes Ergebnis erzielt; wir haben die Zeit für die Generierung aller Indikatoren in einer Woche auf 9-10 Sekunden reduziert. Und wir haben ehrlich gesagt erwartet, dass in Tableau die Reaktionszeit des Dashboards beim ersten Öffnen 20 bis 30 Sekunden betragen würde und dann aufgrund des Caches von 10 auf 12, was uns im Allgemeinen zusagen würde.

Ergebnis:

Erstes geöffnetes Dashboard: 4–5 Minuten
Jeder Klick: 3-4 Minuten
Niemand hatte mit einer solchen zusätzlichen Steigerung der Ladenarbeit gerechnet.

Teil 2. Tauchen Sie ein in Tableau

Stufe 1. Tableau-Leistungsanalyse und schnelle Optimierung

Wir begannen zu analysieren, wo Tableau die meiste Zeit verbringt. Und dafür gibt es recht gute Tools, was natürlich ein Plus von Tableau ist. Das Hauptproblem, das wir identifizierten, waren die sehr komplexen SQL-Abfragen, die Tableau erstellte. Sie wurden hauptsächlich mit Folgendem in Verbindung gebracht:

— Datentransposition. Da Tableau nicht über Tools zum Transponieren von Datensätzen verfügt, mussten wir zum Erstellen der linken Seite des Dashboards mit einer detaillierten Darstellung aller KPIs eine Tabelle anhand eines Falls erstellen. Die Größe der SQL-Abfragen in der Datenbank erreichte 120 Zeichen.

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

Diese. Anforderungsverarbeitung 12 Sekunden + 5 Sekunden Ausführung.

Wir haben uns entschieden, die Berechnungslogik auf der Tableau-Seite zu vereinfachen und einen anderen Teil der Berechnungen auf die Storefront- und Datenbankebene zu verlagern. Dies brachte gute Ergebnisse.

Zuerst haben wir die Transposition im laufenden Betrieb durchgeführt, und zwar über einen vollständigen Outer-Join in der letzten Phase der VIEW-Berechnung, gemäß diesem im Wiki beschriebenen Ansatz Transponieren – Wikipedia, die freie Enzyklopädie и Elementarmatrix – Wikipedia, die freie Enzyklopädie.

Das heißt, wir haben eine Einstelltabelle erstellt – eine Transpositionsmatrix (21x21) und alle Indikatoren zeilenweise aufgeschlüsselt erhalten.

Es war:


Wurde:


Für die Datenbankumsetzung selbst wird nahezu keine Zeit aufgewendet. Die Anfrage nach allen Indikatoren für die Woche wurde weiterhin in etwa 10 Sekunden verarbeitet. Andererseits ist jedoch die Flexibilität bei der Erstellung eines Dashboards auf der Grundlage eines bestimmten Indikators verloren gegangen, d. h. Für die rechte Seite des Armaturenbretts, wo die Dynamik und die detaillierte Aufschlüsselung eines bestimmten Indikators dargestellt werden, funktionierte die Vitrine bisher in 1-3 Sekunden, weil Die Anfrage basierte auf einem Indikator, und jetzt wählte die Datenbank immer alle Indikatoren aus und filterte das Ergebnis, bevor sie das Ergebnis an Tableau zurückgab.

Dadurch verringerte sich die Geschwindigkeit des Armaturenbretts um fast das Dreifache.

Ergebnis:

1. 5 Sek. – Dashboards und Visualisierungen analysieren
2. 15–20 Sekunden – Vorbereitung zum Kompilieren von Abfragen mit Durchführung von Vorberechnungen in Tableau
3. 35-45 Sek. - Kompilierung von SQL-Abfragen und deren parallel-sequentielle Ausführung in Hana
4. 5 Sek. – Ergebnisse verarbeiten, sortieren, Visualisierungen in Tableau neu berechnen
5. Natürlich passten solche Ergebnisse nicht zum Geschäft und wir haben die Optimierung fortgesetzt.

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

Uns war klar, dass es unmöglich war, ein Dashboard mit einer Reaktionszeit von mehreren Sekunden auf einer Storefront zu erstellen, die 10 Sekunden lang läuft, und wir haben Optionen zur Materialisierung von Daten auf der Datenbankseite speziell für das erforderliche Dashboard in Betracht gezogen. Wir sind jedoch auf ein oben beschriebenes globales Problem gestoßen – nichtadditive Indikatoren. Wir konnten nicht sicherstellen, dass Tableau beim Ändern von Filtern oder Drilldowns flexibel zwischen verschiedenen Storefronts und Ebenen wechselt, die für unterschiedliche Produkthierarchien vorgefertigt sind (im Beispiel generieren drei Abfragen ohne UTE, mit UTE1 und UTE2 unterschiedliche Ergebnisse). Deshalb haben wir uns entschieden, das Dashboard zu vereinfachen, die Produkthierarchie im Dashboard aufzugeben und zu sehen, wie schnell es in einer vereinfachten Version sein könnte.

Deshalb haben wir in dieser letzten Phase ein separates Repository zusammengestellt, in dem wir alle KPIs in transponierter Form hinzugefügt haben. Auf der Datenbankseite wird jede Anfrage an einen solchen Speicher in 0,1 – 0,3 Sekunden verarbeitet. Im Dashboard haben wir folgende Ergebnisse erhalten:

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

Die von Tableau aufgewendete Zeit besteht aus:

1. 0,3 Sek. — Dashboard-Analyse und Kompilierung von SQL-Abfragen
2. 1,5-3 Sek. — Ausführung von SQL-Abfragen in Hana für Hauptvisualisierungen (läuft parallel zu Schritt 1)
3. 1,5-2 Sek. — Rendering, Neuberechnung von Visualisierungen
4. 1,3 Sek. — Ausführung zusätzlicher SQL-Abfragen, um relevante Filterwerte (Marke, Abteilung, Stadt, Geschäft) zu erhalten und Ergebnisse zu analysieren

Um es kurz zusammenzufassen

Aus Sicht der Visualisierung gefiel uns das Tableau-Tool. In der Prototyping-Phase haben wir verschiedene Visualisierungselemente berücksichtigt und sie alle in Bibliotheken gefunden, einschließlich einer komplexen mehrstufigen Segmentierung und eines Wasserfalls mit mehreren Treibern.

Bei der Implementierung von Dashboards mit wichtigen Vertriebsindikatoren sind wir auf Leistungsschwierigkeiten gestoßen, die wir bisher nicht überwinden konnten. Wir haben mehr als zwei Monate gebraucht und ein funktional unvollständiges Dashboard erhalten, dessen Reaktionsgeschwindigkeit nahezu akzeptabel ist. Und wir haben daraus Schlussfolgerungen gezogen:

1. Tableau kann nicht mit großen Datenmengen arbeiten. Wenn Sie im ursprünglichen Datenmodell über mehr als 10 GB Daten (ungefähr 200 Millionen x 50 Zeilen) verfügen, wird das Dashboard erheblich langsamer – 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 zwischen Datensätzen mit Standardmitteln anzuzeigen. Wenn Sie Problemumgehungen zum Verbinden von Datensätzen verwenden, wirkt sich dies stark auf die Leistung aus. In unserem Fall haben wir die Möglichkeit in Betracht gezogen, Daten in jedem erforderlichen Ansichtsabschnitt zu materialisieren und diese materialisierten Datensätze unter Beibehaltung der zuvor ausgewählten Filter zu ändern – dies stellte sich in Tableau als unmöglich heraus.
3. Es ist nicht möglich, dynamische Parameter in Tableau festzulegen. Sie können einen Parameter, der zum Filtern eines Datensatzes in einem Extrakt oder während einer Live-Verbindung verwendet wird, nicht mit dem Ergebnis einer anderen Auswahl aus dem Datensatz oder dem Ergebnis einer anderen SQL-Abfrage füllen, sondern nur mit nativer Benutzereingabe oder einer Konstante.
4. Einschränkungen im Zusammenhang mit der Erstellung eines Dashboards mit OLAP|PivotTable-Elementen.
   Wenn Sie in MSTR, SAP SAC und SAP Analysis einen Datensatz zu einem Bericht hinzufügen, sind alle darin enthaltenen Objekte standardmäßig miteinander verknüpft. Tableau verfügt nicht über diese Möglichkeit; die Verbindung muss manuell konfiguriert werden. Dies ist wahrscheinlich flexibler, aber für alle unsere Dashboards ist dies eine zwingende Voraussetzung für Elemente – es entstehen also zusätzliche Arbeitskosten. Wenn Sie außerdem verwandte Filter vornehmen, sodass beispielsweise beim Filtern einer Region die Liste der Städte nur auf die Städte dieser Region beschränkt ist, kommt es sofort zu aufeinanderfolgenden Abfragen an die Datenbank oder den Extrakt, was die Verarbeitung merklich verlangsamt Armaturenbrett.
5. Einschränkungen in den Funktionen. Massentransformationen können weder am Extrakt noch INSBESONDERE am Datensatz von Live-connecta durchgeführt werden. Dies kann über Tableau Prep erfolgen, es ist jedoch zusätzlicher Aufwand und ein weiteres zu erlernendes und zu pflegendes Tool. Sie können beispielsweise Daten nicht transponieren oder mit sich selbst verbinden. Was durch Transformationen auf einzelne Spalten oder Felder geschlossen wird, die durch Groß-/Kleinschreibung oder If ausgewählt werden müssen, erzeugt sehr komplexe SQL-Abfragen, bei denen die Datenbank die meiste Zeit mit dem Kompilieren des Abfragetexts verbringt. Diese Inflexibilität des Tools musste auf der Showcase-Ebene behoben werden, was zu komplexerer Speicherung, zusätzlichen Downloads und Transformationen führt.

Wir haben Tableau nicht aufgegeben. Aber wir betrachten Tableau nicht als ein Werkzeug, das in der Lage ist, industrielle Dashboards zu erstellen und als ein Werkzeug, mit dem sich das gesamte Unternehmensberichtssystem eines Unternehmens ersetzen und digitalisieren lässt.

Wir entwickeln derzeit aktiv ein ähnliches Dashboard in einem anderen Tool und versuchen gleichzeitig, die Dashboard-Architektur in Tableau zu überarbeiten, um sie noch weiter zu vereinfachen. Wenn die Community Interesse hat, werden wir Sie über die Ergebnisse informieren.

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

Source: habr.com