Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Nutzen Sie diese Referenzanleitung und die Beispielszenarien, um Ihnen bei der Auswahl eines Datenspeichers für Ihre Microsoft Fabric-Workloads zu helfen. Alle Datenspeicher sind im einheitlichen Speicherbereich von OneLake verfügbar.
Das Diagramm zeigt einen Entscheidungsleitfaden für die Auswahl eines Fabric Datenspeichers. Verwenden Sie für Streamingereignisdaten und interaktive Analysen mit hoher Granularität ein Eventhouse. Für NoSQL-Datenbanken verwenden Sie Cosmos DB in Fabric. Verwenden Sie für operationale Transaktionsarbeitslasten (OLTP) die SQL-Datenbank in Fabric. Um KI mit Vektordatentypen zu entwickeln, verwenden Sie SQL-Datenbanken in Fabric oder Cosmos DB in Fabric. Für Enterprise Data Warehousing, SQL-basiertes BI, OLAP und vollständige SQL-Transaktionsunterstützung nutzen Sie Fabric Data Warehouse. Für Big Data und maschinelles Lernen mit unstrukturierten, semistrukturierten oder strukturierten Daten sowie Data Engineering verwenden Sie ein Lakehouse. Alle Fabric-Datenspeicher sind standardmäßig in OneLake im offenen Tabellenformat verfügbar.
| Idealer Anwendungsfall | Microsoft Fabric-Workload | In OneLake standardmäßig verfügbare Daten im offenen Tabellenformat |
|---|---|---|
| Streamingereignisdaten, hohe Granularität (in Zeit, Raum, Detail – JSON/Text)-Aktivitätsdaten für interaktive Analysen | Eventhouse | Auf Wunsch verfügbar |
| NoSQL-Datenbank | Cosmos DB in Fabric | Ja |
| Operative transaktionale, OLTP- oder normalisierte Datenbank | SQL-Datenbank in Fabric | Ja |
| Entwicklung von KI mit Vektordatentypen | SQL-Datenbank in Fabric oder Cosmos DB in Fabric | Ja |
| Enterprise Data Warehouse, SQL-basiertes BI, OLAP, vollständige SQL-Transaktionsunterstützung und KI-Funktionen (Vorschau) | Datenlager | Ja |
| Big Data und maschinelles Lernen, unstrukturiertes, halbstrukturiertes oder strukturiertes Daten , Data Engineering | Lakehouse | Ja |
- Verwenden Sie für Streamingereignisdaten und interaktive Analysen mit hoher Granularität ein Eventhouse.
- Für NoSQL-Datenbanken verwenden Sie Cosmos DB in Fabric.
- Für betriebsbezogene, transaktionale, OLTP-Workloads oder normalisierte relationale Datenbanken verwenden Sie SQL-Datenbanken in Fabric.
- Um KI mit Vektordatentypen zu entwickeln, verwenden Sie SQL-Datenbanken in Fabric oder Cosmos DB in Fabric.
- Für Enterprise Data Warehousing, SQL-basiertes BI, OLAP und vollständige SQL-Transaktionsunterstützung nutzen Sie Fabric Data Warehouse.
- Für Big Data und maschinelles Lernen mit unstrukturierten, semistrukturierten oder strukturierten Daten sowie Data Engineering verwenden Sie ein Lakehouse.
- Alle Fabric-Datenspeicher sind standardmäßig in OneLake im offenen Tabellenformat verfügbar, mit Ausnahme einer KQL-Datenbank in einem Eventhouse, wo die Verfügbarkeit von OneLake als Opt-in-Funktion verfügbar ist.
Personas und Fähigkeiten
| Microsoft Fabric-Workload | Primäre Entwicklerpersonas | Primäre Fähigkeiten, Werkzeuge | Primäre Sprachen |
|---|---|---|---|
| Eventhouse | App-Entwickler, Data Scientist, Data Engineer | Kein Code, KQL, SQL | KQL (Kusto-Abfragesprache), T-SQL |
| Cosmos DB in Fabric | KI-Entwickler, App-Entwickler | NoSQL-Konzepte, REST-APIs, ähnlich wie Azure Cosmos DB | REST-API-Integration über JavaScript/TypeScript, Python, C#, Java und andere |
| SQL-Datenbank in Fabric | KI-Entwickler, App-Entwickler, Datenbankentwickler, Datenbankadministrator | Datenbankverwaltung und -entwicklung, ähnlich wie Azure SQL-Datenbank, SSMS, VS Code und SQL Server-kompatible Abfragetools | T-SQL |
| Fabric Data Warehouse | Data Warehouse-Entwickler, Data Architect, Data Engineer, Datenbankentwickler | Data Warehouse-Konzepte, Star-Schemadatenbankdesign, SSMS, VS Code und SQL Server-kompatible Abfragetools | T-SQL, Kein Code |
| Lakehouse | Dateningenieur, Datenwissenschaftler | PySpark, Delta Lake, Notizbücher | Spark (Scala, PySpark, Spark SQL, R) |
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 dem Reinigen, Modellieren und Analysieren von Daten zu beginnen, müssen sich aber entscheiden, ob sie ein Data Warehouse oder ein Seehaus bauen wollen. Nach Prüfung der Details in der vorstehenden Tabelle sind die wichtigsten Entscheidungskriterien die verfügbaren Fachkenntnisse und der Bedarf an tabellenübergreifenden Transaktionen.
Susan hat viele Jahre damit verbracht, Data Warehouses auf relationalen Datenbank-Engines aufzubauen und ist mit 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. Der Großteil des vorhandenen T-SQL-Codes, den sie geschrieben hat, um ihr Warehouse auf SQL Server aufzubauen, funktioniert in Fabric Data Warehouse, was den Übergang erleichtert. Wenn sie sich dafür entscheidet, kann sie sogar dieselben Tools wie SQL Server Management Studio verwenden, die mit ihren anderen Datenbanken arbeiten. Durch die Nutzung des SQL-Editors im Fabric-Portal schreiben Susan und andere Teammitglieder analytische Abfragen, die auf andere Data Warehouses und Delta-Tabellen in Lakehouses verweisen, indem sie einfach dreiteilige Namen verwenden, um datenbankübergreifende Abfragen durchzufü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 Teammitglieder, die T-SQL-Abfragen ausführen, sind Anwender und müssen daher keine UPDATE, DELETE oder INSERT-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
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. Sie kann Abfragen mithilfe von Power BI und KQL durchführen, um aktuelle und frühere Perioden zu vergleichen, aufkommende Probleme schnell zu identifizieren oder georäumliche Analysen von Land- und Seerouten bereitzustellen.
Szenario 4
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-Datenbank. 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, entwirft Kirby Pipelines mit Fabric Data Factory, um Daten in die Fabric SQL-Datenbank zu importieren.