Daten bewegen ohne Daten zu bewegen: Fabric Shortcuts verstehen
Wer in modernen Datenprojekten arbeitet, kennt das Muster: Daten aus Quellsystemen werden kopiert, weil man es schon immer so gemacht hat, weil die Pipeline es vorsieht, weil irgendwo ein Ticket stand. Selten weil es wirklich notwendig ist. Microsoft Fabric adressiert genau diesen Reflex mit einem Feature, das auf den ersten Blick unscheinbar wirkt: Shortcuts.
Daten als Kopie – ein teurer Gewohnheitsfehler
In vielen Unternehmen ist das Kopieren von Daten tief in Prozesse eingebettet – nicht weil es die beste Lösung ist, sondern weil es die gewohnte ist. Die eigentliche Frage, ob eine Datenbewegung überhaupt notwendig ist, wird dabei selten gestellt.
Warum der Reflex so hartnäckig ist
Datenpipelines werden einmal gebaut und selten hinterfragt. Was als pragmatische Lösung beginnt, wird zur Architekturentscheidung by Default – und mit der Zeit zur technischen Schuld. Shortcuts bieten die Möglichkeit, diesen Automatismus zu durchbrechen, ohne bestehende Systeme anfassen zu müssen.
Kein Import, kein Sync sondern ein Verweis
Ein Fabric Shortcut ist weder ein Daten-Import noch eine Synchronisation – sondern ein Verweis auf Daten, die außerhalb von OneLake liegen, ohne dass diese physisch bewegt werden. Was das konkret bedeutet und welche Quellen unterstützt werden, zeigt dieser Abschnitt.
So funktioniert ein Shortcut in der Praxis
Fabric kann diese Daten abfragen, in Pipelines verwenden und direkt in Power BI visualisieren, während die Quelldaten bleiben, wo sie sind.Unterstützte Quellen sind unter anderem:
- Azure Data Lake Storage Gen2 (ADLS)
- Amazon S3
- Google Cloud Storage
- Andere Fabric Workspaces
Die Integration ist dabei vollständig nativ: Fabric erkennt Shortcuts wie eigene Daten, der SQL Endpoint lässt sich direkt darauf abfragen und Power BI greift ohne Umwege darauf zu, ohne dass die Daten je OneLake berührt haben.Der entscheidende Gedanke dahinter ist simpel: OneLake muss keine Daten besitzen, um mit ihnen zu arbeiten.
string[] factTables = {
"FactTable_A",
"FactTable_B",
"FactTable_C",
"FactTable_D"
};
var dimTable = Model.Tables["DimFilterAttribute"];
var columnName = "FilterAttribute";
foreach (var tableName in factTables)
{
var factTable = Model.Tables[tableName];
var relationship = Model.AddRelationship();
relationship.FromColumn = factTable.Columns[columnName];
relationship.ToColumn = dimTable.Columns[columnName];
relationship.FromCardinality = RelationshipEndCardinality.Many;
relationship.ToCardinality = RelationshipEndCardinality.One;
relationship.CrossFilteringBehavior = CrossFilteringBehavior.OneDirection;
relationship.IsActive = true;
}Hier steht eine Caption für ein Code Snippet oder Screenshot
Dies ist ein Testalarm
Warum unnötige Datenbewegung teurer ist als sie aussieht
Datenbewegung ist in vielen Projekten ein Reflex und keine bewusste Entscheidung. Das erzeugt drei klassische Probleme, die sich mit der Zeit summieren.
Die drei häufigsten Folgeprobleme
Datenpipelines werden einmal gebaut und selten hinterfragt. Was als pragmatische Lösung beginnt, wird zur Architekturentscheidung by Default – und mit der Zeit zur technischen Schuld. Shortcuts bieten die Möglichkeit, diesen Automatismus zu durchbrechen, ohne bestehende Systeme anfassen zu müssen.
Redundanz
Dieselben Daten existieren mehrfach an verschiedenen Orten, in verschiedenen Zuständen, und niemand weiß mehr genau, welcher Stand der richtige ist.
Kosten
Speicher- und Transferkosten steigen kontinuierlich, oft ohne dass je jemand aktiv entschieden hat, dass das sinnvoll ist – Cloud-Anbieter berechnen für jeden Datentransfer zwischen Systemen oder Regionen Gebühren, die sich im Laufe der Zeit erheblich summieren können.
Governance-Lücken
Wer ist eigentlich für welche Kopie verantwortlich, wer pflegt sie, und wer bemerkt, wenn sie veraltet ist?
Shortcuts brechen diesen Kreislauf, indem sie statt einer Kopie zu machen einen Verweis setzen. Das Ergebnis aus Nutzersicht ist identisch, der Overhead deutlich geringer. Das Konzept dahinter ist aber nicht neu – Virtualisierung statt Replikation gibt es seit Jahrzehnten, etwa in Form von Datenbankviews oder virtuellen Dateisystemen.
Was Fabric Shortcuts davon unterscheidet, ist die Tiefe der Integration in die Plattform. Ein Shortcut verhält sich nach außen wie ein nativer Ordner in OneLake: Er taucht im Lakehouse auf, lässt sich über den SQL Endpoint abfragen, funktioniert als Datenquelle in Dataflows und Pipelines und ist für Power BI nicht von einer lokalen Tabelle zu unterscheiden. Diese Transparenz ist der eigentliche Fortschritt – nicht die Idee des Verweises selbst, sondern dass er sich nahtlos in eine vollständige Datenplattform einfügt, ohne dass der Nutzer merkt, wo die Daten tatsächlich liegen.
string[] factTables = {
"FactTable_A",
"FactTable_B",
"FactTable_C",
"FactTable_D"
};
var dimTable = Model.Tables["DimFilterAttribute"];
var columnName = "FilterAttribute";
foreach (var tableName in factTables)
{
var factTable = Model.Tables[tableName];
var relationship = Model.AddRelationship();
relationship.FromColumn = factTable.Columns[columnName];
relationship.ToColumn = dimTable.Columns[columnName];
relationship.FromCardinality = RelationshipEndCardinality.Many;
relationship.ToCardinality = RelationshipEndCardinality.One;
relationship.CrossFilteringBehavior = CrossFilteringBehavior.OneDirection;
relationship.IsActive = true;Hier steht eine Caption für ein Code Snippet oder Screenshot
Haavest ist Experte für Datenvisualisierung und individuelle Dashboard-Entwicklung.
Mehr über Datenvisualisierung erfahren
Wo Shortcuts in der Praxis ihren Platz haben
Shortcuts entfalten ihren Nutzen in sehr unterschiedlichen Szenarien – von der schrittweisen Migration bis hin zu Multi-Cloud-Architekturen.
Drei Szenarien, in denen Shortcuts ihren Wert beweisen
Kein Unternehmen migriert seine gesamte Datenlandschaft auf einmal zu Fabric, und genau da liegt der erste echte Anwendungsfall. Shortcuts erlauben es, bestehende ADLS-Container direkt in OneLake einzubinden und parallel zu betreiben, ohne Big Bang, ohne Datenverlust-Risiko durch einen überstürzten Umzug. Der Shortcut fungiert so lange als Brücke zwischen alter und neuer Welt, wie sie gebraucht wird.
Ein zweiter, häufig unterschätzter Fall ist die abteilungsübergreifende Datennutzung. Team A hat Daten in Workspace A aufbereitet, Team B braucht ebenfalls genau diese Daten. Ohne Shortcuts bedeutet das Export, Kopie und früher oder später ein Synchronisationsproblem. Mit Shortcuts setzt Team B aus seinem eigenen Workspace einfach einen Verweis auf Workspace A: die Daten bleiben unter der Kontrolle von Team A, sind aber für Team B direkt nutzbar. Single Source of Truth, ohne organisatorischen Aufwand. Das funktioniert auch workspace-übergreifend zwischen verschiedenen Domänen, solange beide Workspaces im selben Fabric-Tenant liegen. Domänen sind in Fabric ein Governance-Konstrukt zur logischen Gruppierung, aber keine technische Grenze für Shortcuts. Anders sieht es bei unterschiedlichen Tenants aus: Dort wird das aktuell nicht nativ unterstützt. Wer Daten tenant-übergreifend teilen muss, braucht einen gemeinsamen externen Storage wie ADLS Gen2 oder S3 als Zwischenschicht, auf den beide Seiten per Shortcut zugreifen.
Und schließlich Multi-Cloud-Szenarien, die in der Praxis häufiger vorkommen als man denkt. Die Daten liegen aus regulatorischen oder strategischen Gründen in AWS S3 oder Google Cloud Storage und sollen dort bleiben. Mit einem entsprechenden Shortcut kann Fabric diese Daten direkt abfragen, ohne Egress-Kosten durch Kopieren und ohne Datensouveränitätsprobleme zu verursachen.
Was im Lakehouse wie eine gewöhnliche Tabelle aussieht, kann tatsächlich auf eine externe Datenquelle in einer anderen Cloud zeigen. Wenn die Herkunft dieser Daten nicht sauber dokumentiert ist, wird das früher oder später zur Fehlerquelle. Tools wie Microsoft Purview können dabei helfen, die Übersicht zu behalten – ersetzen aber keine klare Dokumentationsstrategie.
