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 Micorsoft 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überhinaus 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 gefundene werde. 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 Entwicklungssytem. Oft gibt es darüberhinaus 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 Technologienf für die Speicherung von Daten zur Verfügung. Beide habe 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. Metadaten getriebene 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 Technologie Auswahl 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 Datemmenge 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 stellte eine definierten 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 kostenintesiven 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, worauf im Rahmen der Entwicklung geachtet werden muss, um Ressourcenverbrauch zu minimieren.

Wenn Sie für Kundenanalysen, Finanzberichterstattung, Produktionsprozesse, Planung oder andere datengetriebene Problemstellungen eine Lösung benötigen, dann beraten wie Sie gerne.

Kontaktieren Sie uns für eine kostenlose Beratung oder eine Demo und wir zeigen Ihnen, wie Microsoft Fabric Ihre Datenstrategie revolutionieren kann.