Tableau im Einzelhandel, wirklich?

Die Zeit für die Berichterstattung in Excel geht schnell zu Ende – der Trend zu benutzerfreundlichen Tools zur Präsentation und Analyse von Informationen ist in allen Bereichen sichtbar. Wir haben bereits intern über die Digitalisierung der Berichterstellung diskutiert und uns für das Visualisierungs- und Self-Service-Analyse-System Tableau entschieden. Alexander Bezugly, Leiter der Abteilung für analytische Lösungen und Berichterstattung der Gruppe „M.Video-Eldorado“, sprach über die Erfahrungen und Ergebnisse beim Aufbau eines operativen Dashboards.

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

Im Folgenden erfahren Sie, mit welchen Herausforderungen wir konfrontiert waren und was wir gelernt haben.

Wie wir angefangen haben

In der Gruppe „M.Video-Eldorado“ gibt es ein gut ausgearbeitetes Datenmodell: strukturierte Informationen mit der erforderlichen Speichertiefe und eine große Anzahl von festen Berichtsvorlagen (siehe Details diesen Artikel geschrieben). Daraus erstellen Analysten entweder Pivot-Tabellen oder formatierte Mailings in Excel, oder ansprechende Präsentationen in PowerPoint für die Endbenutzer.

Vor etwa zwei Jahren begannen wir, anstelle von festen Berichten analytische Reports in SAP Analysis zu erstellen (ein Add-In für Excel, im Wesentlichen eine Pivot-Tabelle über eine OLAP-Engine). Aber dieses Tool konnte die Bedürfnisse aller Benutzer nicht abdecken, die meisten nutzten weiterhin die Informationen, die von den Analysten zusätzlich verarbeitet wurden.

Unsere Endbenutzer lassen sich in drei Kategorien einteilen:

Top-Management. Fordert Informationen in gut präsentierter und anschaulich verständlicher Form an.

Middle-Management, fortgeschrittene Benutzer. Interessiert an der Datenforschung und in der Lage, selbstständig Berichte zu erstellen, wenn die entsprechenden Tools vorhanden sind. Genau sie wurden zu den Hauptbenutzern der analytischen Berichte in SAP Analysis.

Massenbenutzer. Nicht interessiert an selbstständiger Datenanalyse, nutzen Berichte mit begrenztem Freiraum, in Form von Mailings und Pivot-Tabellen in Excel.

Unsere Idee war es, die Bedürfnisse aller Nutzer abzudecken und ihnen ein einheitliches, benutzerfreundliches Werkzeug zu bieten. Wir haben mit dem Top-Management begonnen. Sie benötigten benutzerfreundliche Dashboards zur Analyse der wichtigsten Geschäftsergebnisse. So starteten wir mit Tableau und wählten zunächst zwei Bereiche aus: Verkaufszahlen im Einzelhandel und online, mit eingeschränkter Tiefe und Breite der Analyse, die etwa 80 % der vom Top-Management angeforderten Daten abdecken sollten.

Da die Benutzer der Dashboards das Top-Management waren, kam ein weiterer zusätzlicher KPI des Produkts hinzu – die Reaktionsgeschwindigkeit. Niemand wird 20-30 Sekunden warten, bis die Daten aktualisiert sind. Die Navigation sollte in 4-5 Sekunden erfolgen, am besten sofort. Leider haben wir das nicht erreicht.

So sah das Layout unseres Hauptdashboards aus:

Die zentrale Idee war es, die wichtigsten KPI-Treiber, von denen sich letztendlich 19 angesammelt haben, links zu bündeln und deren Dynamik sowie die Aufschlüsselung nach den wichtigsten Attributen rechts darzustellen. Die Aufgabe scheint nicht kompliziert, die Visualisierung logisch und verständlich, bis man in die Details eintaucht.

Detail 1. Datenvolumen

Die Hauptverkaufstabelle für das Jahr umfasst bei uns etwa 300 Millionen Zeilen. Da sowohl die Dynamik des aktuellen Jahres als auch die des Vorjahres abgebildet werden müssen, beträgt das Datenvolumen nur für die tatsächlichen Verkaufszahlen etwa 1 Milliarde Zeilen. Zudem werden die Informationen zu den Plan-Daten und dem Bereich Internet-Verkäufe separat gespeichert. Daher, selbst wenn wir die spaltenbasierte In-Memory-Datenbank SAP HANA verwendet haben, betrug die Abfragegeschwindigkeit für die Auswahl aller Kennzahlen für eine Woche aus den aktuellen Speichern zur Laufzeit etwa 15-20 Sekunden. Die Lösung dieses Problems drängt sich geradezu auf – zusätzliche Materialisierung der Daten. Aber auch dabei gibt es Fallstricke, die ich im Folgenden erläutere.

Detail 2. Nicht-additive Kennzahlen

Viele unserer KPIs sind an die Anzahl der Belege gebunden. Dieser Wert stellt sich als COUNT DISTINCT der Anzahl der Zeilen (Belegüberschriften) dar und zeigt unterschiedliche Summen je nach gewählten Attributen. Zum Beispiel, wie dieser Wert und davon abgeleitete Werte berechnet werden sollten:

Für die Korrektheit der Berechnungen kann man:

• Solche Kennzahlen zur Laufzeit im Speicher berechnen;
• Die Berechnung über das gesamte Datenvolumen in Tableau durchführen, d.h. auf Anfrage in Tableau alle Daten zu den gewählten Filtern mit der Granularität der Belegpositionen bereitstellen;
• Eine materialisierte Sicht erstellen, in der alle Kennzahlen für alle Auswahlvarianten berechnet werden, die unterschiedliche nicht-additive Ergebnisse liefern.

Es ist klar, dass in den Beispielen UTE1 und UTE2 die Attribute des Materials darstellen, die die Warenhierarchie repräsentieren. Dies ist keine statische Angelegenheit; darüber erfolgt das Management innerhalb des Unternehmens, da verschiedene Produktgruppen von unterschiedlichen Managern betreut werden. Wir hatten viele globale Überarbeitungen dieser Hierarchie, bei denen alle Ebenen verändert wurden, wo die Beziehungen neu bewertet wurden, sowie ständige punktuelle Änderungen, bei denen eine Gruppe von einem Knoten zu einem anderen wechselt. In der üblichen Berichterstattung wird all dies dynamisch aus den Materialattributen berechnet. Im Falle der Materialisierung dieser Daten ist es notwendig, einen Mechanismus zur Verfolgung solcher Änderungen und zur automatischen Übertragung historischer Daten zu entwickeln. Eine durchaus komplexe Aufgabe.

Detail 3. Datenvergleich

Dieser Punkt ähnelt dem vorherigen. Der Kernpunkt ist, dass in der Firma bei der Analyse mehrere Vergleichsebenen mit dem vorherigen Zeitraum gebildet werden:

Vergleich mit dem vorherigen Zeitraum (Tag zu Tag, Woche zu Woche, Monat zu Monat)

In diesem Vergleich wird davon ausgegangen, dass wir je nach dem vom Benutzer gewählten Zeitraum (zum Beispiel die 33. Woche des Jahres) die Dynamik zur 32. Woche anzeigen müssen. Wenn wir Daten für den Monat auswählen würden, zum Beispiel Mai, würde dieser Vergleich die Dynamik zum April zeigen.

Vergleich mit dem Vorjahr

Der Hauptpunkt besteht darin, dass man beim Vergleich von Tagen und Wochen nicht einfach denselben Tag des Vorjahres nimmt, also nicht nur das aktuelle Jahr minus eins setzen kann. Man muss den taggleichen Wochentag betrachten. Im Gegenteil, beim Vergleichen von Monaten muss man genau denselben Kalendertag des Vorjahres heranziehen. Es gibt auch Besonderheiten bei Schaltjahren. In den ursprünglichen Datenspeichern sind alle Informationen nach Tagen aufgeteilt, es gibt keine separaten Felder für Wochen, Monate oder Jahre. Daher muss man, um einen vollständigen analytischen Überblick im Dashboard zu erhalten, nicht nur einen Zeitraum, zum Beispiel eine Woche, betrachten, sondern vier Wochen berechnen und dann diese Daten vergleichen, um die Dynamik und Abweichungen abzubilden. Diese Logik zur Bildung des Vergleichs in der Dynamik kann entweder in Tableau oder auf der Seite des Dashboards implementiert werden. Ja, und wir waren uns dieser Details natürlich bewusst und dachten bereits in der Entwurfsphase darüber nach, aber deren Einfluss auf die Leistung des endgültigen Dashboards war schwer vorherzusagen.

Bei der Einführung des Dashboards folgten wir einem langen Agile-Weg. Unser Ziel war es, so schnell wie möglich ein funktionierendes Werkzeug mit den erforderlichen Daten zur Testung bereitzustellen. Daher arbeiteten wir in Sprints und konzentrierten uns darauf, die Arbeiten im aktuellen Datenspeicher zu minimieren.

Teil 1. Vertrauen in Tableau

Um die IT-Unterstützung zu vereinfachen und Änderungen schnell umzusetzen, haben wir beschlossen, die Logik zur Berechnung nicht-additiver Kennzahlen und den Vergleich vergangener Zeiträume in Tableau zu realisieren.

Schritt 1. Alles live, keine Nachbearbeitung der Dashboards.

In diesem Schritt haben wir Tableau an die aktuellen Dashboards angeschlossen und uns angesehen, wie die Anzahl der Belege für ein Jahr berechnet wird.

Ergebnis:

Die Antwort war ernüchternd – 20 Minuten. Datenübertragung über das Netzwerk, hohe Belastung für Tableau. Wir haben verstanden, dass die Logik für nicht-additive Kennzahlen in HANA realisiert werden muss. Das hat uns nicht wirklich erschreckt, wir hatten bereits ähnliche Erfahrungen mit BO und Analysis gemacht und konnten schnelle Dashboards in HANA erstellen, die korrekt berechnete nicht-additive Kennzahlen liefern. Jetzt blieb nur noch, sie an Tableau anzupassen.

Schritt 2. Wir optimieren die Dashboards, keine Materialisierung, alles in Echtzeit.

Wir haben eine separate neue Präsentation erstellt, die die erforderlichen Daten für TABLEAU dynamisch bereitstellte. Insgesamt haben wir ein gutes Ergebnis erzielt, indem wir die Zeit zur Erstellung aller Kennzahlen innerhalb einer Woche auf 9-10 Sekunden verkürzt haben. Wir hatten ehrlich erwartet, dass die Reaktionszeit des Dashboards in Tableau beim ersten Öffnen 20-30 Sekunden betragen würde und danach aufgrund des Caches zwischen 10 und 12 Sekunden, was uns insgesamt zufrieden gestellt hätte.

Ergebnis:

Erstes Öffnen der Dashboards: 4-5 Minuten
Jeder Klick: 3-4 Minuten
Eine solche zusätzliche Verbesserung der Präsentation hatte niemand erwartet.

Teil 2. Eintauchen in Tableau

Schritt 1. Analyse der Tableau-Leistung und schnelles Tuning

Wir begannen, zu analysieren, wofür Tableau die meiste Zeit benötigt. Dafür gibt es durchaus gute Tools, was natürlich ein Pluspunkt für Tableau ist. Das Hauptproblem, das wir festgestellt haben, waren sehr komplexe SQL-Abfragen, die Tableau erstellte. Diese hingen vor allem mit Folgendem zusammen:

— der Transponierung von Daten. Da Tableau keine Werkzeuge zur Transponierung von Datensätzen hat, mussten wir für die Erstellung des linken Teils des Dashboards mit der detaillierten Darstellung aller KPIs eine Tabelle mithilfe von CASE erstellen. Die Größe der SQL-Abfragen in der Datenbank erreichte 120.000 Zeichen.

— der Auswahl des Zeitraums. Eine solche Abfrage auf Datenbankebene benötigte mehr Zeit zur Kompilierung als zur Ausführung:

D.h. die Bearbeitung der Abfrage dauerte 12 Sekunden + 5 Sekunden zur Ausführung.

Wir beschlossen, die Logik der Berechnungen auf der Tableau-Seite zu vereinfachen und einen weiteren Teil der Berechnungen auf die Präsentation und die Datenbankebene zu verlagern. Das brachte gute Ergebnisse.

Zuerst haben wir die Transponierung dynamisch durchgeführt, und zwar durch einen Full Outer Join in der finalen Berechnungsphase der VIEW, gemäß dem Ansatz, der hier beschrieben ist: Transpose – Wikipedia, die freie Enzyklopädie und Elementarmatrix – Wikipedia, die freie Enzyklopädie.

Das heißt, wir haben eine Konfigurationstabelle erstellt – eine Transpositionsmatrix (21x21) und alle Kennzahlen in zeilenweiser Aufschlüsselung erhalten.

Früher:


Ist geworden:


Das Transponieren der Datenbank benötigt nahezu keine Zeit. Die Anfrage zu allen Metriken für die Woche wurde weiterhin in etwa 10 Sekunden bearbeitet. Allerdings ging die Flexibilität beim Erstellen des Dashboards für eine bestimmte Kennzahl verloren, d.h. für den rechten Teil des Dashboards, wo die Dynamik und die detaillierte Aufschlüsselung einer bestimmten Kennzahl dargestellt sind, wurde der Report früher in 1-3 Sekunden bearbeitet, da die Anfrage nur für eine Kennzahl lief. Jetzt wählt die Datenbank jedoch immer alle Kennzahlen aus und filtert das Ergebnis, bevor es an Tableau zurückgegeben wird.

Infolgedessen hat sich die Geschwindigkeit der Dashboard-Nutzung fast um das Dreifache verringert.

Ergebnis:

1. 5 Sekunden – Parsen des Dashboards, Visualisierungen
2. 15-20 Sekunden – Vorbereitung der Kompilierung von Anfragen mit Vorausberechnungen in Tableau
3. 35-45 Sekunden – Kompilierung der SQL-Anfragen und deren parallele/sequenzielle Ausführung in Hana
4. 5 Sekunden – Verarbeitung der Ergebnisse, Sortierung, Neuberechnung der Visualisierungen in Tableau
5. Natürlich waren solche Ergebnisse für das Geschäft unbefriedigend, und wir setzten die Optimierung fort.

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

Wir waren uns bewusst, dass es unmöglich ist, ein Dashboard mit einer Reaktionszeit von wenigen Sekunden auf einem Report zu erstellen, der 10 Sekunden benötigt, und betrachteten die Möglichkeit der Materialisierung der Daten auf der Datenbankseite speziell für das benötigte Dashboard. Doch wir stießen auf ein globales Problem, das oben beschrieben wurde – nicht additive Kennzahlen. Wir konnten es nicht umsetzen, dass Tableau beim Ändern von Filtern oder Rollouts flexibel zwischen verschiedenen Reports und Ebenen, die für verschiedene Produkt Hierarchien vorab berechnet wurden, umschaltet (im Beispiel generieren drei Anfragen ohne UTE, mit UTE1 und UTE2 unterschiedliche Ergebnisse). Daher entschieden wir uns, das Dashboard zu vereinfachen, auf die Produkthierarchie im Dashboard zu verzichten und zu beobachten, wie schnell es in der vereinfachten Version sein kann.

So sammelten wir in diesem letzten Schritt ein separates Speicher, in dem wir alle KPIs in transponierter Form ablegten. Auf der Datenbankseite wird jede Anfrage an dieses Speicher in 0,1 – 0,3 Sekunden bearbeitet. Im Dashboard erhielten wir folgende Ergebnisse:

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

Die Zeit, die Tableau benötigt, besteht aus:

1. 0,3 Sekunden – Parsen des Dashboards und Kompilierung der SQL-Anfragen
2. 1,5-3 Sekunden – Ausführung der SQL-Anfragen in Hana für die Hauptvisualisierungen (wird parallel zu Punkt 1 gestartet)
3. 1,5-2 Sekunden — Rendering, Neuberechnung von Visualisierungen
4. 1,3 Sekunden — Ausführung zusätzlicher SQL-Abfragen zur Ermittlung relevanter Filterwerte (Marke, Division, Stadt, Geschäft), Parsing der Ergebnisse

Wenn wir eine kurze Zusammenfassung ziehen würden

Uns hat das Tool Tableau aus Sicht der Visualisierung gefallen. In der Entwurfsphase haben wir verschiedene Visualisierungselemente betrachtet und alle in den Bibliotheken gefunden, einschließlich komplexer mehrstufiger Segmentierungen und Multidriver-Waterfall.

Bei der Einführung von Dashboards mit den wichtigsten Verkaufskennzahlen sind wir auf Leistungsprobleme gestoßen, die wir bisher nicht lösen konnten. Wir haben über zwei Monate investiert und ein funktional unvollständiges Dashboard erhalten, dessen Reaktionsgeschwindigkeit am Rande des Erträglichen lag. Daraus haben wir folgende Erkenntnisse gewonnen:

1. Tableau kann nicht mit großen Datenmengen umgehen. Wenn Sie in Ihrem Ausgangsdatensatz mehr als 10 GB Daten haben (ungefähr 200 Millionen × 50 Zeilen), verlangsamt sich das Dashboard erheblich — von 10 Sekunden bis mehrere Minuten pro Klick. Wir haben sowohl bei Live-Verbindungen als auch bei Extrakten experimentiert. Die Arbeitsgeschwindigkeit ist vergleichbar.
2. Einschränkungen bei der Verwendung mehrerer Speicherorte (Datasets). Es gibt keine Möglichkeit, die Beziehung der Datasets mit Standardmitteln anzugeben. Wenn Umgehungslösungen zur Verbindung von Datasets verwendet werden, hat das erhebliche Auswirkungen auf die Leistung. In unserem Fall haben wir in Betracht gezogen, Daten in jedem benötigten Dimensionalen Material zu machen und auf diesen materialisierten Datasets Umschaltungen vorzunehmen, während die zuvor ausgewählten Filter beibehalten wurden — das stellte sich in Tableau als unmöglich heraus.
3. In Tableau können keine dynamischen Parameter erstellt werden. Sie können einen Parameter, der zur Filterung des Datasets im Extrakt oder bei einer Live-Verbindung verwendet wird, nicht mit dem Ergebnis einer anderen Auswahl aus dem Dataset oder einem Ergebnis einer anderen SQL-Abfrage füllen, sondern nur mit der nativen Benutzereingabe oder einer Konstante.
4. Einschränkungen im Zusammenhang mit dem Erstellen von Dashboards mit OLAP-Elementen | Pivot-Tabellen.
   In MSTR, SAP SAC, SAP Analysis, when you add a dataset to a report, all objects on it are linked to each other by default. In Tableau, this is not the case; connections need to be set up manually. This is likely more flexible, but for all our dashboards, it’s a mandatory requirement for the elements – hence this results in extra labor costs. Moreover, if you create linked filters so that, for instance, when filtering by region, the list of cities is limited to only those cities in that region, you immediately encounter sequential queries to the database or extract, which noticeably slows down the dashboard.
5. Limitations in functions. Both with the extract and especially with the dataset from Live-connect, bulk transformations cannot be performed. This can be done through Tableau Prep, but that entails additional labor costs and another tool that needs to be learned and maintained. For example, you cannot transpose data, or join it with itself. This is limited by transformations on individual columns or fields that need to be selected through case or if, leading to very complex SQL queries, where the database spends most of its time compiling the query text. These inflexibilities of the tool had to be addressed at the level of the display, leading to a more complicated storage solution and additional loads and transformations.

We haven't given up on Tableau. However, as a tool capable of building industrial dashboards and a means to replace and digitize the entire corporate reporting system of the company, we are not considering Tableau.

We are currently actively developing a similar dashboard on another tool and simultaneously trying to rethink the dashboard architecture in Tableau to simplify it even further. If the community is interested, we will share the results.

We also welcome your ideas or advice on how to build fast dashboards in Tableau over such large volumes of data, as we have a website where the data far exceeds that in retail.

Quelle: habr.com