Data Warehouse

Die Daten liegen verteilt in ERP, CRM, Shop und Tabellen, und jede Auswertung sucht sie sich neu zusammen. Je nach Quelle kommt eine andere Zahl heraus. Was vor der letzten Umstrukturierung galt, lässt sich oft nicht mehr rekonstruieren.

Ein Data Warehouse ist die Antwort darauf: eine zentrale Datenbank, die nur für Auswertungen da ist. Die Quellsysteme schreiben weiter Buchungen und Aufträge. Das Warehouse lädt regelmäßig eine bereinigte Kopie davon, behält die Historie und stellt sie Berichten, Analysen und KI bereit. Das semantische Modell mit den Kennzahlen setzt darauf auf, wie es entsteht, steht unter Datenmodellierung.

Wann sich ein Warehouse lohnt

Spätestens dann, wenn Berichte Daten aus mehreren Systemen brauchen und jemand sie von Hand zusammenführt. Weitere Anzeichen sind Berichte, die direkt auf der Produktivdatenbank laufen und sie ausbremsen, Zahlen, die je nach Bericht abweichen, weil jeder seine eigene Logik mitbringt, und ein bisheriges System, das nur noch eine Person versteht. Bei einer einzelnen Quelle dagegen kann ein BI-Tool direkt zugreifen, ein Warehouse wäre dort zu viel.

Vom Data Lakehouse grenzen wir es so ab: Das Warehouse hält strukturierte, aufbereitete Daten für Reporting. Für die meisten Unternehmen, deren Daten überwiegend aus ERP, CRM und Shop stammen, ist es die einfachste Lösung. Rohdateien, Logs, Dokumente oder Trainingsdaten für KI sind eher ein Fall für das Lakehouse, das wir auf einer eigenen Seite beschreiben. Beides lässt sich kombinieren.

Drei Schichten, damit Fehler einen festen Ort haben

Wir bauen ein Warehouse in Schichten. Zuerst kommen die Rohdaten, unverändert aus den Quellen übernommen. Das wirkt wie Platzverschwendung, ist aber die Versicherung: Geht in der Verarbeitung etwas schief, wird neu gerechnet, ohne die Quelle noch einmal zu belasten.

Die zweite Schicht bereinigt. Typen werden vereinheitlicht, Dubletten entfernt, Schlüssel zusammengeführt. Hier entsteht die einheitliche Sicht auf Kunden, Produkte und Aufträge. Die dritte Schicht ist die fachliche. Sie ist für die Auswertung modelliert, meist als Fakten und Dimensionen, und von hier lesen BI-Tools und Kennzahlenmodelle.

Im Databricks-Umfeld heißen die Stufen Bronze, Silber und Gold, bekannt als Medallion-Architektur. Wie sie heißen, ist egal. Sie müssen sauber getrennt sein.

Laden, transformieren, Historie behalten

Früher wurden Daten vor dem Laden umgewandelt (ETL), meist in einem eigenen Werkzeug. In Cloud-Warehouses hat sich ELT durchgesetzt: erst roh laden, dann im Warehouse selbst transformieren. Die Rechenleistung ist dort ohnehin vorhanden, und die Rohdaten stehen für spätere Fragen bereit. Wie die Daten aus den Quellen kommen, ist ein eigenes Thema und steht unter Datenpipelines.

Die Transformationen pflegen wir als SQL-Code in einem Repository, meist mit dbt. Der Code ist versioniert, getestet und läuft automatisch. Wer wann was geändert hat, bleibt nachvollziehbar, und mehrere Personen können parallel arbeiten. Verarbeitet wird nach Möglichkeit nur, was neu oder geändert ist, nicht jede Nacht der gesamte Bestand.

Für die Historie gibt es Slowly Changing Dimensions. Wechselt ein Kunde die Region, lässt sich der alte Wert überschreiben (Typ 1), oder der alte Datensatz bleibt mit Gültigkeitszeitraum bestehen und ein neuer kommt dazu (Typ 2). Typ 2 ist der Standard, wenn Berichte auch rückwirkend den damaligen Stand zeigen sollen, etwa den Umsatz einer Region vor der Umstrukturierung. Jede Historisierung kostet Speicher und Pflege. Welche Felder sie wirklich brauchen, klären wir deshalb mit den Fachbereichen.

Data Vault oder dimensionales Modell

Für die Schicht zwischen Rohdaten und Fachsicht gibt es Data Vault. Er trennt Geschäftsschlüssel (Hubs), Beziehungen (Links) und beschreibende Merkmale samt Historie (Satellites). Neue Quellen oder Felder kommen hinzu, ohne dass bestehende Strukturen umgebaut werden, und jede Änderung bleibt nachvollziehbar. Der Preis sind deutlich mehr Tabellen und ein aufwendigeres Modellieren und Laden.

Wir raten dazu bei vielen Quellen, häufigen Änderungen und strengen Nachweispflichten. Bei überschaubarer Quellenzahl ist ein klassisches dimensionales Modell einfacher und schneller fertig. Verbreitet ist auch die Mischform mit Data Vault im Kern und dimensionalen Modellen für die Berichte darüber.

Welche Plattform

Moderne Cloud-Warehouses trennen Speicher und Rechenleistung. Beides skaliert unabhängig, und gerechnet wird nur, solange geladen oder abgefragt wird. Bei der Auswahl entscheiden weniger die Funktionslisten als die Umgebung: Welche Cloud ist ohnehin im Haus, was kann das Team betreiben, wo dürfen die Daten liegen, und wie wird abgerechnet, nach gescannter Datenmenge, nach Rechenzeit oder nach reservierter Kapazität? Bei überschaubaren Datenmengen reicht oft auch eine klassische Datenbank wie PostgreSQL.

Der Umzug aus einem gewachsenen Warehouse

Viele Unternehmen betreiben noch ein Warehouse auf einer lokalen Datenbank oder in SAP BW, über Jahre gewachsen. Ein Umzug in die Cloud lohnt sich, wenn die Hardware erneuert werden müsste, die Ladeläufe nicht mehr ins Zeitfenster passen oder neue Anforderungen wie KI nicht mehr abbildbar sind. Wir gehen schrittweise vor: erst eine Bestandsaufnahme von Ladeprozessen und Berichten, dann ein Zielbild, dann der Umzug in Themenblöcken mit Parallelbetrieb und Abgleich der Zahlen.

Am häufigsten scheitert das daran, dass alles eins zu eins übernommen wird. Alte Logik, die niemand mehr versteht, zieht dann einfach mit um. Besser ist es, sie zu prüfen und dort zu vereinfachen, wo es geht. Ebenso verbreitet ist das alte System, das ewig weiterläuft, weil niemand einen Abschalttermin gesetzt hat, bis zwei Systeme gepflegt werden. Und ohne einen Verantwortlichen pro Kennzahl bleiben abweichende Definitionen auch im neuen System bestehen. Ungeplante Abfragen und zu häufige Ladeläufe treiben außerdem den Verbrauch, deshalb stehen Budgets und Überwachung von Anfang an.

Tests bei jedem Ladelauf

Ein Warehouse nützt nur, wenn man den Zahlen glaubt. Deshalb laufen bei jedem Ladevorgang automatische Tests. Sind die Schlüssel eindeutig? Fehlen Pflichtfelder? Hat jeder Auftrag einen Kunden? Liegen Summen im erwarteten Bereich, kamen die Daten rechtzeitig, und stimmen die Summen mit dem Quellsystem überein?

Schlägt ein Test fehl, wird der Fehler gemeldet. Die fehlerhaften Daten erreichen die Berichte dann nicht oder sind klar gekennzeichnet. Übergreifende Regeln zu Zuständigkeit, Katalog und Zugriffen gehören zur Data Governance.