Ich habe vorher schon Kunden davon überzeugt, von SSAS on premise zu Power BI Services zu wechseln. Man bekommt für wenig Geld eine sehr gute BI-Umgebung, spart sich eine SSAS Instance.

Manche Projekte laden die Daten direkt in Power BI Modelle. Doch ich sehe viele Vorteile darin, die Daten erst einmal für die Verwendung durch Power BI vorzubereiten. Und das passiert bei mir im SQL Server. Was natürlich eine SQL Server Instanz erfordert, oder Datenbanken in der Cloud.

Viele Projekte ziehen derzeit mit ihren Daten in ein Databricks Lakehouse, wodurch die Datenhaltung preiswert wird. Mit Notebooks kann man ganz gut entwickeln und auch ELT Prozesse abbilden. Allerdings ist die Arbeit für jemanden, der lange mit dem SQL Server und TSQL gearbeitet hat, gewöhnungsbedürftig. SSMS kann mit einem Databricks Lakehouse nicht verwendet werden, man arbeitet mit online Editoren oder vielleicht dbeaver. Auch ist Spark SQL nicht TSQL.

Und nun kommt Microsoft Fabric - mit einem sehr überzeugenden Marketing. Alle Daten in einem OneLake, und alle Produkte greifen auf die selben Daten zu: Statt ein Power BI Modell zu beladen, ist dieses live mit den Daten verbunden, und das mit einer Performance, die einem bisherigen Import der Daten entspricht. Das zumindest sagt die Werbung. Alles in einer Entwicklungsumgebung rund um Power BI, und mit diesem Vorteil sind auch Nachteile verbunden, oder Anfangsschwierigkeiten, denn noch handelt es sich um einen Preview.

Dokumentation zu Microsoft Fabric

Probleme durch Auswahl einer falschen Region

Mit dem Test von Fabric beginnen die ersten Probleme: Trotz Aktivierung von Fabric und Zuordnung von Arbeitsbereichen zu dieser Kapazität werden in manchen Mandanten die Fabric Icons nicht angezeigt, so dass eine Nutzung nicht möglich ist. Wobei der Countdown der 60 Tage des kostenlosen Tests weiterläuft. In einem anderen Mandanten gelang mir der Test. Und woran liegt das? Fabric wird nur in bestimmten Regionen unterstützt, West-Deutschland ist nicht dabei. Eine Warnung kommt aber nicht bei der Erstellung einer Test-Kapazität in der falschen Region. Pech gehabt: man hat dann eine Kapazität, für 60 Tage, diese kann aber nicht genutzt werden. Und auch ein Verschieben in eine andere Region ist nachträglich nicht möglich.

SQL Endpoints für Lakehouse und Warehouse

Sehr schön ist, dass das Lakehouse mit einem SQL Endpoint verbunden ist, somit stehen die Tabellen eines Lakehouse gleichzeitig für den Zugriff mit TSQL zur Verfügung, auch im SSMS. Fast so, wie man es vom SQL Server gewohnt ist. Man könnte also fast so arbeiten, wie seit Jahren. Sichten und Prozeduren können schon im Lakehouse erstellt werden, allerdings nur im SQL Endpoint, und man kann auf sie nur über diesen SQL Endpoint zugreifen. Was nicht funktioniert: Das Erstellen von Tabellen über den SQL Endpoint. Und obwohl die Syntax von Databricks das Erstellen von Sichten über Spark SQL ermöglicht, funktioniert das im Fabric Lakehouse nicht. Das verstand ich zunächst nicht, wie auch einige andere Einschränkungen. Bis mir klar wurde, dass Databricks die Technologie Delta Lake eben nur verwendet (oder verwenden kann) und dabei Databricks-spezifische Features erweitert. Diese Features gehören aber nicht immer zu Delta Lake. Und so ist ein Fabric Lakehouse eben ein anderer Aufsatz auf Delta Lake, wobei es andere Features gibt, die in einem Databricks Lakehouse fehlen.

Zusätzlich zum Fabric Lakehouse gibt es noch das Fabric Warehouse. Das funktioniert schon fast so, wie eine gewohnte SQL Server Datenbank. Leider mit zum Teil erheblichen Einschränkungen. So können keine Tabellen mit Identity erstellt werden. Und wie ich nun verstehe, liegt das daran, dass diese vom open source Delta Lake noch nicht unterstützt werden. Vielleicht kommt das noch:

Laden von Daten aus einem on premise SQL Server

Möchte man Daten aus einem on premise SQL Server in Fabric laden, sollte man das gar nicht erst mit Data Factory versuchen, sondern gleich ein "on premise SQL Server Gateway" verwenden und die Daten mit Pipelines laden. Das passiert dann mit M Script - wie in Power Query, also wie in Power BI.

(unvollständige) Versions Kontrolle mit git

Source Control ist für mich obligatorisch. Alles gehört in allen Projekten in git Repositories, oder wenigstens in TSVC oder Subversion. Ich habe gerade die Verlängerung eines Projekts riskiert durch meine penetranten Hinweise auf die Vorteile von Versionskontrolle, technischer Dokumentationen und formaler Bereitstellungsprozesse.

Sehr positiv ist zunächst einmal, dass man einen Fabric Arbeitsplatz mit einem git Repository verbinden kann. Man scheint sich der Wichtigkeit von Versionskontrolle bewusst zu sein. Es ist schade, dass nur Repositories in Azure DevOps unterstützt werden. Also muss man sich damit abmühen, die Azure Repositories irgendwie mit den Orten zu synchronizieren, die man sonst für seine Repositories verwendet.

Derzeit betrifft die Versionskontrolle nur Power BI Berichte und Datasets. Das ist schon einmal ein großer Fortschritt! Leider gibt es für die anderen Bestandteile der Fabric noch keine Versionskontrolle. Notebooks und Queries gehören in ein Repository; Data Factory und Pipelines, Lakehouse und DWH, alles ist (noch) ohne git Anbindung. Unter "coming soon" wird angekündigt, dass ein Ausbau geplant ist.

Mit dem kostenlosen SchemaCompare aus VisualStudio konnte ich mich nicht mit dem Fabric Lakehouse oder dem Fabric Warehouse verbinden, da ich es nicht einmal schaffe, das Microsoft Konto, das für die Verbindung verwendet werden soll, zu ändern. Mein Lieblingstool für Vergleiche, der kommerzielle SQL Examiner, hat die Implementierung auf seiner Roadmap.

mögliche Lösungen für jetzt und heute?

Ich habe derzeit keinen eleganten Plan, wie man die Entwicklung aus Fabric heraus in ein Repository oder vielleicht in eine andere Test-Kapazität retten könnte. Wenn der kostenlose 60 Tage Test beendet wird, dann muss man entweder zahlen, oder die Kapazität wird geschlossen und man verliert alle Inhalte. Jeden Monat 300 € zu zahlen, nur um meine Entwicklung zu behalten, ist mir als Freelancer zu teuer.

Data Pipelines könnte man als Template exportieren und aus einem Template wiederherstellen. Sie sehen dann aber anders aus, als das Original.

Data Factory speichern? Keine Ahnung, ob und wie das geht.

Tabellen im Lakehouse? Man könnte sie explizit unter Verwendung von Notebooks erstellen. Doch Notebooks als Code zu speichern, geht nicht. Es geht zur Zeit über den Umweg einer Visual Studio Code Erweiterung, mit der man Notebooks als Code in einen Arbeitsordner auf dem PC bekommt. Von da aus könnte man sie dann irgendwohin kopieren. Sehr umständlich. Und nicht ausgereift: Wenn man Änderungen gleichzeitig lokal und remote vornimmt, kann man die lokalen Änderungen bei einem merge (noch) nicht rückgängig machen. Wieder einmal meint Software, statt meiner entscheiden zu können, wie zu mergen ist.

Objekte im DWH? Da SchemaCompare zwar angekündigt, aber noch nicht verfügbar ist, könnte man alle Sichten und Prozeduren über Skripte erstellen. Oder über ein SQL Notebook in Azure Data Studio.

Also irgendwie ginge es vielleicht schon, Teile der Entwicklung als Code zu retten, wenn man sich vorher einen Plan macht.

Bereitstellungspipelines

Bereitgestellte Elemente

  • Datasets

  • Berichte

  • Dataflows

  • Datamarts

  • Dashboards

  • Paginierte Berichte

Irgendwie betrifft das alles nur den "Überbau" rund um Power BI: Datasets, Dataflows, Datamarts - alles doch eher aus der Vor-Fabric-Zeit?

Ich sehe einen wichtigen Vorteil von Fabric auch darin, dass nun der "Überbau" (Power BI) viel stärker mit dem "Unterbau" (Lakehouse, DWH) integriert werden kann. Wie kann oder soll da eine gemeinsame Bereitstellung erfolgen, wenn der Überbau stark vom Unterbau abhängt? Wenn sich im Unterbau Tabellen, Sichten und Verknüpfungen ändern die ganz automatisch so auch im Power BI erscheinen, dann ist diese oben beschriebene Bereitstellung unvollständig.

Die Liste der "Coming Soon" für das Fabric Warehouse auf https://blog.fabric.microsoft.com/en-us/blog/introducing-synapse-data-warehouse-in-microsoft-fabric/ lässt hoffen:

  1. Automatic statistics: statistics are automatically computed in the Warehouse as queries are executed ensuring users get optimal performance.

  2. Zero copy Table clones: users can create zero copy Table clones using a T-SQL command.

  3. Data warehouse in Deployment Pipelines: users can use Warehouses in Deployment Pipelines and deploy to Dev, Test and Production workspaces. They can compare schemas, rollback changes and automate via the use of REST APIs.

  4. Data warehouse Git integration: users can connect to a Git repository, develop their warehouse SQL scripts and code, manage versions, commits, and pull requests and download SQL projects.

  5. Data warehouse REST APIs: users can use public REST APIs to automate creation, management, and administration of their data warehouses.

  6. Warehouse integration with Microsoft Fabric Monitoring Hub: users can view query details, monitor, and troubleshoot performance of their solution end-to-end using the Monitoring Hub.

  7. Dataflows Gen2: users can use Dataflows Gen2 with familiar Power Query experiences to transform data and load into the Warehouse.