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 metoderna för migrering av datalager i dedikerade SQL-pooler i Azure Synapse Analytics till Microsoft Fabric 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 migreringsprojektet från Synapse dedikerad SQL-pool till Fabric Warehouse väljer du ett arbetsbelastningsområde där du kan:

• Bevisa hur bra det är att migrera till Fabric Warehouse genom att snabbt leverera fördelarna med den nya miljön. Starta små och enkla, förbered dig för flera små migreringar.
• 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.

Mängden migrerade data i en inledande migrering bör vara tillräckligt stor för att demonstrera funktionerna och fördelarna med Fabric Warehouse-miljön, men inte så stor att det fördröjer möjligheten 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 Warehouse-syntaxen.
• Skapa schemat (DDL) på Fabric Warehouse.
• Migrera datan till Fabric Warehouse.

Alternativ 1. Schema-/datamigrering – Kopieringsguiden och Kopieringsaktivitet för ForEach

Den här metoden använder Data Factory Copy Assistant för att ansluta till den dedikerade SQL-poolen, konvertera DDL-syntaxen för den dedikerade SQL-poolen till Fabric och kopiera data till Fabric 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-direktkopiering av data från den dedikerade SQL-poolen till Fabric Warehouse kräver mellanlagring. Inmatningsprocessen bestod 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 består av att införa data från mellanlagring till Fabric Warehouse. Tidsåtgången för datainmatningen sker mestadels under mellanlagringsfasen. Sammanfattningsvis har stagingprocessen en betydande inverkan på inmatningsprestanda.

Rekommenderad användning

Med hjälp av kopieringsguiden för att generera en ForEach får du ett enkelt användargränssnitt för att konvertera DDL och mata in de valda tabellerna från den dedikerade SQL-poolen till Fabric 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 dedikerad SQL-pool för att skala till högre DWU för att tillåta att extraheringsfrågorna körs. Genom att utnyttja partitionering förbättras hastigheten tio gånger jämfört med ett alternativ utan partition. Du kan öka DWU för att få ytterligare dataflöde via beräkningsresurser, men den dedikerade SQL-poolen har högst 128 aktiva frågor som tillåts.

Mer information om mappning av Synapse DWU till Fabric finns i Blogg: Mappa dedikerade SQL-pooler i Azure Synapse 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 COPY-kommandot för att mata in data i Fabric Warehouse.

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 DDL (scheman) för tabellobjekt från valfri Azure SQL Database eller dedikerad SQL-pool. Den här pipelinen migreras över schemat (DDL) för källdedikerade SQL-pooltabeller till Fabric 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.

• Fältet Fråga måste skapas med ett dynamiskt uttryck, vilket gör att parametern SchemaName kan användas i en fråga som returnerar en lista över 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. Refererar till parametern SchemaName för att tillåta filtrering på 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. Den här metoden använder Dynamic Expression Language inom pipelines för att bygga en SELECT TOP 0 * FROM <TABLE> för att migrera endast schemat utan data till ett Fabric Warehouse.

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.
• Arbetsytans datalagertyp är Data Warehouse och Data Warehouse är inställt på Fabric Warehouse.
• Måltabellens schema och tabellnamn definieras med dynamiskt innehåll.
  • Schema refererar till den aktuella iterationens fält, SchemaName med kodfragmentet: @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 Warehouse-syntaxen.
• Skapa schemat (DDL) på Fabric 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 måste du använda antingen COPY INTO eller Data Factory för att mata in data i Fabric Warehouse.

Migrera med hjälp av SQL-databasprojekt

Microsoft Fabric Data Warehouse stöds i SQL Database Projects-tillägget som är tillgängligt i Azure Data Studio och Visual Studio Code.

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

Mer information om källkontroll för lager i Microsoft Fabric, inklusive Git-integrerings- och distributionspipelines, finns i Källkontroll med lager.

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 Warehouse-syntaxen.
• Skapa schemat (DDL) på Fabric 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 antingen COPY INTO eller Data Factory för att mata in data i Fabric Warehouse.

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 och publicera ett projekt.

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.
  • Det här alternativet kräver att användarna skapar schemat (DDL) på Fabric Warehouse innan data matas in. Ö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 Warehouse-syntaxen.
• Skapa schemat (DDL) på Fabric 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 att befintliga dbt-projekt som var inriktade på olika plattformar, till exempel Synapse-dedikerade SQL-pooler, Snowflake, Databricks, Google Big Query eller Amazon Redshift, kan migreras till ett infrastrukturlager med en enkel konfigurationsändring.

För att komma igång med ett dbt-projekt som riktar sig mot Fabric Warehouse, se Handledning: Konfigurera dbt för Fabric Data Warehouse. Det här dokumentet visar också ett alternativ för att flytta mellan olika lager/plattformar.

Datainmatning till datalager

För inmatning till Fabric Warehouse använder du 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 prestandadataflöde, med tanke på förutsättningen att filerna redan extraheras till Azure Data Lake Storage (ADLS) Gen2.

Flera faktorer att tänka på så att du kan utforma din process för maximal prestanda:

• Med Fabric finns det ingen resurskonkurrens när man läser in flera tabeller från ADLS till Fabric Warehouse samtidigt. Därför försämras inte prestanda vid inläsning av parallella trådar. Det maximala inmatningsflödet kommer endast att begränsas av beräkningskraften för din Fabric-kapacitet.
• Arbetsbelastningshantering för resurser ger en uppdelning av de resurser som allokerats för belastning och frågor. Det finns ingen resurskonkurration när frågor och datainläsning 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 för datalagerhantering i Microsoft Fabric
• Blogg: Mappa dedikerade SQL-pooler i Azure Synapse till Fabric datalagerberäkningskapacitet
• Översikt över Microsoft Fabric-migrering