Migreringsmetoder för Azure Synapse Analytics dedikerade SQL-pooler till Fabric Data Warehouse

Gäller för: ✅ Warehouse i Microsoft Fabric

Denna artikel beskriver metoder för att migrera från Azure Synapse Analytics dedikerade SQL-pooler till Microsoft Fabric Data Warehouse.

Följande tabell sammanfattar metoder för migrering av dataschema (DDL), databaskod (DML) och data. Optionskolumnen länkar till detaljer för varje scenario.

Välj en arbetsbelastning för den första migreringen

När du bestämmer var du ska börja i migreringsprojektet från Synapse dedikerade SQL-pool till Fabric Data Warehouse, välj ett arbetsbelastningsområde där du kan:

• Bevisa möjligheten att migrera till Fabric Data Warehouse genom att snabbt leverera fördelarna med den nya miljön. Börja smått och enkelt, och förbered dig på flera små migrationer.
• Ge din interna tekniska personal tid att få relevant erfarenhet av de processer och verktyg som de använder när de migrerar till andra områden.
• Skapa en mall för ytterligare migreringar som är specifika för synapse-källmiljön och de verktyg och processer som finns för att hjälpa till.

Volymen av migrerad data vid en initial migrering bör vara tillräckligt stor för att visa kapaciteterna och fördelarna med den Fabric Data Warehouse miljön, men inte för stor för att snabbt visa värde. En storlek på 1–10 terabyte är typisk.

Migrering med Fabric Data Factory

Detta avsnitt beskriver Data Factory-alternativ för användare som är bekanta med Azure Data Factory- och Synapse-pipelines. Dra-och-släpp-gränssnittet ger ett enkelt sätt att konvertera DDL och migrera data.

Fabric Data Factory kan utföra följande uppgifter:

• Konvertera schemat (DDL) till Fabric Data Warehouse syntax.
• Skapa schemat (DDL) på Fabric Data Warehouse.
• Migrera datan till Fabric Data Warehouse.

Alternativ 1. Schema- och datamigrering – Copy data-assistent och ForEach Copy Activity

Denna metod använder guiden Copy Data i Data Factory för att ansluta till källans dedikerade SQL-pool, konvertera DDL-syntaxen för den dedikerade SQL-poolen till Fabric och kopiera data till Fabric Data Warehouse. Du kan välja en eller flera måltabeller (för TPC-DS datauppsättning finns det 22 tabeller). Den genererar ForEach för att loopa igenom listan över tabeller som valts i användargränssnittet och skapa 22 parallella kopieringsaktivitetstrådar.

• 22 SELECT frågor (en för varje vald tabell) genereras och körs i den dedikerade SQL-poolen.
• Se till att du har rätt DWU och resursklass för att de genererade frågorna ska kunna köras. I det här fallet behöver du minst DWU1000 med staticrc10 för att högst 32 frågor ska kunna hantera 22 skickade frågor.
• Att kopiera data direkt från den dedikerade SQL-poolen till Fabric Data Warehouse med Data Factory kräver mellanlagring. Intagningsprocessen har två faser:
  • Den första fasen extraherar data från den dedikerade SQL-poolen till ADLS. Denna fas kallas stadieuppgång.
  • Den andra fasen matar in de mellanlagrade data i Fabric Data Warehouse. Största delen av intagningstiden tillbringas i stagingfasen, så staging har en betydande effekt på prestandan.

Rekommenderad användning

Att använda Copy Assistant för att generera en ForEach-aktivitet ger ett enkelt gränssnitt för att konvertera DDL och ta in utvalda tabeller från den dedikerade SQL-poolen till Fabric Data Warehouse i ett steg.

Detta alternativ ger dock inte optimal total genomströmning. Mellanlagring och behovet av att parallellisera läs- och skrivoperationer under fasen från källan till mellanlagret är de främsta orsakerna till latens. Använd detta alternativ endast för dimensionstabeller.

Alternativ 2. DDL/datamigrering – Pipeline med partitionsalternativ

För att förbättra genomströmningen när du laddar större faktatabeller med en Fabric-pipeline, använd en Copy activity för varje faktatabell och aktivera partitionering. Denna konfiguration ger bästa prestanda för Copy activity.

Använd källtabellens fysiska partitioner när de är tillgängliga. Om tabellen inte är fysiskt partitionerad, ange en partitionskolumn samt minimi- och maximumvärden för dynamisk partitionering. I följande skärmdump specificerar pipelinens Source-alternativ ett dynamiskt partitionsintervall baserat på kolumnen ws_sold_date_sk .

Partitionering kan öka stegningsgenomströmningen. Tänk på följande vägledning när du konfigurerar den:

• Beroende på partitionsintervallet kan operationen generera mer än 128 frågor och använda alla samtidighetsplatser i den dedikerade SQL-poolen.
• Du måste skala till minst DWU6000 så att alla frågor kan köras.
• För TPC-DS-tabellen web_sales skickades till exempel 163 frågor till den dedikerade SQL-poolen. Vid DWU6000 kördes 128 förfrågningar medan 35 förfrågningar låg i kö.
• Dynamisk partition väljer automatiskt intervallpartitionen. I det här fallet ett intervall på 11 dagar för varje SELECT-fråga som skickas till den dedikerade SQL-poolen. Till exempel:

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

Rekommenderad användning

För faktatabeller, använd Data Factory med partitioneringsalternativet för att öka genomströmningen.

Parallella läsningar kräver dock att du skalar upp den dedikerade SQL-poolen till en högre DWU så att den kan köra extraheringsfrågorna. Partitionering förbättrar hastigheten tiofalt jämfört med att inte använda partitionering. Du kan öka DWU för mer genomströmning, men en dedikerad SQL-pool tillåter maximalt 128 aktiva frågor.

Mer information om mappningen mellan Synapse DWU och Fabric finns i Blogg: Mappa dedikerade SQL-pooler i Azure Synapse till beräkningskapacitet i Fabric Data Warehouse.

Alternativ 3. DDL-migrering – guiden Kopiera data ForEach kopieringsaktivitet

De två föregående alternativen är lämpliga för mindre databaser. Om du behöver högre genomströmning, använd detta alternativ:

1. Extrahera data från den dedikerade SQL-poolen till ADLS för att minska staging-överhead.
2. Använd antingen Data Factory eller kommandot COPY för att mata in data i ditt lager.

Rekommenderad användning

Du kan fortsätta att använda Data Factory för att konvertera ditt schema (DDL). Genom att använda Copy data assistant kan du välja den specifika tabellen eller Alla tabeller. Denna metod migrerar enligt design schemat i ett steg, och extraherar schemat utan rader genom att använda falska villkoret TOP 0 i frågesatsen.

Följande kodexempel omfattar schemamigrering (DDL) med Data Factory.

Kodexempel: Schemamigrering (DDL) med Data Factory

Du kan använda Fabric Pipelines för att enkelt migrera din DDL (scheman) för tabellobjekt från vilken källkod som helst, Azure SQL Database eller dedikerad SQL-pool. Denna pipeline migrerar schemat (DDL) för de källdedikerade SQL-pooltabellerna till Fabric Data Warehouse.

Rörledningsutformning: parametrar

Denna pipeline accepterar en parameter SchemaName, som du använder för att specificera vilka scheman som ska migreras. Standardschemat är dbo.

I fältet Standardvärde anger du en kommaavgränsad lista över tabellscheman som anger vilka scheman som ska migreras: 'dbo','tpch' för att tillhandahålla två scheman dbo och tpch.

Design av pipeline: Uppslagsaktivitet

Skapa en uppslagsaktivitet och ställ in anslutningen så att den pekar på källdatabasen.

På fliken Inställningar :

• Ange Datalagringstyp till Extern.

• Anslutningen är din dedikerade SQL-pool i Azure Synapse. Anslutningstyp är Azure Synapse Analytics.

• Använd fråga är inställd på Fråga.

• Bygg frågefältet genom att använda ett dynamiskt uttryck, så att du kan använda parametern SchemaName i en fråga som returnerar en lista med målkälltabeller. Välj Fråga och välj sedan Lägg till dynamiskt innehåll.

  Det här uttrycket i LookUp-aktiviteten genererar en SQL-instruktion för att fråga systemvyerna för att hämta en lista över scheman och tabeller. Den refererar till parametern SchemaName för att möjliggöra filtrering av SQL-scheman. Utdata från detta uttryck är en array av SQL-scheman och tabeller som ForEach Activity använder som indata.

  Använd följande kod för att returnera en lista över alla användartabeller med deras schemanamn.

  @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'),')
  ')
  

Rörledningsdesign: ForEachloop

För ForEach-loopen konfigurerar du följande alternativ på fliken Inställningar :

• Inaktivera Sequential för att tillåta flera iterationer att köras samtidigt.
• Ange Batch-antal till 50, vilket begränsar det maximala antalet samtidiga iterationer.
• Använd dynamiskt innehåll i fältet Arklar för att referera till utdata från Uppslagsaktiviteten. Använd följande kodfragment: @activity('Get List of Source Objects').output.value

Pipelinedesign: Kopiera aktivitet i ForEach-loopen

Lägg till en kopieringsaktivitet i ForEach-aktiviteten. Denna metod använder Dynamic Expression Language inom pipelines för att bygga ett SELECT TOP 0 * FROM <TABLE> uttalande som migrerar endast schemat utan data till ett lager.

På fliken Källa :

• Ange Datalagringstyp till Extern.
• Anslutningen är din dedikerade SQL-pool i Azure Synapse. Anslutningstyp är Azure Synapse Analytics.
• Ange Använd fråga till Fråga.
• I fältet Fråga , klistra in den dynamiska innehållsfrågan och använd detta uttryck som returnerar noll rader, men inkluderar tabellschemat: @concat('SELECT TOP 0 * FROM ',item().SchemaName,'.',item().TableName)

På fliken Mål :

• Ange Datalagertyp till Arbetsyta.
• Ange typen av datalager för arbetsytan till Data Warehouse och ange Data Warehouse till lagret.
• Måltabellens schema och tabellnamn definieras med dynamiskt innehåll.
  • Schema avser den aktuella iterationens fält, SchemaName med kodavsnittet: @item().SchemaName
  • Tabellreferenser TableName med utdraget: @item().TableName

Pipelinedesign: Slutpunkt

För Sink pekar du på ditt datavaruhus och refererar till källschemat och tabellnamnet.

När du kör den här pipelinen ser du att ditt datalager fylls med alla tabeller från din källa, med rätt schema.

Migrering genom att använda lagrade procedurer i Synapse dedikerad SQL-pool

Detta alternativ använder lagrade procedurer för att utföra migreringen till Fabric Data Warehouse.

Du kan hämta kodexemplen vid microsoft/fabric-migrering på GitHub.com. Den här koden delas som öppen källkod, så du kan gärna bidra till att samarbeta och hjälpa communityn.

Vad Fabric Migrations lagrade procedurer kan göra:

• Konvertera schemat (DDL) till Fabric Data Warehouse syntax.
• Skapa schemat (DDL) på Fabric Data Warehouse.
• Extrahera data från synapse-dedikerad SQL-pool till ADLS.
• Flagga icke-stödd Fabric-syntax för T-SQL-koder (lagrade procedurer, funktioner, vyer).

Rekommenderad användning

Detta alternativ är utmärkt för dig om du:

• Är bekant med T-SQL.
• Vill använda en integrerad utvecklingsmiljö för T-SQL-utveckling.
• Vill ha mer detaljerad kontroll över vilka uppgifter du arbetar med.

Du kan köra den specifika lagrade proceduren för schemakonverteringen (DDL), dataextraktet eller T-SQL-kodutvärderingen.

För datamigreringen, använd antingen COPY INTO eller Fabric Data Factory för att mata in datan i ditt lager.

Migrera med hjälp av SQL-databasprojekt

Fabric Data Warehouse stöder tillägget SQL Database Projects som finns tillgängligt i Visual Studio Code.

Det här tillägget är tillgängligt i Visual Studio Code. Den här funktionen möjliggör funktioner för källkontroll, databastestning och schemavalidering.

För mer information om versionshantering, se Översikt över utveckling och distribution.

Rekommenderad användning

Använd detta alternativ om du föredrar att använda SQL Database Project för din distribution. Detta alternativ integrerar Fabric Migrations lagrade procedurer i SQL-databasprojektet för att erbjuda en smidig migreringsupplevelse.

Ett SQL Database-projekt kan:

• Konvertera schemat (DDL) till Fabric Data Warehouse syntax.
• Skapa schemat (DDL) på Fabric Data Warehouse.
• Extrahera data från synapse-dedikerad SQL-pool till ADLS.
• Flagga syntax som inte stöds för T-SQL-koder (lagrade procedurer, funktioner, vyer).

För datamigreringen, använd antingen COPY INTO eller Data Factory för att mata in datan i ditt lager.

Microsoft Fabric CAT-teamet tillhandahåller PowerShell-skript för att extrahera, skapa och distribuera schema (DDL) och databaskod (DML) via ett SQL-databasprojekt. För en genomgång, se microsoft/fabric-migration på GitHub.

Mer information om SQL Database Projects finns i Komma igång med SQL Database Projects-tillägget och Skapa ett databasprojekt från kommandoraden.

Migrering av data med CETAS

T-SQL CREATE EXTERNAL TABLE AS SELECT (CETAS)-kommandot ger den mest kostnadseffektiva och optimala metoden för att extrahera data från Azure Synapse dedikerade SQL-pooler till Azure Data Lake Storage (ADLS) Gen2.

Vad CETAS kan göra:

• Extrahera data till ADLS.
  • Detta alternativ kräver att du skapar schemat (DDL) i ditt lager innan du tar in datan. Överväg alternativen i den här artikeln för att migrera schema (DDL).

Fördelarna med det här alternativet är:

• Migreringen skickar endast in en enda fråga per tabell mot Synapses dedikerade SQL-pool. Denna fråga använder inte alla samtidighetsplatser, och den blockerar inte samtidigt kundproduktions-ETL eller frågor.
• Du behöver inte skala upp till DWU6000, eftersom endast en samtidighetsplats används för varje tabell, så du kan använda lägre DWU-nivåer.
• Extraktet körs parallellt över alla beräkningsnoder, och denna funktion förbättrar prestandan.

Rekommenderad användning

Använd CETAS för att extrahera data till ADLS som Parquet-filer. Parquetfiler ger fördelen av effektiv datalagring med kolumnkomprimering som kräver mindre bandbredd för att flyttas över nätverket. Eftersom Fabric lagrar data som Delta-parquetformat är datainsamlingen 2,5 gånger snabbare jämfört med textfilformat, eftersom det inte sker någon konvertering till Delta-formatets överhead under inmatningen.

Så här ökar du CETAS-dataflödet:

• Lägg till parallella CETAS-operationer, vilket ökar användningen av samtidighetsplatser men tillåter större genomströmning.
• Skala DWU på dedikerad Synapse SQL-pool.

Migrering via dbt

Detta avsnitt beskriver dbt-alternativet för kunder som redan använder dbt i sin dedikerade SQL-poolmiljö i Synapse.

Vad dbt kan göra:

• Konvertera schemat (DDL) till Fabric Data Warehouse syntax.
• Skapa schemat (DDL) på Fabric Data Warehouse.
• Konvertera databaskod (DML) till Fabric-syntax.

Dbt-ramverket genererar DDL och DML (SQL-skript) dynamiskt vid varje körning. Genom att använda modellfiler uttryckta i SELECT satser översätter dbt DDL/DML omedelbart till vilken målplattform som helst genom att ändra profil (reťazec pripojenia) och adaptertyp.

Rekommenderad användning

dbt-ramverket använder ett arbetssätt där man börjar med kod. Migrera datan genom att använda alternativ som listas i detta dokument, såsom CETAS eller COPY/Data Factory.

Genom att använda dbt-adaptern för Microsoft Fabric Data Warehouse kan du migrera befintliga dbt-projekt som riktar sig mot olika plattformar som Azure Synapse dedikerade SQL-pooler, Snowflake, Databricks, Google BigQuery eller Amazon Redshift till ett lager med en enkel konfigurationsändring.

För att komma igång med ett dbt-projekt som riktar sig till Fabric Data Warehouse, se Tutorial: Sätt upp dbt för Fabric Data Warehouse. Detta dokument listar också ett alternativ för att flytta mellan olika lager och plattformar.

Datainsamling i Fabric Data Warehouse

För inmatning i Fabric Data Warehouse, använd COPY INTO eller Fabric Data Factory, beroende på vad du föredrar. Båda metoderna är de rekommenderade och bäst presterande alternativen, eftersom de har motsvarande prestandagenomströmning, med tanke på att filerna redan är extraherade till Azure Data Lake Storage (ADLS) Gen2.

Designa din process för maximal prestanda genom att beakta följande faktorer:

• Med Fabric finns det ingen resurskonkurrens när man laddar flera tabeller från ADLS till Fabric Data Warehouse samtidigt. Därför försämras inte prestanda vid inläsning av parallella trådar. Den maximala genomströmningen för dataingestering begränsas endast av beräkningskraften i din Fabric-kapacitet.
• Arbetsbelastningshantering för resurser ger en uppdelning av de resurser som allokerats för belastning och frågor. Det finns ingen resurskonkurrens medan frågor och dataladdning körs samtidigt.

Relaterat innehåll

• Fabric Migration Assistant för datalager
• Skapa ett lager i Microsoft Fabric
• Prestandariktlinjer för Fabric Data Warehouse
• Säkerhet i Fabric Data Warehouse
• Blogg: Mappning av Azure Synapse dedikerade SQL-pooler till beräkningsresurser i Fabric Data Warehouse
• Översikt över Microsoft Fabric-migrering