Skip to Content
Last modified by Dimitri Rupp on 2026/06/11 09:30
Show last authors
1 {{box cssClass="floatinginfobox" title="**Inhalt**"}}
2 {{toc/}}
3 {{/box}}
4
5 = 🏗️ Microsoft Fabric Datenarchitektur im SPL =
6
7 == Überblick ==
8
9 Das Ziel dieses Dokuments ist es, eine kurze Einführung in die Fabric-Datenarchitektur im SPL zu geben.
10
11 **Fabric** ist eine integrierte Datenverwaltungsplattform, die verschiedene Aufgaben wie Datenaufnahme, Speicherung, Transformation und Optimierung in einem einheitlichen System vereint. Sie hilft Unternehmen, Daten effizienter zu verwalten, zu analysieren und darauf zu reagieren, indem sie eine nahtlose Erfahrung über verschiedene Daten-Workloads und -Tools hinweg bietet.
12
13 Im SPL gilt Fabric als **Single Source of Truth**. Daten aus Fabric können in Power BI, Excel-Arbeitsmappen, Board, SQL Management Studio (SSMS), Azure Data Studio und anderen Drittanbieter-Tools genutzt werden, die eine Authentifizierung über Microsoft Entra unterstützen.
14
15 == Fabric im SPL ==
16
17 //Datenfluss in Fabric — Übersicht der wichtigsten Komponenten und Daten-Pipelines im SPL.//
18
19 Basierend auf den bewährten Richtlinien von Microsoft verwenden wir eine **Medaillon-Architektur** zur Datenorganisation. Sie besteht aus drei Ebenen mit zunehmender Datenqualität:
20
21 {{mermaid}}
22 flowchart LR
23 SRC[📂 Quellsysteme<br/>Rimo · BMD · Board · H3A<br/>SharePoint · ADLS] --> B[🥉 Bronze<br/>Rohdaten]
24 B -->|Bereinigung<br/>Validierung<br/>Harmonisierung| S[🥈 Silver<br/>Validierte Daten]
25 S -->|Anreicherung<br/>Aggregation| G[🥇 Gold<br/>Konsumierbare Daten]
26 G --> PBI[📊 Power BI<br/>Berichte und Dashboards]
27 G --> EXT[🔗 Drittanbieter<br/>Excel · Board · SSMS]
28
29 style B fill:#cd7f32,color:#fff
30 style S fill:#c0c0c0,color:#000
31 style G fill:#ffd700,color:#000
32 {{/mermaid}}
33
34 * **Bronze-Schicht (Rohdaten):** erfasst Rohdaten aus verschiedenen Quellen ohne Verarbeitung oder Transformation. Erste Ablagezone für alle Daten.
35 * **Silber-Schicht (validierte Daten):** Daten aus der Bronze-Schicht werden bereinigt, validiert und harmonisiert. Bietet einen verfeinerten Datensatz mit detaillierten Informationen für Analysen.
36 * **Gold-Schicht (angereicherte Daten):** enthält hochverarbeitete und angereicherte Daten, die bereit zur Nutzung sind.
37
38 Diese Architektur gewährleistet, dass die Datenqualität sich schrittweise verbessert, während die Daten jede Schicht durchlaufen — ideal für Datenbereitstellung und Berichterstellung.
39
40 Die Architektur von Fabric im SPL ist in sieben Schlüsselaufgaben organisiert. Eine ähnliche Aufgabenansicht findet sich auch im Fabric-Arbeitsbereich:
41
42 //Aufgaben-Übersicht im Fabric-Arbeitsbereich.//
43
44 == Datenaufnahme ==
45
46 **Zweck:** verantwortlich für das Kopieren von Daten aus verschiedenen Quellen wie On-Premise-Systemen, SharePoint und ADLS.
47
48 Je nach Quelltyp variiert das Element, das für die Datenaufnahme verwendet wird. Zu den Elementen gehören Datenpipelines, Datenflüsse und Notebooks.
49
50 //Datenaufnahme-Aufgabenflow im SPL Fabric.//
51
52 === Datenpipelines ===
53
54 Pipelines können basierend auf ihrem Verwendungszweck in zwei Kategorien eingeteilt werden — **Ingestion-Pipelines** und **Ausführungs-Pipelines**.
55
56 ==== Ingestion-Pipelines ====
57
58 Wenn die Quellsysteme On-Premise-Server sind, werden Datenpipelines für die Datenaufnahme verwendet. Derzeit verwenden wir eine separate Pipeline für jeden einzelnen On-Premise-Server. So haben wir jeweils eine Pipeline für **Rimo, BMD, Board und H3A**. Details zu den einzelnen Pipelines und den kopierten Tabellen finden sich auf der DATA-CATALOGUE-Seite.
59
60 ==== Ausführungs-Pipelines ====
61
62 Ausführungs-Pipelines werden genutzt, um Operationen auszulösen. In bestimmten Fällen müssen zusätzliche Operationen direkt nach dem Durchlauf einer Ingestion-Pipeline ausgeführt werden. Beispielsweise wird bei einer notwendigen Historisierung eine Notebook-Aktivität unmittelbar nach der Kopieraktivität in die Ingestion-Pipeline eingefügt. Die gesamte Pipeline wird dann über eine Ausführungs-Pipeline ausgeführt. Eine Ausführungs-Pipeline kann weitere Pipelines, Datenflüsse, gespeicherte Prozeduren und Notebooks als Aktionselemente enthalten.
63
64 Ausführungs-Pipelines bieten heute keine unmittelbaren Vorteile mehr. Sie waren in der Vergangenheit notwendig, als wir ein Data Warehouse als Datenspeicher verwendeten und gespeicherte Prozeduren für interne Datenübertragungen nutzten. Heute sind sie ein Überbleibsel der vorherigen Architektur und können nach entsprechender Diskussion schrittweise abgeschafft werden.
65
66 === Dataflows ===
67
68 Wenn die Quelle eine Flat-Datei aus SharePoint ist, werden Datenflüsse als Tool für die Datenaufnahme verwendet. Gen2-Datenflüsse bieten das gleiche UI-Erlebnis wie Power Query in einem Power BI-Datenfluss, in Power BI Desktop und in Excel. Als Low-Code-Lösung haben sie Vorteile.
69
70 {{warning}}
71 Datenflüsse sind aus Sicht der **Compute Unit (CU)-Nutzung ineffizient** und verbrauchen erhebliche Ressourcen, selbst bei Dateien von wenigen hundert Megabyte. Daher raten wir von der Verwendung von Datenflüssen im Fabric-Prozessfluss aktiv ab.
72 {{/warning}}
73
74 Im Zuge dieses neuen Ansatzes wurden einige Datenflüsse, die zuvor für interne Datenübertragungen genutzt wurden, durch Notebooks ersetzt. Zudem erfolgt die Ingestion der Telefonica-Excel-Datei nun ausschließlich mit Notebooks unter Nutzung der Shortcut-Funktion von ADLS. Derzeit aktive Datenflüsse werden für die Aufnahme von Kelog-SharePoint-Dateien und H3A-SharePoint-Dateien genutzt.
75
76 === Notebooks ===
77
78 Notebooks in Fabric funktionieren ähnlich wie Jupyter-Notebooks in der Cloud. Sie unterstützen Sprachen wie **Python, SQL und Scala** — Benutzer können Code schreiben, ausführen und ihre Arbeit dokumentieren. Notebooks sind äußerst effizient im CU-Verbrauch. Durch die Nutzung von Python-Bibliotheken wie **Polars** und **PySpark** konnten wir die Verarbeitung großer Tabellen auf weniger als eine Minute reduzieren.
79
80 Notebooks sind daher unser primäres Datentransformations-Tool in Fabric, wo immer möglich. SQL-gespeicherte Prozeduren, die zuvor Teil des Data Warehouses in Fabric waren, wurden durch PySpark oder SparkSQL ersetzt und mit Notebooks ausgeführt. Notebooks können eigenständig oder über eine Ausführungs-Pipeline geplant werden.
81
82 ==== Spark-Notebooks ====
83
84 Diese verwenden die **Apache Spark-Computing-Engine**, die ideal für großskalige Datenverarbeitung und Analysen ist. PySpark und Spark SQL benötigen diesen Typ von Notebook für ihre Funktion. Spark-Notebooks können auch für Aufgaben genutzt werden, die benutzerdefinierte Python-Bibliotheken erfordern. Eine benutzerdefinierte Umgebung kann erstellt werden, in der alle zusätzlichen Bibliotheken installiert werden, um sie dann im Notebook zu verwenden.
85
86 ==== Python-Notebooks ====
87
88 Diese nutzen die **vCore-Verarbeitung** von Microsoft und bieten eine vielseitige und interaktive Umgebung für Verarbeitung und Visualisierung. Die Spark-Engine benötigt in der Regel mehr CU und mehr Zeit für die Initialisierung. Daher verwenden wir, wenn die Aufgabe nicht die Spark-Engine erfordert, reine Python-Notebooks (auch **Vanilla-Notebooks** genannt) für die Verarbeitung.
89
90 Ein wesentlicher Nachteil dieses Notebook-Typs ist, dass keine benutzerdefinierte Umgebung genutzt werden kann. Zusätzliche Bibliotheken, die nicht von Microsoft bereitgestellt werden, müssen bei jedem Lauf installiert werden (mittels ##pip install##). Nichtsdestotrotz setzen wir ein Vanilla-Notebook für die Umwandlung von Excel-Dateien in Delta-Tabellen ein.
91
92 == BronzeStore ==
93
94 **Zweck:** dient als Zwischenspeicher, in dem Daten aus der Ingestion ohne Transformation gespeichert werden.
95
96 BronzeStore ist der generische Name für alle Elemente, die als Zwischenablage für Daten verwendet werden. Er umfasst Lakehouses, semantische Modelle und SQL-Endpunkte, die mit dem Lakehouse verbunden sind. Im Rahmen unserer ursprünglichen Architektur haben wir für jedes Quellsystem ein eigenes Lakehouse entwickelt. Daher gibt es individuelle Lakehouses für **Rimo, BMD, Board, H3A, Telefonica-Dateien und Kelog-Dateien**. Dies war damals erforderlich, da die Schemata von Lakehouses nicht nativ unterstützt wurden — was inzwischen nicht mehr der Fall ist.
97
98 Da es sich um einen Zwischenspeicher handelt, versuchen wir, die Daten aus dem Quellsystem so genau wie möglich abzubilden. Es werden keine Transformationen durchgeführt, außer Konvertierungen von Datentypen. In einigen Fällen mussten Spalten umbenannt werden, um nicht unterstützte Zeichen aus den Spaltennamen zu entfernen.
99
100 //Übersicht über BronzeStore mit den Lakehouses pro Quellsystem.//
101
102 == Bronze to Silver ==
103
104 **Zweck:** nutzt Notebooks und Datenflüsse, um Daten von BronzeStore zu SilverStore zu transformieren, wobei Shortcuts für mehr Effizienz verwendet werden.
105
106 Gemäß der definierten Architektur ist der Übergang der Daten von Bronze zu Silber **nicht zwingend erforderlich**. Solange keine Transformation der Daten notwendig ist, werden sie nicht in die Silber-Schicht verschoben. Falls eine Transformation erforderlich ist, besteht der erste Schritt darin, einen Shortcut von der Bronze-Schicht zum entsprechenden Schema im Silver-Lakehouse zu erstellen.
107
108 Die Elemente unter der Bronze-zu-Silber-Aufgabe führen die erste Stufe der Datentransformation durch. Zu den verwendeten Elementen gehören Datenpipelines, Datenflüsse, Notebooks und gespeicherte Prozeduren.
109
110 Mit der jüngsten Änderung der Architektur sind Datenflüsse, Datenpipelines und gespeicherte Prozeduren nicht mehr in Betrieb. Alle zuvor verwendeten gespeicherten Prozeduren wurden in **PySpark und Spark SQL** überführt und werden nun als Notebooks genutzt. Historisierungen, die zuvor über Datenpipelines durchgeführt wurden, sind nicht mehr im Einsatz und werden jetzt durch Notebooks ersetzt, die eine bessere CU-Nutzung und Leistung bieten.
111
112 //Aufgabenfluss von Bronze zu Silver.//
113
114 == SilverStore ==
115
116 **Zweck:** enthält Lakehouses, die transformierte Daten speichern, organisiert in Schemata, die den Quellsystemen entsprechen.
117
118 SilverStore ist die Ebene, in der transformierte Daten gespeichert werden. Diese Daten werden entweder weiterverarbeitet oder als Quelle für weitere Transformationen genutzt. Die Ergebnisse der Bronze-zu-Silber-Aufgabe werden hier abgelegt.
119
120 Historisch wurden Datenflüsse, gespeicherte Prozeduren und Pipelines verwendet, um Daten von BronzeStore zu SilverStore zu bewegen. Im Einklang mit der neu definierten Architektur minimieren wir nun die Datenbewegung und -duplikation, indem wir nach Möglichkeit Shortcuts nutzen, um Daten aus BronzeStore zu verknüpfen.
121
122 **Lakehouses in SilverStore:**
123
124 * **sharepointfiles_silver_lh** — enthält Tabellen, die aus Flat-Dateien stammen, die in SharePoint und ADLS gespeichert sind. Dieses Lakehouse wurde vor der Einführung von Schemata in Lakehouses erstellt und enthält ein einziges Standardschema ##dbo##. Da es inzwischen überflüssig ist, kann es nach weiterer Diskussion entfernt werden.
125 * **spl_silver_lh** — beinhaltet Tabellen aus On-Premise-Servern und Flat-Datei-Quellen mit separaten Schemata für jedes System.
126
127 Nicht jede Tabelle wird hierher kopiert, es sei denn, sie muss transformiert oder anders gespeichert werden als in ihrer ursprünglichen Form. In solchen Fällen kommt die Bronze-zu-Silber-Aufgabe zum Einsatz. Tabellen, die nach der Transformation erstellt werden, sind normalerweise entweder direkt für die Nutzung bereit oder werden für die nächste Stufe der Transformation verwendet.
128
129 Allgemein gesprochen werden Tabellen aus SilverStore nicht direkt in benutzerorientierten Anwendungen oder Berichten verwendet. Früher, als das Data Warehouse die primäre Single Source of Truth war, wurden Ansichten basierend auf den Tabellen aus SilverStore erstellt.
130
131 //Übersicht über SilverStore.//
132
133 == GoldStore ==
134
135 **Zweck:** enthält ein einziges Lakehouse (##spl_gold_lh##), in dem die endgültigen, konsumierbaren Daten aus allen Lakehouses zur Verteilung und Nutzung in Power-BI-Berichten gespeichert werden.
136
137 ##spl_gold_lh## ist als **Single Source of Truth** im Datenregime von SPL konzipiert. Die hier gehosteten Daten gelten als reinste Form, bereit für die Nutzung in Anwendungen und Berichten. Abhängig vom Quelltyp werden die Daten im Lakehouse in verschiedene Schemata unterteilt.
138
139 Derzeit wird das Lakehouse nicht mit Nutzern außerhalb der Power-BI-Admin-Gruppe geteilt. Die Daten aus diesem Lakehouse sind über SQL-Endpunkt-basierte Datenflüsse in Power BI verfügbar. In einigen Fällen werden Berichte direkt auf den Delta-Tabellen aufgebaut — sowohl im **Direct-Lake-Modus** als auch im **Import-Modus** über SQL-Endpunkte.
140
141 {{warning}}
142 **Bekannte Einschränkung — SQL-Endpunkt-Verzögerung:** Es gibt eine Verzögerung von typischerweise bis zu 15 Minuten zwischen den Daten im Delta Lake und der Verfügbarkeit am SQL-Endpunkt. Daher sollte der Aktualisierungsplan immer mindestens 15 Minuten nach der Datenaufnahme in ##spl_gold_lh## liegen.
143 {{/warning}}
144
145 == Visualisierung ==
146
147 **Zweck:** stellt Daten aus Fabric-Elementen für Power BI und Drittanbieter-Anwendungen bereit.
148
149 //Visualisierungs-Aufgabenflow: Daten aus Fabric zu Power BI und Drittanbieter-Tools.//
150
151 === Direct Lake ===
152
153 **Was es ist:** Der Direct-Lake-Modus ermöglicht Power BI, direkt auf Daten aus einem Fabric-Lakehouse zuzugreifen und Abfragen auszuführen, **ohne die Daten in Power BI zu importieren**. Dieser Modus nutzt die Leistung der In-Memory-Datenverarbeitung.
154
155 **Wie es sich unterscheidet:** Im Gegensatz zu anderen Methoden verbleiben die Daten im Lakehouse und werden in Echtzeit direkt abgefragt. So sind stets aktuelle Ergebnisse ohne Import oder periodische Aktualisierungen verfügbar.
156
157 **Berechtigungen:** Benutzer benötigen Lesezugriff auf das Fabric-Lakehouse, um die Daten in Berichten anzeigen zu können.
158
159 === DirectQuery ===
160
161 **Was es ist:** Der DirectQuery-Modus ermöglicht Power BI, Daten direkt aus der zugrunde liegenden Datenquelle abzufragen — jedes Mal, wenn ein Bericht geladen oder mit ihm interagiert wird. Dies gewährleistet, dass die Daten stets aktuell sind.
162
163 **Wie es sich unterscheidet:** DirectQuery vermeidet ebenfalls den Datenimport, nutzt jedoch keine In-Memory-Verarbeitung. Stattdessen werden Daten auf Abruf abgefragt — das sichert Echtzeit-Updates, kann jedoch die Leistung beeinträchtigen.
164
165 **Berechtigungen:** Benutzer benötigen Lesezugriff auf den SQL-Endpunkt, um die Daten abzufragen und anzuzeigen.
166
167 === Importmodus mit SQL-Endpunkt ===
168
169 **Was es ist:** Im Importmodus importiert Power BI Daten aus dem Fabric-Lakehouse in sein eigenes Datenmodell. Diese Daten können dann innerhalb von Power BI abgefragt und verarbeitet werden. Der SQL-Endpunkt wird genutzt, um die Daten in Power BI zu laden.
170
171 **Wie es sich unterscheidet:** Im Gegensatz zu den beiden anderen Methoden werden die Daten in den Power-BI-Speicher übernommen. Dies verbessert die Abfrageleistung (Daten sind lokal), erfordert jedoch regelmäßige Aktualisierungen, um die Daten aktuell zu halten.
172
173 **Berechtigungen:**
174
175 * Benutzer benötigen Lesezugriff auf den SQL-Endpunkt, um Daten in Power BI Desktop zu importieren.
176 * Für veröffentlichte Berichte kann jeder Benutzer mit mindestens einer Viewer-Rolle den Bericht anzeigen, ohne expliziten Zugriff auf den SQL-Endpunkt zu benötigen.
177
178 {{info}}
179 Um die Nutzung von Compute Units (CU) zu begrenzen, verwenden wir derzeit den **Importmodus mit SQL-Endpunkt als bevorzugte Methode** zur Berichterstellung. Eine begrenzte Anzahl semantischer Modelle wird ebenfalls mit Direct Lake erstellt — diese sind jedoch hauptsächlich für Berichte vorgesehen, die nicht für eine breitere Verteilung bestimmt sind.
180 {{/info}}
181
182 == Optimize ==
183
184 **Zweck:** Optimierung und Bereinigung der Lakehouse-Tabellen in den Bronze-, Silber- und Gold-Schichten.
185
186 Da die Daten im Lakehouse im **Delta-Format** gespeichert werden, wird bei jeder Datenaufnahme eine neue Parquet-Datei im Lakehouse-Ordner erstellt. Im Laufe der Zeit kann die Größe dieser Dateien erheblich zunehmen, was zu höheren Speicherkosten führt.
187
188 Microsoft bietet eine Option zur Bereinigung redundanter Dateien mithilfe der **Maintenance-Funktion**. Durch die Verwendung der ##VACUUM##-Option werden alle nicht verwendeten Dateien, die über einen bestimmten Zeitraum hinausgehen, aus dem Speicher entfernt.
189
190 Weitere Details dazu sind im Abschnitt „Good to know" zu finden.
191
192 **Optimize** hat keine festgelegte Position im Aufgabenfluss. Diese Schicht umfasst ausschließlich Notebooks.
193
194 == Ordnerstruktur ==
195
196 Alle in Fabric erstellten Elemente werden in verschiedene Ordner zusammengefasst, wobei jeder Ordner eine spezifische Funktion hat. Unter jedem übergeordneten Ordner können sich Unterordner befinden. Nachfolgend sind die übergeordneten Ordner im Arbeitsbereich (Stand März 2025) aufgeführt:
197
198 * **00_Execution** — alle Ausführungs-Pipelines
199 * **01_Dataingestion** — alle Datenflüsse und Ingestion-Pipelines
200 * **02_Bronze** — alle Bronze-Layer-Elemente
201 * **03_Silver** — alle Silver-Layer-Elemente
202 * **04_Gold** — alle Gold-Layer-Elemente
203 * **05_StoredProcedure_notebooks** — alle Spark- und Python-Notebooks für interne Datenübertragungen zwischen Ebenen sowie für die Optimierungsschicht
204 * **06_PowerBI Report notebooks** — alle Python- und Spark-Notebooks, die speziell für die Erstellung von Tabellen für Power-BI-Berichte verwendet werden
205 * **07_Power BI Reports und semantische Modelle** — benutzerdefinierte semantische Modelle und paginierte Berichte, die aus Lakehouse-Daten (##spl_gold_lh##) erstellt wurden
206 * **archived_items** — alle Elemente, die nicht mehr in Betrieb sind, werden hier zu Referenzzwecken gespeichert
207
208 ----
209
210 == Verwandte Themen ==
211
212 {{include reference="IT-Wiki.Makros.Verwandte-Themen.WebHome"/}}
213
214 ----
215 **Status:** Migriert — Team-Review ausstehend · **Owner:** //(festlegen)// · **Letzter Review:** 2026-06-11