In diesem ersten Beitrag einer dreiteiligen Serie möchten wir die Erfahrungen teilen, die wir bei IT-Logix mit Fabric gemacht haben. Zunächst werden wir einige Schlüsselkomponenten von Fabric einführen, bevor wir unsere praktischen Erfahrungen darlegen.

Fabric: Die neue Wunderwaffe für Business Intelligence und Datenanalyse? – Unser Erfahrungsbericht

Fabric ist eine umfassende Analyseplattform, die durch ihre innovative Architektur, fortschrittliche Funktionen und Integrationen mit Azure-Diensten sowie beeindruckender Backend-Performance flexible und effiziente Lösungen bietet. Mit OneLake und dem Delta Lake-Format stellt Fabric eine einheitliche Datenebene bereit. Fabric ermöglicht auch die Nutzung von sogenannten Shortcuts, die das Kopieren und Duplizieren von Daten unnötig machen. Fabric trennt Speicherung und Verarbeitung, was Leistung, Skalierbarkeit, Sicherheit und Kosten über verschiedene Betriebsmodi hinweg optimiert. Darüber hinaus unterstützt Fabric Datastreaming-Lösungen sowie Lakehouse- und analytische Data Warehouse-Architekturen und integriert eine breite Palette an Werkzeugen, einschließlich Data Factory, Data Engineering, Data Science, Real-Time Analytics, Power BI und Data Activator. Um das Benutzererlebnis zu verbessern, können Personas wie Power BI, Data Factory, Data Activator, Branchenlösungen, Data Science, Data Engineering und Real-Time Analytics angewendet werden, um die auf Power BI basierende Benutzeroberfläche für typische Rollen maßzuschneidern.

Wie bereits erwähnt, ist OneLake die grundlegende Datenebene von Fabric. Um die Datenhandhabung zu optimieren und an Projektanforderungen anzupassen, kann Power BI über Liveverbindung, DirectQuery, Import-Modus oder die neue DirectLake-Schnittstelle genutzt werden.

Fabric Lakehouse

Ein Lakehouse vereint die skalierbaren Speicherkapazitäten eines Data Lakes mit den Datenmanagement- und Analysefunktionen eines Data Warehouses. Es dient der Verwaltung großer Mengen strukturierter und unstrukturierter Daten. Ein Lakehouse umfasst Elemente wie Datensätze, Tabellen, Views, Schemata, Datenpipelines, Sicherheits- und Governance-Richtlinien, Analyseengines, Integrationspunkte und mehr. Darüber hinaus bietet ein Lakehouse einen integrierten SQL-Endpunkt und ein Power BI-Semantikmodell. Mit OneLake als gemeinsamer Datenbasis lassen sich Daten über mehrere Fabric Capacities hinweg in ihren jeweiligen Lakehouses nutzen, ohne dass eine Duplizierung notwendig ist.

Fabric Data Warehouse

In Fabric gibt es die Möglichkeit, Datalake-zentrierte Data Warehouses zu erstellen. Statt eines dedizierten SQL-Pools werden hier die Daten im Delta-Lake-Format auf OneLake gespeichert. Die strikte Trennung von Berechnung und Speicherung erlaubt eine on-demand Skalierung der Rechenkapazitäten, was sich kosteneffizient auswirkt. Trotz des innovativen Speichermodells können neue Geschäftslogiken per T-SQL implementiert und bestehende Modelle migriert werden.

DirectLake

Der DirectLake ermöglicht eine direkte Verbindung von Rapportierungstools wie Power BI zu den Daten in OneLake. Die Benutzer können ihre Daten direkt in Power BI nutzen, ohne sie zuvor importieren zu müssen. Mit Power Query werden Daten in den Arbeitsspeicher geladen und, je nach Abfragehäufigkeit, dynamisch gehalten oder entfernt. DirectQuery eignet sich ideal für Echtzeit-User Cases, während DirectLake für Near-Real-Time-Cases hilfreich ist, ähnlich dem Import-Modus, aber für wesentlich größere Datenmengen. Sobald die Daten in OneLake sind, kann ein Bericht mit nur wenigen Klicks erstellt werden.

Unsere Erfahrungen in Fabric mit Data Engineering und Spark

Spark Clusters in Fabric

In Fabric wird Data Engineering durch die Möglichkeit Notebooks und Spark-Job Definitions mit nativer Visual Studio Code Integration zu verwenden, vereinfacht. Um erfolgreiches Data Engineering mit Fabric zu gewährleisten, müssen Spark Clusters erstellt werden. Dazu gibt es mehrere Möglichkeiten:

• Starter Pools und das Default Environment
  • Starter Pools (mittlere Knotengrösse mit 8 vCores pro Knoten) werden nach dem Start der Applikation am Laufen gelassen. Wenn keine zusätzlichen Bibliotheken auf der Default Umgebung installiert werden, dauert das Starten des Spark Clusters unter 15 Sekunden
• Custom Pools mit Custom Environments
  • Variable Knoten-Konfiguration, bei der die Anzahl der verfügbaren vCores von Ihrer Fabric-Kapazität abhängt
  • Der Start des Spark-Clusters mit benutzerdefinierten Umgebungen kann 1 bis 2 Minuten in Anspruch nehmen

Unser Fazit zum Umgang mit Spark Pools und Environments in Fabric:

Verwenden Sie, wenn möglich, die Standardbibliotheken des Default-Environments und definieren Sie Ihre bevorzugte Spark-Konfiguration als Standardpool für Ihren Arbeitsbereich. Andernfalls kann das Initialisieren eines Cuctom-Pools und das Installieren zusätzlicher Bibliotheken viel Zeit in Anspruch nehmen, was bei kurzlebigen Anwendungen die Gesamtdurchlaufzeit erheblich beeinträchtigen kann.

Paralleles Ausführen von Notebook Code

Um Daten mit Notebooks möglichst effizient zu verarbeiten, untersuchten wir zwei Möglichkeiten, Notebook Code in den Spark Cluster parallel auszuführen:

• Zum einen lassen sich durch das Einbinden von MS Spark Utilities mehrere Notebooks parallel starten und somit Code gleichzeitig ausführen. Hierbei ist jedoch Vorsicht geboten, wenn mehrere Notebooks dieselben Datenobjekte laden, manipulieren und Änderungen speichern.
• Eine andere Möglichkeit ist das Verwenden von Python-nativen thread-pools welche aber dem Global Interpreter Lock (GIL) un-terstehen. Durch die Einschränkung des GIL’s lassen sich viele rechenintensive Prozesse nicht effizient parallelisieren. Rein IO-intensive Prozesse wie laden, speichern oder verschieben von Dateien, jedoch schon.

Bezüglich der Kombination von Spark Cluster und Knotengrösse gegenüber paralleler Note-bookausführung konnten wir in unseren Tests keine Abhängigkeiten finden. Für Python Multithreading ist es dahingegen besser, eine grosse Anzahl an vCores als Executor Kerne zur Verfügung zu stellen und zugleich eine geringe Anzahl an Executors zu haben. Im Fabric Kontext bedeutet dies: grosse Knoten (L oder grösser) mit wenig Executors, jedoch mindestens zwei Knoten, wobei der eine ein Masterknoten und der andere ein Arbeiterknoten ist. Für den Masterknoten reicht es aus, wenige vCores zuzuordnen.

Ausblick

Im zweiten Teil der Reihe werden wir unsere Erfahrung bezüglich Datawarehouse Automation erläutern. Wir werden kurz das Archivieren und Aufarbeiten von Daten im Lakehausekontext per Medallion-Architektur anschneiden und uns dann das Fabric Datawarehouse genauer unter die Lupe nehmen.

Du willst mehr über Microsoft Fabric erfahren?

Dann solltest Du unbedingt den MAKE BI 2024 besuchen. Sichere Dir hier Dein Ticket!