Für Business Intelligence sammelt man alle Daten eines Unternehmens an einer Stelle, und nutzt sie für Reporting. Fabric geht einen Schritt weiter: Es macht diese Informationen gleichzeitig für Künstliche Intelligenz verfügbar, und verteilt sie weiter. Daten sind der Treibstoff für AI, und Fabric ist als zentraler Datenspeicher für Microsoft Copilot der Ort, aus dem die Microsoft KI ihr Wissen zieht. Dieses Wissen kann dann wiederum in Power BI, Windows, Microsoft 365, Dynamics 365 und anderen Systemen Ihre Arbeit erleichtern.
„Fabric is the biggest launch of a data product from Microsoft since the launch of SQL Server“ (Satya Nadella, 2023)
Wir begleiten Sie bei der Einführung von Microsoft Fabric, beraten Sie unabhängig zu Vor- und Nachteilen, und kümmern uns langfristig um die technische Umsetzung. Wir managen Ihre Daten in Fabric, strukturieren und verknüpfen sie so miteinander, dass wir für Ihr Geschäft heute ein solides Fundament aufbauen. Gleichzeitig passen wir Power BI an die neuen Fabric-Prozesse an, die Ihre Ladezeiten, Datenmengen und Speicherverbrauch grundlegend reduzieren.
In Workshops evaluieren wir die Machbarkeit einer Migration nach Fabric für Ihr Unternehmen, und erarbeiten den individuell besten Migrationspfad.
Power BI wird Teil von Fabric
Wir betrachteten Power BI lange Zeit als eigenständige Applikation. Sie wird aber immer mehr Teil von Fabric. In Power BI konnte ich wunderbar Daten aus verschiedenen Quellen abgreifen und transformieren, und als Ergebnis bekam ich ein Datenset. In Fabric kann ich weiterhin die Daten abgreifen und transformieren, kann aber dabei mein Ziel frei definieren, zum Beispiel wieder eine Tabelle beschreiben. So wird das ehemalige Silo zu einem Hub, der die Daten auch für andere verfügbar macht.
Fabric is the data layer for AI, and the basis of Copilot
Hier geht es nun um weit mehr als nur Reports. Es geht um die Datengrundlage für die komplette Microsoft AI im Unternehmen (Data is the fuel that powers AI). In Fabric wird gemanaged, welche Daten im Unternehmen vorhanden sind, wie diese zu interpretieren sind, und wie sie ausgewertet werden können. Es wird damit zum Treibstoff von Copilot. Somit werden Business-Intelligence-Experten automatisch zur existentiellen Grundlage für zukünftige AI-Projekte.
Über „Notebooks“, in denen ich SPARK SQL und Python schreiben kann, lassen sich die Daten beliebig modifizieren und auch für KI und Maschinelle Lernverfahren trainieren. Außerdem kann ich in Python über „sempy“ (auch „semantic link“ genannt) DAX-Abfragen direkt auf meine semantischen Power BI-Modelle machen, und damit auch alle Measures nutzen. (Zitat: The idea behind: Also look what the business created, and use this to train your data models.) Zudem bekomme ich einen SQL Endpoint, auf den ich mit Management Studio oder meiner Applikation zugreifen kann. Die Berechtigungen für den SQL Endpoint sind jedoch abhängig von dem Objekt, das ich in Fabric erstellt habe:
- Warehouse: Ein Warehouse ist wie eine Datenbank mit Clustered Columnstore Indices. Dort habe ich strukturierte Tabellen, und bekomme mit dem SQL Endpoint alle Berechtigungen (z.B. Daten modifizieren, Daten hinzufügen). Zwar gibt es keine Identity Columns, Temp Tables und Primary-Key-Foreign-Key-Relationships, aber ansonsten ist es ähnlich zu SQL Server. Transaktionen werden hier auch untersützt.
- Lakehouse: Ein Lakehouse ist ein Hybrid aus Datenbank und Dateispeicher, so wie man es von Polybase oder Hadoop im letzten Jahrzehnt kannte. Dort kann ich nicht nur relationale Tabellen auswerten, sondern auch Exceldateien, Bilder, Videos, Audiodateien und sonstige Dateien. Das ist später die ideale Basis, um eigene GPTs zu programmieren, und der KI den Kickstart zu geben! In dieser Hybridkonstellation aus OneDrive und Tabellen hat der SQL Endpoint zwar Leseberechtigungen, kann aber weder Daten hinzufügen noch Objekte transformieren. Sie nennen den SQL Endpoint „Warehouse on the lake“. Möchte man in einem Lakehouse Daten transformieren, muss man das stattdessen in einem SPARK Notebook tun, wo man auch definieren kann, welche Datei auf welche Art zu welcher Tabelle wird. Glücklicherweise kann man in diesen SPARK Notebooks dann einfach eine Zeile mit %%sql beginnen, und darunter dann wieder normales SQL schreiben. Das Speicherformat in einem Lakehouse ist komplett Open Source, und nennt sich „delta parquet files“. Das ist kompatibel u.a. mit Databricks, Snowflake, Amazon und der Google Cloud. Die Reihenfolge, mit der Fabric die Daten im Delta Store abspeichert, entspricht der Vertipaq-Engine aus SQL Server Analysis Services (SSAS), und somit auch der aus dem Power BI Importmodus. Transaktionen werden hier nicht unterstützt. Everything running on SSD, with Terabyte caching. Mit dem „OneLake File Explorer“ kann ich mir direkt im Windows Explorer anschauen, was im OneLake liegt, und die Dateien dort sogar kopieren und verschieben. Ein „Staging-Schema“ wie im Warehouse brauche ich im Lakehouse nicht mehr, wenn die Daten auf vorhandenen Dateien basieren.
One copy of the data (this part is revolutionary)
Die Architektur von Fabric ermöglicht in vielen Fällen, dass Daten nicht mehr kopiert werden müssen, um verwendet zu werden. Anstatt über Ladeprozesse die Daten in verschiedene Systeme zu laden (zum Beispiel von der Datenbank in verschiedene Power BI Semantikmodelle), reicht es zukünftig, wenn nur noch eine virtuelle Referenz auf die Daten vorhanden ist. Diese virtuelle Referenz kann an beliebig vielen Stellen verwendet werden. Man unterscheidet hier zwischen:
- Shortcut: Das ist tatsächlich nur eine Referenz auf den Original-Datenspeicher. Abfragen werden dabei zur Laufzeit direkt an die Quelle weitergeleitet. Das geht sowohl mit Fabric-Daten als auch mit Snowflake, Databricks, Amazon, Google Cloud und sonstigen Datenquellen, die auf Delta Files (parquet) basieren. Zusätzlich geht es mit dem Dataverse.
- Mirroring: Hier wird ein CDC-ähnlicher Stream von einer Datenbank (z.B. SQL Server) zu Fabric hin automatisch aufgesetzt. CDC (change data capture) gibt es in SQL Server schon lange. Jede Transaktion (z.B. Veränderung von Daten oder der Struktur) spiegelt sich mit leichter Verzögerung dann automatisch in Fabric wider.
In beiden Fällen entfällt die Programmierung der wie früher üblichen Ladeprozesse. Trotzdem lassen sich dann quellenübergreifend alle Daten in einer Abfrage miteinander verbinden (z.B. joinen).
Every week we're deploying to production
Die Features, die Fabric bekommen soll, stehen immer für das nächste „Semester“ fest, das jeweils am 1. Oktober und 1. April beginnt. Jede Woche gibt es neue Releases, die Fabric immer weiter verbessern. Verbesserungswünsche werden priorisiert nach der Anzahl Votes auf ideas.fabric.microsoft.com. Der Dark Mode für Power BI Desktop ist mit 10.000 Votes nun endlich umgesetzt worden.
It's all in one place - unified experience
In den letzten 20 Jahren brauchte man für Business Intelligence-Projekte immer eine Vielzahl von Tools. Import-Programme, ETL, Windows Services, Task Scheduler, SSAS, Visual Studio, Management Studio – da war es normal, immer 3-6 verschiedene Komponenten miteinander zu kombinieren, um ans Ziel zu kommen. Fabric hat diese Funktionalitäten alle, sodass ich nur ein ein einziges Programm brauche, und kein anderes mehr. Alles steuere ich über Fabric, von vorne bis hinten, inklusive AI. Für mich persönlich ist das eine Traum-Vorstellung. Fabric ist gedacht als „Software as a Service“, wo sich Microsoft selbst um die ganzen Einstellungen kümmert, ähnlich wie in Microsoft 365.
Excel is not a data source! Ok, it's a datasource, but not a database
Wenn ich im Lakehouse Exceldateien habe, dann sollte ich in PowerQuery erst einmal als Schritt „convert to list“ zusätzlich reinprogrammieren, um den Inhalt der Exceldateien in SQL zu konvertieren. Dieses SQL kann dann mit den restlichen Abfragen so verknüpft werden, dass das Ergebnis eines kompletten PowerQuery-Workflows als ein einziges konsolidiertes SQL-Statement auf der Quelle ausgeführt wird. Diesen Prozess nennt man „Query Folding“, und man erkennt ihn im web-basierten Power Query Editor an dem grünen Blitz (statt der roten Uhr). Ich kann mir dort sogar Ausführungspläne anzeigen lassen (Rechtsklick => View Execution Plan), bei denen ich ganz links „Value.NativeQuery“ sehen sollte, wenn alles gut ist. In Power BI Desktop sei das Folding jedoch noch nicht verfügbar. Zitat: „I look for that day, because this will help everyone“.
The heart of Power BI is the ability to create semantic models. This is SSAS Tabular.
In Power BI wird genau dieselbe Engine verwendet wie in SQL Server Analysis Services Tabular, das in SQL Server 2012 zum ersten Mal erfunden wurde. Damals hat es die multidimensionalen OLAP-Cubes abgelöst, und heute noch bildet es dauerhaft das Herz von Power BI.
You have the fact tables in the middle, and the dimensions on the outside. That's what Power BI loves, and that's still true
Das Thema Sternschema mit der Bedeutung von Fakten und Dimensionen bringe ich in jeder Power BI-Schulung als eins der ersten Themen bei, noch bevor wir Power BI Desktop öffnen. Es nicht einzuhalten, ist trotzdem mit der häufigste Fehler, den ich bei Kunden sehe. Adam Saxton hat es bestätigt: Das Sternschema, wie man es vor 20 Jahren gelernt hat, ist heute noch die einzig wahre Basis für Power BI.
In the semantic model we should have clean names for the business
In der Datenbank kryptische Namen zu haben (z.B. Abkürzungen) ist ok, aber nicht im Semantic Model in Power BI. Das Semantic Model sollte Business-verständlich genau zeigen, um was es in der Spalte geht.
Never use "my workspace"
„Mein Arbeitsbereich“ in Power BI ist wirklich nur für Anfänger gedacht, die sonst keine Lizenz haben. Erst recht nicht zur Weiterverteilung von Reports an Kollegen. Laut Adam sollte man ihn nie nutzen. Wichtig zu wissen ist auch, dass Fabric-Admins jederzeit die Möglichkeit haben, sich auf „Mein Arbeitsbereich“ anderer Kollegen Zugriff zu gewähren, ohne dass diese es mitbekommen. Dessen sollte sich jeder bewusst sein.
Common distribution method for larger audiences than 3 people: Create an app, and share the app with them.
I love Git integration with Power BI projects
Ähnlich wie in Visual Studio-Projekten, kann ich auch in Power BI ganze Projekte anlegen (.pbip-Dateien), und diese wiederum per GitHub oder Azure DevOps unter Quellcodeverwaltung stellen. Sowohl GitHub als auch DevOps gehören zu 100% Microsoft, und können von Fabric aus bedient werden. GitHub sei jedoch etwas fehlerresistenter. In größeren Projekten sollte ich einen Produktiv-Branch und eigene Entwicklungs-Branches haben, und kann dann direkt in Fabric Merge-Konflikte beheben und die Branches ineinander integrieren. Die Daten werden dabei nicht eingecheckt, sondern liegen nur in einer lokalen .abf-Datei.
Pipeline is an orchestration piece. It manages the dataflows.
In Fabric kann ich eine „Pipeline“ anlegen, das kann ich mir ähnlich vorstellen wie früher eine SSIS-Datei (SQL Server Integration Services). Ich definiere dort einen Workflow, der aus Aktionen besteht, die wiederum an Bedingungen geknüpft miteinander verbunden sind. Eine Aktion kann z.B. sein, eine Tabelle von einer Quelle nach Fabric zu laden. Die nächste Aktion kann dann sein, ein Semantic Model zu aktualisieren, das auf diesen Daten basiert. Über den „Monitor“ kann ich mir dann Arbeitsbereichs-übergreifend anschauen, welche Ladeprozesse in welchen Pipelines wann durchgelaufen sind, wie lange sie gebraucht haben, und auf welche Fehler sie gestoßen sind. So habe ich in Fabric ein ganzes ETL-Tool komplett integriert, wie es vorher nur mit Azure Data Factory (ADF) in der Cloud möglich war. Die Einzelaktionen können hier nun endlich auch wie in Power BI mit PowerQuery umgesetzt werden. Das wird den Entwicklungsprozess deutlich erleichtern.
Evaluate your Fabric usage with the capacity metrics app
Fabric lässt sich nur über Kapazitäten lizenzieren, und nicht wie Power BI nach der Anzahl Benutzer. Die Hardware hinter allen Fabric-Kapazitäten ist immer dieselbe. Wenn Jobs mehr Saft brauchen als es der bezahlten Kapazität entspricht, werden sie einfach mit einer Fehlermeldung beendet. Die Kapazitäten reichen von ca. 300 EUR / Monat bis hin zu Enterprise-Varianten mit 6-stelligen Monatsbeträgen. Die kleinste Variante wurde jedoch the jail genannt, und vorgeschlagen als temporäre Strafe für Benutzer, die zu hohen Workload erzeugen. Um die benötigte Fabric-Kapazität einschätzen zu können, solle man einen realistischen Workload erzeugen sowohl auf der Lade-Seite (= „background“) als auch auf der Benutzungs-Seite der Power BI-Reports. In Fabric gibt es dafür einen vorgefertigten Power BI-Report, der diese Metriken auswertbar macht. Oben rechts im Report sieht man, wieviel % der vorhandenen Kapazität man zu welchem Zeitpunkt genutzt hat (Reports in rot, Ladeprozesse in blau). Die Ladeprozesse werden als 10-Minuten-Durchschnitt dargestellt. Wenn ich mit Rechtsklick den Drill-Through in der Grafik auswähle, lässt sich das bis auf 30-Sekunden-Abschnitte herunterbrechen. Zudem werden Load-Verursacher in einer Burndown-Tabelle dargestellt.
I'm a manager, I can drag files in a folder, I'm a data scientist.
So einfach sei es, mit Fabric zu arbeiten. Dateien reinziehen, und schon nenne ich mich Data Scientist. In der Theorie zumindest.
Whenever you have a small amount of data and a good DBA, use DirectQuery.
It works if you have a little bit of data, or even mid-sized data and a very good DBA.
The first time you run a Direct Lake Power BI model, you'll say: Import mode is faster.
Aus den letzten 8 Jahren Power BI kennt man den Abfrage-Modus „Import“ und „DirectQuery“. Der Import-Modus lädt alle Daten nachts in die Power BI-Datei, wohingegen DirectQuery für jede Interaktion des Benutzers SQL generiert, das direkt an die Datenbank gesendet wird.
Mit dem Lakehouse wird nun ein dritter Modus „Direct Lake“ eingeführt. Hier müssen die Daten gezwungenermaßen in Fabric liegen, aber im Gegenzug müssen die Power BI DataSets die Daten gar nicht mehr selbst laden, sondern existieren nur noch virtuell. Technisch gesehen sind die DataSets bzw semantischen Modelle dann eine In-Memory-Engine, die ihre Daten erst zur Laufzeit aus der Quelle holt, und sie dann solange zwischenspeichert bis sie über den Caching-Algorithmus wieder entfernt werden. Dadurch entfällt der Ladeprozess für die DataSets! Hier eine Veranschaulichung von mir, die den Einspareffekt zeigt:
In diesem Beispiel habe ich 9 Tabellen, aus denen 3 verschiedene DataSets werden. In der alten Power BI-Welt (Import-Modus) müsste ich für jedes DataSet die dazugehörigen Daten einmal laden, und käme damit insgesamt auf 17 Ladeprozesse. In der neuen Welt (Direct Lake) reicht es, wenn jede Tabelle nur einmal geladen wird. Somit spare ich mir 8 Ladeprozesse ein. Gleichzeitig heißt das jedoch, dass manche Daten davon „kalt“ sind, und erst aufgewärmt werden müssen. Deshalb empfiehlt Patrick, DAX-Statements über sempy in ein Notebook als letzten Schritt einer Pipeline einzubauen, die Montagsmorgens realistische Abfragen simulieren, um den Cache aufzuwärmen.
In general, data preparation should be performed as far upstream as possible
Danke, Adam, für die Unterstützung. Anreicherungen und Transformationen von Daten sollten so weit hinten im Backend wie nur möglich erfolgen. Auf die Frage „Who uses calculated columns“ hat sich zum Glück im Raum niemand gemeldet, denn Power BI-Reports sind nicht dazu da, Daten zu säubern oder um Kategorien anzureichern. Wann immer möglich, sollte man das im SQL machen bzw im Ladeprozess, der Power BI vorgelagert ist. Dann ist es auch wiederverwendbar. Anreicherungen haben im Report nichts zu suchen, auch wenn viele Anfänger das tun.
Adam, put us asleep with security….
Allgemein lässt sich sagen, dass Fabric ISO 27001-zertifiziert ist, und somit hohen Datenschutzanforderungen entspricht. Die Microsoft-Cloud ist ein Hochsicherheitstrakt, mit dem sich mittelständische Unternehmen nicht messen können. Entra ID (= Azure Active Directory) wird in Fabric genauso verwendet wie in Power BI. TLS-Verschlüsselung 1.2 ist in allen Verbindungen aktiviert.
Da wir viele verschiedene Objekte in Fabric haben, gibt es auch verschiedene Security-Ebenen, von denen manche sogar noch in Entwicklung sind (Preview):
- Workspace Security: Ich kann einem Benutzer für einen Arbeitsbereich eine bestimmte Rolle zuweisen, z.B. Viewer, Contributor oder Admin. Viewer können darin tatsächlich nur Power BI-Reports sehen, und keine sonstigen Fabric-Elemente. Contributors und Admins hingegen sehen auch alle Fabric-Elemente.
- Row-level security für semantische Modelle: Wie in Power BI auch, kann ich pro semantischem Modell Rollen einführen, deren Sichtbarkeit ich auf Elemente einer Dimension beschränke (z.B. Kundengruppe).
- Row-level security für Tabellen: Da ich in Fabric auch SQL Endpoints an Benutzer bereitstellen kann, kann ich diese Tabellen so vorfiltern, dass der Benutzer in SQL nur die für ihn relevanten Daten abfragen kann. Das geht jedoch nur, wenn das Filterkriterium tatsächlich in dieser einen Tabelle vorhanden ist, und nicht in einer anderen Tabelle. Ich erinnere mich an ein Projekt, wo wir das in SQL Server 2012 bereits benutzt hatten – gleiche Syntax, gleicher Effekt. Habe ich jedoch für DWH typische Faktentabellen, dann ist mein Filterkriterium meist nicht mehr in der Tabelle selbst. Ein weiterer Nachteil ist, dass der Direct Lake-Modus nicht kombinierbar ist mit diesen Filterkriterien, und somit als Fallback immer auf das langsamere DirectQuery zurückgegriffen wird.
ADD FILTER PREDICATE Security.tvf_securitypredicate(SalesRep)
- Object-level security für Spalten in SQL: Für einen SQL-Endpoint, den ich einem Benutzer bereitstelle, kann ich angeben, welche Spalten er sehen darf, und welche nicht. Das geht ganz einfach so:
GRANT SELECT ON InternetSales(Column1, Column2 ….) DENY SELECT ON InternetSales(Column3)
- Object-level security für Tabellen: Wie in SQL Server auch, kann ich Rollen definieren, die entweder auf ein Schema oder auf ausgewählte Datenbankobjekte wie Tabellen / Views / Stored Procedures Rechte auf verschiedenen Ebenen bekommen (Read / Write / Alter / Execute etc). Diesen Rollen kann ich dann Benutzer zuordnen. Anzumerken ist jedoch, dass dieser Teil noch in der Preview-Phase ist. Die Berechtigung für sonstige Dateien (z.B. Bilder, Audiodateien) scheint zudem auch noch nicht so granular möglich zu sein.
