Ein Data Warehouse (abgekürzt “DWH”) ist eine Datenbank die strukturierte Daten zur weiteren Verarbeitung erfasst. Die häufigsten Anwendungsgebiete der Daten sind Reporting, Business Intelligence und Analytics.
Das Ziel eines DWHs ist es, möglichst einfach Daten in hoher Qualität bereit zu stellen, um nachfolgende Analyseschritte zu vereinfachen. In diesem Artikel gehen wir genauer auf die Definition eines Data Warehouses ein, zeigen die grundlegende Architektur auf und diskutieren häufige Fragen, wie zum Beispiel wie ein DWH aktuell bleibt.
Zusammenfassung des Artikels
- Ein Data Warehouse (DWH) speichert strukturierte Daten
- Ziel ist eine einfache analytische Weiterverwendung, vor allem Reporting, Visualisierung und Business Intelligence
- Es bedient vor allem Business / Data Analysts und Business Stakeholder
- Die Architektur des Data Warehouses besteht aus den Layern Staging, Storage, Data Marts und Serve
- Es gibt eine Bandbreite an Tools um ein DWH aufzubauen, zum Beispiel AWS RedShift, Azure Synapse, SnowFlake oder eine einfache SQL-Datenbank
Inhaltsverzeichnis
Das Data Warehouse (DWH): Eine verständliche Definition
Was ist ein Data Warehouse? Wie der Name schon sagt ist es ein “Datenlager”. Der wichtige Punkt hierbei ist, dass es sich um ein geordnetes, vorher definiertes Lager handelt, das sowohl Einlagerung als auch Entnahme von Daten sehr einfach macht. Das Ziel eines DWHs ist, Daten nicht nur für operative Prozesse zu verwenden, sondern zu analysieren und Wissen daraus zu generieren.
Etwas genauer definiert ist ein Data Warehouse eine oder mehrere Datenbanken, die Daten in einem vorgegebenen Schema speichern. Ein Schema definiert die Struktur des Inhalts und wie die einzelnen Datenbanktabellen zusammenhängen. Zum Beispiel, dass die Kundennummer über alle Tabellen als Unique Identifier gilt.
Das wichtige dabei zu verstehen ist, dass bei einem DWH die spätere Entnahme möglichst einfach und effektiv von statten gehen soll. Daher werden sowohl Schema als auch Inhalt vorher definiert, dokumentiert und auch (optimalerweise) nachhaltig gepflegt. Dieses “Schema-on-Write”-Prinzip des Data Warehouses hat selbstverständlich zur Folge, dass viel Zeit und Gedanken vorab in die Anwendungsfälle und Struktur des DWH fließen müssen.
Um einen sehr einfachen Vergleich zu ziehen, kann ein Data Warehouse wie eine gut gepflegte Excel-Tabelle gesehen werden. Die Daten sind in Spalten (Attribute) und Zeilen (Einträge) organisiert, bei dem jeder Eintrag übereinstimmen muss damit sie Sinn machen. Die Tabelle kann einfach genutzt werden um einfache Analysen, zum Beispiel Summen oder Pivottabellen, durchzuführen.
In Realität sind Warehouses selbstverständlich ungemein komplexer. Es stellen sich viele Herausforderungen bezüglich Skalierung (Wachstum mit Anzahl an Daten), Zugriff (hunderte von Nutzern), Sicherheit (Welche Daten dürfen von wem gesehen werden?), Datenpflege (Datenqualität), Historie (Wie mit alten Daten umgehen), Versionierung (Was, wenn sich etwas an der Struktur des DWH ändert?) und mehr.
Zusammengefasst ist ein Data Warehouse eine Datenbank, in der Daten für analytische Zwecke wie Visualisierung oder Business Intelligence gespeichert werden. In den nachfolgenden Abschnitten möchten wir auf Vor- und Nachteile eines DWHs, die beteiligte Architektur, Rollen und häufige Fragen eingehen.
Was ist Kobold AI?
Kobold AI bietet den Einsatz künstlicher Intelligenz ohne technisches Vorwissen. Einfach, schnell und günstig KI anwenden, um Mehrwert durch Daten zu generieren.
Wie es funktioniert erklärt unser interaktives Video:
Warum braucht man ein DWH?
Ein Data Warehouse hat sich inzwischen in fast jedem mittleren oder großen Unternehmen etabliert. Doch warum braucht man überhaupt ein DWH?
Ganz einfach gesagt ermöglicht es ein Data Warehouse, Daten aus verschiedenen Quellen zu sammeln, zu strukturieren und auszuliefern. Dies hat zum Ziel, Daten über den operativen Teil hinaus zu nutzen. Anwendungsfälle sind vor allem Reporting, Analytics und Data Science.
Daher muss unsere Frage eher lauten: Warum empfinden viele Unternehmen datenbasiertes Arbeiten wie Reporting, Datenanalyse und Datenwissenschaft als relevant? Die Antwort darauf ist einfach: Weil es einen Mehrwert generiert. Sobald man Daten schnell und einfach einsetzen kann, um Fragen zu beantworten oder zumindest mehr Wissen über das eigene Unternehmen, die Kunden, Lieferanten und deren Verhalten zu generieren, hilft dies, besser zu steuern.
Ob nun im täglichen operativen Geschäft oder strategisch: Daten helfen, bessere Entscheidungen zu treffen. Und ein Data Warehouse ist eine technologische Basis, Daten schnell und einfach dafür zu liefern.
Vorteile und Nachteile eines DWHs
Als Übersicht die generellen Vor- und Nachteile eines Data Warehouses tabellarisch aufgeschlüsselt:
| Vorteil | Nachteil |
|---|---|
| Strukturierte Daten zentral erfasst | Keine unstrukturierten Daten erfassbar |
| Einfacher Zugriff und Weiterverwendung | Business Rules oft nicht ausreichend definiert und dokumentiert |
| Gepflegte Daten und Prozesse | Oft langsame Anbindung neuer Datenquellen |
| Fördert “data-driven thinking” durch einfache Bereitstellung | Oft geringe Granularität / zeitliche Auflösung der Daten |
Typische Daten in einem DWH
- Salesdaten: Die Bestellungen und Umsätze sind häufig zentral in DWHs, manuelle Forecasts hingegen sind selten zu finden.
- ERP: Strukturierte Order-Daten sind einfach zu integrieren
- Logistik: Je nach Unternehmen werden Logistikdaten teilweise fokussiert integriert
- Kundendaten: Kundendaten sind teilweise sehr stark in einem DWH integriert, oft allerdings auch stark im CRM selbst verankert
- Webanalytics: Webanalytics-Daten werden häufig extrahiert und in ein DWH integriert, da sie meist über eine einfache Schnittstelle zur Verfügung gestellt werden.
Was man hingegen nicht häufig in DWHs findet sind Daten aus den Bereichen Text (zum Beispiel Social Media, Content), Videoanalysen und ähnliche unstrukturierte Daten.
Anwendung für Daten aus dem Data Warehouse
Es gibt eine Bandbreite an Anwendungen für Data Warehouse Daten. Meistens werden Daten aus dem Warehouse visuell oder tabellarisch aufbereitet, um Entscheidungsträger im Unternehmen über den Stand der Vorgänge zu informieren. Diese deskriptive, historische Analyse manifestiert sich in folgenden Anwendungen:
- Reporting: KPIs und tabellarische Reports zu wichtigen Kennzahlen
- Dashboards: Visualisierung des Stands und der der Entwicklung von Kennzahlen
- Business Intelligence: Fortführende Analysen von DWH-Daten zur Identifikation von Stärken und Chancen eines Unternehmens
- ggf. Data Science: Bei hoher Auflösung der Daten sind auch Methoden aus dem Bereich der künstlichen Intelligenz möglich
Grundlegende Data Warehouse Architektur (Beispiel)
Eine Data Warehouse Architektur besteht im Prinzip aus sechs Schichten:
Data Sources: Die Datenquellen
Die Datenquellen für ein Data Warehouse sind primär interne Daten. Systeme wie das ERP, ein CRM, ein Logistik-System oder ein Service-Tool stellen oft wertvolle Daten bereit. Doch nach und nach werden immer mehr externe Datenquellen wie zum Beispiel Webanalytics (Google Analytics, Adobe Analytics..), SalesForce oder Facebook Ads mit angebunden. Auch andere Quellen wie beispielsweise IoT Devices können Daten für ein DWH liefern, sind jedoch abhängig von der Frequenz und Granularität.
Staging: Einlesen und Aufbereiten zur Speicherung
Das Data Staging deckt die beiden ersten zwei Teile des ETL (extract-transform-load) Prozesses ab. Während dem Staging werden die Datenquellen eingeladen und aufbereitet, um sie persistent in der Datenbank abzulegen. Gegebenenfalls werden auch Daten mit anderen Datenquellen abgeglichen und/oder zusammengefügt, um ein holistischeres Bild der Realität zu liefern.
Eine besondere Herausforderung spielt auch die Extraktionsart. Bis vor einer Weile war der sogenannte “Full extract”, also ein komplettes kopieren der Datenquelle, üblich. Dadurch hatte man immer die aktuellsten Daten im DWH gespeichert und konnte sie ohne Bedenken auf Aktualität, einer der wichtigen Faktoren in Datenqualität, weiter verarbeiten. Durch die Unmengen an Daten die inzwischen üblich sind, wird dieses Vorgehen aber immer mehr zum Problem. Die Menge an historischen Daten wird zum Beispiel in Enterprise-Unternehmen oder im IoT-Bereich schnell zu groß.
Folglich gibt es neuere Herangehensweisen, die sich auf Teil-Extraktion (“incremental extract”, zum Beispiel zeitlich begrenzt) oder auf Veränderungs-Extraktion (“Change Data Capture”, CDC) stützt. In diesem Methoden werden nur neu hinzugefügte oder veränderte Daten extrahiert. Die Voraussetzung ist zusätzlicher Modellierungs- und Verwaltungsaufwand, der große Vorteil jedoch sehr viel geringere Update-Laufzeiten des Data Warehouses.
Weiterhin müssen bereits in dieser Phase des ETL-Prozesses weitere Themen wie Historie (wie bilde ich zeitlich neue Daten ab) und Versionierung (was, wenn sich mein Datenmodell ändert?) bedacht werden, da sie einen großen Einfluss auf alle nachfolgenden Prozesse und Software-Lösungen haben.
Storage: Persistente Speicherung der Daten
Das eigentliche Herzstück jedes Data Warehouses ist der Storage Layer zur persistenten Speicherung der Daten. Dabei ist Skalierung der kritischste Punkt: Wie kann die Datenbank auf Datenmenge und Zugriffsmenge angepasst skaliert werden?
Generell ist klar, dass Data Warehouses als solches strukturierte Daten speichern. Es gibt zwar Ausnahmen wie zum Beispiel SnowFlake, die auch semi-strukturierte Daten erlauben, aber dies ist meist nicht der Fokus. Im einfachsten Fall würde daher eine einfache SQL-Datenbank als Basis reichen.
Diese Idee verflüchtet sich allerdings schnell, so wir über große Datenmengen sprechen. In diesem Fall ist die Hardware auf der die Datenbank läuft meist der limitierende Faktor. Daher muss eine Skalierung bedacht werden. Entweder vertikal (mehr CPU oder RAM) oder horizontal (mehrere Computer). On-Premise (also im eigenen Rechenzentrum) läuft dies auf Hardware-Basis, in der Cloud sind diese Ressourcen on-Demand verfügbar.
Wichtig zu differenzieren ist der klassische Data Warehouse Prozess der ETL-Ingestion von Daten von einer ELT-Variante. Zweitere Variante hat sich mit dem Aufkommen von Data Lakes etabliert und zielt darauf ab, zuerst die Rohdaten zu speichern, bevor sie in eine strukturierte Form überführt werden. Die zwei wichtigsten Vorteile dieses Vorgehens sind, dass einerseits auch unstrukturierte Daten (z.B. Bilder, Videos) gespeichert werden können und dass die aufwendige Vorbereitung (Datenmodellierung) erst im Nachgang / bei Bedarf gemacht werden muss.
Inzwischen ist es üblich und hauptsächlich empfohlen, selbst bei klassischen Data Warehouses alle Daten “roh wegzuspeichern” und sich erst dann um die Überführung in eine strukturierte Datenbank zu kümmern. Die Idee ist einerseits, dass Speicherung wenig kostet und somit kein “Schaden” dadurch generiert wird, andererseits dass durch Advanced Analytics immer mehr Rohdaten benötigt werden, um auch wirklich Datenpotential zu heben.
Während die ETL-Strecke herkömmlicherweise mittels Code (z.B. python) realisiert wurde, setzen sich inzwischen immer mehr Tools (z.B. Pentaho, Talend Stitch, AWS Glue,..) durch, die diese Aufgabe übernehmen. Vor allem für standardisierte externe Datenquellen (z.B. Facebook, Google..) ist es ein einfaches, dies als Softwarelösung umzusetzen.
Was ist Kobold AI?
Kobold AI bietet den Einsatz künstlicher Intelligenz ohne technisches Vorwissen. Einfach, schnell und günstig KI anwenden, um Mehrwert durch Daten zu generieren.
Wie es funktioniert erklärt unser interaktives Video:
Data Marts: Verfeinerung und Teilausschnitte um Business-Probleme zu lösen
Während ein Data Warehouse im Grundprinzip alle Daten eines Unternehmens beinhaltet, gibt es eine nachgelagerte Abstraktionsebene: Die Data Marts. Ein Data Mart ist ein Subset von Daten, die teilweise auch anderweitig angereichert (z.B. durch unstrukturierte Daten) oder aggregiert sind.
Warum benötigt man einen Data Mart? Die Idee ist, von einer sehr hohen Komplexität auf eine geringe, domänenspezifische Ansicht zu reduzieren. Dies erlaubt Datenanalysten schneller und einfacher die relevanten Daten zu identifizieren, ermöglicht fachspezifische Ansichten auf Datensätze und reduziert technische Faktoren wie Ladezeit und Updatefrequenz.
Ein weiterer Vorteil eines Data Marts können die Zugriffs- und Sicherheitsregeln sein. Wenn das gesamte Data Warehouse mit unlimitierten Zugriff an von aussen oder innen zugängliche Applikationen angebunden werden, hat dies im Falle eines Vorfalls verheerende Auswirkungen. Bei einem Data Mart hingegen werden die Zugriffe auf dieses Subset an Daten reduziert und somit die Risiken minimiert.
Serve Layer: Bereitstellung der Daten über Schnittstellen oder Zugriff
Die letzte Data Warehouse spezifische Ebene ist der Serve Layer, zu Deutsch die Bereitstellung der Daten. Neben Sicherheitsaspekten gilt hier vor allem auch die Frage, ob die Daten rein für Visualisierungszwecke (Business Intelligence) verwendet werden sollen oder weitere Advanced Analytics basierte Anwendungsfälle geplant sind.
Generell werden SQL-basierte Data Warehouses einfach über einen Direktzugriff angebunden. Dies eignet sich für viele Anwendungen mit fester Verwertung wie Dashboards. Möchte man die gelagerten Daten hingegen etwas flexibler nutzen, zum Beispiel über automatisiert generierte Reports oder im Bereich Data Science, gibt es auch neuere Konzepte wie die zur Verfügungstellung über APIs.
Wichtige Aspekte der Bereitstellung sind selbstverständlich Zugangskontrolle, Datensicherheit, Dokumentation (z.B. Qualität, Datenkatalog) und optimalerweise ein Self-Service-Prinzip.
Fazit der Beispielarchitektur
Die Anzahl der Schichten variiert leicht, je nachdem ob man beispielsweise Ingestion & Staging zusammengefasst oder einzeln lässt. Manche Architekturen weisen auch ETL als dem Staging nachgefassten Prozess auf, während er hier eher sowohl Ingestion, Staging als auch Storage umfasst.
Während diese Beispielarchitektur für Data Warehouses sicherlich als Blueprint genutzt werden kann, gibt es viele Dinge die individuell beachtet und somit modifiziert werden müssen. Ob nun interne oder externe Datenquellen, ob full extract oder incremental, ob raw dump oder direkt in das Warehouse transferiert, ob high volume oder high variability: Je nachdem welche Anforderungen man an das DWH stellt muss eine passende Architektur gewählt werden.
Welche Software / Tools gibt es um ein Data Warehouse aufzusetzen?
Hier eine grobe Übersicht über Tools, über die ein Data Warehouse realisiert werden kann:
| Software | Beschreibung |
|---|---|
| SAP Data Warehouse Cloud / SAP BW/4HANA / SAP HANA | Wohl das bekannteste DWH von SAP. |
| AWS Glue (ETL), AWS RedShift (Storage), AWS QuickSight (Visualisation) | AWS-basierte Services, können ergänzt oder ersetzt werden durch anderes Services (Event Streaming, S3 storage, etc). |
| Azure Data Factory (ETL), Azure SQL Data Warehouse (Storage), PowerBI (Visualisation) | Wie AWS, jedoch für Microsoft Cloud Services. |
| Oracle Data Warehousing (Storage) | Oracle ist besonders stark in SQL-Datenbanken. |
| Alteryx (ETL, Visualisation) | Die Stärke von Alteryx liegt vor allem im ETL-Prozess und dem Aufbereiten für Analysen. |
| Talend / Stitch (ETL) | Talend fokussiert sich auf ETL. |
| MuleSoft (ETL) | MuleSoft fährt eine API-Mesh Strategie in ihrem ETL-Prinzip. |
Ein Data Warehouse aufbauen: Grober Ablauf-Plan / Framework
Ein Data Warehouse im Unternehmen aufzubauen ist sehr komplex und erfordert einen langfristigen Invest. Inzwischen ist es auch üblich, DWHs nicht mehr Monolithisch-wasserfallmäßig über mehrere Jahre hinweg aufzubauen, sondern sukzessive agil zu erstellen. Daten und Anwendungsfälle werden nach und nach eingearbeitet statt eine allumfassende Lösung zu kreieren. Nichtsdestotrotz möchten wir hier grob skizzieren, welche Aspekte beim Aufbau eines Data Warehouses wichtig sind und wie diese in einem groben Framework abgearbeitet werden könnten.
- Identifikation und Ausformulierung der Anwendungsfälle (Stakeholder Research)
- Erstellung Ziel-KPIs und Hierarchie (KPI-Tree)
- Identifikation und Überprüfung entsprechender Datenquellen
- Definition der Architektur und der eingesetzten Lösungen / Software
- Umsetzung der Architektur und iterative Anbindung der Datenquellen (Data Engineering)
- Iterative Überprüfung der Daten, Visualisierung und Abnahme durch Business-Stakeholder
Wichtig zu erkennen ist, dass nebst der generellen Architektur sehr viel in einem agilen, iterativen Vorgehen umgesetzt werden sollte. Dies hat zum Hintergrund, dass damit schneller Ergebnisse sichtbar werden und gleichermaßen auch flexibler auf neue Herausforderungen reagiert werden kann. Weiterhin ist die Menge an Datenquellen in den meisten Unternehmen so hoch, dass ein Wasserfall-Vorgehen nicht realisierbar ist.
Zusammengefasst sollte der Aufbau eines Data Warehouses drei Hauptfaktoren im Blick behalten:
- Stakeholder-zentriert arbeiten
- Architektur basierend auf Anwendungsfällen definieren
- Agile Umsetzung statt langjährigen Projekt
Welche Rollen sind an einem DWH beteiligt?
Die Idee eines Data Warehouses beruht auf der Verwendung von Daten über operative Zwecke hinaus. Folglich gibt es viele Personen, die sich mit einem Data Warehouse bzw. dessen Verwendung beschäftigen sollen:
- BI Experten: Das Herzsstück eines DWHs sind ein oder mehrere Business Intelligence Experten. Sie kennen Aufbau, Dokumentation und Anwendung des Warehouses und organisieren die Anbindung von neuen Datenquellen. Oftmals sind sie auch direkt für die Erstellung von Reports und ähnlichem zuständig.
- Domänenexperten: Während BI Experten eine Querfunktion darstellen, wird der Mehrwert eines DWHs in der Domäne, also zum Beispiel Sales, Marketing oder Logistik generiert. Daher sind Domänenexperten dafür verantwortlich, die richtigen Daten anzubinden und die richtigen Auswertungen zu generieren.
- Controlling: Einer der häufigsten Ursprünge von Business Intelligence ist die Controlling-Abteilung eines Unternehmens. Daher sind sie auch oft eng an einem Data Warehouse beteiligt.
- Datenbankadministration: Setzt man auf eine SQL-Datenbank, braucht es technische Unterstützung aus der IT.
- Cloud Solution Engineers: Setzt man hingegen auf eine Cloud-Lösung, muss diese aufgebaut und gepflegt werden. Ob Cloud Solution Engineer oder Data Engineer oder Data Architect: Eine sehr wertvolle Rolle, um die Datenflüsse zu gewährleisten und die Infrastruktur am Laufen zu halten.
- Business Analysts / Data Analysts: Oft gibt es neben dem generellen BI Experten auch verantwortliche Analysten in der Domäne oder einer zentralen Einheit, die sich um die Auswertung der Daten kümmern. Hier gilt es, Domänenwissen mit Daten-Expertise zu kombinieren, um möglichst “actionable insights” zu generieren.
- Visualisation Experts: Ist ein Unternehmen sehr bewandert im Einsatz von Daten und Dashboards, wird die Visualisierung selbst – also die Erstellung des Dashboards – ggf. sogar an Experten dafür ausgelagert.
- Data Scientists: Eine andere Art von Konsument für Daten aus dem DWH sind Data Scientists. Sind die Daten in sehr hoher Auflösung vorhanden, kann mittels Data Mining neue Erkenntnisse herausgearbeitet werden.
Häufige Fragen zum Data Warehouse (FAQ)
Was ist ein Data Mart?
Ein Data Mart ist ein Subset an Daten eines Data Warehouses für einen speziellen Zweck. Zum Beispiel nur Marketing-relevante Daten für die Marketing-Abteilung. Somit ist es also quasi eine Art kleinere Data Warehouse eines Data Warehouses.
Data Marts werden erstellt, um die Komplexität zu reduzieren, Sicherheit zu erhöhen und den Analyseprozess zu vereinfachen.
Data Warehouse vs. Data Lake: was ist der Unterschied?
Data Warehouses speichern explizit strukturierte, vorbereitete Daten zu einem spezifischen Zweck (Analyse bzw. Business Intelligence). Data Lakes hingegen speichern sowohl strukturierte als auch unstrukturierte Daten für eine Vielzahl an (ggf. noch unbekannten) Anwendungszwecken.
Für eine detailliertere Unterscheidung, besucht unseren Artikel “Data Warehouse vs Data Lake: Der Unterschied einfach erklärt”.
DWH vs Enterprise Data Warehouse (EDW): Was ist der Unterschied?
Sowohl Data Warehouse (DW oder DWH) als auch Enterprise Data Warehouse (EDW) bezeichnen das gleiche Prinzip zur Datenspeicherung. Der einzige Unterschied kann sein, dass Enterprise Data Warehouses für große Konzerne gedacht und geplant sind. Semantisch gibt es aber keinen Unterschied.
Basiert ein Data Warehouse auf ETL oder ELT?
Generell basiert ein DWH auf ETL, also Extraktion-Transform (Staging)-Load. Die Datenmodellierung wird vorab erledigt und Daten strukturiert in die Datenbank überführt. Jedoch ändert sich die Datenlandschaft und somit auch die Rolle des DWHs. Oft sind sie in einen größeren Datenprozess eingebaut, der auf ELT basiert. Hierbei werden die Daten erst in einen Data Lake extrahiert und von dort dann mittels ETL ins DWH überführt.
Wie werden Daten im DWH geupdated?
Es gibt prinzipiell zwei Methoden: Full extract und partial / incremental extraction. Im full extract wird die gesamte Datenquelle neu ins DWH eingespeist. In der incremental extraction werden nur neue Daten hinzugefügt beziehungsweise veränderte Daten angepasst.
Wie oft wird ein Data Warehouse geupdated?
Die “Update Frequency” eines DWHs ist stark abhängig vom Unternehmen, der eingesetzten Technologie, den Datenmengen und den Anwendungsfällen. Der häufigste Fall ist wohl eine batch extraction, die einmal in der Nacht ausgeführt wird. Moderner hingegen sind höhere Update-Frequenzen oder Real-Time Data Warehouses, die zum Beispiel durch einen Event Stream gefördert werden.
Was ist Kobold AI?
Kobold AI bietet den Einsatz künstlicher Intelligenz ohne technisches Vorwissen. Einfach, schnell und günstig KI anwenden, um Mehrwert durch Daten zu generieren.
Wie es funktioniert erklärt unser interaktives Video: