Share via

Microsoft Fabric-Entscheidungsleitfaden: Auswählen eines Datenspeichers

  • Artikel

Verwenden Sie diesen Referenzleitfaden und die Beispielszenarien, um zu ermitteln, ob Sie einen Datenspeicher für Ihre Microsoft Fabric-Workloads nutzen sollten.

Datenspeichereigenschaften

Data Warehouse Lakehouse Power BI Datamart KQL-Datenbank (Eventhouse)
Datenvolumen Unbegrenzt Unbegrenzt Bis zu 100 GB Unbegrenzt
Datentyp Strukturiert Unstrukturiert, teilweise strukturiert, strukturiert Strukturiert Unstrukturiert, teilweise strukturiert, strukturiert
Primäre* Entwickler*innen Data Warehouse-Entwickler*innen, SQL-Techniker*innen Technische Fachkräfte für Daten, wissenschaftliche Fachkräfte für Daten Citizen Developers Citizen Data Scientists, technische Fachkräfte für Daten, wissenschaftliche Fachkräfte für Daten, SQL-Expert*innen
Kenntnisse der primären Entwickler*innen SQL Spark (Scala, PySpark, Spark SQL, R) Kein Code, SQL Kein Code, KQL, SQL
Daten organisiert nach Datenbanken, Schemas und Tabellen Ordner und Dateien, Datenbanken und Tabellen Datenbank, Tabellen, Abfragen Datenbanken, Schemas und Tabellen
Dient zum Lesen von Vorgängen. T-SQL, Spark (unterstützt das Lesen von Tabellen mithilfe von Verknüpfungen, unterstützt jedoch noch nicht den Zugriff auf Ansichten, gespeicherte Prozeduren, Funktionen usw.). Spark, T-SQL Spark, T-SQL, Power BI KQL, T-SQL, Spark, Power BI
Schreibvorgänge T-SQL Spark (Scala, PySpark, Spark SQL, R) Dataflow, T-SQL KQL, Spark, Connector-Ökosystem
Transaktionen mit mehreren Tabellen Ja Nr. Nein Ja, für die Erfassung mit mehreren Tabellen. Weitere Informationen finden Sie in der Aktualisierungsrichtlinie.
Primäre Entwicklungsschnittstelle SQL-Skripts Spark-Notebooks, Spark-Auftragsdefinitionen Power BI KQL-Abfrageset, KQL-Datenbank
Security Objektebene (Tabelle, Ansicht, Funktion, gespeicherte Prozedur usw.), Spaltenebene, Zeilenebene, DDL/DML, dynamische Datenmaskierung Zeilenebene, Tabellenebene (bei Verwendung von T-SQL), keine für Spark Integrierter RLS-Editor Sicherheit auf Zeilenebene
Zugreifen auf Daten über Verknüpfungen Ja (indirekt über das Lakehouse) Ja Keine Ja
Kann eine Quelle für Verknüpfungen sein Ja (Tabellen) Ja (Dateien und Tabellen) Nein Ja
Elementübergreifende Abfragen Ja, Abfragen in Lakehouse- und Warehouse-Tabellen Ja, Abfragen in Lakehouse- und Warehouse-Tabellen, Abfragen in Lakehouses (einschließlich Verknüpfungen mithilfe von Spark) Nein Ja, Abfragen in KQL-Datenbanken, Lakehouses und Warehouses mit Verknüpfungen
Erweiterte Analyse Native Zeitreihenelemente, vollständige Geospeicherung und Abfragefunktionen
Unterstützung für erweiterte Formatierung Vollständige Indizierung für Freitext und teilweise strukturierte Daten wie JSON
Erfassungslatenz Erfassung in Warteschlangen, Streamingerfassung mit einer Latenz von einigen Sekunden

Hinweis

Eventhouse ist ein Arbeitsbereich für mehrere KQL-Datenbanken. KQL-Datenbank ist allgemein verfügbar, während Eventhouse in der Vorschau ist. Weitere Informationen finden Sie unter Eventhouse -Übersicht (Vorschau).

Szenarien

Überprüfen Sie diese Szenarien, um die Auswahl eines Datenspeichers in Fabric zu erleichtern.

Szenario 1

Susan ist eine professionelle Entwicklerin und neu bei Microsoft Fabric. Sie kann mit dem Bereinigen, Modellieren und Analysieren von Daten beginnen, muss sich jedoch entscheiden, ob sie ein Data Warehouse oder ein Lakehouse erstellt. Nach der Überprüfung der Details in der vorherigen Tabelle sind die wichtigsten Entscheidungspunkte die Qualifikationen und die Notwendigkeit von Transaktionen mit mehreren Tabellen.

Susan hat jahrelange Erfahrung im Erstellen von Data Warehouses für relationale Datenbank-Engines und ist mit der SQL-Syntax und -Funktionalität vertraut. Im Hinblick auf das Gesamtteam sind die Personen, die die Daten hauptsächlich verwenden, auch mit SQL und SQL-Analysetools vertraut. Sie entscheidet sich für die Verwendung eines Data Warehouse, das es dem Team ermöglicht, hauptsächlich mit T-SQL zu interagieren. Zudem können alle Spark-Benutzer*innen in der Organisation auf die Daten zugreifen.

Szenario 2

Rob ist eine technische Fachkraft für Daten und muss mehrere Terabyte an Daten in Fabric speichern und modellieren. Sein Team kann PySpark- und T-SQL-Kenntnisse vorweisen. Die meisten Personen im Team, die T-SQL-Abfragen ausführen, verwenden die Daten nur und müssen daher keine INSERT-, UPDATE- oder DELETE-Anweisungen schreiben. Die restlichen Entwickler*innen sind mit der Arbeit in Notebooks vertraut. Da die Daten in Delta gespeichert sind, können sie mit einer ähnlichen SQL-Syntax interagieren.

Rob beschließt, ein Lakehouse zu verwenden. Auf diese Weise kann das Datentechnikteam die vielfältigen Fähigkeiten für die Daten nutzen, während die Teammitglieder mit umfassenden T-SQL-Kenntnissen die Daten verwenden können.

Szenario 3

Ash ist Citizen Developer und Power BI-Entwickler. Er ist mit Excel, Power BI und Office vertraut. Seine Aufgabe besteht darin, ein Datenprodukt für eine Geschäftseinheit zu entwickeln. Er weiß, dass er nicht über die erforderlichen Kenntnisse zum Erstellen eines Data Warehouse oder Lakehouse verfügt. Außerdem scheinen diese Lösungen hinsichtlich der Anforderungen und Datenvolumen nicht geeignet zu sein. Nach Überprüfung der Details in der obigen Tabelle stellt er fest deutlich, dass die eigenen Kenntnisse, die Notwendigkeit eines Self-Service-Ansatzes sowie No-Code-Kenntnisse und Datenvolumen unter 100 GB zu den wichtigsten Entscheidungspunkten zählen.

Ash arbeitet mit Business Analysts zusammen, die mit Power BI und Microsoft Office vertraut sind und bereits über ein Premium-Kapazitätsabonnement verfügen. Im Hinblick auf das gesamte Team wird deutlich, dass hauptsächlich Analyst*innen die Daten verwenden werden, die mit No-Code-Tools und SQL-Analysetools vertraut sind. Seine Wahl fällt auf Data Marts in Power BI, mit denen das Team unter Verwendung einer No-Code-Umgebung das Produkt schnell entwickeln kann. Abfragen können über Power BI und T-SQL ausgeführt werden. Gleichzeitig können auch alle Spark-Benutzer*innen in der Organisation auf die Daten zugreifen.

Szenario 4

Daisy ist Business Analystin und hat Erfahrung in der Verwendung von Power BI zum Analysieren von Lieferkettenengpässen in einer großen globalen Einzelhandelskette. Sie muss eine skalierbare Datenlösung erstellen, die Milliarden von Datenzeilen verarbeiten und zum Erstellen von Dashboards und Berichten verwendet werden kann, die bei Geschäftsentscheidungen helfen sollen. Die Daten stammen von Werken, Lieferanten, Speditionen und anderen Quellen in verschiedenen strukturierten, teilweise strukturierten und unstrukturierten Formaten.

Daisy entscheidet sich für eine KQL-Datenbank aufgrund ihrer Skalierbarkeit, der schnellen Antwortzeiten, der fortschrittlichen Analysemöglichkeiten einschließlich Zeitreihenanalyse, der Geodatenfunktionen und des schnellen direkten Abfragemodus in Power BI. Abfragen können mit Power BI und KQL ausgeführt werden, um aktuelle und frühere Zeiträume zu vergleichen, neue Probleme schnell zu identifizieren oder Geoanalysen von Land- und Seerouten bereitzustellen.

Zugehöriger Inhalt