Die Zeit für Reporting in Excel schwindet schnell – der Trend hin zu benutzerfreundlichen Tools zur Darstellung und Analyse von Informationen ist in allen Bereichen sichtbar. Wir haben schon lange über die Digitalisierung von Reporting gesprochen und uns für das Visualisierungs- und Self-Service-Analyse-System Tableau entschieden. Alexander Bezugly, Leiter der Abteilung für Analyselösungen und Reporting der Gruppe „M.Video-Eldorado“, hat über die Erfahrungen und Ergebnisse beim Aufbau eines funktionalen Dashboards berichtet.
Ich sage es gleich, nicht alles, was geplant war, konnte umgesetzt werden, aber die Erfahrung war interessant, und ich hoffe, sie wird auch für Sie nützlich sein. Und falls jemand Ideen hat, wie man es besser machen könnte, wäre ich für Ratschläge und Ideen sehr dankbar.
Im Folgenden erfahren Sie, womit wir konfrontiert waren und was wir gelernt haben.
Wie wir angefangen haben
Bei „M.Video-Eldorado“ gibt es ein gut durchdachtes Datenmodell: strukturierte Informationen mit der erforderlichen Speichertiefe und eine große Anzahl von Berichten in fester Form (siehe näher ). Daraus erstellen die Analysten entweder Pivot-Tabellen oder formatierte Excel-Reports oder ansprechende Präsentationen in PowerPoint für die Endanwender.
Vor etwa zwei Jahren haben wir anstelle fester Berichte begonnen, analytische Berichte in SAP Analysis zu erstellen (eine Excel-Erweiterung, die im Grunde eine Pivot-Tabelle über einer OLAP-Engine ist). Dieses Tool konnte jedoch die Bedürfnisse aller Nutzer nicht abdecken, sodass die meisten weiterhin Informationen verwendeten, die von Analysten zusätzlich bearbeitet wurden.
Unsere Endnutzer lassen sich in drei Kategorien unterteilen:
Top-Management. Fordert Informationen in einer gut aufbereiteten und anschaulich verständlichen Form an.
Middle-Management, fortgeschrittene Nutzer. Interessieren sich für Datenanalysen und sind in der Lage, eigenständig Berichte zu erstellen, wenn die entsprechenden Tools vorhanden sind. Genau sie wurden zu den Hauptnutzern der analytischen Berichte in SAP Analysis.
Massenbenutzer. Haben kein Interesse an der eigenständigen Datenanalyse, verwenden Berichte mit eingeschränkter Freiheit, in Form von Newsletter und Pivot-Tabellen in Excel.
Unsere Idee war es, die Bedürfnisse aller Benutzer zu erfüllen und ihnen ein einheitliches, benutzerfreundliches Werkzeug zu bieten. Wir haben uns entschieden, mit dem Top-Management zu beginnen. Sie benötigten bequeme Dashboards zur Analyse der wichtigsten Geschäftsergebnisse. So starteten wir mit Tableau und wählten zunächst zwei Bereiche: die Verkaufszahlen im Einzelhandel und online mit einer begrenzten 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, stellte sich ein weiterer zusätzlicher KPI des Produkts heraus – die Antwortgeschwindigkeit. Niemand wird 20-30 Sekunden warten, bis die Daten aktualisiert sind. Die Navigation sollte in 4-5 Sekunden erfolgen, besser wäre sofortiges Feedback. Leider ist uns das nicht gelungen.
So sah das Layout unseres Hauptdashboards aus:
Die Schlüsselidee war es, die wichtigsten KPI-Treiber, insgesamt 19, auf der linken Seite zu bündeln und ihre Dynamik sowie die Aufschlüsselung nach den Hauptattributen rechts darzustellen. Die Aufgabe scheint unkompliziert, die Visualisierung logisch und nachvollziehbar, bis man in die Details eintaucht.
Detail 1. Datenvolumen
Die Hauptverkaufstabelle umfasst bei uns etwa 300 Millionen Zeilen. Da wir die Dynamik im Vergleich zum Vorjahr und vorvorjahr abbilden müssen, beträgt das Datenvolumen allein für die tatsächlichen Verkäufe etwa 1 Milliarde Zeilen. Zudem speichern wir separat Informationen zu den geplanten Daten und einen Block für den Internetverkauf. Daher, selbst wenn wir die spaltenbasierte In-Memory-Datenbank SAP HANA verwenden, betrug die Bearbeitungsgeschwindigkeit einer Abfrage, die alle Kennzahlen für eine Woche aus den aktuellen Speichern in Echtzeit abruft, etwa 15-20 Sekunden. Die Lösung dieses Problems drängt sich geradezu auf – die zusätzliche Materialisierung der Daten. Doch auch hier gibt es einige Fallstricke, die wir gleich erörtern werden.
Detail 2. Nicht addierbare Kennzahlen
Viele unserer KPIs basieren auf der Anzahl der Belege. Diese Kennzahl stellt eine DISTINCT COUNT der Anzahl der Zeilen (Belegüberschriften) dar und zeigt unterschiedliche Summen, je nach gewählten Attributen. Zum Beispiel, wie diese Kennzahl und die davon abgeleiteten Werte berechnet werden sollten:
Für die Richtigkeit der Berechnungen kann man:
- Solche Kennzahlen in Echtzeit im Speicher berechnen;
- Die Berechnung muss für das gesamte Datenvolumen in Tableau durchgeführt werden, d.h. auf Anfrage sollte Tableau alle Daten anhand der ausgewählten Filter mit der Granularität der Belegpositionen bereitstellen.
- Eine materialisierte Ansicht erstellen, in der alle Kennzahlen für alle Abtropfvarianten berechnet werden, die unterschiedliche, nicht-additive Ergebnisse liefern.
Es ist klar, dass in den Beispielen UTE1 und UTE2 die Attribute des Materials die Warenhierarchie repräsentieren. Dies ist keine statische Angelegenheit, darüber wird innerhalb des Unternehmens gesteuert, da verschiedene Manager für unterschiedliche Warengruppen verantwortlich sind. Wir haben viele globale Überarbeitungen dieser Hierarchie gehabt, bei denen alle Ebenen geändert wurden, die Wechselwirkungen neu bewertet wurden, ebenso wie ständige punktuelle Änderungen, bei denen eine Gruppe von einem Knoten zu einem anderen wechselt. In der regulären Berichterstattung wird all dies in Echtzeit aus den Attributen des Materials berechnet. Im Falle der Materialisierung dieser Daten ist es notwendig, einen Mechanismus zur Überwachung solcher Änderungen und zur automatischen Aktualisierung historischer Daten zu entwickeln. Das ist eine durchaus anspruchsvolle Aufgabe.
Detail 3. Vergleich der Daten
Dieser Punkt ähnelt dem vorherigen. Bei der Analyse in Unternehmen wird in der Regel erwartet, dass mehrere Vergleichsebenen im Verhältnis zum vorherigen Zeitraum gebildet werden:
Vergleich zum vorherigen Zeitraum (Tag für Tag, Woche für Woche, Monat für Monat)
In diesem Vergleich gehen wir davon aus, dass wir je nach dem vom Benutzer gewählten Zeitraum (zum Beispiel die 33. Woche des Jahres) die Dynamik zur 32. Woche darstellen müssen. Wenn wir die Daten für den Monat Mai auswählen, würde dieser Vergleich die Dynamik im Vergleich zu April zeigen.
Vergleich zum Vorjahr
Der entscheidende Punkt ist, dass Sie beim Vergleich von Tagen und Wochen nicht einfach den gleichen Tag wie im Vorjahr nehmen können, also den aktuellen Jahr minus eins. Sie müssen den Vergleichstag der Woche beachten. Beim Vergleich von Monaten hingegen sollten Sie genau denselben Kalendertag des Vorjahres heranziehen. Zudem gibt es Besonderheiten bei Schaltjahren. In den ursprünglichen Speicherorten sind alle Informationen nach Tagen verteilt, es gibt keine separaten Felder für Wochen, Monate oder Jahre. Daher müssen Sie, um eine umfassende analytische Auswertung im Dashboard zu erhalten, nicht nur einen Zeitraum, beispielsweise eine Woche, betrachten, sondern vier Wochen und diese Daten anschließend noch vergleichen, um die Dynamik und Abweichungen zu reflektieren. Diese Logik zur Erstellung von Vergleichen über Zeiträume kann entweder in Tableau oder auf der Seite der Präsentation umgesetzt werden. Ja, und wir waren uns dieser Details natürlich bewusst und haben bereits in der Planungsphase darüber nachgedacht, aber ihre Auswirkungen auf die Leistung des endgültigen Dashboards waren schwer vorhersehbar.
Bei der Implementierung des Dashboards gingen wir einen langen agilen Weg. Unser Ziel war es, so schnell wie möglich ein funktionierendes Werkzeug mit den benötigten Daten zum Testen bereitzustellen. Daher arbeiteten wir in Sprints und konzentrierten uns auf die Minimierung der Arbeiten auf der Seite des aktuellen Speichers.
Teil 1. Vertrauen in Tableau
Um die IT-Unterstützung zu erleichtern und Änderungen schnell umzusetzen, entschieden wir uns, die Logik zur Berechnung nicht-additiver Kennzahlen und den Vergleich früherer Zeiträume in Tableau zu implementieren.
Schritt 1. Alles live, keine Anpassungen der Dashboards.
In diesem Schritt verbanden wir Tableau mit den aktuellen Dashboards und wollten herausfinden, wie die Anzahl der Belege für ein Jahr berechnet werden würde.
Das Ergebnis:
Die Antwort war ernüchternd – 20 Minuten. Datenübertragungen über das Netzwerk, hohe Belastung für Tableau. Wir erkannten, dass die Logik für nicht-additive Kennzahlen in HANA umgesetzt werden musste. Das machte uns nicht allzu viel Angst, da wir bereits ähnliche Erfahrungen mit BO und Analysis gemacht hatten und wussten, wie man schnelle Dashboards in HANA erstellt, die richtig 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 ein neues, separates Dashboard erstellt, das die erforderlichen Daten für TABLEAU in Echtzeit bereitstellt. Insgesamt haben wir ein gutes Ergebnis erzielt: Die Zeit zur Erstellung aller Kennzahlen reduzierte sich auf 9-10 Sekunden innerhalb einer Woche. Wir hatten ehrlich gesagt erwartet, dass die Ladezeit des Dashboards in Tableau beim ersten Öffnen 20-30 Sekunden betragen würde und danach aufgrund von Caching auf 10 bis 12 Sekunden sinken würde, was uns grundsätzlich zufrieden gestellt hätte.
Das Ergebnis:
Erste Öffnung des Dashboards: 4-5 Minuten
Jeder Klick: 3-4 Minuten
Eine solche zusätzliche Arbeitsbelastung für das Dashboard hatte niemand erwartet.
Teil 2. Einführung in Tableau
Phase 1. Leistungsanalyse von Tableau und schnelles Tuning
Wir begannen mit der Analyse, wo Tableau die meiste Zeit verbringt. Dafür gibt es ein recht gutes Werkzeug, was natürlich ein Vorteil von Tableau ist. Das Hauptproblem, das wir identifizierten, waren die sehr komplexen SQL-Abfragen, die Tableau generiert hat. Diese hängt hauptsächlich mit Folgendem zusammen:
— der Transponierung von Daten. Da Tableau keine Werkzeuge zur Transponierung von Datensätzen hat, mussten wir zur Erstellung des linken Teils des Dashboards mit einer detaillierten Darstellung aller KPIs eine Tabelle über einen Case generieren. Die Größe der SQL-Abfragen in der Datenbank erreichte 120.000 Zeichen.
— die Auswahl des Zeitraums. Eine solche Abfrage auf Datenbankebene benötigte mehr Zeit für die Kompilierung als für die Ausführung:
Das heißt, die Verarbeitung der Anfrage dauerte 12 Sekunden + 5 Sekunden für die Ausführung.
Wir haben uns entschieden, die Logik der Berechnungen auf der Tableau-Seite zu vereinfachen und einen weiteren Teil der Berechnungen auf die Datenbank- und Frontend-Ebene zu verlagern. Das hat gute Ergebnisse gebracht.
Zunächst haben wir die Transponierung zur Laufzeit durchgeführt, indem wir einen vollständigen Outer Join in der finalen Berechnung der VIEW verwendet haben, gemäß dem in der Wiki beschriebenen Ansatz. und .
Das heißt, wir haben eine Einstellungs-Tabelle – eine Transponierungsmatrix (21x21) erstellt und alle Kennzahlen in Zeilenaufteilung erhalten.
War:
Ist geworden:
Die Datenbanktransposition dauert kaum Zeit. Die Abfrage für alle Datenpunkte der Woche wurde nach wie vor in etwa 10 Sekunden bearbeitet. Allerdings wurde die Flexibilität beim Erstellen des Dashboards für einen bestimmten Indikator eingeschränkt; das heißt, die rechte Seite des Dashboards, auf der die Dynamik und die detaillierte Aufschlüsselung eines spezifischen Indikators dargestellt sind, benötigte früher 1-3 Sekunden, da die Abfrage nur für einen Indikator lief. Jetzt zieht die Datenbank jedoch immer alle Indikatoren ab und filtert das Ergebnis, bevor es an Tableau zurückgegeben wird.
Daher hat sich die Geschwindigkeit des Dashboards fast um das Dreifache verringert.
Das Ergebnis:
- 5 Sek. – Parsen des Dashboards und der Visualisierungen
- 15-20 Sek. – Vorbereitung zur Kompilation der Abfragen mit Durchführung der Vorausberechnungen in Tableau
- 35-45 Sek. – Kompilation der SQL-Abfragen und ihre parallele-sequenzielle Ausführung in Hana
- 5 Sek. – Verarbeitung der Ergebnisse, Sortierung, Neuberechnung der Visualisierungen in Tableau
- Natürlich waren solche Ergebnisse für das Geschäft nicht akzeptabel, und wir setzten die Optimierung fort.
Phase 2. Minimal logische Verarbeitung in Tableau, vollständige Materialisierung
Wir haben verstanden, dass es unmöglich ist, ein Dashboard mit einer Reaktionszeit von wenigen Sekunden auf einer Schnittstelle, die nur zehn Sekunden aktiv ist, zu erstellen. Daher haben wir darüber nachgedacht, Daten für das erforderliche Dashboard direkt in der Datenbank zu materialisieren. Dabei sind wir jedoch auf ein grundlegend neues Problem gestoßen – nicht additive Kennzahlen. Es gelang uns nicht, Tableau so zu konfigurieren, dass es beim Ändern von Filtern oder Ansichten flexibel zwischen verschiedenen Schnittstellen und Ebenen wechselt, die für unterschiedliche Produkt hierarchien vordefiniert sind (im Beispiel erzeugen drei Abfragen ohne UTE, mit UTE1 und UTE2 unterschiedliche Ergebnisse). Daher haben wir beschlossen, das Dashboard zu vereinfachen, die Produkthierarchie aufzugeben und zu sehen, wie schnell die vereinfachte Version sein kann.
In diesem letzten Schritt haben wir ein separates Repository erstellt, in dem wir alle KPIs in transponierter Form zusammengefasst haben. Jeder Zugriff auf dieses Repository in der Datenbank dauert zwischen 0,1 und 0,3 Sekunden. Im Dashboard erzielten wir die folgenden Ergebnisse:
Erste Öffnung: 8-10 Sekunden
Jeder Klick: 6-7 Sekunden
Die Zeit, die Tableau benötigt, setzt sich zusammen aus:
- 0,3 Sek. – Parsing des Dashboards und Kompilierung von SQL-Abfragen
- 1,5-3 Sekunden – Ausführung von SQL-Abfragen in Hana für die Hauptvisualisierungen (parallel zu Punkt 1 gestartet)
- 1,5-2 Sekunden – Rendering, Aktualisierung der Visualisierungen
- 1,3 Sekunden – Ausführung zusätzlicher SQL-Abfragen zur Erfassung relevanter Filterwerte (Marke, Division, Stadt, Geschäft), Parsing der Ergebnisse
Zusammenfassend gesagt
Wir fanden das Tableau-Tool hinsichtlich der Visualisierung ansprechend. In der Entwurfsphase haben wir verschiedene Visualisierungselemente betrachtet und alle in den Bibliotheken gefunden, einschließlich komplexer mehrstufiger Segmentierungen und Multi-Driver-Waterfall-Diagramme.
Bei der Implementierung von Dashboards mit den wichtigsten Verkaufskennzahlen sind wir auf Leistungsprobleme gestoßen, die wir bislang nicht überwinden konnten. Wir haben mehr als zwei Monate investiert und ein funktional unvollständiges Dashboard erhalten, dessen Reaktionsgeschwindigkeit an der Grenze des Akzeptablen liegt. Unsere Erkenntnisse sind:
- Tableau kann mit großen Datenmengen nicht umgehen. Wenn Ihr Ausgangsdatensatz mehr als 10 GB Daten umfasst (etwa 200 Millionen x 50 Zeilen), verlangsamt sich das Dashboard erheblich – von 10 Sekunden bis zu mehreren Minuten für jeden Klick. Wir haben sowohl bei Live-Verbindungen als auch bei Extraktionen experimentiert. Die Leistung war vergleichbar.
- Es gibt Einschränkungen bei der Verwendung mehrerer Datenspeicher (Datasets). Es ist nicht möglich, die Beziehungen zwischen Datasets mit den standardmäßigen Mitteln anzugeben. Wenn alternative Lösungen zur Verbindung von Datasets verwendet werden, hat dies erhebliche Auswirkungen auf die Leistung. In unserem Fall haben wir in Betracht gezogen, die Daten in jeder benötigten Darstellung zu materialisieren und dann zwischen diesen materialisierten Datasets zu wechseln, während die zuvor gewählten Filter beibehalten werden – dies war in Tableau nicht möglich.
- In Tableau sind dynamische Parameter nicht möglich. Sie können einen Parameter, der zur Filterung eines Datasets in der Extraktion oder bei Live-Verbindungen verwendet wird, nicht mit dem Ergebnis einer anderen Auswahl aus dem Dataset oder dem Ergebnis einer anderen SQL-Abfrage füllen, nur durch Benutzereingaben oder Konstanten.
- Einschränkungen beim Aufbau von Dashboards mit OLAP-Elementen|Pivot-Tabellen.
In MSTR, SAP SAC, SAP Analysis sind alle Objekte standardmäßig miteinander verbunden, wenn Sie einen Datensatz zu einem Bericht hinzufügen. In Tableau gibt es diese Verbindung nicht, sie muss manuell eingerichtet werden. Das ist wahrscheinlich flexibler, aber für alle unsere Dashboards ist das eine zwingende Anforderung für die Elemente – daher verursacht es zusätzliche Arbeitsaufwände. Darüber hinaus, wenn Sie verbundene Filter erstellen, um beispielsweise die Liste der Städte nur auf die Städte dieser Region zu beschränken, werden sofort sequenzielle Abfragen an die Datenbank oder den Extrakt gestellt, was das Dashboard deutlich verlangsamt. - Einschränkungen bei den Funktionen. Sowohl bei der Extraktion als auch bei dem Dataset aus Live-Connect können keine massenhaften Transformationen durchgeführt werden. Dies ist über Tableau Prep möglich, aber es erfordert zusätzlichen Arbeitsaufwand und einen weiteren zu erlernenden und zu wartenden Tool. Zum Beispiel können Sie die Daten nicht transponieren oder sie mit sich selbst verknüpfen. Es ist nur möglich, Transformationen über einzelne Spalten oder Felder durchzuführen, die über CASE oder IF ausgewählt werden müssen. Das führt zu sehr komplexen SQL-Abfragen, bei denen die Datenbank die meiste Zeit mit der Kompilierung der Abfragetexte beschäftigt ist. Diese Einschränkungen des Tools mussten auf der Ebene der Präsentation gelöst werden, was zu einer Verkomplizierung des Speichers, zusätzlichen Ladezeiten und Transformationen führt.
Wir haben Tableau nicht aufgegeben. Allerdings betrachten wir es nicht als ein Tool, das in der Lage ist, industrielle Dashboards zu erstellen oder als Mittel, mit dem die gesamte Unternehmensberichtssystematik digitalisiert werden kann.
Aktuell entwickeln wir ein ähnliches Dashboard mit einem anderen Tool und prüfen parallel die Architektur des Dashboards in Tableau, um es weiter zu vereinfachen. Wenn die Community interessiert ist, werden wir gerne über die Ergebnisse berichten.
Wir freuen uns auch auf Ihre Ideen oder Vorschläge, wie man in Tableau schnelle Dashboards über solche großen Datenmengen erstellen kann. Denn unsere Webseite hat erheblich mehr Daten als im Einzelhandel.
Quelle: habr.com
