Microsoft Fabric-Entscheidungsleitfaden: Auswählen eines Datenspeichers
Verwenden Sie diesen Referenzleitfaden und die Beispielszenarien, um zu ermitteln, ob Sie einen Datenspeicher für Ihre Microsoft Fabric-Workloads nutzen sollten.
Datenspeichereigenschaften
Diese Tabelle vergleicht Datenspeicher wie Warehouse, Lakehouse, Power BI Datamart und Eventhouse auf der Grundlage von Datenvolumen, Typ, Entwickler-Persona, Fähigkeiten, Operation. und sonstige Funktionen.
| Lagerort | Lakehouse | Power BI Datamart | 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, Spaltenebene (für Lakehouse, auf das über einen SQL-Analytics-Endpunkt zugegriffen wird), Tabellenebene (bei Verwendung von T-SQL), keine für Spark | Integrierter RLS-Editor | Sicherheit auf Zeilenebene |
| Zugreifen auf Daten über Verknüpfungen | Ja, durch ein Lakehouse mit dreiteiligen Namen | 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) | No | Ja, Abfragen in KQL-Datenbanken, Lakehouses und Warehouses mit Verknüpfungen |
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.
Susan erstellt ein neues Lakehouse und greift auf die Data Warehouse-Funktionen mit dem Lakehouse-SQL-Analyseendpunkt zu. Mithilfe des Fabric-Portals werden Verknüpfungen zu den externen Datentabellen erstellt und im /Tables-Ordner platziert. Susan kann jetzt T-SQL-Abfragen schreiben, die auf Verknüpfungen zum Abfragen von Delta Lake-Daten im Lakehouse verweisen. Die Verknüpfungen werden im SQL-Analyseendpunkt automatisch als Tabellen angezeigt und können mit T-SQL mithilfe von dreiteiligen Namen abgefragt werden.
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 Eventhouse 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.