Migrationsmethoden für dedizierte SQL-Pools von Azure Synapse Analytics zum Fabric Data Warehouse

Zutreffend für: ✅ Warehouse in Microsoft Fabric

Dieser Artikel beschreibt Methoden zur Migration von Data Warehousing in Azure Synapse Analytics dedizierten SQL-Pools zu Microsoft Fabric Data Warehouse.

Tipp

Weitere Informationen zur Strategie und Planung Ihrer Migration finden Sie unter Planung der Migration: dedizierte SQL-Pools für Azure Synapse Analytics zu Fabric Data Warehouse.

Eine automatisierte Oberfläche für die Migration von dedizierten SQL-Pools von Azure Synapse Analytics ist über den Fabric-Migrations-Assistenten für Data Warehouseverfügbar. Der Rest dieses Artikels enthält weitere manuelle Migrationsschritte.

In dieser Tabelle werden Informationen zu Datenschemamethoden (Data Schema, DDL), Datenbankcode (DML) und Datenmigrationsmethoden zusammengefasst. Die einzelnen Szenarien werden später in diesem Artikel in der Spalte Optionen näher erläutert.

Optionsnummer	Option	Funktionsbeschreibung	Fähigkeit/Vorliebe	Szenario
1	Datenfabrik	Schemakonvertierung (DDL) Datenextraktion Datenaufnahme	ADF/Pipeline	Vereinfachtes Alles-in-Einem-Schema (DDL) und Datenmigration. Empfohlen für Dimensionstabellen.
2	Datenfabrik mit Partition	Schemakonvertierung (DDL) Datenextraktion Datenaufnahme	ADF/Pipeline	Verwenden von Partitionierungsoptionen zum Erhöhen des Lese-/Schreib-Parallelismus, der zehnmal den Durchsatz gegenüber Option 1 bereitstellt, empfohlen für Faktentabellen.
3	Data Factory mit beschleunigtem Code	Schemakonvertierung (DDL)	ADF/Pipeline	Konvertieren und migrieren Sie zuerst das Schema (DDL), und verwenden Sie dann CETAS zum Extrahieren und COPY/Data Factory, um Daten für eine optimale Gesamtaufnahmeleistung aufzunehmen.
4	Gespeicherte Prozeduren beschleunigen Code	Schemakonvertierung (DDL) Datenextraktion Codebewertung	T-SQL	SQL-Anwender, die die IDE benutzen, um genauer zu kontrollieren, an welchen Aufgaben sie arbeiten möchten. Verwenden Sie COPY/Data Factory, um Daten zu erfassen.
5	SQL-Datenbankprojekterweiterung für Visual Studio Code	Schemakonvertierung (DDL) Datenextraktion Codebewertung	SQL-Projekt	SQL-Datenbankprojekt für die Bereitstellung mit der Integration von Option 4. Verwenden Sie COPY oder Data Factory, um Daten zu erfassen.
6	EXTERNE TABELLE ALS SELECT ERSTELLEN (CETAS)	Datenextraktion	T-SQL	Kostengünstige und leistungsstarke Datenextraktion in Azure Data Lake Storage (ADLS) Gen2. Verwenden Sie COPY/Data Factory, um Daten zu erfassen.
7	Migrieren mithilfe von dbt	Schemakonvertierung (DDL) Konvertierung von Datenbankcode (DML)	dbt	Vorhandene dbt-Benutzer können den dbt Fabric-Adapter verwenden, um ihre DDL und DML zu konvertieren. Anschließend müssen Sie Daten mithilfe anderer Optionen in dieser Tabelle migrieren.

Auswählen einer Workload für die erste Migration

Wenn Sie entscheiden, wo Sie mit dem Synapse-dedizierten SQL-Pool für Fabric Data Warehouse Migrationsprojekt anfangen möchten, wählen Sie einen Arbeitslastbereich, in dem Sie:

• Beweisen Sie die Tragfähigkeit der Migration zu Fabric Data Warehouse, indem Sie die Vorteile der neuen Umgebung schnell umsetzen. Fang klein und einfach an und bereite dich auf mehrere kleine Migrationen vor.
• Geben Sie Ihrem technischen Personal Zeit, relevante Erfahrungen mit den Prozessen und Tools zu sammeln, die sie nutzen werden, wenn sie in andere Bereiche wechseln.
• Erstellen Sie eine Vorlage für weitere Migrationen, die speziell auf die Synapse-Quellumgebung und die vorhandenen Tools und Prozesse zugeschnitten ist.

Tipp

Führen Sie eine Inventur der zu migrierenden Objekte durch und dokumentieren Sie den Migrationsprozess von Anfang bis Ende, so dass er für andere dedizierte SQL-Pools oder Workloads wiederholt werden kann.

Das Volumen der migrierten Daten bei einer Erstmigration sollte groß genug sein, um die Fähigkeiten und Vorteile der Fabric Data Warehouse-Umgebung zu demonstrieren, aber nicht zu groß, um schnell den Wert zu zeigen. In der Regel liegt die Größe im Bereich von 1 bis 10 TB.

Migration mit Fabric Data Factory

In diesem Abschnitt werden die Optionen mit Data Factory für die Zielgruppe mit Low-Code/No-Code erläutert, die mit Azure Data Factory und Synapse Pipeline vertraut sind. Diese Option zum Ziehen und Ablegen der Benutzeroberfläche bietet einen einfachen Schritt zum Konvertieren der DDL und zum Migrieren der Daten.

Fabric Data Factory kann die folgenden Aufgaben ausführen:

• Konvertiere das Schema (DDL) in Fabric Data Warehouse Syntax.
• Erstellen Sie das Schema (DDL) auf Fabric Data Warehouse.
• Migriere die Daten zu Fabric Data Warehouse.

Option 1: Schema-/Datenmigration – Kopier-Assistent und ForEach-Copy-Aktivität

Diese Methode verwendet den Data Factory Copy Assistant, um sich mit dem dedizierten Quell-SQL-Pool zu verbinden, die DDL-Syntax des dedizierten SQL-Pools in Fabric umzuwandeln und Daten in Fabric Data Warehouse zu kopieren. Sie können eine oder mehr Zieltabellen auswählen (für das TPC-DS-Dataset gibt es 22 Tabellen). Das Programm generiert ForEach, um eine Schleife durch die Liste der in der Benutzeroberfläche ausgewählten Tabellen zu ziehen und 22 parallele Copy-Aktivität-Threads zu erzeugen.

• 22 SELECT-Abfragen (eine für jede ausgewählte Tabelle) wurden generiert und im dedizierten SQL-Pool ausgeführt.
• Stellen Sie sicher, dass Sie über die entsprechende DWU- und Ressourcenklasse verfügen, damit die generierten Abfragen ausgeführt werden können. In diesem Fall benötigen Sie mindestens DWU1000, staticrc10 damit maximal 32 Abfragen 22 übermittelte Abfragen verarbeiten können.
• Das direkte Kopieren von Daten aus dem dedizierten SQL-Pool in Data Factory Fabric Data Warehouse erfordert Staging. Der Aufnahmeprozess besteht aus zwei Phasen.
  • Die erste Phase besteht aus dem Extrahieren der Daten aus dem dedizierten SQL-Pool in ADLS und wird als „Staging“ bezeichnet.
  • Die zweite Phase speichert die Daten aus dem Staging in Fabric Data Warehouse. Der größte Teil der Datenerfassung findet in der Stagingphase statt. Zusammenfassend wirkt sich das Staging auf die Erfassungsleistung aus.

Empfohlene Verwendung

Mit dem Copy Wizard erstellt man einen ForEach und bietet eine einfache Benutzeroberfläche, um DDL zu konvertieren und die ausgewählten Tabellen aus dem dedizierten SQL-Pool in einem Schritt zu Fabric Data Warehouse.

Allerdings ist es nicht optimal für den Gesamtdurchsatz. Die Anforderung, Staging zu verwenden, und die Notwendigkeit, Lese- und Schreibvorgänge für den Schritt „Source to Stage“ zu parallelisieren, sind die Hauptfaktoren für die Leistungslatenz. Es wird empfohlen, diese Option nur für Dimensionstabellen zu verwenden.

Option 2. DDL/Datenmigration – Pipeline mit Partitionsoption

Um den Durchsatz zu verbessern, um größere Faktentabellen mithilfe der Fabric-Pipeline zu laden, empfiehlt es sich, "Aktivität kopieren" für jede Fact-Tabelle mit Partitionsoption zu verwenden. Dies bietet die beste Leistung mit Copy-Aktivität.

Sie haben die Möglichkeit, die physische Partitionierung der Quelltabelle zu verwenden, falls verfügbar. Wenn die Tabelle keine physische Partitionierung hat, müssen Sie die Partitionsspalte angeben und Min/Max-Werte liefern, um die dynamische Partitionierung zu verwenden. Im folgenden Screenshot geben die Pipelinequellenoptionen einen dynamischen Bereich von Partitionen basierend auf der ws_sold_date_sk Spalte an.

Während die Verwendung der Partition den Durchsatz mit der Stagingphase erhöhen kann, gibt es Überlegungen, die entsprechenden Anpassungen vorzunehmen:

• Abhängig von Ihrem Partitionsbereich werden möglicherweise alle Parallelitätsslots verwendet, da mehr als 128 Abfragen auf dem dedizierten SQL-Pool erstellt werden können.
• Sie müssen auf ein Minimum von DWU6000 skalieren, damit alle Abfragen ausgeführt werden können.
• Beispielsweise wurden für die TPC-DS-Tabelle web_sales 163 Abfragen an den dedizierten SQL-Pool übermittelt. Bei DWU6000 wurden 128 Abfragen ausgeführt, während 35 Abfragen in die Warteschlange gestellt wurden.
• Dynamische Partition wählt automatisch die Bereichspartition aus. In diesem Fall wird ein 11-tägiger Bereich für jede SELECT-Abfrage an den dedizierten SQL-Pool übermittelt. Beispiel:

  WHERE [ws_sold_date_sk] > '2451069' AND [ws_sold_date_sk] <= '2451080')
  ...
  WHERE [ws_sold_date_sk] > '2451333' AND [ws_sold_date_sk] <= '2451344')
  

Empfohlene Verwendung

Für Faktentabellen empfehlen wir die Verwendung von Data Factory mit Partitionierungsoption, um den Durchsatz zu erhöhen.

Die erhöhten parallelisierten Reads erfordern jedoch einen eigenen SQL-Pool, um auf eine höhere DWU zu skalieren, damit die Extraktionsabfragen ausgeführt werden können. Durch die Nutzung von Partitionierung verbessert sich die Rate zehnmal im Vergleich zu einer Option ohne Partition. Du kannst die DWU erhöhen, um zusätzlichen Durchsatz durch Rechenressourcen zu erzielen, aber der dedizierte SQL-Pool erlaubt maximal 128 aktive Abfragen.

Weitere Informationen zur Zuordnung von Synapse DWU zu Fabric finden Sie im Blog: Zuordnen von dedizierten Azure Synapse SQL-Pools zur Fabric Data Warehouse-Berechnung.

Option 3. DDL-Migration – Copy-Assistent forEach Copy-Aktivität

Die beiden vorherigen Optionen sind gute Möglichkeiten zur Datenmigration für kleinere Datenbanken. Wenn Sie jedoch einen höheren Durchsatz benötigen, empfehlen wir eine alternative Option:

1. Extrahieren Sie die Daten aus dem dedizierten SQL-Pool in ADLS und verringern Sie so den Aufwand für die Stage Leistung.
2. Verwenden Sie entweder Data Factory oder den BEFEHL COPY, um die Daten in Ihr Warehouse zu übertragen.

Empfohlene Verwendung

Sie können weiterhin Data Factory verwenden, um Ihr Schema (DDL) zu konvertieren. Mit dem Kopier-Assistenten können Sie die bestimmte Tabelle oder Alle Tabellenauswählen. Dadurch werden das Schema und die Daten in einem Schritt migriert. Dabei wird das Schema ohne Zeilen extrahiert, indem die falsche Bedingung TOP 0 in der Abfrageanweisung verwendet wird.

Im folgenden Codebeispiel wird die Schemamigration (DDL) mit Data Factory behandelt.

Codebeispiel: Schemamigration (DDL) mit Data Factory

Sie können Fabric Pipelines verwenden, um Ihre DDL (Schemata) für Tabellenobjekte aus jeder Quelle, Azure SQL-Datenbank oder einem dedizierten SQL-Pool zu migrieren. Diese Pipeline migriert das Schema (DDL) für die dedizierten Quellcode-SQL-Pooltabellen zu Fabric Data Warehouse.

Pipelineentwurf: Parameter

Diese Pipeline akzeptiert einen Parameter SchemaName, mit dem Sie angeben können, welche Schemas migriert werden sollen. Das dbo Schema ist die Standardeinstellung.

Geben Sie in das Feld Standardwert eine durch Komma getrennte Liste von Tabellenschemata ein, die angibt, welche Schemata migriert werden sollen: 'dbo','tpch' um zwei Schemata bereitzustellen, dbo und tpch.

Pipelineentwurf: Lookup-Aktivität

Erstellen Sie eine Lookup-Aktivität, und legen Sie die Verbindung so fest, dass sie auf Ihre Quelldatenbank verweist.

Auf der Registerkarte Einstellungen:

• Setzen Sie den Datenspeichertyp auf Extern.

• Die Verbindung ist Ihr dedizierter SQL-Pool in Azure Synapse. Verbindungstyp ist Azure Synapse Analytics.

• Verwendungsabfrage ist auf Abfrage festgelegt.

• Das Abfragefeld muss mit einem dynamischen Ausdruck erstellt werden, der es ermöglicht, den Parameter SchemaName in einer Abfrage zu verwenden, die eine Liste von Zielquellentabellen zurückgibt. Wählen Sie Abfrage und dann Dynamischen Inhalt hinzufügen aus.

  Dieser Ausdruck innerhalb der Lookup-Aktivität generiert eine SQL-Anweisung zur Abfrage der Systemansichten, um eine Liste von Schemas und Tabellen abzurufen. Er verweist auf den Parameter SchemaName , um das Filtern von SQL-Schemata zu ermöglichen. Die Ausgabe ist ein Array von SQL-Schema und Tabellen, die als Eingabe in die ForEach-Aktivität verwendet werden.

  Verwenden Sie den folgenden Code, um eine Liste aller Benutzertabellen mit ihrem Schemanamen zurückzugeben.

  @concat('
  SELECT s.name AS SchemaName,
  t.name  AS TableName
  FROM sys.tables AS t
  INNER JOIN sys.schemas AS s
  ON t.type = ''U''
  AND s.schema_id = t.schema_id
  AND s.name in (',coalesce(pipeline().parameters.SchemaName, 'dbo'),')
  ')
  

Pipelineentwurf: ForEach-Schleife

Konfigurieren Sie für die ForEach-Schleife die folgenden Optionen auf der Registerkarte Einstellungen:

• Deaktivieren Sie Sequenziell, damit mehrere Iterationen gleichzeitig ausgeführt werden können.
• Setzen Sie Batch-Anzahl auf 50, um die maximale Anzahl der gleichzeitigen Iterationen zu begrenzen.
• Das Feld „Elemente“ muss dynamischen Inhalt verwenden, um auf die Ausgabe der Lookup-Aktivität zu verweisen. Verwenden Sie den folgenden Codeausschnitt: @activity('Get List of Source Objects').output.value

Pipelineentwurf: Copy-Aktivität in der ForEach-Schleife

Fügen Sie in der ForEach-Aktivität eine Kopieraktivität hinzu. Diese Methode verwendet die Dynamic Expression Language innerhalb von Pipelines, um ein SELECT TOP 0 * FROM <TABLE> Schema zu erstellen, das nur das Schema ohne Daten in ein Warehouse migriert.

Auf der Registerkarte Quelle:

• Setzen Sie den Datenspeichertyp auf Extern.
• Die Verbindung ist Ihr dedizierter SQL-Pool in Azure Synapse. Verbindungstyp ist Azure Synapse Analytics.
• Legen Sie Abfrage verwenden auf Abfrage fest.
• Fügen Sie im Feld Abfrage die dynamische Inhaltsabfrage ein und verwenden Sie diesen Ausdruck, der keine Zeilen, sondern nur das Tabellenschema zurückgibt: @concat('SELECT TOP 0 * FROM ',item().SchemaName,'.',item().TableName)

Gehen Sie in der Registerkarte Ziel folgendermaßen vor:

• Setzen Sie den Datenspeichertyp auf Arbeitsbereich.
• Der Workspace-Datenspeichertyp ist Data Warehouse und das Data Warehouse ist auf das Warehouse gesetzt.
• Das Schema und der Tabellenname der Zieltabelle werden mithilfe dynamischer Inhalte definiert.
  • Schema bezieht sich auf das aktuelle Iterationsfeld SchemaName mit dem Ausschnitt: @item().SchemaName
  • Die Tabelle verweist auf TableName mit dem Codeschnipsel: @item().TableName

Pipelineentwurf: Senke

Für Senke zeigen Sie auf Ihr Warehouse und verweisen auf das Quellschema und den Tabellennamen.

Nachdem Sie diese Pipeline ausgeführt haben, wird Ihr Data Warehouse mit jeder Tabelle in Ihrer Quelle mit dem richtigen Schema aufgefüllt.

Migration mit gespeicherten Prozeduren im dedizierten SQL-Pool von Synapse

Diese Option verwendet gespeicherte Prozeduren zum Ausführen der Fabric-Migration.

Sie können die Codebeispiele bei der Microsoft/Fabric-Migration auf GitHub.comabrufen. Dieser Code wird als Open Source freigegeben. Sie können also zur Zusammenarbeit beitragen und der Community helfen.

Was die gespeicherten Prozeduren für die Migration tun können:

• Konvertiere das Schema (DDL) in Fabric Data Warehouse Syntax.
• Erstellen Sie das Schema (DDL) auf Fabric Data Warehouse.
• Extrahieren Sie Daten aus dem dedizierten SQL-Pool von Synapse in ADLS.
• Nicht unterstützte Fabric-Syntax für T-SQL-Codes (gespeicherte Prozeduren, Funktionen, Ansichten) markieren.

Empfohlene Verwendung

Dies ist eine großartige Option für diejenigen, die:

• Mit T-SQL vertraut sind.
• Eine integrierte Entwicklungsumgebung wie das SQL Server Management Studio (SSMS) verwenden möchten.
• Mehr Kontrolle darüber haben möchten, welche Aufgaben sie bearbeiten möchten.

Sie können die spezifische gespeicherte Prozedur für die Schemakonvertierung (DDL), den Datenextrakt oder die T-SQL-Codebewertung ausführen.

Für die Datenmigration musst du entweder COPY INTO die Fabric Data Factory verwenden, um die Daten in dein Warehouse zu importieren.

Migration mit SQL-Datenbankprojekten

Microsoft Fabric Data Warehouse wird in der SQL-Datenbankprojekteerweiterung unterstützt, die in Visual Studio Code verfügbar ist.

Diese Erweiterung ist in Visual Studio Code verfügbar. Dieses Feature ermöglicht Funktionen für Quellcodeverwaltung, Datenbanktests und Schemaüberprüfung.

Weitere Informationen zur Quellkontrolle finden Sie unter Entwicklung und Bereitstellungsübersicht.

Empfohlene Verwendung

Dies ist eine gute Option für diejenigen, die SQL-Datenbankprojekt für die Bereitstellung verwenden möchten. Diese Option integrierte im Wesentlichen die gespeicherten Fabric-Prozeduren in das SQL-Datenbankprojekt, um eine nahtlose Migrationserfahrung zu ermöglichen.

Ein SQL-Datenbankprojekt kann:

• Konvertiere das Schema (DDL) in Fabric Data Warehouse Syntax.
• Erstellen Sie das Schema (DDL) auf Fabric Data Warehouse.
• Extrahieren Sie Daten aus dem dedizierten SQL-Pool von Synapse in ADLS.
• Nicht unterstützte Syntax für T-SQL-Codes (gespeicherte Prozeduren, Funktionen, Ansichten) markieren.

Für die Datenmigration verwenden Sie dann entweder COPY INTO Data Factory, um die Daten in Ihr Warehouse zu übertragen.

Das Microsoft Fabric CAT-Team hat eine Reihe von PowerShell-Skripts bereitgestellt, um die Extraktion, Erstellung und Bereitstellung von Schema (DDL) und Datenbankcode (DML) über ein SQL-Datenbankprojekt zu verarbeiten. Eine exemplarische Vorgehensweise zur Verwendung des SQL-Datenbankprojekts mit unseren hilfreichen PowerShell-Skripts finden Sie unter microsoft/fabric-migration zu GitHub.com.

Weitere Informationen zu SQL-Datenbankprojekten finden Sie unter "Erste Schritte mit der Erweiterung SQL-Datenbankprojekte " und "Erstellen eines Datenbankprojekts" über die Befehlszeile.

Migration von Daten mit CETAS

Der Befehl T-SQL CREATE EXTERNAL TABLE AS SELECT (CETAS) bietet die kostengünstigste und optimale Methode zum Extrahieren von Daten aus Synapse dedizierten SQL-Pools in Azure Data Lake Storage (ADLS) Gen2.

Was CETAS tun kann:

• Daten nach ADLS extrahieren.
  • Diese Option erfordert, dass Nutzer das Schema (DDL) in Ihrem Warehouse erstellen, bevor sie die Daten einnehmen. Berücksichtigen Sie die Optionen in diesem Artikel zum Migrieren des Schemas (DDL).

Die Vorteile dieser Option sind:

• Für den dedizierten SQL-Pool von Synapse wird nur eine einzelne Abfrage pro Tabelle übermittelt. Dadurch werden nicht alle Parallelitätsslots verwendet, sodass gleichzeitige ETL/Abfragen der Kundenproduktion nicht blockiert werden.
• Die Skalierung auf DWU6000 ist nicht erforderlich, da nur ein einzelner Parallelitätsslot für jede Tabelle verwendet wird, sodass Kunden niedrigere DWUs verwenden können.
• Der Extrakt wird parallel auf allen Serverknoten ausgeführt, und das ist der Schlüssel zur Verbesserung der Leistung.

Empfohlene Verwendung

Verwenden Sie CETAS, um die Daten als Parquet-Dateien in ADLS zu extrahieren. Parquet-Dateien bieten den Vorteil einer effizienten Datenspeicherung mit spaltenweiser Komprimierung, die weniger Bandbreite für die Übertragung über das Netzwerk benötigt. Da Fabric die Daten im Delta-Parket-Format gespeichert hat, ist die Datenaufnahme im Vergleich zum Textdateiformat außerdem 2,5 Mal schneller, da während der Aufnahme keine Konvertierung in das Delta-Format erforderlich ist.

So erhöhen Sie den CETAS-Durchsatz:

• Fügen Sie parallele CETAS Vorgänge hinzu, was die Nutzung von Parallelitätsslots erhöht, aber einen höheren Durchsatz ermöglicht.
• Skalierung der DWU auf dem dedizierten SQL-Pool von Synapse.

Migration über dbt

In diesem Abschnitt erfahren Sie mehr über die dbt-Option für Kunden, die dbt bereits in ihrer aktuellen dedizierten Synapse-SQL-Pool-Umgebung verwenden.

Was dbt tun kann:

• Konvertiere das Schema (DDL) in Fabric Data Warehouse Syntax.
• Erstellen Sie das Schema (DDL) auf Fabric Data Warehouse.
• Konvertieren von Datenbankcode (DML) in Fabric-Syntax.

Das dbt-Framework generiert automatisch DDL- und DML-Skripts (SQL-Skripts) mit jeder Ausführung. Bei Modelldateien, die in SELECT-Anweisungen formuliert sind, kann die DDL/DML durch Ändern des Profils (Zeichenfolge) und des Adaptertyps sofort auf jede Zielplattform übertragen werden.

Empfohlene Verwendung

Das dbt-Framework ist ein Code-first-Ansatz. Die Daten müssen mithilfe der in diesem Dokument aufgeführten Optionen wie CETAS oder COPY/Data Factorymigriert werden.

Der DBT-Adapter für Microsoft Fabric Data Warehouse ermöglicht es, bestehende DBT-Projekte, die auf verschiedene Plattformen abzielten, wie Synapse-dedizierte SQL-Pools, Snowflake, Databricks, Google Big Query oder Amazon Redshift, mit einer einfachen Konfigurationsänderung in ein Warehouse zu migrieren.

Um mit einem DBT-Projekt zu beginnen, das auf Fabric Data Warehouse abzielt, siehe Tutorial: Einrichten von DBT für Fabric Data Warehouse. Dieses Dokument enthält auch eine Option für den Wechsel zwischen verschiedenen Warehouses/Plattformen.

Datenaufnahme in Fabric Data Warehouse

Für die Aufnahme in Fabric Data Warehouse verwenden COPY INTO oder Fabric Data Factory, je nach Vorliebe. Beide Methoden sind die empfohlenen und leistungsstärksten Optionen, da sie über einen entsprechenden Leistungsdurchsatz verfügen. Voraussetzung ist, dass die Dateien bereits in Azure Data Lake Storage (ADLS) Gen2 extrahiert werden.

Beachten Sie mehrere Faktoren, damit Sie Ihren Prozess für maximale Leistung entwerfen können:

• Bei Fabric gibt es keinen Ressourcenkonflikt, wenn mehrere Tabellen gleichzeitig von ADLS auf Fabric Data Warehouse geladen werden. Daher gibt es keine Leistungsbeeinträchtigung beim Laden paralleler Threads. Der maximale Erfassungsdurchsatz wird nur durch die Computeleistung Ihrer Fabric-Kapazität begrenzt.
• Die Fabric-Workload-Verwaltung bietet eine Trennung der für Last und Abfragen zugewiesenen Ressourcen. Es gibt keine Ressourcenkonflikte, wenn Abfragen und das Laden von Daten gleichzeitig ausgeführt werden.

Verwandte Inhalte

• Fabric Migration Assistant für Data Warehouse
• Erstellen eines Warehouse in Microsoft Fabric
• Leistungsrichtlinien des Fabric Data Warehouse
• Sicherheit für Data Warehousing in Microsoft Fabric
• Blog: Zuordnen von dedizierten AZURE Synapse-SQL-Pools zur Fabric Data Warehouse-Berechnung
• Übersicht über die Microsoft-Fabric-Migration