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

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

Den här artikeln beskriver metoder för att migrera datalagring i Azure Synapse Analytics dedikerade SQL-pooler till Microsoft Fabric Data Warehouse.

Den här tabellen sammanfattar information för dataschema (DDL), databaskod (DML) och datamigreringsmetoder. Vi expanderar ytterligare på varje scenario senare i den här artikeln, länkad i kolumnen Alternativ .

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

När du bestämmer var du ska börja med Synapses dedikerade SQL-pool för att Fabric Data Warehouse migreringsprojekt, 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

I det här avsnittet diskuterar vi alternativen med Data Factory för den persona med låg kod/ingen kod som är bekant med Azure Data Factory och Synapse Pipeline. Detta drag-and-drop-alternativ i användargränssnittet erbjuder ett enkelt steg för 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-/datamigrering – Kopieringsguiden och Kopieringsaktivitet för ForEach

Denna metod använder Data Factory Copy Assistant för att ansluta till källpoolen dedikerade SQL-poolen, konvertera DDL-syntaxen från 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) genererades och kördes i den dedikerade SQL-poolen.
• Kontrollera att du har rätt DWU- och resursklass så att de genererade frågorna kan 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.
• Data Factory kopierar data direkt från den dedikerade SQL-poolen till Fabric Data Warehouse kräver staging. Intagningsprocessen består av två faser.
  • Den första fasen består av att extrahera data från den dedikerade SQL-poolen till ADLS och kallas mellanlagring.
  • Den andra fasen tar in data från staging till Fabric Data Warehouse. Tidsåtgången för datainmatningen sker mestadels under mellanlagringsfasen. Sammanfattningsvis har stagingprocessen en betydande inverkan på inmatningsprestanda.

Rekommenderad användning

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

Dock är det inte optimalt med den övergripande genomströmningen. Kravet på att använda mellanlagring, behovet av att parallellisera läsning och skrivning för steget "Källa till steg" är de viktigaste faktorerna för prestandafördröjningen. Vi rekommenderar att du endast använder det här alternativet för dimensionstabeller.

Alternativ 2. DDL/datamigrering – Pipeline med partitionsalternativ

För att förbättra genomströmningen för att ladda in större faktatabeller genom att använda Fabric-pipeline, rekommenderar vi att du använder Kopieringsaktivitet för varje faktatabell med partitionsalternativ. Detta ger bästa prestanda med aktiviteten Kopiera.

Du kan välja att använda källtabellens fysiska partitionering, om den är tillgänglig. Om tabellen inte har fysisk partitionering måste du ange partitionskolumnen och ange min/max-värden för att använda dynamisk partitionering. I följande skärmbild anger alternativen för Source ett dynamiskt intervall av partitioner baserat på ws_sold_date_sk-kolumnen.

För att öka genomflödet i mellanlagringsfasen med partitionering, finns det viktiga överväganden för att göra lämpliga justeringar.

• Beroende på partitionsintervallet kan det potentiellt använda alla samtidighetsfack eftersom det kan generera över 128 frågor i den dedikerade SQL-poolen.
• Du måste skala till minst DWU6000 så att alla frågorna 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 frågeställningar medan 35 ställdes 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 rekommenderar vi att du använder Data Factory med partitioneringsalternativet för att öka dataflödet.

De ökade parallelliserade läsningarna kräver dock en dedikerad SQL-pool för att skalas till högre DWU för att extrahera frågorna ska kunna köras. Genom att utnyttja partitionering förbättras hastigheten tio gånger jämfört med ett alternativ utan partition. Du kan öka DWU:n för att få extra genomströmning via beräkningsresurser, men den dedikerade SQL-poolen har maximalt 128 aktiva frågor tillåtna.

Mer information om Synapse DWU till infrastrukturmappning finns i Blogg: Mappa dedikerade AZURE Synapse SQL-pooler till Fabric Data Warehouse-beräkning.

Alternativ 3. DDL-migrering – Kopieringsguiden För varje kopieringsaktivitet

De två tidigare alternativen är bra alternativ för datamigrering för mindre databaser. Men om du behöver högre dataflöde rekommenderar vi ett alternativt alternativ:

1. Extrahera data från den dedikerade SQL-poolen till ADLS för att minska prestandapåverkan vid förberedande skeden.
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). Med hjälp av guiden Kopiera kan du välja den specifika tabellen eller Alla tabeller. Avsiktligt migrerar detta schemat och data i ett steg och extraherar schemat utan några rader, med hjälp av det falska villkoret, TOP 0 i frågeuttryck.

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

Den här pipelinen accepterar en parameter SchemaName, som gör att du kan ange vilka scheman som ska migreras över. Schemat dbo är standard.

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.

• Frågefältet måste byggas med ett dynamiskt uttryck, vilket gör att parametern SchemaName kan användas 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 för detta är en matris med SQL-schema och tabeller som ska användas som indata i ForEach-aktiviteten.

  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 Sekventiell så att flera iterationer kan köras samtidigt.
• Ange Batch-antal till 50, vilket begränsar det maximala antalet samtidiga iterationer.
• Fältet Objekt måste använda dynamiskt innehåll 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 en som migrerar SELECT TOP 0 * FROM <TABLE> 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 klistrar du in frågan med dynamiskt innehåll och använder det här uttrycket som returnerar noll rader, endast tabellschemat: @concat('SELECT TOP 0 * FROM ',item().SchemaName,'.',item().TableName)

På fliken Mål :

• Ange Datalagertyp till Arbetsyta.
• Workspace-datalagringstypen är Data Warehouse och Data Warehouse är inställd på lagret.
• Måltabellens schema och tabellnamn definieras med dynamiskt innehåll.
  • Schema avser fältet i den aktuella iterationen, SchemaName med snipeten: @item().SchemaName
  • Tabellen refererar till TableName med kodfragmentet: @item().TableName

Pipelinedesign: Slutpunkt

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

När du har kört den här pipelinen visas informationslagret fyllt med varje tabell i källan, med rätt schema.

Migrering med lagrade procedurer i synapse-dedikerad SQL-pool

Det här alternativet använder lagrade procedurer för att utföra infrastrukturmigreringen.

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 lagrade procedurer för migrering 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 infrastruktursyntax som inte stöds för T-SQL-koder (lagrade procedurer, funktioner, vyer).

Rekommenderad användning

Detta är ett bra alternativ för dem som:

• Är bekant med T-SQL.
• Vill du använda en integrerad utvecklingsmiljö som SQL Server Management Studio (SSMS).
• Vill ha mer detaljerad kontroll över vilka uppgifter de vill arbeta med.

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

För datamigreringen behöver du använda antingen COPY INTO Fabric Data Factory för att mata in datan i ditt lager.

Migrera med hjälp av SQL-databasprojekt

Microsoft Fabric Data Warehouse stöds i SQL Database Projects-tillägget som är 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

Det här är ett bra alternativ för dem som föredrar att använda SQL Database Project för distributionen. Det här alternativet integrerade i stort sett lagrade procedurer för infrastrukturmigrering i SQL Database-projektet för att ge en sömlös 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änder du sedan antingen COPY INTO Data Factory för att mata in datan i ditt lager.

Microsoft Fabric CAT-teamet har tillhandahållit en uppsättning PowerShell-skript för att hantera extrahering, skapande och distribution av schema (DDL) och databaskod (DML) via ett SQL Database-projekt. En genomgång av hur du använder SQL Database-projektet med våra användbara PowerShell-skript finns i microsoft/fabric-migration på GitHub.com.

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

Kommandot T-SQL CREATE EXTERNAL TABLE AS SELECT (CETAS) ger den mest kostnadseffektiva och optimala metoden för att extrahera data från 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 användarna skapar schemat (DDL) i ditt lager innan de 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:

• Endast en enskild fråga per tabell skickas mot den dedikerade SQL-källpoolen för Synapse. Detta kommer inte att använda upp alla samtidighetsplatser och kommer därför inte att blockera ETL-processer och frågor för samtidig kundproduktion.
• Skalning till DWU6000 krävs inte eftersom endast en enda samtidighetslucka används för varje tabell, så att kunderna kan använda lägre DWUs.
• Extraktet körs parallellt över alla beräkningsnoder, och detta är nyckeln till att förbättra prestandan.

Rekommenderad användning

Använd CETAS för att extrahera data till ADLS som Parquet-filer. Parquet-filer ger fördelen med effektiv datalagring med kolumnkomprimering som tar mindre bandbredd för att flytta över nätverket. Eftersom Fabric lagrar data i Delta parquetformat, kommer datainmatningen dessutom att bli 2,5 gånger snabbare jämfört med textfilformatet, eftersom det inte finns några omkostnader för konvertering till Delta-formatet 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

I det här avsnittet diskuterar vi dbt-alternativet för de kunder som redan använder dbt i sin aktuella Synapse-dedikerade SQL-poolmiljö.

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. Med modellfiler som uttrycks i SELECT-instruktioner kan DDL/DML omedelbart översättas till valfri målplattform genom att ändra profilen (anslutningssträng) och adaptertypen.

Rekommenderad användning

Dbt-ramverket är en kod-först-ansats. Data måste migreras med hjälp av alternativ som anges i det här dokumentet, till exempel CETAS eller COPY/Data Factory.

DBT-adaptern för Microsoft Fabric Data Warehouse gör det möjligt att migrera befintliga dbt-projekt som riktade sig mot olika plattformar som Synapse dedikerade SQL-pooler, Snowflake, Databricks, Google Big Query 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. Det här dokumentet visar också ett alternativ för att flytta mellan olika lager/plattformar.

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