Vor ungefähr 4 Jahren haben wir unser Berichtssystem von Oracle auf SAP Hana umgestellt. Heute werden etwa 10.000 Tische gespeichert, 38.000 Benutzer verwenden es und täglich finden mehr als 5.000 Ladevorgänge statt. Derzeit besteht unser Komplex, auf dem das System arbeitet, aus 8 Servern mit 14 TB Speicher. Das Berichtssystem verarbeitet täglich 1,5 pb Daten. Gleichzeitig war Hana etwa 20-mal produktiver als Oracle, DB2 und MySQL. Und heute möchte ich erzählen, wie wir im Rahmen der Integration von M.Video und Eldorado zusätzlich die Leistung des Berichtssystems gesteigert haben, welche Optimierungen wir vorgenommen haben.
Laden
Heute erzeugen von mehreren tausend vom System erstellten Berichten nur 10 70% der Gesamtlast. Der schwerste Bericht in der Hana-Datenbank ist Weekly Bussines Review. Es läuft 30 Minuten und verbraucht 4 TB Speicher. 90% aller Berichte werden vom Contact Center erstellt: Wir haben einen Service erstellt, der beim Anrufen eines Kunden über seine Telefonnummer automatisch einen Bericht öffnet und dem Betreiber den gesamten Verlauf der Einkäufe des Anrufers und seine Interaktion mit dem Unternehmen anzeigt.
Datenmodell
Das Schlüsseldatenmodell, auf dem der Großteil der Berichte basiert, enthält 1.500 Tabellen. Die meisten davon sind Referenztabellen. Mit diesem Modell können Sie jede Richtung des Unternehmens analysieren. Ein Beispiel ist die Visualisierung eines Datenmodells, das mit dem Universe-Designer erstellt wurde. Es stimmt, es spiegelt nur ein Zehntel unseres Systems wider.
Leistung
Zum Zeitpunkt der Fusion von M.Video und Eldorado betrug die Datenmenge in den beiden Meldesystemen etwa 10 TB: 7 TB im BW auf dem HANA M.Video-System, 2 TB im BW auf HANA Eldorado und 1 TB zusätzliche Daten in HADOOP (historische Daten). Bei der Kombination der Systeme hatten wir Hardwareeinschränkungen: Der M. Video-Komplex bestand aus 6 Knoten (jeweils 2 TB), einschließlich einer Sicherung. Dieses System kann auf maximal 8 Knoten erweitert werden, von denen eine Sicherung.
In Vorbereitung auf den Zusammenschluss gingen wir davon aus, dass die Gesamtmenge aller Daten 13 TB erreichen würde. Basierend auf den SAP-Empfehlungen benötigten wir daher ein System mit 16 Knoten mit jeweils 2 TB, einschließlich zwei Sicherungsknoten. Außerdem musste ein Knoten als Hauptknoten zugewiesen werden, der mit einem solchen Informationsvolumen Verwaltungsfunktionen übernehmen würde. Das heißt, für einen korrekten Betrieb mussten 13 Knoten bereitgestellt werden.
Wie Sie sehen können, reichen die verfügbaren Ressourcen kategorisch nicht aus. Und das war die erste Herausforderung.
Die zweite Hauptschwierigkeit vor dem Zusammenschluss bestand darin, dass die Geschwindigkeit des Systems häufig nicht den Anforderungen des Unternehmens entsprach. Der Hauptgrund war die große Anzahl gleichzeitiger Aufrufe der Datenbank. Aus Sicht des Systems sah es aus wie ein Schneeball, der entweder zum Einfrieren und Unterbrechen eines Teils der Prozesse oder sogar zu globalen Speicherauszügen von "nicht genügend Speicher" auf den Knoten führen kann.
Es war klar, dass eine zweifache Erhöhung der Datenmenge in den Berichten (für zwei Marken) ohne wesentliche Änderungen zu einer etwa zweifachen Verschlechterung der Situation führen würde.
Aus diesem Grund haben wir uns entschlossen, das System in folgenden Bereichen zu optimieren:
- Berichterstattung Beschleunigung der kritischsten und ressourcenintensivsten Berichte und Überarbeitung des Datenmodells.
- Repository . Archivierungs- und Speicheroptimierung.
- Downloads . Optimieren Sie das Verfahren und ändern Sie den Download-Zeitplan.
Der allgemeine Ansatz zur Optimierung war folgender:
Zuerst führten wir eine Analyse in alle Richtungen durch, identifizierten die Ursachen von Problemen und analysierten dann die Fähigkeiten des Systems mit den erforderlichen Ressourcen. Wir haben auch sofort versucht, diesen Prozess so weit wie möglich zu automatisieren, damit wir in Zukunft die Ursachen von Problemen schnell identifizieren und die Leistung schnell wiederherstellen können.
Was haben wir getan:
- Die Konfiguration der ABAP-Anwendungsserver wurde geändert: Anzahl der Instanzen, effektive Nutzung der NUMA-Technologie und optimale Anzahl der Workflows.
- Wir haben die optimalen Parameter von HANA und dem Linux-Betriebssystem angewendet.
- Wir haben den Rückgang des CPU-Verbrauchs analysiert.
- Wir haben den RAM-Verbrauch im gesamten beobachteten Zeitintervall analysiert.
- Wir haben das Auftreten von OOM auf HANA analysiert.
- Wir haben das Auftreten von Sperren im System und die Verfügbarkeit von Systemressourcen für Wartevorgänge (Warten) analysiert.
- Wir haben den Datenausgleich unter Berücksichtigung der Umverteilung und Aufteilung der Daten für die SCALE-OUT HANA-Lösung analysiert.
- Wir haben die Ursachen von ABAP-Dumps analysiert, die sich auf den Betrieb kritischer Ketten auswirken.
Basierend auf den Ergebnissen wurden Leistungsberichte sowie Anweisungen erstellt, damit in Zukunft Engpässe im System und Spitzenzeitintervalle unabhängig ermittelt werden können.
Welche Ergebnisse wurden erzielt:
Eine Reihe optimierter Berichte SAP BO begann um ein
Vielfaches schneller zu arbeiten und verbrauchte
hunderte Male weniger Speicher .
Hier einige bemerkenswerte Beispiele dafür, wie das System die Auswahlbedingungen falsch erfüllt und wie Abfragen in HANA korrekt erstellt werden.
Beim Filtern nach nicht materialisierten Objekten wurden Probleme festgestellt, insbesondere (!) Bei Verwendung von
COUNT DISTINCT Indikatoren (eine CD kann sowohl auf Universumsebene als auch in einer Funktion im Lebenslauf geschrieben werden).
Selbst wenn Sie die CD von der Abfrage ausschließen, wird die erste Option immer noch 20-mal langsamer als die zweite ausgeführt, und bei einer CD ist die Geschwindigkeit mehr als 500-mal höher.
Ein Sonderfall bei der Verwendung nicht materialisierter Objekte in Filtern: Verbundfilter von zwei oder mehr Objekten, z. B. Kleben einer Woche und eines Jahres:
Abfragen mit geklebten Filtern funktionieren nicht so langsam wie die Konvertierung in ein Datum, verlangsamen jedoch die Abfragen (etwa 2-3 Mal).
Um Statistiken über den Betrieb des Berichtssystems, Ladeprozesse und Ketten zu sammeln, haben wir das folgende Schema entwickelt:
Gleichzeitig haben wir den Berichten einen speziellen Kommentar mit dem Namen des Berichts hinzugefügt. Somit können wir die Last von verschiedenen Teilen des Systems vergleichen und die Periode von Periode zu Periode vergleichen.
Pläne
Wir haben viele Pläne für die Entwicklung von Geschäftsfunktionen und eine wesentliche Überarbeitung des Datenvisualisierungstools. Der globale Trend, an dem wir aktiv teilnehmen, besteht darin, das Berichtssystem in das Paradigma der digitalen Transformation zu integrieren.
Was meinst du
Als unser Berichtssystem noch jung war, kamen Benutzer häufig mit ähnlichen Anfragen zu uns: „Automatisieren Sie die Erstellung eines Berichts, aus dem hervorgeht, wie viel Nettogewinn ein bestimmtes Geschäft oder das gesamte Unternehmen erzielt hat.“
Dann kamen sie zu uns mit der Bitte, einen Algorithmus zu entwickeln, der abhängig von bestimmten Faktoren einen Plan oder eine Prognose für einen Nettogewinn erstellt.
Und heute sind wir zu dem Schluss gekommen, dass Benutzer die genaue Prognose des Nettogewinns wissen wollen. Wir haben alle notwendigen Daten für die Entwicklung von Prognosealgorithmen, und es gibt Datenanalysespezialisten, die Modelle für maschinelles Lernen erstellen können. Wie Sie wissen, erfordert dies sehr große Datenmengen. Einer der Haupttrends bei der Entwicklung unseres Berichtssystems ist der Übergang zur Analyse und Erstellung von Modellen, die auf Big Data basieren.
Ein paar Worte zu unserem Team
Heutzutage führen große Unternehmen zunehmend Prognosesysteme ein, die auf vom System selbst entwickelten Algorithmen für maschinelles Lernen basieren. Vor zwei Jahren haben wir ein Kompetenzzentrum im Bereich der Datenanalyse des Digital Retail Data Science Center eingerichtet. In diesem Jahr haben wir eine Gruppe von Dateningenieuren. Wir führen ein neues System zur Verarbeitung und Analyse von Big Data ein. Und wir brauchen Mitarbeiter im Team in den Abteilungen Support, Entwicklung und angewandte Datenanalyse.
Wenn Sie sich für diese Bereiche interessieren, wenn Sie die Stärke in sich spüren - willkommen! Sie werden interessante und schwierige Arbeit finden, manchmal stressig, aber immer kreativ.
