Mit Microsoft Fabric, einer All-in-One-Analyselösung als SaaS-Plattform, hat das integrierte Power BI ein ordentliches Update an Funktionalitäten zu der bisherigen Standalone-Version erhalten. Microsoft hat Fabric als Public Preview veröffentlicht, sodass u.a. Power BI Nutzer:innen bereits verschiedene neue Funktionalitäten erproben können. Das haben wir als Anlass genommen, einen genaueren Blick in die integrierte Power-BI-Lösung von MS Fabric zu werfen.
In diesem Blogpost möchten wir unsere gesammelten Erfahrungen mit Microsoft Fabric schildern. Zur Veranschaulichung nutzen wir die beispielhafte Migration einer Lösung, die auf Power BI Dataflows aufbaut. Insbesondere zielen wir darauf ab, die neuen Funktionalitäten in MS Fabric von Power BI Dataflows und Power BI im Allgemeinen zu untersuchen und positive Aspekte sowie Herausforderungen im Umgang mit der aktuellen MS Fabric-Version darzulegen.
Was ist Microsoft Fabric?
Microsoft hat im Mai 2023 eine neue All-in-One-Analyselösung namens Fabric als Public Preview veröffentlicht. Diese Lösung adressiert Probleme im gesamten Analytics Workflow, die insbesondere bei der Zusammenarbeit unterschiedlicher Teams und Expert:innen wie Data Engineers, Data Scientists, Data Analysts, BI-Entwickler:innen etc. auftreten. Es werden folgende Herausforderungen angegangen:
- Die Verwendung unterschiedlicher Tools (aus Power BI, Azure Synapse und Azure Data Factory) zur Bewältigung verschiedener Schritte des Analytics-Workflows führt zu einem hohen Integrationsaufwand. Ohne Integration können die Ergebnisse unterschiedlicher Teams nicht genutzt werden.
- Daten entstehen in sämtlichen Bereichen eines Unternehmens, sodass sie fragmentiert über verschiedene Quellsysteme und in ganz unterschiedlichen Formaten vorliegen. Das erschwert den Zugriff und auch die Übersichtlichkeit leidet darunter.
- Die Verwaltung von Berechtigungen zur Datensicherheit kann die Arbeit an einem Datenprojekt erheblich beeinträchtigen.
Fabric greift diese Probleme als einheitliche Software-as-a-Service-Plattform auf mit einer Kombination bewährter Microsoft Analytics-Tools bestehend aus Power BI, Azure Synapse und Azure Data Factory, sowie neuer Tools und stellt eine Self-Service Datenanalyse Software mit mehreren Komponenten bereit. Diese umfassen unter anderem das Data Warehouse, die Data Factory, Datentechnik, Data Science, Real-Time Analytics und Power BI, um maßgeschneiderte Tools für den nahtlosen Analytics Workflow zu bieten. Im Mittelpunkt von Fabric steht die Lake-zentrische Architektur mit dem sogenannten OneLake, durch den sowohl das „One Copy“-Prinzip als auch „One Security“ durchgesetzt werden. Die wesentlichen Vorteile der Zusammenarbeit ergeben sich damit in der Wiederverwendung von Arbeitsergebnissen verschiedener Teams und der transparenten und vereinfachten Verwaltung von Sicherheitsberechtigungen mit Zugriffskontrolle.
Power BI in Microsoft Fabric
Power BI gehört wohl zu einer der bekanntesten Business-Intelligence-Plattformen und hat sich erfolgreich bei vielen Unternehmen etabliert. Es bietet eine breite Palette an Funktionalitäten an, um Daten zu integrieren, zu analysieren und zu visualisieren. Oftmals unterstützen die aufbereiteten Daten in Dashboards und Reports den Prozess, geschäftsrelevante Entscheidungen zu treffen.
Power BI in MS Fabric unterstützt alle Power BI-Funktionalitäten und bietet darüber hinaus noch weitere Zusatzfunktionen an. Erfahrene Nutzer:innen von Power BI sind mit der Aufmachung der Projektumgebung von Microsoft Fabric sehr vertraut, da die SaaS-Basis von Microsoft Fabric der SaaS-Basis von Power BI entspricht. Konkreter heißt dies:
- Die Navigation im MS Fabric Portal ist analog zum Power BI Portal.
- Das Konzept der MS Fabric Workspaces ist ebenfalls mit den Workspaces von Power BI gleichzusetzen. Der Unterschied besteht darin, dass mehr „Items“ wie z. B. Apps, Lakehouses, Data Warehouses, Dataflows, Reports etc. verfügbar sind.
- Nutzer:innen von Power BI Premium wird ebenfalls das „Capacity Modell“ von MS Fabric sehr bekannt vorkommen. Eine Capacity besteht aus mehreren „Stock Keeping Units“ (kurz SKU), die unterschiedliche Rechenleistungen bereitstellen.
Zudem sind die folgenden Neuerungen zu betonen. Zum einen wird die einheitliche Nutzer:innenerfahrung durch Git-Integration für Power BI gestärkt, und der Zugriff auf Power BI ist nun unabhängig vom Betriebssystem durch Einführung der GUI innerhalb des Browsers möglich.
Viele der von uns betrachteten neuen Konzepte spielen sich innerhalb der Data Factory ab, welche die nächste Generation von Azure Data Factory innerhalb von MS Fabric ist. Mit dieser können Dataflows Gen2 für Power BI aufgesetzt werden, die den Power BI Dataflows Gen1 mit neuen Features entsprechen. Die Dokumentation erwähnt unter anderem Vereinfachungen des Aufsetzens eines Dataflow in Power Query, Leistungsverbesserung der Compute-Engine und automatische Entwurfsspeicherung des Bearbeitungsstands eines Dataflow in der Cloud. Die folgenden Punkte sind für uns relevant:
- Entwurf-Speicherung: Vorgenommene Änderungen eines Dataflow werden automatisch in der Cloud gespeichert. Erst nach Veröffentlichung eines Dataflow, werden diese Änderungen innerhalb der Aktualisierung des Dataflow übernommen und während der im Hintergrund ausgeführten Überprüfung auf Fehler gegengecheckt.
- Datenziele von Dataflows Gen2: ETL-Logik und Zielspeicher können nun dank internem Speicher, dem sogenannten Staging-Speicher und der Spezifikation von einer aus vier möglichen Datensenken getrennt werden, darunter das Fabric-Lakehouse oder das Warehouse.
- Pipelines: Die neue mögliche Integration mit Datenpipelines kann die Aneinanderreihung von Dataflows orchestrieren. Es ist auch möglich, innerhalb einer Pipeline ein Python-Notebook ausführen zu lassen.
- Power BI Datasets: Datasets, die als semantisches Datenmodell mit definierten Metriken, Measures und Beziehungen beschrieben werden, profitieren von dem „Direct Lake“. Damit soll schnelles Laden der Daten in die Power BI-Engine gewährleistet werden.
Muss denn nun eine komplette Migration von Power BI vorgenommen werden, wenn man auf MS Fabric umsteigen will? Laut Microsoft ist das nicht notwendig, die Migration erfolgt automatisch – allerdings nur in ihrer alten Funktionalität. Das heißt zwar, dass produktive Bestandteile einfach weiter genutzt werden können, um eine Fortsetzung der Arbeitsprozesse zu gewährleisten. Wer jedoch von den versprochenen innovativen Funktionalitäten profitieren will, muss eine händische Umstellung verschiedener Komponenten von Power BI vornehmen.
Untersuchung neuer Funktionalitäten von Power BI in Microsoft Fabric durch Migrations-POC
Microsoft Fabric verspricht neue Kompetenzen zu den bereits vorhandenen Funktionen von Power BI. Mithilfe eines Migrations-POC wollten wir untersuchen, inwieweit ein bestehendes Projekt in Power BI von den versprochenen Funktionalitäten profitiert, auf welche Hürden wir dabei stoßen werden, oder auch welche alternativen Lösungen angestrebt werden müssen, um den POC zu realisieren.
Der ausgewählte Migrations-POC basiert auf einer Datenaufbereitungsstrecke eines Forecast Reports, die in Power BI Desktop umgesetzt wurde. Ziel des POCs ist es, diese Datenaufbereitung, die aus einer Aneinanderreihung von Dataflows Gen1 besteht, in MS Fabric zu den dazugehörigen Dataflows Gen2 zu migrieren. Die Dataflows Gen1 tragen zu einem Datenmodell „Central Dataset“ bei, das zur Erstellung mehrerer interner Reports dient. Das migrierte Datenmodell „Central Dataset“ soll analog im MS Fabric Warehouse zur Verfügung gestellt werden.
Wir streben dazu die folgenden Umsetzungen in Microsoft Fabric basierend auf der ursprünglichen Realisierung des Forecast Reports in Power BI Desktop an:
- Migration der Dataflows, d.h. die Dataflows Gen1 werden so weit wie möglich identisch zu Dataflows Gen2 in MS Fabric übertragen. Die Ergebnisse eines Dataflow Gen2 werden im Lakehouse gespeichert.
- Orchestrierung mithilfe von Pipelines in MS Fabric, die Aktualisierungen mehrmals pro Tag erlauben. Außerdem zielen wir auf die inkrementelle Verarbeitung bestimmter Daten basierend auf Zeitangaben ab.
- Einführung von Fehlermeldungen durch E-Mail Versand bei fehlerhaftem Durchlaufen eines Dataflow.
- Bereitstellung eines einheitlichen Datenmodells als Dataset analog zum Central Dataset, auf dem Measures und Beziehungen zwischen Tabellen definiert werden.
Durchführung des Migrations-POC
Die konkrete Durchführung des POCs basiert auf den folgenden Schritten. In jedem Schritt schildern wir ebenfalls beobachtete Vorteile sowie Probleme und Lösungen.
1. Erstellung eines Microsoft Fabric Workspace
Um das Vorhaben umzusetzen, ist es notwendig, einen Workspace anzulegen. Nach Aktivierung des MS Fabric Tenants, wurde ein Fabric Test-Workspace angelegt. Bereits bestehende Elemente aus dem ehemaligen Power BI Umfeld wie Berichte und Datasets wurden übernommen. Neue Elemente wie SQL-Endpunkte und Lakehouses wurden zusätzlich erstellt. Zudem wurden in den konvertierten SQL-Endpunkten Zwischenergebnisse der bisherigen Implementierung aus Power BI Desktop sichtbar und zugreifbar. Diese Funktion gab es im ursprünglichen Power BI nicht.
Die automatische Konvertierung hat allerdings auch Fragen aufgeworfen. Elemente gleicher Workspaces wurden beim Anlegen eines neuen Microsoft Fabric Workspace durch verschiedene Mitarbeiter unterschiedlich behandelt. Dieses Verhalten kann leider nur schwer nachvollzogen werden.
2. Migration aller Dataflows Gen1 zu Dataflows Gen2
Umsetzung der Migration von Dataflows
Unsere betrachtete Datenintegration und -aufbereitungsstrecke des POCs untergliedert sich in die folgenden logischen Ebenen mit mehreren Dataflows:
- Extract-Ebene: Aus unterschiedlichen internen Systemen werden Daten von inovex abgerufen, d.h. verschiedene Schnittstellen der Quellsysteme werden durch Dataflows angesprochen, um entsprechende Daten abzurufen. Die Daten werden im Lakehouse in einer neu angelegten Tabelle zwischengespeichert.
- Transformation-Ebene: Die Daten aus der Extract-Ebene werden durch weitere Dataflows in einem dreistufigen Verfahren bestehend aus „Extraction“, „Transformation“ und „Load“ zusammengefasst, verändert und aufbereitet, um final wieder in einer neuen Tabelle im Lakehouse abgelegt zu werden.
- Datenmodell-Ebene: Die Datenergebnisse aus der Transformation-Ebene werden durch zwei weitere Dataflows angepasst und verarbeitet. Das Endergebnis wird analog zu den vorherigen Ebenen in einer Tabelle im Lakehouse gespeichert.
Mittels des folgenden Kopieransatzes wird nun jeder Dataflow manuell in einen neuen Dataflow Gen2 in Fabric übertragen. Zunächst werden innerhalb von Power Query Parameter und Token angelegt, die in manchen Abfrage verwendet werden. Danach wird der gesamte Code einer bestehenden Abfrage aus dem „Erweiterten Editor“ des Dataflow Gen1 in eine leere Abfrage für den äquivalenten Dataflow Gen2 kopiert. Zu berücksichtigen sind Abhängigkeiten zu weiteren Dataflows, die ebenfalls neu angelegt oder angepasst werden müssen. Dieser Ansatz entspricht dem zweiten Lösungsvorschlag der Dokumentation zum Migrieren von Dataflows, allerdings ohne abhängige Elemente aus dem Dataflow Gen1 zu erzeugen. Unser gewählter Kopieransatz bringt damit den Vorteil mit sich, dass die unerwünschte Duplizierung von mehrfach verwendeten Vorgänger Dataflows verhindert wird.
Nun werden die zugehörigen Abhängigkeiten der Dataflows in der neu verfügbaren Diagrammansicht sichtbar. Zur Speicherung der Ergebnisse eines Dataflows haben wir als Datensenke ein vorhandenes Lakehouse aus unserem Workspace ausgewählt. Dieses konnte per Klick ausgewählt werden und unter Angabe eines Namens die Tabelle angelegt werden.
Verlangsamte Ausführung von Dataflows durch die Staging-Option
Besondere Neuerungen sind die Diagrammansicht nach Anlegen eines Dataflow und die automatisch aktivierte Staging Option, die wohl der Standard-Einstellung „Enable Load“ von Power BI entspricht. Dies ist eine Möglichkeit, die Transformation der Daten des Dataflow Gen2 im internen Speicher bzw. dem Staging-Speicher zwischenzuspeichern. Darauf kann dann mithilfe eines Dataflow-Connectors zugegriffen werden. Diese Option führt zu erhöhten Ausführungszeiten, was sich durch eine schnellere Abwicklung nach dem Deaktivieren des Staging bemerkbar macht. Aus Effizienzgründen haben wir auf Staging verzichtet. Hierbei ist jedoch zu beachten, dass nach dem Deaktivieren eine eigenständige Verwaltung der Zwischenergebnisse notwendig ist.
Notwendige Umbenennungen von Tabellenspaltennamen im Lakehouse
Microsoft Fabric erlaubt nur alphanumerische Zeichen und Unterstriche bei der Benennung von Tabellen und Spalten im Lakehouse. Das heißt beispielsweise, dass enthaltene Leerzeichen und deutsche Umlaute in Tabellennamen und -spalten bei Verwendung des Lakehouse geändert werden müssen. Unter Umständen müssen daher nicht passende Namen einer Ergebnisspalte eines Dataflow zu einer entsprechenden Spalte einer Tabelle umbenannt werden. Die GUI bietet hierfür eine automatische Korrektur an, was sich als hilfreich erwiesen hat. Bei bereits bestehenden Tabellen kann jedoch nicht auf die automatische Korrektur zurückgegriffen werden, sodass die manuelle Nacharbeit unseren Arbeitsprozess beeinträchtigt hat.
Fehlerhafte automatische Festlegung von Tabellenspalten-Eigenschaften
Es kam zu unerwarteten Fehlern durch eine automatische Festlegung von Spalteneigenschaften einer Tabelle im Lakehouse durch das Tool. Hierbei handelte es sich um ein Nullwert-Verbot für eine Tabellenspalte. Das Problem wurde durch das Auffüllen mit Textwerten oder das Auslagern der entsprechenden Null-Werte dieser Spalten im entsprechenden Dataflow umgangen. Eine weitere Alternative besteht darin, die gewünschten Tabellen und deren Struktur über den SQL-Endpunkt zu erstellen. Allerdings ist es (bislang) noch nicht möglich, entsprechende Eigenschaften zu ändern.
Lange Wartezeiten mit anschließenden Fehlermeldungen beim Veröffentlichen und Aktualisieren der migrierten Dataflows
Sowohl die Veröffentlichung von Dataflows, als auch die anschließend automatisch ausgeführte Aktualisierung haben oft zu langen und unerklärlichen Wartezeiten geführt, obwohl die Menge der verarbeiteten Inhalte dafür zu gering ist. Ebenfalls kam es zu unerwarteten Fehlermeldungen, die bei der Bearbeitung des entsprechenden Dataflow und der dortigen Aktualisierung nicht aufgetreten waren. Diese wurden erst durch eine Fehlermeldung oder durch eine Timeout-Meldung nach langen Aktualisierungszeiten bemerkt. Umständliches Herunterladen der Fehlermeldungen, als auch dann fraglich begründete Fehlermeldungen, erschweren die Arbeit beim Veröffentlichen und Aktualisieren von Dataflows. Im Verlauf der Bearbeitung des POC wurden weitere Aktualisierungen bei MS Fabric eingespielt, sodass manche Probleme bereits behoben wurden (Stand: 10.2023).
Allerdings ist auch das erfolgreiche Aktualisieren eines Dataflow keine Garantie dafür, dass das Abfragen der dabei erstellten Tabelle fehlerfrei funktioniert. Dabei haben wir mitunter beobachtet, dass es manchmal zu Problemen mit falschen Parquet-Metadaten kommen kann. MS Fabric legt in manchen Fällen einen anderen Datentyp eines Feldes in der Datenbank ab als den verwendeten Datentyp im Dataflow. Beim Versuch, diesen Fehler zu beheben, war das Löschen der erstellten Tabelle schwierig, da das Recht dazu nicht automatisch an Bearbeiter:innen übertragen wurde. Durch direkten Zugriff auf das Lakehouse konnte das Problem behoben werden.
Ebenfalls ist uns aufgefallen, dass insgesamt die Performance der Dataflows langsamer als in unserer vorherigen Power BI Umgebung scheint. Berücksichtigt wurde die Bearbeitung auf SKU F2 und F4. Für aussagekräftige Schlüsse müssen hier noch genauere Laufzeitmessungen unternommen werden.
Orchestrierung der Dataflows Gen2
Umsetzung der Orchestrierung von Dataflows
Für die Orchestrierung mittels Pipelines, haben wir zunächst die übliche Vorgehensweise laut Dokumentation vorgenommen, welche wir als sehr einfach und gut umsetzbar empfanden. Dies umfasste sowohl den Aufruf eines Dataflow in eine Pipeline zu integrieren, als auch das Aufsetzen einer Komponente zum E-Mail-Versand bei Fehlermeldungen. Es ist ebenfalls einfach, die Dataflows zusätzlich noch in eine definierte Reihenfolge zu bringen.
Im weiteren Verlauf der Bearbeitung unseres POC sind wir auf Problemstellungen gestoßen, die nicht mit einer von Microsoft vorgeschlagenen Lösung bewältigt werden konnten. Daher haben wir alternative Lösungen ausprobiert.
Aufgrund der bislang fehlenden Möglichkeit einer dynamischen Parameterübergabe in einer Pipeline zu einem Dataflow, haben wir es innerhalb eines Dataflow umgesetzt. Wir setzen dafür Parameter in einer Abfrage ein, sodass die Filterung schon in der Datenbank stattfindet, aus der die Daten abgerufen werden. Hierfür werden in unserer Lösung zwei Abfragen genutzt: Eine dient zur Ermittlung des Startpunkts und eine weitere zur gezielten Datenabfrage. Dabei wird der Startpunkt in das SQL-Statement eingebaut, um eine Teil-Datenmenge ohne Verwendung von Parametern oder Abhängigkeit von Direct Query oder Query Folding zu erhalten.
Der Pipeline-Editor
Es war umständlich mit dem Pipeline-Editor zu arbeiten, insbesondere sobald mehrere Komponenten der Pipeline dargestellt werden. Beispielsweise führt das Einfügen von neuen Dataflow-Komponenten zum Verschieben von bereits platzierten Komponenten. Ebenfalls werden vor dem Einfügen einer Komponente vorgenommene Maßstabsänderungen nicht beibehalten. Nach dem Speichern und erneuten Öffnen der Pipeline werden die Komponenten an beliebigen Stellen platziert. Die zuvor genutzte Einstellung wurde nicht gespeichert. Die Umsetzung in den Vorgänger Tools empfanden wir als angenehmer.
Fehlerbenachrichtigungen mit Gmail
Der Versand von Fehlermeldungen kann aktuell (Stand 08.2023) nur über Outlook 365 ausgeführt werden. Dies ist leider problematisch, sofern intern andere Anbieter zur Verwaltung der E-Mails genutzt werden. Das Problem war lösbar durch Nutzung einer Python Library und dem Aufsetzen eines entsprechenden Notebooks, das den Versand der Mails über SMTP von Gmxail ermöglicht. Somit hat der Austausch der Outlook-Komponente mit dem Notebook innerhalb der Pipeline zum Erfolg geführt.
4. Bereitstellung eines Datenmodells für interne Reports
Umsetzung im Warehouse
Es wurden verschiedene Vor- und Nachteile abgewägt, ob das Lakehouse oder Warehouse von MS Fabric zum Ablegen des finalen Datasets genutzt wird. Eine klare Entscheidung war nicht auf Anhieb ersichtlich. Zunächst erschien die Option einfacher, die finalen Tabellen im Warehouse abzulegen, um im Anschluss Beziehungen und Measures darauf aufzusetzen. Es stellte sich im Verlauf der Bearbeitung heraus, dass hierzu auch Möglichkeiten im Lakehouse existieren. Da jedoch die ursprüngliche Umsetzung im Warehouse getätigt wurde, und somit der Forecast Report wie gehabt auf Tabellen in einem Warehouse zugreifen kann, fiel die Wahl vorerst auf das Warehouse. Unsere finale Bearbeitung ist hier allerdings noch nicht abgeschlossen. Die Erstellung des Datasets aus dem Browser heraus kann getätigt werden, ohne Power BI Desktop oder einen Report zu benötigen. Allerdings mussten wir feststellen, dass es nicht möglich ist, „Calculated Columns“ zu erstellen. Dessen Funktionalität kann nicht durch Measures übernommen oder in Power Query abgebildet werden. Das hat dazu geführt, dass unser Ziel-Dataset nicht angelegt werden konnte.
Unterschiedliche Relation-Aktivierungen in Power BI Desktop
Aufgefallen ist uns zudem, dass es offenbar Unterschiede bei der Prüfung der Zulässigkeit von aktiven Relationen zwischen den Tabellen zwischen Power BI Desktop und der Online-Version des Warehouse gibt. Die Aktivierungen von Beziehung waren im ehemaligen Central Dataset fraglich, hingegen ist positiv aufgefallen, dass die Aktivierungen im Warehouse nachvollziehbar sind. Insbesondere sind Probleme aufgetreten zwischen diversen Fakten- und Dimensionstabellen, die Beziehungen zur Datumsdimension (Kalender) erstellen.
Fazit zur Durchführung des Migrations-POC in MS Fabric
Microsoft Fabric gibt Anlass zur Hoffnung, Herausforderungen bei der Zusammenarbeit innerhalb eines Daten-Projekts aufzugreifen und zu vereinfachen. Die Zusammensetzung aus bereits bekannten Microsoft Produkten soll den Einstieg in Microsoft Fabric für die Endnutzer:innen erleichtern.
Unsere bisherige Arbeit mit Microsoft Fabric hat sowohl positive Aspekte als auch negative Aspekte zum Vorschein gebracht. Einige neue Funktionalitäten haben sich durchaus als lohnend herausgestellt, wie der betriebssystem-unabhängige Zugriff über den Browser auf Power BI zur effizienten Modifikation unterschiedlicher Komponenten oder die neue Diagrammansicht zur Bearbeitung von Dataflows. In mehreren Fällen war es zudem möglich, die Schritte der Dokumentation gut nachzuahmen, um etwa die Dataflows zu migrieren oder eine einfache Pipeline aufzusetzen.
Auch wenn die Migration der Dataflows durch Kopieren des Codes sehr schnell erledigt werden konnte, trügt hier der Anschein. Viele unerwartete Herausforderungen sind aufgetreten beim Erproben, Veröffentlichen und Aktualisieren der migrierten Dataflows. Das Auffinden von Lösungen zu den aufgetretenen Problemen hat mehr Aufwand erfordert als erwartet. Das Gleiche gilt bei individuellen Umsetzungswünschen. Mit Geduld und Ausprobieren konnten „Quick Fixes“ gefunden werden, die jedoch manchmal umständlich erscheinen. Die Arbeit mit der neuen GUI vom Pipeline-Editor konnte nicht ganz überzeugen. Außerdem mussten wir leider ein großes Defizit feststellen bezüglich der Performance bei der Ausführung der migrierten Dataflows.
Natürlich muss eingeräumt werden, dass Microsoft ausdrücklich darauf hinweist, dass MS Fabric sich in einer Preview-Version befindet. Das heißt, Fehleranfälligkeiten und unerklärliches Verhalten des neuen Tools waren zu erwarten. Auch ist es relativ gewöhnlich, nachträgliche Anpassungen vornehmen zu müssen, um durch eine Migration von neuen Features zu profitieren. Zudem informiert Microsoft über bekannte Einschränkungen und Problemstellungen in der Dokumentation und arbeitet fortwährend an Aktualisierungen (Verlinkung verweist beispielhaft auf Probleme von Data Factory).
Wir freuen uns auf die weitere Entwicklung von MS Fabric und hoffen, dass einige beobachtete Mängel noch behoben werden. Denn insgesamt weist MS Fabric viel Potential auf, den komplexen Analytic-Workflow durch die beworbenen Features zu vereinfachen.
Quellen
- https://learn.microsoft.com/de-de/fabric/
- https://powerbi.microsoft.com/en-us/blog/introducing-microsoft-fabric-and-copilot-in-microsoft-power-bi/
- https://ssbipolar.com/2023/05/23/introducing-microsoft-fabric/
- https://davidalzamendi.com/microsoft-fabric/#What_are_some_of_the_challenges_that_Microsoft_Fabric_is_trying_to_solve
- https://www.pmone.com/wissen/blog/microsoft-fabric-hype-oder-gamechanger/
- https://medium.com/@kanerika/microsoft-fabric-vs-power-bi-a-comparative-analysis-66c67c617ebe
