Daten in Microsoft Fabric validieren

Ein praxisnaher Leitfaden zur Datenqualität in Microsoft Fabric — Warehouse und SQL-Analyseendpunkt des Lakehouse, das T-SQL für die sechs wesentlichen Prüfungen, die Falle der Metadatensynchronisation und wie Sie alles als versionierten Data Contract betreiben.

2026-08-30 · 8 min read

Um Daten in Microsoft Fabric zu validieren, verbinden Sie sich über das Standard-T-SQL-Protokoll mit dem Warehouse oder dem SQL-Analyseendpunkt des Lakehouse, formulieren jede Erwartung als Aggregatabfrage, die eine Anzahl von Verstößen zurückgibt, und führen den Stapel nach jeder Pipeline aus. Die sechs Prüfungen, auf die es ankommt, sind überall dieselben — Nullwerte, doppelte Schlüssel, unerlaubte Werte, Zahlen außerhalb des Bereichs, fehlerhaft formatierte Zeichenketten, veraltete Zeilen —, aber Fabric bringt zwei Fehlerbilder mit, die die Prüfungen berücksichtigen müssen: Die Metadaten des SQL-Endpunkts können hinter dem zurückbleiben, was OneLake tatsächlich enthält, und die T-SQL-Oberfläche ist bewusst schmaler als die von SQL Server.

Womit Sie sich eigentlich verbinden

Fabric stellt drei SQL-sprechende Dinge bereit, und die Unterschiede sind für die Validierung relevant:

• Warehouse — lesend und schreibend per T-SQL auf Delta-Tabellen in OneLake. Volle DML.
• SQL-Analyseendpunkt des Lakehouse — eine schreibgeschützte T-SQL-Sicht auf die Delta-Tabellen des Lakehouse, automatisch synchron gehalten.
• Gespiegelte Datenbanken — replizierte Quellen, bereitgestellt über denselben schreibgeschützten Endpunkt.

Alle drei sprechen das TDS-Protokoll, jeder SQL-Server-Client kann sich also verbinden. Alle drei sind aus Sicht eines Validierungstools schreibgeschützt oder überwiegend lesend — genau das, was man will. Catalyst behandelt Fabric als eigenen Verbindungstyp, statt den von SQL Server wiederzuverwenden, weil sich Authentifizierungsmodell und Dialektgrenzen unterscheiden. Wenn Sie bei null anfangen: Der vollständige Leitfaden zur Datenvalidierung behandelt, was auf jeder Engine gleich ist; dieser Leitfaden behandelt, was Fabric anders macht.

Die Falle der Metadatensynchronisation

Das ist die Fabric-Besonderheit, die man verstehen muss. Wenn ein Spark-Job oder eine Pipeline eine Delta-Tabelle in ein Lakehouse schreibt, erkennt der SQL-Analyseendpunkt die Änderung asynchron. Für ein kurzes Zeitfenster kann der Endpunkt den vorherigen Zustand der Tabelle melden — alte Zeilenzahlen, gelegentlich sogar eine Tabelle, die es noch gar nicht gibt.

Die Folge für die Validierung: Eine Prüfung, die unmittelbar am Ende eines Notebooks anläuft, kann Metadaten von vor dem Schreibvorgang lesen und fälschlich bestehen — was schlimmer ist als ein Fehlalarm. Zwei Gegenmaßnahmen:

1. Stoßen Sie die Validierung aus der Abschlussaktivität der Pipeline an, mit einer kurzen Verzögerung, statt aus dem Notebook selbst.
2. Nehmen Sie neben jeder metadatenbasierten Regel eine Aktualitätsregel auf Zeilenebene auf, sodass ein hinterherhinkender Endpunkt als Aktualitätsfehler sichtbar wird statt als Schweigen.

Die sechs Prüfungen, die jede Tabelle braucht

Das T-SQL von Fabric hat dieselben grundlegenden Grenzen wie SQL Server — kein Operator für reguläre Ausdrücke, TOP n statt LIMIT n, Quoting mit eckigen Klammern — plus ein paar eigene: kein MERGE auf dem Leseendpunkt und ein schmalerer Satz eingebauter Funktionen als bei einer vollwertigen SQL-Server-Instanz.

1. Vollständigkeit — Nullwerte in Pflichtspalten

SELECT COUNT_BIG(*) AS violations
FROM [dbo].[orders]
WHERE [order_id] IS NULL;

COUNT_BIG statt COUNT: Fabric-Warehouses halten Faktentabellen locker jenseits der int-Grenze von 2,1 Milliarden Zeilen.

2. Eindeutigkeit — doppelte Geschäftsschlüssel

SELECT COUNT_BIG(*) AS violations
FROM (
    SELECT [order_id]
    FROM [dbo].[orders]
    WHERE [order_id] IS NOT NULL
    GROUP BY [order_id]
    HAVING COUNT(*) > 1
) AS dupes;

Fabric Warehouse unterstützt PRIMARY KEY- und UNIQUE-Constraints nur als NOT ENFORCED-Metadaten für den Optimizer. Sie weisen keine Duplikate ab. Läuft eine Pipeline für eine Partition erneut, landen die Duplikate, der Constraint behauptet weiterhin Eindeutigkeit, und der Optimizer kann sogar falsche Ergebnisse liefern, weil er ihm vertraut. Eindeutigkeit explizit zu validieren ist hier keine Redundanz — es ist die einzige Durchsetzung, die es gibt.

3. Konformität — Werte außerhalb einer erlaubten Menge

SELECT COUNT_BIG(*) AS violations
FROM [dbo].[orders]
WHERE [status] IS NOT NULL
  AND [status] NOT IN ('pending', 'paid', 'shipped', 'refunded');

Behalten Sie die Null-Absicherung: NULL NOT IN (...) ergibt UNKNOWN, und die Zeile verschwindet aus der Zählung.

4. Genauigkeit — Zahlen außerhalb eines plausiblen Bereichs

SELECT COUNT_BIG(*) AS violations
FROM [dbo].[orders]
WHERE [total_amount] IS NOT NULL
  AND ([total_amount] < 0 OR [total_amount] > 100000);

Delta speichert Dezimalzahlen originalgetreu, nutzen Sie für Geldbeträge also decimal statt float. Achten Sie auf Schema-Drift auf der Spark-Seite: Ein Notebook, das eine Spalte heute als double und morgen als decimal schreibt, ändert den Spaltentyp am SQL-Endpunkt — und eine Bereichsprüfung, die zuvor sauber verglich, vergleicht plötzlich mit Rundungsfehlern.

5. Konformität — fehlerhaft formatierte Identifier

Es gibt keine Regex. Wie bei SQL Server lassen sich verankerte Muster mit fester Form in LIKE mit Zeichenklassen übersetzen:

-- ^ORD-[0-9]{6}$  becomes:
SELECT COUNT_BIG(*) AS violations
FROM [dbo].[orders]
WHERE [reference] IS NOT NULL
  AND [reference] NOT LIKE 'ORD-[0-9][0-9][0-9][0-9][0-9][0-9]';

Alles, was Alternativen, optionale Gruppen oder unbegrenzte Wiederholung enthält, lässt sich nicht ausdrücken. Catalyst übersetzt eine regex-Regel nach LIKE, wenn das Muster es zulässt, und meldet andernfalls einen ausdrücklichen Fehler wegen nicht unterstützten Dialekts — die Prüfung taucht also als Fehler auf, statt stillschweigend zu bestehen. Für wirklich komplexe Muster führen Sie die Validierung im Spark-Notebook durch, das die Tabelle schreibt, wo Sie eine echte Regex-Engine haben, und behalten eine grobe LIKE- oder validValues-Regel auf der SQL-Schicht als Absicherung.

6. Aktualität — Freshness

SELECT COUNT_BIG(*) AS violations
FROM [dbo].[orders]
WHERE [created_at] < DATEADD(HOUR, -24, SYSUTCDATETIME());

SYSUTCDATETIME() statt GETDATE(), damit die Prüfung nicht mit der Region der Kapazität oder mit der Sommerzeit verrutscht.

Zugriff und Authentifizierung

Fabric authentifiziert über Microsoft Entra ID statt über SQL-Logins. Für einen automatisierten Validator nutzen Sie einen Service Principal:

1. Registrieren Sie eine App in Entra ID und erstellen Sie ein Client-Secret.
2. Fügen Sie den Service Principal dem Fabric-Workspace mit der Rolle Viewer hinzu — genug, um vom SQL-Endpunkt zu lesen, zu wenig, um irgendetwas zu ändern.
3. Vergeben Sie SELECT auf den konkreten Schemas, wenn Sie enger einschränken wollen als workspaceweites Lesen.
4. Stellen Sie sicher, dass die Mandanteneinstellung aktiviert ist, die Service Principals die Nutzung der Fabric-APIs erlaubt — sie ist in vielen Mandanten standardmäßig aus und die übliche Ursache eines sonst unerklärlichen Login-Fehlers.

Catalyst speichert das Client-Secret verschlüsselt und verbindet sich read-only; nur Metadaten und Prüfergebnisse verlassen den Workspace.

Auch über die Kapazität lohnt sich ein Gedanke. Validierungsabfragen verbrauchen Capacity Units aus demselben Pool wie alles andere im Workspace. Eine große Suite von Full Table Scans, die alle fünfzehn Minuten auf einer F2-Kapazität läuft, drosselt Ihre Berichte. Grenzen Sie Prüfungen auf Partitionen ein, wo es geht, und staffeln Sie die Zeitpläne.

Von Ad-hoc-SQL zum Data Contract

Die Erwartungen zu deklarieren macht sie nachvollziehbar und portabel über alle drei Fabric-Oberflächen hinweg. Catalyst nutzt den Open Data Contract Standard:

apiVersion: v3.0.0
kind: DataContract
info:
  title: orders
  version: 1.0.0
  owner: fabric-platform
schema:
  - name: orders
    physicalName: orders
    physicalType: table
    properties:
      - name: order_id
        logicalType: string
        required: true
        primaryKey: true
        quality:
          - rule: nullCount
            dimension: completeness
            severity: error
            mustBe: "0"
          - rule: duplicateCount
            dimension: uniqueness
            severity: error
            mustBe: "0"
      - name: status
        logicalType: string
        quality:
          - rule: validValues
            dimension: conformity
            severity: error
            mustBe: "['pending', 'paid', 'shipped', 'refunded']"
      - name: total_amount
        logicalType: number
        physicalType: decimal(12,2)
        quality:
          - rule: between
            dimension: accuracy
            severity: error
            mustBe: "[0, 100000]"
      - name: reference
        logicalType: string
        quality:
          - rule: regex
            dimension: conformity
            severity: warning
            mustBe: "'^ORD-[0-9]{6}
#39;"
      - name: created_at
        logicalType: timestamp
        quality:
          - rule: freshness
            dimension: timeliness
            severity: error
            mustBe: "<= 24h"
    quality:
      - rule: rowCount
        dimension: consistency
        severity: error
        mustBe: "> 0"

Die rowCount-Regel auf Tabellenebene verdient sich ihren Platz speziell in Fabric: Ein leeres Ergebnis nach einem Pipeline-Lauf ist das klassische Symptom eines Delta-Schreibvorgangs, der im falschen Pfad gelandet ist — und es ist die Prüfung, die am ehesten anschlägt, wenn SQL-Endpunkt und OneLake auseinanderlaufen.

Catalyst importiert die Spalten aus INFORMATION_SCHEMA.COLUMNS, kompiliert jede Regel zu Fabric-korrektem T-SQL und hält pro Prüfung pass, warn oder fail fest. Das YAML läuft verlustfrei durch den visuellen Builder, sodass der Contract in Ihrem Repository derjenige ist, der ausgeführt wird.

Fabric-Stolperfallen, die man kennen sollte

Zeitplanung und Alerting

Hängen Sie die Validierung an das Ende der Data-Factory-Pipeline, die die Tabelle erzeugt, mit einem kurzen Puffer, damit der SQL-Endpunkt nachziehen kann. Alarmieren Sie beim Übergang in den Fehlerzustand statt auf den Dauerzustand, und behalten Sie den Schweregrad error den Regeln vor, die einen nachgelagerten Power-BI-Refresh tatsächlich stoppen sollten — ein semantisches Modell, das auf einem fehlgeschlagenen Ladelauf neu aufgebaut wird, ist der Weg, auf dem schlechte Daten in ein Vorstandsdashboard gelangen.

Häufige Fragen

Kann ich SQL-Server-Tools nutzen, um Microsoft-Fabric-Daten zu validieren?

Überwiegend ja. Das Warehouse und der SQL-Analyseendpunkt von Fabric sprechen das TDS-Protokoll, SQL-Server-Clients und -Treiber verbinden sich also. Die Unterschiede liegen in der Authentifizierung (Entra ID statt SQL-Logins), in einer schmaleren T-SQL-Oberfläche am schreibgeschützten Endpunkt und in nicht durchgesetzten Constraints. Regeln, die für SQL Server geschrieben wurden, lassen sich in der Regel unverändert portieren.

Warum tauchen Duplikate auf, obwohl meine Fabric-Tabelle einen Primärschlüssel hat?

Weil Fabric-Constraints als NOT ENFORCED deklariert sind — sie informieren den Query-Optimizer, weisen aber keine Zeilen ab. Eine erneut laufende Pipeline schreibt doppelte Schlüssel ohne Weiteres. Validieren Sie Eindeutigkeit explizit mit einer duplicateCount-Regel; es ist die einzige vorhandene Durchsetzung.

Wie führe ich eine Regex-Prüfung in Fabric aus?

Auf der SQL-Schicht gar nicht — T-SQL hat keinen Regex-Operator. Verankerte Muster fester Länge lassen sich als LIKE mit Klassen im Stil von [0-9] umschreiben. Für alles Komplexere führen Sie die Musterprüfung im Spark-Notebook durch, das die Tabelle schreibt, und behalten eine grobe LIKE- oder validValues-Regel am SQL-Endpunkt als Absicherung.

Welche Berechtigungen braucht ein Service Principal für die Validierung?

Die Workspace-Rolle Viewer reicht normalerweise, um vom SQL-Analyseendpunkt zu lesen, dazu die Mandanteneinstellung, die Service Principals die Nutzung der Fabric-APIs erlaubt. Vergeben Sie SELECT auf konkreten Schemas, wenn Sie enger eingrenzen wollen. Schreibrechte sind nicht erforderlich — jede Prüfung ist ein aggregierendes SELECT.

Verbraucht die Validierung Fabric-Kapazität?

Ja. Die Abfragen laufen gegen die Capacity Units Ihrer Kapazität, im selben Pool wie Pipelines und Power-BI-Refreshes. Halten Sie Prüfungen spalten- und partitionsbezogen, wo es möglich ist, und staffeln Sie die Zeitpläne, damit ein Validierungsdurchlauf nicht mit dem morgendlichen Bericht-Refresh kollidiert.