DataMart-Optimierung – 8 Tipps zur Performance-Verbesserung

Viele Systemadministratoren wissen nicht, wo sie anfangen sollen, um den voran beschriebenen Performance-Problemen zu begegnen. Jede Situation benötigt ein individuell zugeschnittenes Verfahren. Wichtig ist, das Problem nicht auszusitzen, sondern aktiv zu handeln, andernfalls besteht die Gefahr, dass sich Probleme mit der Zeit potenzieren!

Generell wird zwischen fachlichen und technischen Lösungsansätzen zur Optimierung unterschieden:

Ein fachlicher Ansatz bedeutet, bestehende DataMart-Strukturen zu verändern und an neue Gegebenheiten anzupassen. Häufig ist dieser Schritt mit einem erheblichen Arbeitsaufwand verbunden. Falls richtig angewendet, kann dies allerdings einen signifikanten Performanceschub geben. Die Tipps eins bis drei sind häufig gewählte Ansätze zur fachlichen Performance-Optimierung.

Tipps vier bis acht sind technische Ansätze, bei denen versucht wird, durch Änderungen am System oder den Beladungs-ETLs Verbesserungen herbeizuführen. Technische Ansätze sind zumeist einfacher zu implementieren, haben allerdings auch weniger signifikante Auswirkungen auf die Performance im Vergleich zu fachlichen Ansätzen.

1. Logisches Design
Das logische Design eines DataMarts ist die Umsetzung eines konzeptionellen Entwurfs. Im Grunde ist es eine Abbildung der realen Business-Prozesse und definiert die benötigten Informationen, sowie die Verbindungen zwischen den Tabellen eines DataMarts.
Schlechte logische Designs führen zu einem nicht-performanten physikalischen Design. Performance-Probleme entstehen in der Folge durch miteinander verbundene Datensätze, welche über multiple Tabellen gestreut wurden. Solch eine Streuung verursacht einen erhöhten Verbrauch von Serverressourcen, was wiederum zu erhöhten IT-Kosten führen kann.

Um ein logisches Design zu erstellen, das einen expliziten Business-Need unterstützt, werden folgende Schritte benötigt:

a. Entitäten identifizieren
Analysten erstellen ein logisches Datenmodell, indem sie eine Business Funktion/Aktivität genau untersuchen. Durch die Untersuchung wird ein „User View“ kreiert, welcher kritische Informationen für die Business Aktivität/Funktion repräsentiert. Stellen Sie sich vor, sie kreieren einen Webshop. Um diesen Shop am Laufen zu halten, benötigen Sie Informationen zu Verkäufen, Kunden, Produkten, Warenlager und Auslieferungen. Dies sind Ihre Entitäten.

b. Hinzufügen von Attributen
Anschließend werden Dimensionen zu den Entitäten zugeordnet. Diese Dimensionen sind beschreibende oder ergänzende Details der Entitäten. Zum Beispiel müssen Sie für die Entität ‚Kunde‘ wissen, welche Anschrift er besitzt, um ihm das bestellte Produkt auszuliefern. Zu den Verkäufen müssen Sie wissen, an welchem Datum ein Verkauf stattfand, welches Produkt verkauft wurde und wie hoch der Preis war.

c. Integration der verschiedenen Views
Zuletzt werden die gesammelten User Views in ein Gesamtbild integriert. Hierbei ist die Zuordnung der Beziehung zwischen Entitäten und Attributen wichtig.

2. Rücknahme der Normalisierung
Eine Normalisierung wird in Datenschemata vorgenommen, um Redundanzen zu vermeiden. Dies geschieht unter Einhaltung der Normalisierungsregeln für gewöhnlich, sobald Daten aus den Quellsystemen im Core Layer gespeichert werden. Für einen DataMart jedoch ist es in den meisten Fällen üblich, diese Normalisierung aufzulösen. Eine Denormalisierung ist unter anderem in den folgenden zwei Fällen gängige Praxis.

a. Aggregierte Tabellen
Aggregierte Tabellen speichern vorberechnete Resultate, welche über ein Set von Dimensionen zusammengefasst wurden (z. B. Summen- oder Maximierungsfunktionen). Dies ist eine beliebte Variante, um SQL-Abfragen und damit die Performance und den Datenspeicherbedarf zu optimieren.

b. Komplizierte Joins durch Vorberechnungen vermeiden
Falls häufig aufkommende DataMart-Abfragen auf komplexen Joins verschiedener Tabellen basieren, können die benötigten Daten in einer Tabelle gespeichert werden. Auf diese Weise werden die SQL-Abfragen beschleunigt, da Joins Rechenleistung kosten.

3. Historische Daten
Häufig beinhalten DataMarts viele historisch gewachsene Datenbestände, die im normalen Gebrauch obsolet sind.
Bei Abfragen auf den Tabellen ist die Abfragegeschwindigkeit spürbar langsamer. Als Gegenmaßnahme können selten benutzte historische Daten in Views oder eigens dafür bereitgestellte Tabellen verschoben werden. Falls historische Daten nicht benötigt werden, sollte die Möglichkeit des Löschens der Daten in Betracht gezogen werden.

Tipps 4-8 entnehmen Sie bitte der angefügten Broschüre bzw. der CINTELLIC Publikation.