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
Verwenden Sie diese Informationen, um Fabric-Datenspeicher wie Warehouse, 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:
| Lakehouse | Lagerort | Eventhouse | |
|---|---|---|---|
| Datenvolumen | Unbegrenzt | Unbegrenzt | Unbegrenzt |
| Datentyp | Unstrukturiert, Teilweise strukturiert, Strukturiert |
Strukturiert | Unstrukturiert, Teilweise strukturiert, Strukturiert |
| Primäre* Entwickler*innen | Technische Fachkräfte für Daten, wissenschaftliche Fachkräfte für Daten | Data Warehouse-Entwickler, Datenarchitekt, 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 |
| Dient zum Lesen von Vorgängen. | 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 | No | Ja | Ja, für die Erfassung mit mehreren Tabellen |
| Primäre Entwicklungsschnittstelle | Spark-Notebooks, Spark-Auftragsdefinitionen | SQL-Skripts | KQL-Abfrageset, KQL-Datenbank |
| Security | 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 | Ja |
| Kann eine Quelle für Verknüpfungen sein | Ja (Dateien und Tabellen) | Ja (Tabellen) | Ja |
| Elementübergreifende Abfragen | Ja | Ja | Ja |
| Erweiterte Analyse | 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 geo-räumliche und Abfragefunktionen |
| Unterstützung für erweiterte Formatierung | Tabellen, die mit PARQUET, CSV, AVRO, JSON und einem beliebigen Apache Hive-kompatiblen Dateiformat definiert wurden | Tabellen, die mit PARQUET, CSV, AVRO, JSON und einem beliebigen Apache Hive-kompatiblen Dateiformat definiert wurden | Vollständige Indizierung für Freitext und teilweise strukturierte Daten wie JSON |
| Erfassungslatenz | 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.
| Fabric SQL-Datenbank | Power BI Datamart | |
|---|---|---|
| Datenvolumen | 4 TB | Bis zu 100 GB |
| Datentyp | Strukturiert, Teilweise strukturiert, Unstrukturiert |
Strukturiert |
| Primäre* Entwickler*innen | KI-Entwickler, App-Entwickler, Datenbankentwickler, DB-Administrator | Datenwissenschaftler, Datenanalyst |
| Primäre Entwicklungskompetenz | SQL | Kein Code, SQL |
| Daten organisiert nach | Datenbanken, Schemas, Tabellen | Datenbank, Tabellen, Abfragen |
| Dient zum Lesen von Vorgängen. | T-SQL | Spark, T-SQL |
| Schreibvorgänge | T-SQL | Dataflow, T-SQL |
| Transaktionen mit mehreren Tabellen | Ja, vollständige ACID-Konformität | No |
| Primäre Entwicklungsschnittstelle | SQL-Skripts | Power BI |
| Security | Objektebene, RLS, CLS, DDL/DML, dynamische Datenmaske | Integrierter RLS-Editor |
| Zugreifen auf Daten über Verknüpfungen | Ja | No |
| Kann eine Quelle für Verknüpfungen sein | Ja (Tabellen) | No |
| Elementübergreifende Abfragen | Ja | No |
| Erweiterte Analyse | T-SQL-Analysefunktionen, Daten, die in Delta-Parkett in OneLake für Analysen repliziert wurden | Schnittstelle für die Datenverarbeitung mit automatisierter Leistungsoptimierung |
| Unterstützung für erweiterte Formatierung | Tabellenunterstützung für OLTP, JSON, Vektor, Graph, XML, räumlich, Schlüsselwert | Tabellen, die mit PARQUET, CSV, AVRO, JSON und einem beliebigen Apache Hive-kompatiblen Dateiformat definiert wurden |
| 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.
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 Fabric 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 mit dem SQL-Analyseendpunkt des Lakehouse auf die Data Warehouse-Funktionen 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.
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 Fabric mit 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. Die SQL-Datenbank in Fabric erstellt und löscht automatisch nicht gruppierte Indizes auf der Grundlage starker Signale aus Ausführungsplänen, die im Laufe der Zeit beobachtet wurden.
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 von analytischen Arbeitslasten und vermeiden eine 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 Datenpipelines mit Fabric Data Factory, um Daten in die Fabric SQL-Datenbank zu importieren.