Microsoft Fabric Real-Time Architektur: RTI, Mirroring & Shortcuts im Test

Es ist ein unbeschreibliches Gefühl, wenn man vor Publikum auf einen Knopf drückt und hofft, dass die gesamte Demo-Umgebung nicht ausgerechnet in diesem Moment beschließt, ein Nickerchen zu machen.

Diese Erfahrung durfte ich am 8. Mai 2026 während meines Vortrags bei New Stars of Data machen. Während der Live-Demo erschien irgendwann folgende Nachricht im Teams-Chat:

This is sorcery not fantasy 😄 What a great demo

— Feedback aus dem Publikum während des Vortrags

Genau dieses Gefühl wollte ich mit der Demo erzeugen.

Während der Vorbereitung des Vortrags stellte ich mir immer wieder die Frage: Was gilt in Microsoft Fabric eigentlich als „real-time” und wie unterscheidet sich das in der Praxis von Mirroring und Shortcuts?

Alle drei versprechen nahezu sofortigen Zugriff auf aktuelle Daten, aber die Erfahrung in der Praxis ist nicht ganz dieselbe. Anstatt mich auf Dokumentation und Annahmen zu verlassen, wollte ich die Unterschiede selbst messen.

Falls du wissen möchtest, wie der Bewerbungsprozess für NSOD ablief, habe ich darüber bereits in einem separaten Beitrag geschrieben: New Stars of Data: Der ehrliche Guide für angehende Data-Speaker

Hinweis: Da Microsoft die Bezeichnungen von Fabric-Komponenten in der deutschsprachigen Oberfläche bisher nicht konsequent übersetzt, verwende ich in diesem Artikel überwiegend die englischen Produkt- und Feature-Namen.

Aufbau einer Live-Demo: Ingestion & Performance in Microsoft Fabric

Anstatt die drei Ingestion-Pfade (RTI, Mirroring und Shortcuts) mit synthetischen Daten zu testen, habe ich das Publikum selbst als Datenquelle der Demo genutzt.

Jeder konnte direkt im Browser über die im Vortrag gezeigten Fragen abstimmen, ohne eine App zu installieren oder einen Account anzulegen. Die Klicks landeten in einem Azure-basierten Backend und wurden anschließend in eine Azure-SQL-Datenbank geschrieben. Jede Frage war einem bestimmten Fabric-Ingestion-Pfad zugeordnet, sodass wir die Latenz der jeweiligen Variante direkt erleben konnten.

Etwa die Hälfte der 23 Teilnehmenden hat während des Vortrags aktiv abgestimmt. Für ein Remote-Event um 10 Uhr morgens – wenn die Leute erfahrungsgemäß oft nur mit einem halben Ohr zuhören und parallel noch E-Mails checken – ist das meiner Meinung nach eine gute Quote.

Ich bin gespannt, ob sich das diesen Samstag beim Data Saturday Croatia vor Ort ändert.

Die Demo bestand aus zwei unterschiedlichen Abstimmungsmodi:

• Standard Voting: Eine Stimme pro Frage und Person. Doppelte Stimmen wurden durch einen Unique Constraint in der Datenbank verhindert. Alle sahen die aggregierten Ergebnisse in einem Donut-Chart.
• Latency Mode: Ein +1-Button konnte beliebig oft angeklickt werden. Im Dashboard wurden ausschließlich die eigenen Klicks angezeigt. Die Daten wurden dabei parallel auf zwei Wegen abgebildet: direkt aus Azure SQL über ein JavaScript-Visual und zusätzlich über einen eingebetteten Power-BI-Bericht in DirectQuery-Modus. Das zeitliche Delta zwischen diesen beiden Elementen machte die End-to-End-Latenz sichtbar. Zusätzlich habe ich den Eventstream, die KQL-Datenbank und ein RTI Dashboard live gezeigt, um zu veranschaulichen, was innerhalb von Fabric zwischen Klick und Visualisierung passiert.

Beim ersten Aufruf der Seite wurde ein zufälliger, fiktiver Popkultur-Name generiert, zum Beispiel „Iron Man #A3F2“. So blieb die Zuordnung über mehrere Fragen hinweg ohne Login erhalten. Das Schöne daran: Es wurden zu keinem Zeitpunkt personenbezogene Daten erfasst. Da der Anzeigename deterministisch über einen einfachen Hash aus einer im localStorage gespeicherten UUID berechnet wurde, erzeugte das System für dieselbe UUID auch immer exakt denselben fiktiven Namen.

Die End-to-End-Architektur: Von Azure SQL nach Microsoft Fabric

Jede Stimme durchlief unabhängig vom Fragetyp zunächst denselben ersten Schritt:

Browser → Azure Function → Azure SQL

Die SQL-Datenbank war die zentrale Datenquelle. Je nach Frage nahm die Stimme anschließend einen anderen Weg durch Fabric.

Der gemeinsame Ablauf sah folgendermaßen aus: Nach dem Aufruf der Abstimmungsseite – einer schlanken Single-Page-Anwendung aus purem HTML und JavaScript – wird die Stimme abgegeben. Mit dem Klick auf den Button landet die Anfrage in einer Azure Function auf Python-Basis, welche die Daten direkt in Azure SQL schreibt. Die Azure-SQL-Tabellen werden im Hintergrund laufend nach Fabric gespiegelt, sodass letztlich alle Daten auch in der gespiegelten Fabric-Kopie landen. Von dort stellt der Power-BI-Bericht die Ergebnisse aller drei Ingestion-Methoden über DirectQuery bereit.

Jeder Fabric-Ingestion-Pfad verhält sich dabei etwas anders:

1. RTI über Eventstream

Die Azure Function sendet die Stimme zusätzlich an einen benutzerdefinierten Eventstream-Endpunkt, der sie in eine Eventhouse-KQL-Datenbank weiterleitet. Dieser Pfad macht die Daten innerhalb von Millisekunden bis wenigen Sekunden nach dem Klick abfragbar.

2. Mirroring aus Azure SQL

Hier ging es komplett ohne zusätzlichen Backend-Code, da Fabric die Azure-SQL-Tabellen kontinuierlich im Hintergrund repliziert. Weil der Mirroring-Konnector in Power BI allerdings keinen DirectQuery-Modus unterstützt, habe ich den SQL Endpoint der gespiegelten Datenbank über dem SQL Server Konnector verwendet.

3. Shortcuts über ADLS Gen2

Die Azure Function schreibt jede Stimme direkt in eine Delta-Tabelle in Azure Data Lake Storage Gen2. Ein Fabric Shortcut macht diese Daten anschließend als Lakehouse-Tabelle verfügbar.

Technischer Stack und Fabric-Komponenten

Schauen wir uns an, wie die Daten vom ersten Klick bis zur finalen Visualisierung im Dashboard durch das System fließen.

• Azure Function, Python 3.13: Verarbeitet eingehende Browser-Anfragen und verteilt die Payload auf mehrere Ziele. Ursprünglich hatte ich das Ganze in Node.js gebaut, bin aber auf Python gewechselt, weil die native deltalake-Bibliothek das Schreiben von Delta-Tabellen deutlich einfacher machte.
• Azure SQL Datenbank: Dient als transaktionale Datenbank für die Abstimmungsanwendung und bildet die Referenz für den Latenzvergleich mit Fabric.
• ADLS Gen2-Container: Speichert die Delta-Parquet-Dateien für den externen Shortcut-Test.
• Eventstream, benutzerdefinierter Endpunkt: Nimmt die Abstimmungsdaten als kontinuierlichen Datenstrom entgegen. Für diese Demo verwendete ich eine Push-basierte REST-API, die einzelne Abstimmungs-Payloads direkt von der Azure Function entgegennahm.
• Eventhouse + KQL-Datenbank: Speichert und verarbeitet den Live-Klickstream der Abstimmungen. Das Eventhouse dient als übergeordneter Container für eine oder mehrere KQL-Datenbanken, während die KQL-Datenbank die Daten enthält und Ingestion sowie Abfragen übernimmt.
• Mirroring, Quelle Azure SQL: Repliziert die Azure-SQL-Datenbank kontinuierlich nach Fabric für analytische Workloads.
• Shortcuts: Virtuelle Verknüpfungen, mit denen Daten abgefragt werden können, ohne die zugrunde liegenden Dateien zu verschieben oder zu kopieren. In dieser Demo machten sie sowohl gespiegelte Daten als auch in ADLS gespeicherte Delta-Tabellen für das Reporting verfügbar.
• Power BI Embedded & RTI Dashboard: Die Reportoberflächen, die das Publikum während der Demo zu sehen bekam. Das RTI Dashboard zeigte den Streaming-Pfad, während der eingebettete Power-BI-Bericht alle Ingestion-Methoden und deren End-to-End-Latenz gegenüberstellte.

In einem späteren Beitrag werde ich zeigen, wie man eine vereinfachte Version dieses Systems selbst aufsetzen kann.

Fallstricke in Microsoft Fabric und Erkenntnisse aus der Praxis

Latenzvergleich: Real-Time Intelligence vs. Mirroring

RTI über Eventstream war erwartungsgemäß der schnellste Pfad. Stimmen erschienen innerhalb von Millisekunden bis wenigen Sekunden in der KQL-Datenbank. Das RTI Dashboard zeigte die Ergebnisse nahezu unmittelbar nach jedem Klick an, nachdem ich die automatische Seitenaktualisierung mit der Einstellung „Minimal time interval: Continuous“ aktiviert hatte. Ehrlich gesagt hatte ich erwartet, dass dies die Standard-Einstellung für RTI Dashboards ist.

Hinweis: Mit dem Fabric Update vom Juni 2026 wurde die klassische automatische Seitenaktualisierung durch den neuen Modus Live Refresh ersetzt. Anstatt Visualisierungen in festen Intervallen neu zu laden, werden sie nun nur noch aktualisiert, wenn neue Daten erkannt werden. Dadurch lassen sich unnötige Aktualisierungen und Capacity-Kosten reduzieren. Gleichzeitig wurde jedoch das minimale Aktualisierungsintervall auf 10 Sekunden erhöht.

Mirroring erreichte auf einem warmen System im Durchschnitt etwa 18 Sekunden End-to-End-Latenz. Das Verhalten war konsistent und schneller, als ich ursprünglich erwartet hatte. Die Einschränkung „auf einem warmen System“ ist dabei allerdings wichtig. Nach längeren Inaktivitätsphasen wurde Mirroring spürbar langsamer.

Fabric Mirroring nach Inaktivitätsphasen

In meiner Demo war Mirroring sehr vorhersehbar, solange die Replikation bereits aktiv war. Neue Stimmen erschienen in der Regel nach ungefähr 18 Sekunden. Knifflig wurde es allerdings beim ersten Klick nach einer längeren Pause. Wenn die Quelltabelle eine Weile im Leerlauf war, brauchte die erste Änderung spürbar länger, um sichtbar zu werden.

Die pragmatische Lösung war ein kurzes Warm-up vor dem Vortrag. Etwa eine Stunde vor Beginn und noch einmal wenige Minuten vor dem Live-Start habe ich jeden Fragetyp geöffnet, wieder geschlossen und einige Teststimmen abgegeben. Elegant ist das nicht, aber es funktioniert.

ADLS Gen2 Delta-Shortcuts und das Small-File-Anti-Pattern

Der Shortcut-Pfad basierte auf einer Delta-Tabelle in ADLS Gen2. Um zusätzliche Verzögerungen durch Batch-Verarbeitung zu vermeiden, schrieb die Azure Function jede Stimme direkt als einzelnen Delta-Eintrag. Das führte zwangsläufig zu vielen sehr kleinen Dateien.

Für eine Demo war das völlig ausreichend. In einer produktiven Umgebung würde man die Schreibvorgänge bündeln oder die Dateien regelmäßig per OPTIMIZE konsolidieren, um das klassische Small-File-Anti-Pattern zu vermeiden.

Interessanter als das Dateiformat selbst war jedoch das beobachtete Latenzverhalten. Auf einem warmen System wurden neue Daten meist innerhalb weniger Sekunden sichtbar. Nach längeren Inaktivitätsphasen konnte dieselbe Änderung allerdings mehrere Minuten benötigen, bevor sie über den Shortcut verfügbar war.

Zusammengefasst ergab sich für die drei Ingestion-Pfade folgendes Bild:

Metrik	RTI über Eventstream	Mirroring	ADLS Gen2-Shortcuts
Beobachtete Latenz	Millisekunden bis ~2 Sekunden	~18 Sekunden	Sekunden bis mehrere Minuten
Konsistenz	Sehr hoch	Hoch auf warmem System	Stark schwankend
Verhalten nach Inaktivität	Kaum Veränderung	Erste Änderung langsamer	Teilweise deutlich höhere Latenz
Demo-Fazit	Schnellster Pfad	Gute Balance aus Einfachheit und Geschwindigkeit	Einfach aufzusetzen, aber mit der größten Schwankungsbreite

Während Shortcuts innerhalb von Fabric in meinen Tests recht konsistent arbeiteten, verhielten sich die externen Shortcuts vom ADLS-Container nach Fabric deutlich weniger vorhersehbar. Die genaue Ursache konnte ich nicht eindeutig isolieren. Auch hier erwies sich ein kurzes Warm-up vor dem Vortrag als die pragmatischste Lösung.

DirectQuery vs. Direct Lake für Echtzeitberichte in Microsoft Fabric

Schnelle Ingestion ist nur ein Teil der Gleichung. Entscheidend ist letztlich, wann die Daten tatsächlich für die Benutzer sichtbar werden. Deshalb haben wir nicht nur die Ingestion-Latenz gemessen, sondern die gesamte End-to-End-Latenz vom Eingang der Stimme bis zur Anzeige im eingebetteten Power-BI-Bericht betrachtet.

DirectQuery vs. Direct Lake

Ich habe für den Bericht den DirectQuery-Modus gewählt. Der KQL-Connector in Power BI unterstützt DirectQuery und Import, bietet jedoch keinen nativen Direct-Lake-Modus.

Man könnte die Eventhouse-Tabellen über die OneLake-Verfügbarkeit bereitstellen und darauf ein Direct-Lake-Modell aufbauen. Damit würde jedoch nicht mehr direkt gegen die KQL-Datenbank abgefragt werden. Zusätzlich käme ein weiterer Materialisierungsschritt von Eventhouse nach OneLake hinzu.

Für die Live-Demo wollte ich den Datenpfad bewusst möglichst kurz halten und zusätzliche Schichten vermeiden, die die gemessene End-to-End-Latenz beeinflussen könnten.

Bei den gespiegelten Daten ergab sich eine ähnliche Herausforderung. Während der KQL-Connector DirectQuery und Import unterstützt, bietet der Mirroring-Connector nur die Wahl zwischen Import und Direct Lake.

Da ich sowohl den RTI- als auch den Mirroring-Pfad im selben Bericht gegenüberstellen wollte, habe ich die gespiegelte Datenbank stattdessen über ihren SQL Endpoint und den SQL-Server-Connector angebunden. Dadurch konnte ich auch für die gespiegelten Daten DirectQuery verwenden und beide Pfade unter denselben Bedingungen vergleichen.

Auto Page Refresh: Wenn der Bericht langsamer ist als die Daten

Schnelle Datenaktualisierung ist nur die halbe Miete. Der Bericht muss die Änderungen schließlich auch sichtbar machen. Dafür habe ich Auto Page Refresh (APR) mit einem festen Intervall von einer Sekunde verwendet.

Die Funktion aktualisiert die Visualisierungen automatisch, ohne dass der Benutzer den Bericht manuell neu laden muss. Es gibt zwei Auslösemodi:

• Festes Intervall: Aktualisiert alle N Sekunden oder Minuten, unabhängig davon, ob sich Daten geändert haben.
• Änderungserkennung: Fragt in einem definierten Intervall ein Measure ab und aktualisiert die Visualisierungen nur dann, wenn eine Änderung erkannt wird.

Beide Varianten benötigen dedizierte Kapazität. Auf Shared Capacity ist das minimale Abfrageintervall auf 30 Minuten begrenzt, wodurch APR für Echtzeit-Reporting praktisch unbrauchbar wird. Auf Premium- oder Fabric-F-SKUs kann das minimale Intervall auf Kapazitätsebene bis auf eine Sekunde reduziert werden.

Ich habe mich für ein festes Intervall statt Änderungserkennung entschieden, weil die Änderungserkennung in meinem Szenario längere und weniger vorhersehbare Verzögerungen verursachte.

Der größte Fallstrick: APR besitzt ein minimales Aktualisierungsintervall auf Kapazitätsebene. Liegt das im Bericht konfigurierte Intervall darunter, wird stattdessen der Kapazitätswert erzwungen.

Standardmäßig beträgt dieser Wert fünf Minuten. Ein Bericht, der auf eine Sekunde konfiguriert wurde, aktualisiert sich dann trotzdem nur alle fünf Minuten, ohne Fehlermeldung oder Warnung. Das tatsächlich erzwungene Intervall lässt sich im Bereich Seitenaktualisierung in der Weboberfläche einsehen, ist dort aber etwas versteckt:

Bei der Vorbereitung bin ich gleich doppelt in diese Falle gerauscht. Beim ersten Mal hat mich die Fehlersuche einen knappen Tag gekostet, weil ich von der Restriktion schlicht nichts wusste. Das zweite Mal erwischte mich, als ich mitten im Projekt die Kapazität gewechselt und glatt vergessen hatte, dass die Einstellung pro Kapazität und nicht global für den gesamten Mandanten gilt. Neue Kapazität bedeutete wieder Standardwerte. Eine gute Erinnerung daran, dass Standardkonfigurationen genau dann zuschlagen, wenn man sie am wenigsten erwartet.

Um die Einstellung zu ändern, benötigst du Capacity-Admin-Berechtigungen. In der Fabric-Oberfläche findest du sie unter:

Einstellungen → Verwaltungsportal → Kapazitätseinstellungen → Power BI Workloads → Mindestintervall für Aktualisierung

Eventstream Live Preview ist kein Live-Stream

Der Datenvorschau-Bereich am unteren Rand des Eventstream-Editors ist übrigens kein Live-Stream. Auch im Live-Modus sieht man dort keine laufend eintreffenden Ereignisse, sondern nur eine manuell aktualisierbare Vorschau der Daten.

Die Vorschau dient dazu, zu überprüfen, ob überhaupt Daten ankommen und in welchem Format sie vorliegen, sowie Schema- oder Verbindungsprobleme auszuschließen.

Microsoft Fabric RTI-Dashboards: Grenzen bei Publish to Web und Embedding

RTI-Dashboards eignen sich gut für internes Monitoring. Sobald jedoch externe Benutzer ins Spiel kommen, stößt man schnell an Grenzen. Weder Publish to Web noch die Einbettung in öffentliche Websites werden derzeit unterstützt.

Für meine Demo bedeutete das, dass die Teilnehmer die RTI-Dashboards nicht direkt sehen konnten. Die öffentliche Anzeige der Ergebnisse musste daher über einen eingebetteten Power-BI-Bericht erfolgen, während die RTI-Dashboards im Hintergrund als Referenz für die Latenzmessung dienten.

Wie geht’s weiter?

Die hier beschriebene Architektur war nur ein kleiner Teil des Projekts.

Eine vereinfachte Version des Demo-Setups sowie weitere Beiträge zu RTI, Mirroring und Shortcuts in Microsoft Fabric folgen in separaten Beiträgen.