Microsoft Fabric-Entscheidungsleitfaden: Data Warehouse oder Lakehouse
Verwenden Sie diesen Referenzleitfaden und die Beispielszenarien, um die Auswahl zwischen dem Data Warehouse oder einem Lakehouse für Ihre Workloads mit Microsoft Fabric zu unterstützen.
Wichtig
Microsoft Fabric befindet sich derzeit in der VORSCHAU. Diese Informationen beziehen sich auf eine Vorabversion des Produkts, an der vor der Veröffentlichung noch wesentliche Änderungen vorgenommen werden können. Microsoft übernimmt keine Garantie, weder ausdrücklich noch stillschweigend, für die hier bereitgestellten Informationen.
Data Warehouse- und Lakehouse-Eigenschaften
| Data Warehouse | Lakehouse | Power BI-Datamart | |
|---|---|---|---|
| Datenvolumen | Unbegrenzt | Unbegrenzt | Bis zu 100 GB |
| Datentyp | Strukturiert | Unstrukturierte semistrukturiert, Strukturiert |
Strukturiert |
| Primäre Entwicklerpersona | Data Warehouse-Entwickler, SQL-Techniker |
Datentechniker, Data Scientist |
Citizen Developer |
| Primärer Entwicklerqualifikationssatz | SQL | Spark (Scala, PySpark, Spark SQL, R) |
Kein Code, SQL |
| Daten organisiert nach | Datenbanken, Schemas und Tabellen | Ordner und Dateien, Datenbanken und Tabellen |
Datenbank, Tabellen, Abfragen |
| Dient zum Lesen von Vorgängen. | Funken T-SQL |
Funken T-SQL |
Funken T-SQL, Power BI |
| Schreibvorgänge | T-SQL | Spark (Scala, PySpark, Spark SQL, R) |
Dataflows, T-SQL |
| Transaktionen mit mehreren Tabellen | Ja | Nein | No |
| Primäre Entwicklungsschnittstelle | SQL-Skripts | Spark-Notebooks, Spark-Auftragsdefinitionen |
Power BI |
| Security | Objektebene (Tabelle, Ansicht, Funktion, gespeicherte Prozedur usw.), Spaltenebene, Zeilenebene, DDL/DML |
Zeilenebene, Tabellenebene (bei Verwendung von T-SQL), keine für Spark |
Integrierter RLS-Editor |
| Zugreifen auf Daten über Tastenkombinationen | Ja (indirekt durch das Lakehouse) | Ja | Nein |
| Kann eine Quelle für Tastenkombinationen sein | Ja (Tabellen) | Ja (Dateien und Tabellen) | No |
| Elementübergreifende Abfragen | Ja, Abfragen in Lakehouse- und Warehousetabellen | Ja, Abfragen in Lakehouse- und Lagertabellen; Abfrage zwischen Lakehouses (einschließlich Tastenkombinationen mithilfe von Spark) |
No |
Szenarien
Sehen Sie sich diese Szenarien an, um Hilfe bei der Auswahl zwischen lakehouse oder data warehouse in Fabric zu finden.
Szenario 1
Susan, eine professionelle Entwicklerin, ist neu in Microsoft Fabric. Sie können mit dem Bereinigen, Modellieren und Analysieren von Daten beginnen, müssen sich aber entscheiden, ein Data Warehouse oder ein Lakehouse zu erstellen. Nach der Überprüfung der Details in der vorherigen Tabelle sind die wichtigsten Entscheidungspunkte die verfügbaren Qualifikationen und die Notwendigkeit von Transaktionen mit mehreren Tabellen.
Susan hat viele Jahre damit verbracht, Data Warehouses für relationale Datenbank-Engines zu erstellen und ist mit SQL-Syntax und -Funktionalität vertraut. Im Hinblick auf das größere Team sind die hauptverbraucher dieser Daten auch mit SQL- und SQL-Analysetools vertraut. Susan entscheidet sich für die Verwendung eines Data Warehouse, das es dem Team ermöglicht, hauptsächlich mit T-SQL zu interagieren und gleichzeitig allen Spark-Benutzern im organization den Zugriff auf die Daten zu ermöglichen.
Szenario 2
Rob, ein Datentechniker, muss mehrere Terabyte an Daten in Fabric speichern und modellieren. Das Team verfügt über eine Mischung aus PySpark- und T-SQL-Kenntnissen. Die meisten Teams, die T-SQL-Abfragen ausführen, sind Consumer und müssen daher keine INSERT-, UPDATE- oder DELETE-Anweisungen schreiben. Die restlichen Entwickler arbeiten gerne in Notebooks, und da die Daten in Delta gespeichert sind, können sie mit einer ähnlichen SQL-Syntax interagieren.
Rob beschließt, ein Lakehouse zu verwenden, das es dem Data Engineering-Team ermöglicht, seine vielfältigen Fähigkeiten gegen die Daten zu nutzen, während die Teammitglieder, die in T-SQL hochqualifiziert sind, die Daten nutzen können.
Szenario 3
Ash, ein Citizen Developer, 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 Anforderungen und Datenvolumen zu sein. Sie überprüfen die Details in der vorherigen Tabelle und stellen fest, dass die wichtigsten Entscheidungspunkte ihre eigenen Fähigkeiten und ihre Notwendigkeit für eine Self-Service-, keine Codefunktion und ein Datenvolumen unter 100 GB sind.
Ash arbeitet mit Business Analysts zusammen, die mit Power BI und Microsoft Office vertraut sind, und weiß, dass sie bereits über ein Premium-Kapazitätsabonnement verfügen. Wenn sie über ihr größeres Team nachdenken, erkennen sie, dass die primären Consumer dieser Daten Analysten sein können, die mit No-Code und SQL-Analysetools vertraut sind. Ash beschließt, einen Power BI-Datamart zu verwenden, der es dem Team ermöglicht, die Funktion schnell und ohne Code zu erstellen. Abfragen können über Power BI und T-SQL ausgeführt werden. Gleichzeitig können auch alle Spark-Benutzer im organization auf die Daten zugreifen.