Skip to Content

Microsoft-Fabric-Datenarchitektur im SPL

Version 1.1 by Dimitri Rupp on 2026/06/11 09:16
Warning
For security reasons, the document is displayed in restricted mode as it is not the current version. There may be differences and errors due to this.
Inhalt

🏗️ Microsoft Fabric Datenarchitektur im SPL

Überblick

Das Ziel dieses Dokuments ist es, eine kurze Einführung in die Fabric-Datenarchitektur im SPL zu geben.

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.

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.

Fabric im SPL

Datenfluss in Fabric — Übersicht der wichtigsten Komponenten und Daten-Pipelines im SPL.

Basierend auf den bewährten Richtlinien von Microsoft verwenden wir eine Medaillon-Architektur zur Datenorganisation. Sie besteht aus drei Ebenen mit zunehmender Datenqualität:

flowchart LR
    SRC[📂 Quellsysteme
Rimo · BMD · Board · H3A
SharePoint · ADLS] --> B[🥉 Bronze
Rohdaten]
    B -->|Bereinigung
Validierung
Harmonisierung| S[🥈 Silver
Validierte Daten]
    S -->|Anreicherung
Aggregation| G[🥇 Gold
Konsumierbare Daten]
    G --> PBI[📊 Power BI
Berichte und Dashboards]
    G --> EXT[🔗 Drittanbieter
Excel · Board · SSMS]

    style B fill:#cd7f32,color:#fff
    style S fill:#c0c0c0,color:#000
    style G fill:#ffd700,color:#000
  • Bronze-Schicht (Rohdaten): erfasst Rohdaten aus verschiedenen Quellen ohne Verarbeitung oder Transformation. Erste Ablagezone für alle Daten.
  • Silber-Schicht (validierte Daten): Daten aus der Bronze-Schicht werden bereinigt, validiert und harmonisiert. Bietet einen verfeinerten Datensatz mit detaillierten Informationen für Analysen.
  • Gold-Schicht (angereicherte Daten): enthält hochverarbeitete und angereicherte Daten, die bereit zur Nutzung sind.

Diese Architektur gewährleistet, dass die Datenqualität sich schrittweise verbessert, während die Daten jede Schicht durchlaufen — ideal für Datenbereitstellung und Berichterstellung.

Die Architektur von Fabric im SPL ist in sieben Schlüsselaufgaben organisiert. Eine ähnliche Aufgabenansicht findet sich auch im Fabric-Arbeitsbereich:

Aufgaben-Übersicht im Fabric-Arbeitsbereich.

Datenaufnahme

Zweck: verantwortlich für das Kopieren von Daten aus verschiedenen Quellen wie On-Premise-Systemen, SharePoint und ADLS.

Je nach Quelltyp variiert das Element, das für die Datenaufnahme verwendet wird. Zu den Elementen gehören Datenpipelines, Datenflüsse und Notebooks.

Datenaufnahme-Aufgabenflow im SPL Fabric.

Datenpipelines

Pipelines können basierend auf ihrem Verwendungszweck in zwei Kategorien eingeteilt werden — Ingestion-Pipelines und Ausführungs-Pipelines.

Ingestion-Pipelines

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.

Ausführungs-Pipelines

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.

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.

Dataflows

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.

Warning

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.

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.

Notebooks

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.

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.

Spark-Notebooks

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.

Python-Notebooks

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.

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.

BronzeStore

Zweck: dient als Zwischenspeicher, in dem Daten aus der Ingestion ohne Transformation gespeichert werden.

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.

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.

Übersicht über BronzeStore mit den Lakehouses pro Quellsystem.

Bronze to Silver

Zweck: nutzt Notebooks und Datenflüsse, um Daten von BronzeStore zu SilverStore zu transformieren, wobei Shortcuts für mehr Effizienz verwendet werden.

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.

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.

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.

Aufgabenfluss von Bronze zu Silver.

SilverStore

Zweck: enthält Lakehouses, die transformierte Daten speichern, organisiert in Schemata, die den Quellsystemen entsprechen.

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.

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.

Lakehouses in SilverStore:

  • 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.
  • spl_silver_lh — beinhaltet Tabellen aus On-Premise-Servern und Flat-Datei-Quellen mit separaten Schemata für jedes System.

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.

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.

Übersicht über SilverStore.

GoldStore

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.

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.

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.

Warning

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.

Visualisierung

Zweck: stellt Daten aus Fabric-Elementen für Power BI und Drittanbieter-Anwendungen bereit.

Visualisierungs-Aufgabenflow: Daten aus Fabric zu Power BI und Drittanbieter-Tools.

Direct Lake

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.

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.

Berechtigungen: Benutzer benötigen Lesezugriff auf das Fabric-Lakehouse, um die Daten in Berichten anzeigen zu können.

DirectQuery

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.

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.

Berechtigungen: Benutzer benötigen Lesezugriff auf den SQL-Endpunkt, um die Daten abzufragen und anzuzeigen.

Importmodus mit SQL-Endpunkt

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.

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.

Berechtigungen:

  • Benutzer benötigen Lesezugriff auf den SQL-Endpunkt, um Daten in Power BI Desktop zu importieren.
  • 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.
Information

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.

Optimize

Zweck: Optimierung und Bereinigung der Lakehouse-Tabellen in den Bronze-, Silber- und Gold-Schichten.

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.

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.

Weitere Details dazu sind im Abschnitt „Good to know" zu finden.

Optimize hat keine festgelegte Position im Aufgabenfluss. Diese Schicht umfasst ausschließlich Notebooks.

Ordnerstruktur

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:

  • 00_Execution — alle Ausführungs-Pipelines
  • 01_Dataingestion — alle Datenflüsse und Ingestion-Pipelines
  • 02_Bronze — alle Bronze-Layer-Elemente
  • 03_Silver — alle Silver-Layer-Elemente
  • 04_Gold — alle Gold-Layer-Elemente
  • 05_StoredProcedure_notebooks — alle Spark- und Python-Notebooks für interne Datenübertragungen zwischen Ebenen sowie für die Optimierungsschicht
  • 06_PowerBI Report notebooks — alle Python- und Spark-Notebooks, die speziell für die Erstellung von Tabellen für Power-BI-Berichte verwendet werden
  • 07_Power BI Reports und semantische Modelle — benutzerdefinierte semantische Modelle und paginierte Berichte, die aus Lakehouse-Daten (spl_gold_lh) erstellt wurden
  • archived_items — alle Elemente, die nicht mehr in Betrieb sind, werden hier zu Referenzzwecken gespeichert
Information

Migrations-Hinweis: Diese Seite wurde am 24.05.2026 aus dem SharePoint WikiPowerBI ins Lumi-XWiki-Staging migriert.

Original-Autor: Bukkerji Sreejith (Consulter, Erstellung 2025-05-06)
Original-Quelle: Microsoft Fabric Datenarchitektur im SPL (SharePoint)
Migration: Dimitri Rupp via ClaudeAI

Bemerkungen zur Migration:

  • 7 Bilder mit sprechenden Dateinamen übernommen (01-data-movement-in-fabric.png bis 07-visualisierung.png)
  • Sprach-Glättung: Pseudo-Listen mit Bindestrich-Sätzen in echte Bullet-Listen umgewandelt; inline-bold Stichworte als eigene H4-Subheadings (Spark-Notebooks, Python-Notebooks, Direct Lake, DirectQuery, Importmodus); CU-Warnung zu Datenflüssen und SQL-Endpunkt-Verzögerung als sichtbare Warning-Boxen
  • Mermaid-Diagramm Medallion-Architektur ergänzt am Anfang: visualisiert die Datenfluss-Hierarchie Bronze → Silver → Gold mit Quellsystemen und Verbrauchern
  • Inhaltliche Substanz unverändert; alle Schemata, Lakehouse-Namen und technischen Bezeichner 1:1 aus Original

Verwandte Themen

Failed to execute the [velocity] macro. Cause: [The execution of the [velocity] script macro is not allowed in [xwiki:IT-Wiki.Makros.Verwandte-Themen.WebHome]. Check the rights of its last author or the parameters if it's rendered from another script.]. Click on this message for details.

Status: Migriert — Team-Review ausstehend · Owner: (festlegen) · Letzter Review: 2026-06-11