Microsoft Fabric-Entscheidungsleitfaden: Auswählen eines Datenspeichers
Verwenden Sie dieses Referenzhandbuch und die Beispielszenarien, die Ihnen bei der Auswahl eines Datenspeichers für Ihre Microsoft Fabric-Workloads helfen.
Datenspeichereigenschaften
Verwenden Sie diese Informationen, um Fabric-Datenspeicher wie Lager, Lakehouse, Eventhouse, SQL-Datenbank und Power BI-Datenmart zu vergleichen, basierend auf Datenvolume, Typ, Entwicklerpersona, Fähigkeiten, Vorgängen und anderen Funktionen. Diese Vergleiche sind in den folgenden beiden Tabellen angeordnet:
| Tabelle 1 von 2 | Lakehouse | Lager | Eventhouse |
|---|---|---|---|
| Datenvolumen | Unbegrenzt | Unbegrenzt | Unbegrenzt |
| Datentyp | Unstrukturiert Teilweise strukturiert, Strukturiert |
Strukturiert, Teilweise strukturiert (JSON) |
Unstrukturiert Teilweise strukturiert, Strukturiert |
| Primäre Entwicklerpersona- | Dateningenieur, Datenwissenschaftler | Data Warehouse-Entwickler, Datenarchitekt, Dateningenieur, Datenbankentwickler | App-Entwickler, Datenwissenschaftler, Datentechniker |
| Primäre Entwicklungskompetenz | Spark (Scala, PySpark, Spark SQL, R) | SQL | Kein Code, KQL, SQL |
| Daten organisiert nach | Ordner und Dateien, Datenbanken und Tabellen | Datenbanken, Schemas und Tabellen | Datenbanken, Schemas und Tabellen |
| Lesevorgänge | Spark, T-SQL | T-SQL, Spark* | KQL, T-SQL, Spark |
| Schreibvorgänge | Spark (Scala, PySpark, Spark SQL, R) | T-SQL | KQL, Spark, Connector-Ökosystem |
| Transaktionen mit mehreren Tabellen | Nein | Ja | Ja, für die Erfassung mit mehreren Tabellen |
| Primäre Entwicklungsschnittstelle | Spark-Notizbücher, Spark-Auftragsdefinitionen | SQL-Skripts | KQL Queryset, KQL-Datenbank |
| Sicherheit | RLS, CLS**, Tabellenebene (T-SQL), keine für Spark | Objektebene, RLS, CLS, DDL/DML, dynamische Datenformatierung | RLS |
| Zugreifen auf Daten über Verknüpfungen | Ja | Ja, über den SQL-Analyseendpunkt | Ja |
| Kann eine Ursprungsquelle für Abkürzungen sein | Ja (Dateien und Tabellen) | Ja (Tabellen) | Ja |
| Elementübergreifende Abfragen | Ja | Ja | Ja |
| Erweiterte Analysen | Schnittstelle für umfangreiche Datenverarbeitung, integrierte Datenparallelität und Fehlertoleranz | Schnittstelle für umfangreiche Datenverarbeitung, integrierte Datenparallelität und Fehlertoleranz | Systemeigene Elemente der Zeitreihe, vollständige georäumliche und Abfragefunktionen |
| Erweiterte Formatierungsunterstützung | Tabellen, die mithilfe von PARQUET, CSV, AVRO, JSON und jedem kompatiblen Apache Hive-Dateiformat definiert sind | Tabellen, die mithilfe von PARQUET, CSV, AVRO, JSON und jedem kompatiblen Apache Hive-Dateiformat definiert sind | Vollständige Indizierung für Freitext und halbstrukturierte Daten wie JSON |
| Verzögerung bei der Aufnahme | Sofort verfügbar für Abfragen | Sofort verfügbar für Abfragen | Erfassung in Warteschlangen, Streamingerfassung mit einer Latenz von einigen Sekunden |
* Spark unterstützt das Lesen von Tabellen mithilfe von Tastenkombinationen, unterstützt den Zugriff auf Ansichten, gespeicherte Prozeduren, Funktionen usw. noch nicht.
| Tabelle 2 von 2 | Fabric SQL-Datenbank | Power BI Datamart |
|---|---|---|
| Datenvolumen | 4 TB | Bis zu 100 GB |
| Datentyp | Strukturiert, Teilweise strukturiert, unstrukturiert |
Strukturiert |
| Primäre Entwicklerpersona- | KI-Entwickler, App-Entwickler, Datenbankentwickler, DB-Administrator | Wissenschaftliche Fachkraft für Daten, Data Analyst |
| Primäre Entwicklungskompetenz | SQL | Kein Code, SQL |
| Daten geordnet nach | Datenbanken, Schemas, Tabellen | Datenbank, Tabellen, Abfragen |
| Lesevorgänge | T-SQL | Spark, T-SQL |
| Schreibvorgänge | T-SQL | Datenflüsse, T-SQL |
| Transaktionen mit mehreren Tabellen | Ja, vollständige ACID-Konformität | Nein |
| Primäre Entwicklungsschnittstelle | SQL-Skripts | Power BI |
| Sicherheit | Objektebene, RLS, CLS, DDL/DML, dynamische Datenmaske | Integrierter RLS-Editor |
| Zugreifen auf Daten über Verknüpfungen | Ja | Nein |
| Kann eine Abkürzungsquelle sein | Ja (Tabellen) | Nein |
| Elementübergreifende Abfragen | Ja | Nein |
| Erweiterte Analysen | T-SQL-Analysefunktionen, Daten, die in Delta-Parkett in OneLake für Analysen repliziert wurden | Schnittstelle für die Datenverarbeitung mit automatisierter Leistungsoptimierung |
| Erweiterte Formatierungsunterstützung | Tabellenunterstützung für OLTP, JSON, Vektor, Graph, XML, spatial, key-value | Tabellen, die mithilfe von PARQUET, CSV, AVRO, JSON und jedem kompatiblen Apache Hive-Dateiformat definiert sind |
| Erfassungslatenz | Sofort verfügbar für Abfragen | Sofort verfügbar für Abfragen |
** Sicherheit auf Spaltenebene, die über einen SQL-Analyseendpunkt über T-SQL im Lakehouse verfügbar ist.
Drehbücher
Überprüfen Sie diese Szenarien, um Hilfe bei der Auswahl eines Datenspeichers in Fabric zu erfahren.
Szenario 1
Susan, ein professioneller Entwickler, ist neu bei Microsoft Fabric. Sie sind bereit, mit der Reinigung, Modellierung und Analyse von Daten zu beginnen, müssen aber entscheiden, ein Data Warehouse oder ein Seehaus zu erstellen. Nach Überprüfung der Details in der vorherigen Tabelle sind die wichtigsten Entscheidungspunkte die verfügbaren Fähigkeiten und die Notwendigkeit von Transaktionen mit mehreren Tabellen.
Susan hat viele Jahre damit verbracht, Data Warehouses auf relationalen Datenbankmodulen zu erstellen und ist mit DER SQL-Syntax und -Funktionalität vertraut. Denken Sie an das größere Team, die primären Verbraucher dieser Daten sind auch mit SQL- und SQL-Analysetools vertraut. Susan entscheidet sich, ein Fabric Warehousezu verwenden, das es dem Team ermöglicht, hauptsächlich mit T-SQL zu interagieren, während alle Spark-Benutzer in der Organisation auf die Daten zugreifen können.
Susan erstellt ein neues Data Warehouse und interagiert mit T-SQL genau wie ihre anderen SQL Server-Datenbanken. Die meisten der vorhandenen T-SQL-Code, den sie zum Erstellen ihres Warehouses auf SQL Server geschrieben hat, arbeitet am Fabric Data Warehouse und erleichtert den Übergang. Wenn sie sich dafür entscheidet, kann sie sogar dieselben Tools wie SQL Server Management Studio verwenden, die mit ihren anderen Datenbanken arbeiten. Mit dem SQL-Editor im Fabric-Portal schreiben Susan und andere Teammitglieder Analyseabfragen, die auf andere Data Warehouses und Delta-Tabellen in Lakehouses verweisen, indem sie einfach dreiteilige Namen verwenden, um datenbankübergreifende Abfragen auszuführen.
Szenario 2
Rob, ein Datentechniker, muss mehrere Terabyte Daten in Fabric speichern und modellieren. Das Team verfügt über eine Mischung aus PySpark- und T-SQL-Fähigkeiten. Die meisten Mitglieder des Teams, das T-SQL-Abfragen ausführt, sind Nutzer und müssen daher keine INSERT-, UPDATE- oder DELETE-Anweisungen schreiben. Die restlichen Entwickler arbeiten bequem in Notizbüchern, und 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, ein Bürgerentwickler, ist ein Power BI-Entwickler. Sie sind mit Excel, Power BI und Office vertraut. Sie müssen ein Datenprodukt für eine Geschäftseinheit erstellen. Sie wissen, dass sie nicht ganz über die Fähigkeiten verfügen, ein Data Warehouse oder ein Lakehouse zu erstellen, und diese scheinen zu viel für ihre Bedürfnisse und ihr Datenvolumen zu sein. Sie überprüfen die Details in der vorherigen Tabelle und sehen, dass die wichtigsten Entscheidungspunkte ihre eigenen Fähigkeiten und ihre Notwendigkeit für einen Self-Service, keine Codefunktion und Datenvolumen unter 100 GB sind.
Ash arbeitet mit Geschäftsanalysten zusammen, die mit Power BI und Microsoft Office vertraut sind und wissen, dass sie bereits über ein Premium-Kapazitätsabonnement verfügen. Wenn sie über ihr größeres Team nachdenken, erkennen sie, dass die primären Verbraucher dieser Daten Analysten sind, die mit No-Code- und SQL-Analysetools vertraut sind. Ash entscheidet sich für 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, während alle Spark-Benutzer in der Organisation auch auf die Daten zugreifen können.
Szenario 4
Daisy ist eine erfahrene Business Analystin, die Power BI nutzt, um Engpässe in der Lieferkette für eine große globale Einzelhandelskette zu analysieren. Sie müssen eine skalierbare Datenlösung erstellen, die Milliarden von Datenzeilen verarbeiten kann und zum Erstellen von Dashboards und Berichten verwendet werden kann, die zum Treffen von Geschäftsentscheidungen verwendet werden können. Die Daten stammen aus Anlagen, Lieferanten, Versandfirmen und anderen Quellen in verschiedenen strukturierten, halbstrukturierten und unstrukturierten Formaten.
Daisy entscheidet sich, Eventhouse aufgrund seiner Skalierbarkeit, schnellen Reaktionszeiten, erweiterten Analysefunktionen, einschließlich Zeitreihenanalysen und Geospatialfunktionen, sowie des schnellen Modus für direkte Abfragen in Power BI zu verwenden. Abfragen können mithilfe von Power BI und KQL ausgeführt werden, um zwischen aktuellen und vorherigen Zeiträumen zu vergleichen, neue Probleme schnell zu identifizieren oder geo-räumliche Analysen von Land- und Seerouten bereitzustellen.
Szenario 5
Kirby ist ein Anwendungsarchitekt, der in der Entwicklung von .NET-Anwendungen für Betriebsdaten erfahren hat. Sie benötigen eine hohe Parallelitätsdatenbank mit vollständiger ACID-Transaktionscompliance und stark erzwungenen Fremdschlüsseln für relationale Integrität. Kirby möchte den Vorteil der automatischen Leistungsoptimierung nutzen, um die tägliche Datenbankverwaltung zu vereinfachen.
Kirby entscheidet sich für eine SQL-Datenbank in Fabricmit demselben SQL-Datenbankmodul wie Azure SQL Database. SQL-Datenbanken in Fabric werden automatisch skaliert, um den Bedarf während des gesamten Arbeitstags zu erfüllen. Sie verfügen über die volle Funktionalität von Transaktionstabellen und die Flexibilität der Transaktionsisolationsstufen von serialisierbar bis zum Lesen von zugesicherten Momentaufnahmen. SQL-Datenbank in Fabric erstellt und löscht nicht gruppierte Indizes automatisch basierend auf starken Signalen von im Laufe der Zeit beobachteten Ausführungsplänen.
In Kirbys Szenario müssen Daten aus der operativen Anwendung mit anderen Daten in Fabric verknüpft werden: in Spark, in einem Lager und aus Echtzeitereignissen in einem Eventhouse. Jede Fabric-Datenbank enthält einen SQL-Analyseendpunkt, sodass daten über Spark oder mit Power BI-Abfragen im DirectLake-Modus in Echtzeit aufgerufen werden können. Diese Berichterstellungslösungen entlasten die primäre operative Datenbank vom Aufwand analytischer Workloads und vermeiden Denormalisierung. Kirby verfügt auch über vorhandene Betriebsdaten in anderen SQL-Datenbanken und muss diese Daten ohne Transformation importieren. Um vorhandene Betriebsdaten ohne Datentypkonvertierung zu importieren, erstellt Kirby Datenpipelinen mit Fabric Data Factory, um Daten in die Fabric SQL-Datenbank zu importieren.