top of page
Suche

Open Mirroring in Microsoft Fabric

Mirroring ist für mich eines der spannendsten Fabric-Features, weil es genau da ansetzt, wo Datenplattform-Projekte gerne unnötig kompliziert werden: Du willst Daten aus einer bestehenden Quelle in Fabric haben – möglichst aktuell, stabil und bitte ohne direkt die nächste ETL-/ELT-Großbaustelle aufzumachen.


Fabric bringt dafür verschiedene Mirrored Items mit. Das Grundprinzip: Du hast irgendwo schon eine Datenbank, und Fabric baut dir daraus ein Replikat im OneLake. Das ist super, wenn deine Quelle offiziell unterstützt ist und du schnell eine saubere Spiegelung brauchst.


Richtig interessant wird es aber in dem Moment, wo Fabric nicht mehr entscheidet, welche Quellen erlaubt sind. Genau da kommt Open Mirroring ins Spiel. In der Doku wirkt das erstmal wie ein Detail – in der Praxis steckt dahinter eine Idee, die dir eine ganze Kategorie Integrationsstress abnehmen kann, wenn du sie sauber einordnest.



Was Open Mirroring anders macht als normales Mirroring

Klassisches Mirroring hängt stark daran, ob Fabric deine Quelle direkt versteht (Connector, Support-Liste, etc.). Open Mirroring dreht das Prinzip um:

Fabric muss die Quelle nicht kennen – Fabric muss nur verstehen, was sich geändert hat.

Konkret: Du legst in Fabric eine Mirror Database an. Die Tabellen werden dann nicht über einen klassischen Connector befüllt, sondern über Datenpakete, die du (oder ein Datenprovider) Richtung OneLake anliefert. Fabric übernimmt dabei den Part, der sonst gerne bei dir landet: Änderungen erkennen, korrekt anwenden, Zielzustand nachziehen.


Die zentrale Voraussetzung ist dabei glasklar:Die Daten müssen nicht nur „als Daten“ kommen – sie müssen als Änderungsereignisse kommen. Fabric will wissen, ob ein Datensatz neu, geändert oder gelöscht werden soll. Wenn diese Info zuverlässig mitgeliefert wird, kann Fabric die Zieltabelle auf Stand halten – ohne dass du dir eine klassische ETL-Pipeline zusammenschraubst.

Der Kern ist also: Kein klassischer Pipeline-Lauf – solange die Quelle Changes liefern kann.


Der Row Marker: das Signal, das aus Daten „Events“ macht

Row Marker: Das ist im Grunde ein Marker pro Datensatz, der Fabric sagt, was passieren soll. Du lieferst also nicht nur „Kunde 4711“, sondern „Kunde 4711 + Aktion“.


Damit kann Fabric unterscheiden:

  • Insert: Datensatz einfügen

  • Update: Datensatz aktualisieren

  • Delete: Datensatz löschen

  • Upsert: einfügen, falls nicht vorhanden – sonst aktualisieren


Und genau diese Unterscheidung macht aus einem simplen Export einen kontinuierlichen Änderungsstrom. Bildlich gesprochen: Open Mirroring ist weniger „ich kopiere Tabellen“, sondern eher „ich spiele ein Change-Log nach“. Fabric ist der Empfänger, der Ereignisse annimmt und daraus den aktuellen Zustand rekonstruiert.


Warum das so spannend ist: Entkopplung von der Quelle

Der größte Charme von Open Mirroring ist die Unabhängigkeit: Es geht nicht mehr darum, ob dein Quellsystem in irgendeiner Liste steht. Es geht darum, ob du es hinbekommst, die Änderungen so zu liefern, dass Fabric sie verarbeiten kann.


Das öffnet Türen in typischen Realitätsszenarien:

  • Du hast ein Fachsystem, das fachlich kritisch ist, aber technisch „sperrig“ (alt, proprietär, schlecht integrierbar).

  • Du hast einen Export, aber nichts davon ist „Fabric-ready“.

  • Du hast keine Lust, erst einen Connector-Zoo oder ein ELT-Gerüst aufzubauen, nur um erstmal Daten in Fabric zu bekommen.


Mit Open Mirroring verschiebst du die Arbeit: Du musst Fabric nicht beibringen, wie man das System abfragt. Du musst nur eine Strecke bauen, die Changes inklusive Row Marker in OneLake anliefert.


Und ja – im Netz gibt’s schon kreative Beispiele bis hin zu Excel als Quelle. Ob das produktiv eine gute Idee ist, steht auf einem anderen Blatt. Aber es zeigt: Entscheidend ist nicht die Quelle. Entscheidend ist, ob du Änderungen sauber beschreiben kannst.


Doppelte Daten – aber nicht automatisch doppelte Schmerzen

Mirroring hat den offensichtlichen Haken: Daten liegen doppelt. Einmal im Quellsystem, einmal als Replikat in Fabric. Klingt erstmal nach doppelt bezahlen. Spannend ist aber, was Microsoft im Mirroring-Kontext (laut Transkript) als Gegenmodell positioniert:


  • Speicher-Entgegenkommen je nach Kapazität: Es wird erwähnt, dass abhängig von der Kapazitätsgröße Mirroring-Speicher „kostenlos“ enthalten sein kann – als Beispiel wird eine F64 genannt, bei der bis zu 64 TB für Mirroring möglich sein sollen. (Wichtig: Das ist genau der Punkt, den man für die eigene Planung sauber gegen die aktuellen Fabric-Infos spiegeln sollte.)

  • Compute-Kosten entstehen vor allem bei Nutzung: Die Replikation selbst wirkt im Demo-/Transcript-Kontext nicht wie extra Compute-Dauerfeuer. Teurer wird es, wenn du auf die Daten zugreifst: SQL, Power BI, Spark – also dann, wenn wirklich gearbeitet wird.


Unterm Strich ergibt sich eine Kostenlogik, die Open Mirroring attraktiver macht, als man beim Stichwort „doppelte Datenhaltung“ erstmal denkt: Du baust dir nicht zwingend ein extra ETL-System – du nutzt eine Plattformfunktion und zahlst den „echten“ Verbrauch primär beim Arbeiten mit den Daten.


Eine Demo, die das Prinzip greifbar macht

Im Video wird das Ganze bewusst simpel demonstriert: Eine lokale SQL-Datenbank ist die Quelle, ein kleines Sync-Tool liest aus und liefert Datenpakete nach Fabric. Der Ablauf ist fast unspektakulär – und genau das ist das Gute daran:


  1. In Fabric wird ein Workspace angelegt.

  2. Darin entsteht eine Mirror Database als Ziel.

  3. Auf der Quellseite läuft ein Sync-Tool, gesteuert über Konfiguration:

    • mehrere Tabellen sind konfiguriert, aber nur eine ist aktiv (im Beispiel „Sales 3“)

    • ein Intervall (z. B. 10 Sekunden Pause)

    • Paketlogik (im Beispiel 13 Zeilen pro Paket, absichtlich klein, damit man mehrere Dateien sieht)


Die Inkrementalität ist in der Demo ID-basiert – nicht Timestamp-basiert. Das ist ein wichtiger Punkt: Open Mirroring zwingt dich nicht in genau einen Mechanismus. Du musst nur zuverlässig erkennen können, was neu ist und was sich verändert hat, und das als Events liefern.

Während das Tool läuft, werden Paketdateien erzeugt, hochgeladen, gewartet. Fabric verarbeitet das, schreibt Metadaten (inkl. Metadata-JSON) und zieht die Infos in die Zieltabelle.

Und ja: Es ruckelt auch mal. Timeouts, Verzögerungen, dieses klassische „warum dauert das jetzt?“ – wirkt erstmal wie Reibung, ist aber eigentlich wertvoll, weil es die echten Themen zeigt, die du produktiv lösen willst: Retry-Logik, Monitoring, nachvollziehbare Zustände.


SQL-Select auf die replizierte Tabelle

Der Beweis ist nicht, dass irgendwo Dateien liegen. Der Beweis ist: Du machst ein SELECT und die Tabelle ist da. Genau das passiert in der Demo: Mirror Database öffnen, per SQL SELECT * FROM Sales 3 – und die Daten stehen in Fabric wie eine normale Tabelle. In der Demo sind es 30 Zeilen, verteilt über mehrere Pakete, am Ende vollständig repliziert.


Und ab hier wird’s praktisch: Du kannst sofort weiterarbeiten – Power BI, SQL, Modellierung, Spark, was auch immer zu deinem Fabric-Setup passt.


Wann Open Mirroring Sinn ergibt – und wann eher nicht

Open Mirroring ist kein Allheilmittel. Wenn du:

  • komplexe Transformationen brauchst,

  • Validierungen,

  • Business-Regeln,

  • Datenqualitätsschichten,

…dann wirst du weiterhin Pipelines, Notebooks, Dataflows & Co. einsetzen. Open Mirroring ersetzt keine Datenkuratierung.


Seine Stärke ist woanders:

  • Wenn du schnell ein Replikat brauchst, ohne gleich die komplette Datenbewegungsarchitektur zu bauen.

  • Wenn dir schlicht der Connector fehlt, du aber Änderungen aus der Quelle herausbekommst.

  • Wenn ein Provider dir Changes liefern kann und du in Fabric einfach zuverlässig „mitlesen“ willst.


Wenn du Änderungen zuverlässig liefern kannst (oder liefern lassen kannst), ist Open Mirroring ein extrem eleganter Einstieg: Daten in Fabric, als Tabellen, sofort nutzbar – und darauf kannst du sauber aufbauen.

Fazit: Mehr als noch ein Connector

Open Mirroring ist für mich vor allem ein Architekturbaustein. Nicht noch ein Feature, sondern eine andere Denkweise:


Fabric muss nicht die Quelle verstehen. Fabric muss nur die Änderungsereignisse verstehen.

Wenn du das einmal so siehst, wirst du bei vielen „geht nicht“-Quellen plötzlich denken: Vielleicht geht’s doch – wenn ich die Changes liefern kann.


Und wenn du beim Lesen direkt eine Quelle im Kopf hattest, bei der dir heute genau dieser Weg fehlt: Dann ist das ein ziemlich guter Hinweis, dass Open Mirroring für dich relevant ist.

Der nächste sinnvolle Schritt

Power BI entfaltet seinen Nutzen erst dann vollständig, wenn Dashboards sauber aufgebaut, Datenmodelle durchdacht und Kennzahlen klar definiert sind.Genau diese Grundlagen entscheiden darüber, ob Berichte genutzt oder ignoriert werden.


Wenn du Power BI strukturiert aufsetzen oder bestehende Lösungen verbessern willst, unterstützen wir dich mit:


So wird aus einem funktionierenden Bericht eine belastbare Analytics-Lösung.

bottom of page