Microsoft Fabric

Bei der Einführung von Microsoft Fabric gibt es Fragestellungen, deren Lösung für den Erfolg des Projektes wichtig sind. All diese Fragestellungen wurden bei Partake schon vielfach erfolgreich gelöst. Profitieren auch Sie von unserem Erfahrungsschatz bei der Einführung von Microsoft Fabric.


Workspace Topologie?
Alle Fabric Objekte wie z.B. Lakehouses, Notebooks oder Power BI Modelle werden in Workspaces abgelegt. Workspaces dienen als Mittel der Strukturierung und einfachen Berechtigungssteuerung.

Aber welche Aufteilung in Workspaces ist für den konkreten Anwendungsfall die beste? Klar ist, dass eine Aufteilung nach den verschiedenen Systemumgebungen wie Development, Test und Produktion erforderlich ist. Darüber hinaus können aber auch Aufteilungen für Verarbeitungsstufen (z.B. bronze, silver, gold), für die Trennung von Code und Storage oder für unterschiedliche Fachthemen Sinn ergeben.

Es muss dabei die Balance zwischen Übersichtlichkeit der Workspace Topologie und Notwendigkeit zur Strukturierung gefunden werden. Die von uns in Projekten unterschiedlicher Größe gewonnene Erfahrung hilft uns, für jeden Einsatzfall eine passende Lösung zu finden.


Deployment?
Eine professionelle Lösungsentwicklung findet nicht am produktiven System statt, sondern auf einem dedizierten Entwicklungssystem. Oft gibt es darüber hinaus auch noch ein oder mehrere Testsysteme.

Für Fabric stehen mehrere Alternativen bereit, um eine fertig entwickelte Lösung in die Produktion zu überführen. Innerhalb von Fabric gibt es Deployment Pipelines, die einfach zu konfigurieren sind und für viele Fälle das Mittel der Wahl sind. Es besteht aber auch die Möglichkeit, automatisierte Deployments über Git Release Pipelines zu nutzen. 

Git ist ein verbreiteter Standard zur sicheren und transparenten Verwaltung von Quellcode, der auch bei Fabric Standard ist. Das Deployment per Git-Release-Pipelines bietet sich jedenfalls an, wenn ein größeres Entwicklerteam am Werk ist und an mehreren Projekten oder Features parallel gearbeitet wird.


Warehouse oder Lakehouse?
Mit Fabric Warehouse und Lakehouse stehen unterschiedliche Technologien für die Speicherung von Daten zur Verfügung. Beide haben unterschiedliche Vorzüge. Welche Technologie sollte also für welchen Einsatzzweck am besten gewählt werden.

Die Vorzüge der Lakehouse-Technologie kommen immer dann zum Tragen, wenn es um automatisierten Datenverarbeitung geht. Metadatengetriebene Prozesse sind hier am einfachsten zu implementieren. Das Warehouse ist dagegen für SQL-lastige Workloads besser geeignet.

Die meisten Anwendungen können mit beiden Technologien erstellt werden. Allerdings können sich die jeweiligen Lösungen deutlich unterscheiden, was den Aufwand und die Wartbarkeit angeht. Daher ist hier eine sorgfältige initiale Technologieauswahl sehr wichtig.


Python oder PySpark?
Die im Rahmen der Datenverarbeitung in Fabric eingesetzten Notebooks können auf unterschiedlichen Plattformen basieren. Neben den etablierten PySpark Notebooks, können Notebooks auch auf reinem Python aufsetzen. Hier gibt es zwar Limitationen, was die verarbeitbare Datenmenge angeht, für viele Einsatzzwecke sind sie aber trotzdem sehr gut geeignet und können nicht zuletzt deshalb eine gute Wahl sein, weil sie mit geringeren Kosten verbunden sind.


Direct Lake oder Import?
Für Power BI war es bislang typisch, dass Daten in regelmäßigen Zeitabständen importiert werden mussten. Dazu musste die passende Verbindung im Power BI Service konfiguriert und alle Datenquellen – ggf. über ein Gateway für on-premise Daten – zugeordnet werden.

In Fabric gibt es nun auch die Möglichkeit, per Direct-Lake-Verfahren direkt auf Daten zuzugreifen. Die Notwendigkeit des möglicherweise zeitaufwändigen und ressourcenintensiven Imports entfällt damit. Alle Daten stehen in nahezu Echtzeit in den Reports zur Verfügung.
Wir können Sie beraten, was mit Direct Lake möglich ist und welche Limitationen bestehen.


Capacity Limits?
Die Abrechnung von Fabric Diensten erfolgt über sogenannte Fabric Capacities. Es gibt diese in unterschiedlicher Größe und jede Capacity-Größe stellt eine definierte Anzahl von Abrechnungseinheiten pro Minute zur Verfügung. Ist diese Anzahl von Abrechnungseinheiten aufgebraucht, so muss entweder die Capacity-Größe erweitert werden oder es muss auf den nächsten Abrechnungszeitraum gewartet werden.

Haben Sie vielleicht eine Fabric Capacity im Einsatz, überschreiten regelmäßig die Limits und müssen daher mit Einschränkungen umgehen?

Oft gibt es alternativ zur kostenintensiven Erweiterung der Fabric-Capacity die Möglichkeit, die bestehenden Prozesse dahingehend zu optimieren, dass weniger Ressourcen verbraucht werden. Wir haben im Rahmen unserer Fabric Projekte einen Erfahrungsschatz aufgebaut, auf den im Rahmen der Entwicklung geachtet werden muss, um den Ressourcenverbrauch zu minimieren.

If you need a solution for customer analytics, financial reporting, production processes, planning, or other data-driven challenges, we’d be happy to advise you.

Feel free to contact us for a free consultation or demo, and we’ll show you how to integrate Microsoft Fabric into your data strategy.