Speichermöglichkeiten in Fabric

c

Sie haben beschlossen, Fabric ist das Richtige für Sie. Aber nun wissen Sie nicht, wie Sie anfangen wollen? Welche Speichermöglichkeiten gibt es in Fabric? Sollen die Daten jetzt in ein Warehouse oder in ein Lakehouse? Und was ist dieses Eventhouse oder ein Datamart?

Klar, um anfangen zu können müssen Sie erst einmal verstehen, wie Sie Ihre Daten speichern wollen. Dabei kommt es allerdings nicht nur auf Ihre Daten an, sondern besonders auch auf Ihr Team. Denn auch Ihr Team hat besondere Fähigkeiten, die bei der Auswahl der richtigen Technologie nicht Außen vor gelassen werden sollten. Vorweg genommen sind die beiden wahrscheinlichsten Fälle für Ihre Anwendung entweder das Lakehouse oder das Warehouse, als Speichermöglichkeiten in Fabric.

Zuerst sollten wir aber einmal geklärt haben, was eigentlich was ist. Alle vier Möglichkeiten sind Architekturentscheidungen. Grundlegend speichern all diese Optionen die Daten in unterschiedlicher Weise organisiert im OneLake. Das heißt am Ende ist alles in Microsoft Fabric und alles ist nur auf unterschiedliche Art strukturiert am selben Ort.

Da wir nun geklärt haben, dass alles erstmal nur Datenspeichermöglichkeiten sind müssen wir nun natürlich klären: „Warum sollte ich mich für eins entscheiden, wenn am Ende alles am selben Ort ist?“ Die Antwort darauf ist, dass die einzelnen Architekturen unterschiedliche Vorteile für unterschiedliche Anwendungsbereiche bieten. Die beiden einfachsten Fälle zuerst. Ein Eventhouse hat einen klaren Fokus auf Streamingdaten. Das heißt, wenn Sie dauerhaft Daten erhalten von z.B. IoT Geräten dann ist ein Eventhouse das Richtige. Andere Beispiele sind Zeitreihen und Finanzdaten oder auch Telemetrie und Protokolldaten. Dabei können die Daten mit KQL und SQL verwaltet werden und sind auch mit Power BI abrufbar. Die Verwendung vom Eventhouse ermöglicht auch unbegrenzt große Datenmengen.

Die zweite schnell erklärte Architektur ist der Power BI Datamart. Hier handelt es sich um einen Spezialfall. Ein Power BI Datamart ist für Power BI Berichte gedacht und ist keine allgemeine Datenspeicherung für alle Anwendungen. Deshalb ist der Power BI Datamart auch auf 100 GB begrenzt. Für die Bearbeitung des Datamarts sind dabei auch vor allem No Code und SQL Kenntnisse wichtig. Der Datamart in dieser Form ist für Power BI Entwickler gedacht, die eine größere Menge an Daten speichern und bearbeiten wollen. Das Ziel ist es Daten für Power BI bereitzustellen.

Damit sind wir auch schon bei den beiden letzten Architekturen angekommen. Das Warehouse ist die klassische SQL Lösung, dabei werden nur strukturierte Daten verarbeitet. Die Organisation erfolgt mit Hilfe von Schemata und Tabellen. Dabei ist die Hauptsprache ganz klar T-SQL. Außerdem ist ein Warehouse auch für alle Datenmengen vorgesehen, sodass es hier keine Obergrenze gibt.

Ähnliches gilt auch für das Lakehouse auch hier gibt es keine Obergrenze. Die wichtigsten Unterschiede sind, dass andere Fähigkeiten wichtig sind und dass nicht nur strukturierte Daten gespeichert werden können. Im Lakehouse werden unstrukturierte, semistrukturierte und strukturierte Daten aufbewahrt. Dabei werden die Daten in Ordnern und Dateien gespeichert. Ebenso kann man Daten auch in Tabellen organisieren, wie in einem Warehouse. Das Lakehouse ist damit flexibler, was aber nicht notwendigerweise besser ist. Ein weiterer wichtiger Unterschied ist, dass die Entwicklung mit Spark stattfindet. Was genau Spark ist, ist hier erstmal nicht relevant. Wichtig ist nur, dass die Entwickler hier mit Scala, Python (PySpark), SQL (Spark SQL) und R arbeiten. Wenn Ihr Team schon Erfahrung mit diesen Sprachen hat, können Sie hierbei schneller Erfolge erzielen.

Natürlich gibt es noch weitere Details, aber dieser Beitrag soll einen Überblick über die wichtigsten Unterschiede von verschiedenen Speichermöglichkeiten in Fabric geben. Zusammengefasst lässt sich sagen, dass die richtige Wahl vor allem vom Team und den Anforderungen abhängt. Jede Architektur hat ihre Berechtigung, nur ist nicht jede immer geeignet.

Wenn Sie weitere Hilfe brauchen, lesen Sie doch den Artikel Lakehouse vs. Warehouse oder kontaktieren Sie uns und lassen sich beraten. Wir bauen seit über einem Jahrzehnt Datenarchitekturen und können auf viele erfolgreiche Projekte zurückblicken.