Referenzarchitektur: Data Warehouse / Analyse

Analytische Abfragen (Reporting, Aggregation, breite Scans) unterscheiden sich grundlegend von OLTP-Transaktionen: wenige, aber sehr breite, lang laufende Abfragen. Ausgehend von der Entscheidung, Analysen von OLTP zu trennen, geht dieser Baum Schritt für Schritt Komponenten wie Lademethode (ETL vs. ELT), spaltenorientierten Speicher/Columnstore, Star-Schema-Modellierung, Partitionierung + Komprimierung und Vorberechnung mit Materialized Views durch und wägt dabei zwischen Parallelität und Durchsatz ab.

Läuft deine Analyse-Workload auf derselben Datenbank wie OLTP?

Der häufigste Fehler ist, schwere Berichte auf der produktiven Transaktions-DB laufen zu lassen und so die OLTP-Latenz zu verschlechtern. Die erste Entscheidung ist die Trennung: Laufen Analysen noch auf der OLTP-Instanz, baust du eine separate Analyseumgebung auf, oder entscheidest du gerade, wie die Daten dorthin gelangen?

• Berichte laufen noch auf dem produktiven OLTP; sie bremsen OLTP
• Ein separates Warehouse existiert; wie soll ich Daten laden?
• Ein Warehouse existiert; Abfragen sind weiterhin langsam, wie soll ich modellieren?

Wo transformierst du: vor oder nach dem Laden?

Wirst du beim Übertragen von Daten aus den Quellen ins Warehouse Bereinigung/Transformation vor dem Laden in einer separaten Verarbeitungsschicht erledigen (ETL), oder die Rohdaten zuerst ins Warehouse laden und mit SQL in der leistungsstarken Warehouse-Engine transformieren (ELT)? Die Entscheidung hängt von der Rechenleistung des Warehouse und vom Bedarf an Schemaflexibilität ab.

• Transformation ist komplex/extern; vor dem Laden erledigen
• Das Warehouse ist leistungsstark; roh laden, intern mit SQL transformieren

Liegt der Abfrageengpass im Speicherlayout oder im Datenmodell?

Sind Analysen langsam, gibt es zwei Hauptstellschrauben. Breite Scans lesen bei zeilenbasiertem Speicher die ganze Zeile; spaltenorientierter Speicher liest nur die benötigten Spalten und komprimiert gut. Auf Modellseite bedeutet übermäßige Normalisierung viele Joins, die Abfragen bremsen; ein Star-Schema (Fakten + Dimensionen) vereinfacht die Analyse.

• Breite Aggregations-Scans sind langsam; wenige Spalten werden gelesen
• Zu viele Joins, komplexes normalisiertes Schema
• Derselbe schwere Bericht liefert wiederholt dasselbe Ergebnis

Empfehlung: Analysen von OLTP trennen

Transaktionale und analytische Workloads ersticken einander auf derselben Engine: Lange Berichte halten Sperren/IO und verzögern kurze Transaktionen. Analysen auf ein separates Ziel zu verlagern (eine Read Replica oder ein separates Analyse-Warehouse), entlastet beide Seiten.

Empfehlung: ETL (vor dem Laden transformieren)

Bei ETL werden Daten aus den Quellen geholt (Extract), in einer separaten Verarbeitungsschicht bereinigt und transformiert (Transform) und erst dann ins Warehouse geladen (Load). Nur saubere, modellkonforme Daten gelangen ins Warehouse.

Empfehlung: ELT (im Warehouse transformieren)

Bei ELT werden Rohdaten zuerst ins Warehouse geladen und die Transformation erfolgt in der leistungsstarken SQL-Engine des Warehouse selbst. Da moderne spaltenorientierte Warehouses hohe Rechenleistung haben, bewegst du die Daten einmal und verarbeitest sie intern, statt die Transformation zu den Daten zu bringen.

Empfehlung: spaltenorientierter Speicher / Columnstore + Komprimierung

Analytische Abfragen scannen typischerweise wenige Spalten über alle Zeilen. Spaltenorientierter Speicher hält Daten Spalte für Spalte; er liest nur die benötigten Spalten, komprimiert sehr gut, weil ähnliche Werte nebeneinander liegen, und das IO sinkt drastisch.

Empfehlung: Star-Schema (Fakten + Dimensionen)

In einem Analysemodell steht im Zentrum eine Faktentabelle mit den Kennzahlen, umgeben von beschreibenden Dimensionstabellen. Verglichen mit einem übernormalisierten Schema sinkt die Zahl der Joins, Abfragen werden einfacher und die Engine erzeugt bessere Pläne.

Empfehlung: Vorberechnung mit Materialized Views

Läuft dieselbe schwere Aggregation (Tagesumsatz, Monatszusammenfassung) wiederholt und liefert dasselbe Ergebnis, speichere das Ergebnis physisch in einer Materialized View und lass Berichte das vorberechnete Ergebnis lesen. Die schwere Berechnung läuft einmal und Abfragen antworten sofort.