Wer sich mit dem Thema Business Intelligence beschäftigt, wird schnell mit dem Begriff Data Warehouse konfrontiert. Eine sich daran anschließende Frage ist häufig, ob mit Power BI ein Data Warehouse noch benötigt wird. In diesem Beitrag erläutere ich dir die wichtigsten Begriffe zu diesem Themengebiet. Dabei zeige ich dir auch, wie sich ein Data Warehouse in eine BI-Landschaft einreiht und welche Rolle Power BI in diesem Zusammenhang spielt.
Ein Blick in die Welt des Data Warehousings
In dem ersten Teil ignorieren wir erst einmal Power BI und werfen einen Blick auf das Data Warehouse an sich. Dabei beantworten wir die Fragen:
- Was ist ein Data Warehouse?
- Wie sieht eine klassische Data Warehouse Architektur aus?
- Welche wesentlichen Technologien spielen dabei eine Rolle?
- Was sind die Vor- und Nachteile eines Data Warehouses?
Zuvor ein kurzer Rückblick: Die Kernaktivitäten einer Reporting-Lösung
In einem vorausgegangenen Beitrag habe ich die wesentlichen Kernaktivitäten einer Reporting-Lösung erläutert. Diese sind:
- Datenerstellung
- Datenintegration
- Datenmodellierung
- Datenpräsentation
Diese Kernaktivitäten bilden die Grundlage für die Beschreibung der verschiedenen Data Warehousing Technologien. Folgend findest du als Grundlage noch einmal das Bild aus dem Artikel, welches die verschiedenen Aktivitäten zeigt.
Sofern dir die Begriffe noch nichts sagen, empfehle ich dir vorab einen Blick in den Beitrag.
Was ist ein Data Warehouse?
Ein Data Warehouse ist ein zentraler Ort für die Vorhaltung unternehmensweit harmonisierter Daten, welche für den Aufbau analytischer Datenmodelle vorgehalten werden. Mit einem Data Warehouse wird das Risiko minimiert, dass verschiedene Datenmodelle bei dem gleichen Sachverhalt verschiedene Zahlen ausgeben.
Je mehr Datenintegrationslogik in ein zentral gesteuertes Data Warehouse überführt wird, desto höher ist die Wahrscheinlichkeit, dass z.B. in verschiedenen Datenmodellen auch der gleiche Umsatz oder die gleiche Mitarbeiteranzahl abgebildet wird, sofern die Daten aus dem Data Warehouse auch genutzt werden.
In den folgenden Kapitel durchlaufen wir nun sukzessive verschiedene Versionen einer BI-Architektur unter Berücksichtigung verschiedener Technologien.
Die traditionelle Data Warehouse Architektur
Durch diverse technischer Innovationen und Cloud Computing unterlag das Data Warehouse in den letzten Jahren einem starken Wandel. Die neuen Technologien ergänzen aber häufig das Data Warehouse und ersetzen es nicht. Daher starten wir unsere Reise durch die Welten des Data Warehousing mit einer traditionellen Architektur, welche genau in dieser Form auch heute noch regelmäßig vorkommt.
Vorstellung der grundlegenden Komponenten
Eine traditionelle Data Warehouse Architektur besteht aus drei verschiedenen Kernkomponenten:
- Data Warehouse
- Data Marts
- ETL-Tool
Das folgende Bild zeigt das Zusammenspiel zwischen diesen Komponenten anhand der Kernaktivitäten einer Reporting-Lösung. Danach gehe ich auf die Begriffe Data Warehouse, Data Mart und ETL genauer ein.
Wie du in dem Bild sehen kannst, finden die Reporting-Kernaktivitäten Datenintegration und Datenmodellierung zweimal statt, einmal im Scope des Data Warehouses und einmal im Scope der Data Marts. Um die Unterschiede besser nachvollziehen zu können, werden die Kernkomponenten nun genauer beschrieben.
| Begriff | Beschreibung |
|---|---|
| Data Mart | Ein Data Mart entspricht im Prinzip genau dem analytischen Datenmodell, welches du auch ohne Data Warehouse bauen würdest und welches ich in dem Beitrag über die Kernaktivitäten einer Reporting-Lösung erläutert habe. Dieses Datenmodell ist eine datenbasierte Repräsentation des Anwendungsfalls, welchen du analysieren möchtest. Ein gutes Datenmodell folgt dem Sternenschema, weswegen ich dem Sternenschema einen eigenen Beitrag gewidmet habe. Sobald das Datenmodell vorliegt, werden zusätzlich Berechnungen (Metriken und KPIs) ergänzt, sodass diese in der letzten Phase, der Datenpräsentation, verwendet werden können. |
| Data Warehouse | Das Hauptziel des Data Warehouses ist die unternehmensweite Harmonisierung von Daten für analytische Zwecke. Das Data Warehouse basiert in der Regel auf einer relationalen Datenbank. Die Daten werden dementsprechend in Form von Tabellen abgespeichert sowie mittels Schlüssel und Beziehungen miteinander verknüpft. Typischerweise werden auch hier bereits die Konzepte des Sternenschemas berücksichtigt, um die Datenintegrationsaktivitäten im Scope des Data Marts möglichst zu reduzieren und die Datenintegrität zwischen mehreren Data Marts zu erhöhen. |
| ETL-Tools | Mit Power Query verfügt Power BI Desktop zwar bereits über ETL-Funktionalitäten, jedoch gibt es für die Abdeckung von Datenintegrationsanforderungen natürlich auch spezialisierte ETL-Tools mit größeren Funktionsumfang, welche bei Data Warehouse Architekturen zur Anwendung kommen. Darüber hinaus landen Daten bei Power Query am Ende immer in Power BI. Die hochspezialisierten Tools sind dagegen in der Lage, Daten an verschiedenste Zielorte zu laden. |
Gegenüberstellung des Data Warehouses und der Data Marts
Um insbesondere die Unterschiede zwischen Data Warehouse und Data Mart besser zu verstehen, findest du folgend eine Gegenüberstellung anhand verschiedener Kriterien.
| Kriterium | Data Warehouse | Data Mart |
|---|---|---|
| Ziel | Bereitstellung unternehmensweit harmonisierter Daten als Grundlage für analytische Zwecke | Bereitstellung eines Datenmodells inkl. KPIs als Grundlage für Reports für einen bestimmten Anwendungsfall oder eine bestimmte Abteilung |
| Anzahl | Im besten Fall ein einziges Data Warehouse | Mehrere Data Marts, zum Beispiel pro Anwendungsfall oder Abteilung |
| Datenquelle | Operative Quellsysteme | Datawarehouse (unternehmensweit harmonisierte Daten) sowie operative Quellsysteme über Direktanbindung (siehe nächstes Kapitel) |
| Granularität | Häufig höchstmöglicher Detailgrad, bzw. auf Transaktionsebene | Häufig aggregierte Daten (für bessere Performance) und nur Details, wo gefordert |
| Rollen | Datenarchitekt, Datenbankadministrator und ETL-Spezialist | Datenanalyst |
Hybride Befüllung von Data Marts
Bei einer Data Warehouse Architektur werden Data Marts häufig nicht ausschließlich durch das Data Warehouse befüllt. Denn häufig werden in dem Data Warehouse nur Daten mit einer gewissen Relevanz verarbeitet und bereitgestellt. Die Bewertung der Relevanz kann in jedem Unternehmen anders ausfallen.
Aus diesem Grund ist es gängig, dass ein Datenanalyst zum Beispiel Finanzdaten aus dem Data Warehouse heranzieht und darüber hinaus weitere Daten aus den Quellsystemen über eine Direktverbindung einspielt, welche nicht von dem Data Warehouse berücksichtigt werden. Ein anderer klassischer Fall wäre eine separate Excel-Datei, wo noch bestimmte Planzahlen, Mapping-Tabellen oder Kommentare vorgehalten werden. Das untere Bild verdeutlich das hier beschriebene Szenario.
Weitere Technologien auf dem Vormarsch
In den bisherigen Kapiteln lag der Fokus auf dem traditionellen Data Warehouse, welches auf relationalen Datenbanken basiert. Mit hoher Wahrscheinlichkeit hast du aber schon einmal von den Begriff „Data Lake“ gehört.
| DWH-Komponente | Beschreibung |
|---|---|
| Data Lake | Ein Data Lake ist ein hochflexibler, kostengünstiger und multifunktionaler Datenspeicher. Der signifikanteste Unterschied zum Data Warehouse besteht darin, dass die Daten nicht in Form von Tabellen und Beziehungen (strukturierte Daten), sondern direkt als Datei abgelegt werden. Klassische Dateitypen sind z.B. CSV, JSON und Parquet (semi-strukturierte Daten). Es können aber auch Bild-, Video- oder PDF-Dateien (unstrukturierte Daten) ohne Probleme und ohne jegliche Transformation hochgeladen werden. Ein Data Lake ist, stark vereinfacht, vergleichbar mit dem Dateiexplorer auf deinem Laptop, nur dass ein Data Lake enorme Mengen mehr Speicher, mehr Power sowie zusätzlicher Funktionen vorweist. Ein Data Lake ergänzt eher ein Data Warehouse, anstatt es zu ersetzen. |
| Data Lakehouse | Gerade für den Einstieg sind die oben genannten Begriffe bereits eine Menge Input. Daher halten wir es hier kurz. Relationale Datenbanken und Data Lakes haben jeweils ihre Stärken und Schwächen und daraus resultierende Einsatzgebiete. Davon ausgehend haben sich mit der Zeit neue All-in-One-Lösungen etabliert, welche Funktionalitäten aus relationalen Datenbanken, Data Lakes und ETL-Tools zusammen in einer Lösung abbilden, sogenannte Data Lakehouses. |
| ELT | Wir haben bisher immer den Begriff ETL verwendet und nun kommt der Begriff ELT? So wie ETL für Extract, Transform, Load steht, steht ELT für Extract, Load, Transform. Es ist also tatsächlich nur eine andere Reihenfolge der Aktivitäten. Dieser Ansatz hat sich insbesondere mit dem Vormarsch des Data Lakes etabliert, da hier flexibel und kostengünstig unabhängig vom Dateiformat die Daten direkt aus den Quellsystemen extrahiert und direkt abgelegt werden können. Gleichzeitig werden dabei die Quellsysteme Performance-seitig entlastet, da die rechenintensiven Transformationen erst durchgeführt werden, nachdem die Daten separat abgespeichert werden. Um es einfach zu halten verwende ich allgemein den Begriff ETL, wohinter sich aber beides hinter verbergen kann. |
Das folgende Bild ergänzt unsere Architektur um einen Data Lake. Eine Data Lakehouse wäre dementsprechend eine Kombination aller Komponenten (Data Warehouse, Data Lake und ETL) in einer Lösung.
Begriff "Data Warehouse Architektur" Da wir nun gesehen haben, dass sich durch den technologischen Wandel hinter dem Begriff Data Warehouse am verschiedenste Technologien verbergen können, werde ich für die folgenden Kapitel einfach den Begriff DWH nutzen. Damit meine ich die Sammlung aller oben vorgestellten Tools für die Sammlung, Integration und Vorhaltung von Daten mit dem Zweck, diese den Datenanalysten für den Aufbau analytischer Datenmodelle zur Verfügung zu stellen.
Benötige ich ein Data Warehouse? Vor- und Nachteile im Überblick
Vielleicht stellst du dir nun die Frage, ob sich ein Data Warehouse für dein Unternehmen lohnt. Vielleicht hilft dir bei der Einschätzung die folgende Übersicht der Vor- und Nachteile. Dabei wird nicht zwischen Data Warehouse, Data Lake oder Data Lakehouse unterschieden.
- Single Source of Truth für unternehmensweit gültige Daten
- Verbesserte Datenintegration, dank größerem Funktionsumfang
- Mehr Performance bei besonders großen Datenmengen
- Entlastung der Quellsysteme durch zentrales Timing, der Datenextraktionen
- Bessere Data mart Performance durch aggregierte Daten, während Details im DWH harmonisiert vorliegen
- Skalierbare Automatisierung Versionierung und Historisierung von Daten
- Datenanalysten können sich auf Datenmodelle und Reports konzentrieren
- Bespielung verschiedener BI- und Visualisierungslösungen mit den gleichen Daten möglich
- Zusätzliche Kosten für Technologie (Lizenzen) und Personal (Datenarchitekt, DWH-Administrator und/oder ETL-Experten)
- Weiteres Knowhow notwendig (Personalbeschaffung oder Dienstleister)
- Höhere Software-Komplexität, da mehr Tools im Einsatz
- Mehr Rollen und Personen in der Kommunikationskette von Datengenerierung bis Datenpräsentation
Aber einer gewissen Größe oder Komplexität heißt es nicht mehr ob, sondern wie? Bei all den Vor- und Nachteilen ist wichtig zu verstehen, dass man ab einer gewissen Anforderungskomplexität und Unternehmensgröße nicht mehr um eine separate Datenintegrationsschicht (in welcher Form auch immer) herumkommt. In diesem Fall geht es nicht mehr darum, ob man es braucht, sondern nur noch darum, wie man es aufsetzt.
Data Warehousing und Power BI
Nach der allgemeinem Einführung in die Welt des Data Warehousings schauen wir uns nun das Ganze im Zusammenhang mit Power BI an. Dabei gehen wir auf zwei verschiedene Szenarien ein:
- Power BI als Data Mart mit separaten Data Warehouse
- Data Warehousing mit Power BI Dataflows
Power BI geht auch ohne Data Warehouse Ein Data Warehouse ist keine zwingende Voraussetzung für Power BI. Durch die umfangreichen Funktionalitäten von Power BI lassen sich auch ohne Data Warehouse effektive Reporting-Lösungen implementieren. Dies gilt vor allem dann, wenn das vorausgegangene Reporting zum Beispiel nur auf Excel beruht. Doch spätestens wenn mehrere Power BI Datasets und Reports etabliert wurden, sollte das Thema Data Warehousing in Erwägung gezogen werden.
Szenario 1: Verwendung von Power BI mit separatem Data Warehouse
Bevor wir uns Szenarien anschauen, wo wir Power BI für Data Warehouse Aktivitäten verwenden, schauen wir uns erst einmal das klassische Szenario an, in welchem Power BI die Rolle des Data Marts annimmt und mit einem separaten Data Warehouse verknüpft wird. Dieses Data Warehouse kann auf verschiedenen Technologien von verschiedenen Anbietern bestehen. Ich stelle dir hier die wesentlichen Technologien aus dem Microsoft Azure Stack vor. Microsoft Azure ist die Cloud Computing Platform vom Microsoft. Mit Microsoft Azure ist es möglich, ganze IT-Infrastrukturen flexibel aufsetzen und eine Vielzahl an Software-Lösungen direkt einzubinden. Das Aufsetzung und die Wartung dieser Lösungen wird typischerweise durch die IT-Abteilung oder durch einen Dienstleister übernommen, also nicht durch die Fachabteilung.
Bitte beachte, dass die vorgestellten Technologien in verschiedensten Kombinationen verwendet werden können. Da in diesem Beitrag der Fokus nicht auf Microsoft Azure liegt, halte ich die Erläuterungen wirklich sehr kurz.
| Microsoft Azure Komponente | Beschreibung |
|---|---|
| Azure SQL | Ein Dienst für die Bereitstellung einer relationalen Datenbank als Basis für das traditionelle Data Warehouse |
| Azure Data Lake Storage | Ein Dienst für die Bereitstellung eines Data Lakes für die Speicherung diverser Medien und Dateitypen |
| Azure Data Factory | Eine ETL-Lösung für die Erfüllung einfacher und komplexer Datenintegrationsanforderungen |
| Azure Synapse | Das Microsoft-eigene Data Lakehouse, welches eine Vielzahl an Features von Azure SQL, Data Lake Storage und Data Factory in einer Lösung vereint |
Die folgende Abbildung zeigt die Einordnung der Azure Technologien in die bisher vorgestellte DWH-Architektur und ergänzt diese um die Power BI Komponenten, wobei das Dataset dem oben vorgestellten Data Mart entspricht. Die als optional dargestellten Dataflows, werden in dem folgenden Kapitel vorgestellt.
Szenario 2: Data Warehousing mit Power BI Dataflows: kosteneffizient, einfach zu bedienen und effektiv, aber mit Grenzen
So wie es in Power BI Desktop das Modul Power Query gibt, gibt es im Power BI Service die sogenannten Dataflows. Ein Dataflow ist im Prinzip eine Stand-Alone-Variante eines Power Query Moduls mit dem Unterschied, das Dataflows sich direkt im Power BI Service befinden. Dataflows können innerhalb aller Arbeitsbereiche erstellt werden, außer den Personal Workspaces.
Aufbau der Lösung
Genau wie mit Power Query, verbindest du dich bei der Erstellung eines Dataflows mithilfe der bekannten Konnektoren mit einer oder mehrerer Datenquellen. Sobald die Verbindung hergestellt wurde, erlebst du das gleiche Look & Feel wie in dem Power Query Modul in Power BI Desktop, sogar mit weiteren Features. Das besondere an einem Dataflow ist, dass das Ergebnis der Abfrage auch direkt in dem Dataflow gespeichert wird. Es können auch mehrere Dataflows miteinander verknüpft werden. Dies ist auch der Grund, warum mithilfe von Dataflows eine zentrale Datenintegrationsschicht aufgebaut werden kann. Denn nachdem die Daten durch einen Dataflow gelaufen sind, kannst du dich zum Beispiel mit Power BI Desktop mit dem Dataflow verbinden und auf Basis der in dem Dataflow harmonisierten Daten deine Lösung bauen. Dabei kannst du auch in Power Query zusätzliche Transformation vornehmen, bevor du die Daten in dein Datemodell (Dataset) hineinlädst.
In diesem Beispiel werden die unternehmensweiten Integrationsaktivitäten, welche sonst in einem DWH stattfinden würden, innerhalb eines Power BI Workspaces mit Premium Lizenz (auch Premium pro User möglich) abgebildet. Für die Durchführung der ETL-Schritte werden Power BI Dataflows verwendet.
Der Power BI Premium Workspace bildet die Single Source of Truth für die unternehmensweit gültigen Daten. Von hier ausgehend werden über weitere Dataflows die Daten an die Datenanalysten der verschiedenen Bereiche (z.B. Finance oder HR) verteilt. Auf diese Weise wird sichergestellt, dass die jeweiligen Datenanalysten nur die Daten sehen, welche sie auch sehen sollen.
Folgend findest du wesentliche Argumente, warum dieser Ansatz eine erwägenswerte Option für die Implementierung einer zentralen Datenintegrationsschicht ist:
- Einfaches Preismodell mit vergleichsweise geringen Zusatzkosten*
- Keinerlei Tool-Übergänge — alles findet in Power BI statt
- Es kann mit bestehendem Knowhow direkt losgelegt und somit auch sehr zügig Mehrwert generiert werden
- Es lässt sich sehr rollierend mit ersten Use-cases verproben und dann iterativ ausrollen
* benötigt Power BI Premium, bzw. Power BI Premium pro User
Power BI Data Marts Im Mai 2022 hat Microsoft eine neue Komponente innerhalb des Power BI Services vorgestellt, nämlich die Power BI Data Marts. Kurz beschrieben vereinen Power BI Data Marts die Komponenten Dataflow und Dataset. Darüber hinaus können Daten zum Beispiel auch per SQL abgefragt werden. Persönlich habe ich Power BI Data Marts noch nicht im Produktivszenario genutzt und auch ein Blick in die Power BI Community zeigt, dass Power BI Data Marts sich bei der Verwendung wenn dann häufig noch in der Pilotierung befinden. Aus diesem Grund habe ich Power BI Data Marts hier ausgeklammert. An dieser Stelle solltest du erst einmal mitnehmen, dass "Data Mart" ein gängiger BI-Architektur-Begriff ist (wie oben beschrieben) und "Power BI Data Mart" eine Power BI Service Produktkomponente ist. Falls du mehr über Power BI Data Marts erfahren möchtest, findest du hier einen einführenden Microsoft-Learn-Beitrag Introduction to datamarts - Power BI | Microsoft Learn.
Grenzen der Lösung
Wie in dem Titel bereits erwähnt, stößt diese Lösung aber auch an Grenzen und lässt sich nicht endlos skalieren. Mit zunehmenden Daten, Personen und Anforderungen bedarf es einfach irgendwann hochspezialisierter Tools für Datenintegration, Datenhaltung und Datenmanagement. Folgend findest du eine Auswahl an Grenzen, welche in dem Power BI Dataflow Szenario nicht oder nur mäßig abgedeckt werden.
- Großvolumige Skalierung von Datenmenge und Rechenleistung
- Realisierung von ETL-Aktivitäten mit hoher Komplexität
- Historisierung und Versionierung von Daten
- Verwendung diverser Programmiersprachen
- Fortgeschrittene Anforderungen im Bereich Administration und Datenmanagement
- Integration weiterer Services und Software-Lösungen
- Bereitstellung der Daten für Aktivitäten außerhalb des Microsoft Ökosystems
Das sieht vielleicht für den einen oder anderen erst einmal nach einer ganzen Menge Nachteile aus. Aber nicht alle diese Nachteile müssen dein Unternehmen betreffen. Daher ist es aber umso wichtige wirklich zu bewerten, was am Ende in welchem Zeitraum benötigt wird und was nicht. Denn man sollte nicht vergessern, dass die Spezial-Tools ein deutlich umfangreicheres Knowhow erfordern, sowohl technisch als auch organisatorisch. Darüber hinaus ist die Einführung einer der Spezial-Tools deutlich komplexer und erfordert ein deutlich höheres Investment mit längerer Implementierungszeit.
Gerade deswegen kann aber die hier vorgestellte Ansatz ein höchsteffiziente und effektive Lösung oder ein Zwischenschritt auf dem Weg zu einer zukünftigen DWH-Architektur sein.
Fazit
Dieser Beitrag gab dir einen Einblick in die grundlegenden Architekturbestandteile des Data Warehousings und ordnete Power BI in in diesem Zusammenhang ein. Ich hoffe, dass du aus dem Artikel die folgenden Punkte entnehmen konntest.
- Ein Data Warehouse ist ein zentraler Ort für die Vorhaltung unternehmensweit harmonisierter Daten, welche für den Aufbau analytischer Datenmodelle vorgehalten werden
- ein Data Warehouse basiert häufig auf einer relationalen Datenbank und wird mittlerweile oft durch ein Data Lake ergänzt
- Für die Befüllung von Data Warehouses und Data Lakes kommen spezielle ETL-Tools zum Einsatz
- Ein Data Lakehouse ist eine All-in-One-Lösung, welche die zuvor genannten Lösungen zusammen vereint
- Power BI geht auch ohne Data Warehouse. Doch mit zunehmender Unternehmensgröße, Anzahl an Stakeholdern und Datenvielfalt, sollte das Thema Data Warehousing evaluiert und angegangen werden
- Wenn man Data Warehousing im Zusammenspiel mit Power BI durchführen möchte, gibt es zwei grundlegende Szenarien: 1) Data Warehousing mit Power BI Premium und Dataflows 2) Power BI mit separater DWH-Lösung
- Power BI Dataflows ist eine sehr kosteneffiziente, effektive Lösung, direkt realisierbare Lösung, stößt irgendwann aber an Grenzen, vor allem mit zunehmender Unternehmensgröße
- Power BI mit separater DWH-Lösung ermöglicht die Abbildung komplexester Szenarien und lässt sich nahezu endlos skalieren, jedoch geht es mit hohen Kosten und längeren Implementierungszeiten einher
- Aufgrund der hohen Flexibilität und geringen Implementierungsaufwand sind Power BI Dataflows auch eine solide Option für einen Zwischenschritt Richtung „echter“ DWH-Architektur
Ich freue mich sehr, dass du es bis hierhin geschafft hast! Bleib datenhungrig und bis bald!