Migreringsmetoder for Azure Synapse Analytics dedikerte SQL-pooler til Fabric datalager

Gjelder for: ✅ Warehouse i Microsoft Fabric

Denne artikkelen beskriver metoder for migrering fra Azure Synapse Analytics dedikerte SQL-pooler til Microsoft Fabric datalager.

Følgende tabell oppsummerer metoder for migrering av dataskjema (DDL), databasekode (DML) og data. Kolonnen Alternativ lenker til detaljer for hvert scenario.

Velg en arbeidsbelastning for den første overføringen

Når du skal bestemme hvor du skal starte med Synapses dedikerte SQL-pool for å Fabric datalager migreringsprosjekt, velg et arbeidsområde hvor du kan:

• Bevis levedyktigheten av å migrere til Fabric datalager ved raskt å levere fordelene ved det nye miljøet. Start i det små og enkelt, og forbered deg på flere små migrasjoner.
• Gi de interne tekniske ansatte tid til å få relevant erfaring med prosessene og verktøyene de bruker når de overfører til andre områder.
• Opprett en mal for videre overføringer som er spesifikke for synapsemiljøet for kilden, og verktøyene og prosessene som er på plass for å hjelpe.

Volumet av migrerte data i en innledende migrasjon bør være stort nok til å demonstrere kapasitetene og fordelene ved det Fabric datalager miljøet, men ikke for stort til raskt å vise verdi. En størrelse i området 1-10 terabyte er typisk.

Overføring med Fabric Data Factory

Denne delen beskriver Data Factory-alternativer for brukere som er kjent med Azure Data Factory og Synapse-pipelines. Dra-og-slipp-grensesnittet gir en enkel måte å konvertere DDL og migrere data på.

Fabric Data Factory kan utføre følgende oppgaver:

• Konverter skjemaet (DDL) til Fabric datalager syntaks.
• Lag skjemaet (DDL) på Fabric datalager.
• Migrer dataene til Fabric datalager.

Alternativ 1. Skjema- og datamigrering - Copy data assistant og ForEach Copy Activity

Denne metoden bruker Data Factory Copy dataassistent for å koble til kildens dedikerte SQL-pool, konvertere DDL-syntaksen fra den dedikerte SQL-poolen til Fabric, og kopiere data til Fabric datalager. Du kan velge én eller flere måltabeller (for TPC-DS datasett er det 22 tabeller). Den genererer ForEach for å gå gjennom listen over tabeller som er valgt i brukergrensesnittet, og gyte 22 parallelle kopier aktivitetstråder.

• 22 SELECT spørringer (én for hver valgt tabell) genereres og utføres i den dedikerte SQL-poolen.
• Sørg for at du har riktig DRU og ressursklasse slik at spørringene kan kjøres. I dette tilfellet trenger du minimum DWU1000 med staticrc10 for å tillate maksimalt 32 spørringer å håndtere 22 spørringer som er sendt inn.
• Å kopiere data direkte fra den dedikerte SQL-poolen til Fabric datalager med Data Factory krever staging. Inntaksprosessen har to faser:
  • Den første fasen henter data fra den dedikerte SQL-poolen inn i ADLS. Denne fasen kalles staging.
  • Den andre fasen tar inn de trinnvise dataene i Fabric datalager. Mesteparten av inntakstiden brukes i staging-fasen, så stagingen har en betydelig effekt på ytelsen.

Anbefalt bruk

Ved å bruke Copy-assistenten for å generere en ForEach-aktivitet får du et enkelt grensesnitt for å konvertere DDL og importere utvalgte tabeller fra den dedikerte SQL-poolen til Fabric datalager i ett steg.

Dette alternativet gir imidlertid ikke optimal total gjennomstrømning. Staging og behovet for å parallellisere lesing og skriving i kilde-til-trinn-fasen er hovedkildene til latens. Bruk dette alternativet kun for dimensjonstabeller.

Alternativ 2. DDL/dataoverføring – datasamlebånd ved hjelp av partisjonsalternativ

For å forbedre gjennomstrømningen når du laster inn større faktatabeller med en Fabric-pipeline, bruk en Copy activity for hver faktatabell og aktiver partisjonering. Denne konfigurasjonen gir best mulig Copy activity-ytelse.

Bruk kildetabellens fysiske partisjoner når de er tilgjengelige. Hvis tabellen ikke er fysisk oppdelt, spesifiser en partisjonskolonne og minimums- og maksimumsverdier for dynamisk partisjonering. I det følgende skjermbildet spesifiserer pipeline Source-alternativene et dynamisk partisjonsområde basert på kolonnen.ws_sold_date_sk

Partisjonering kan øke staging-gjennomstrømningen. Vurder følgende veiledning når du konfigurerer den:

• Avhengig av partisjonsområdet kan operasjonen generere mer enn 128 spørringer og bruke alle samtidighetsplasser i den dedikerte SQL-poolen.
• Du må skalere til et minimum DWU6000 for å tillate at alle spørringer kan kjøres.
• For TPC-DS-tabellen web_sales ble for eksempel 163 spørringer sendt til det dedikerte SQL-utvalget. På DWU6000 kjørte 128 spørringer mens 35 sto i kø.
• Dynamisk partisjon velger automatisk områdepartisjonen. I dette tilfellet er det et 11-dagers område for hver SELECT-spørring som sendes til det dedikerte SQL-utvalget. Eksempel:

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

Anbefalt bruk

For faktatabeller, bruk Data Factory med partisjoneringsalternativet for å øke gjennomstrømningen.

Men parallelle lesinger krever at du skalerer den dedikerte SQL-poolen til en høyere DWU slik at den kan utføre ekstraksjonsspørringene. Partisjonering forbedrer hastigheten ti ganger sammenlignet med å ikke bruke partisjonering. Du kan øke DWU-en for mer gjennomstrømning, men en dedikert SQL-pool tillater maksimalt 128 aktive spørringer.

For mer informasjon om Synapse DWU to Fabric mapping, se Blogg: Mapping Azure Synapse dedikerte SQL-pooler til Fabric datalager compute.

Alternativ 3. DDL-migrering - Kopidataassistent for hver kopiaktivitet

De to foregående alternativene egner seg for mindre databaser. Hvis du trenger høyere gjennomstrømning, bruk dette alternativet:

1. Hent ut dataene fra den dedikerte SQL-poolen til ADLS for å redusere staging-overhead.
2. Bruk enten Data Factory eller COPY-kommandoen for å importere dataene til lageret ditt.

Anbefalt bruk

Du kan fortsette å bruke Data Factory til å konvertere skjemaet (DDL). Ved å bruke Copy data-assistenten kan du velge den spesifikke tabellen eller Alle tabellene. Med design migrerer denne metoden skjemaet i ett steg, og henter ut skjemaet uten rader ved å bruke feilbetingelsen TOP 0 i spørringssetningen.

Følgende kodeeksempel dekker skjemaoverføring (DDL) med Data Factory.

Kodeeksempel: Skjemaoverføring (DDL) med Data Factory

Du kan bruke Fabric Pipelines for enkelt å migrere DDL (skjemaer) for tabellobjekter fra hvilken som helst kilde Azure SQL Database eller dedikert SQL-pool. Denne pipelinen migrerer skjemaet (DDL) for de dedikerte SQL-pooltabellene til Fabric datalager.

Utforming av datasamlebånd: parametere

Denne pipelinen aksepterer en parameter SchemaName, som du bruker for å spesifisere hvilke skjemaer som skal migreres. Standardskjemaet er dbo.

Angi en kommadelt liste over tabellskjema som angir hvilke skjemaer som skal overføres, i standardverdifeltet: 'dbo','tpch' for å angi to skjemaer og dbotpch.

Utforming av datasamlebånd: Oppslagsaktivitet

Opprett en oppslagsaktivitet, og angi tilkoblingen til å peke til kildedatabasen.

I Innstillinger-fanen:

• Angi datalagertype til Ekstern.

• Tilkoblingen er azure Synapse-dedikert SQL-utvalg. Tilkoblingstypen er Azure Synapse Analytics.

• Bruksspørring er satt til Spørring.

• Bygg spørringsfeltet ved å bruke et dynamisk uttrykk, slik at du kan bruke parameteren SchemaName i en spørring som returnerer en liste med mål-kildetabeller. Velg Spørring og velg deretter Legg til dynamisk innhold.

  Dette uttrykket i oppslagsaktiviteten genererer en SQL-setning for å spørre systemvisningene for å hente en liste over skjemaer og tabeller. Den refererer til parameteren SchemaName for å tillate filtrering på SQL-skjemaer. Utdataene til dette uttrykket er et array av SQL-skjemaer og tabeller som ForEach Activity bruker som input.

  Bruk følgende kode til å returnere en liste over alle brukertabeller med skjemanavnet.

  @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ørledningsutforming: Forgrunnsløkke

Konfigurer følgende alternativer i Innstillinger-fanen for Foreach-løkken:

• Deaktiver Sequential for å tillate flere iterasjoner å kjøre samtidig.
• Angi partiantall til 50, og begrens maksimalt antall samtidige gjentakelser.
• Bruk dynamisk innhold i Items-feltet for å referere til utdataene fra LookUp-aktiviteten. Bruk følgende kodesnutt: @activity('Get List of Source Objects').output.value

Utforming av datasamlebånd: Kopier aktivitet i Foreach-løkken

Legg til en kopiaktivitet i Foreach-aktiviteten. Denne metoden bruker Dynamic Expression Language i pipelines for å bygge en SELECT TOP 0 * FROM <TABLE> setning som migrerer kun skjemaet uten data til et lager.

I Kilde-fanen:

• Angi datalagertype til Ekstern.
• Tilkoblingen er azure Synapse-dedikert SQL-utvalg. Tilkoblingstypen er Azure Synapse Analytics.
• Angi bruksspørring til spørring.
• I Spørringsfeltet , lim inn den dynamiske innholdsspørringen og bruk dette uttrykket som returnerer null rader, men inkluderer tabellskjemaet: @concat('SELECT TOP 0 * FROM ',item().SchemaName,'.',item().TableName)

På Mål-fanen:

• Angi datalagertype til arbeidsområde.
• Sett Workspace-datalagertypen til datalager og sett datalager til lageret.
• Skjema- og tabellnavnet for måltabellen defineres ved hjelp av dynamisk innhold.
  • Skjema refererer til feltet i den nåværende iterasjonen, SchemaName med utdraget: @item().SchemaName
  • Tabellreferanser TableName med utdraget: @item().TableName

Rørledningsutforming: Vask

Pek på lageret for Sink, og referer til kildeskjemaet og tabellnavnet.

Når du kjører denne pipelinen, ser du lageret ditt fylt med hver tabell i kildekoden din, med riktig skjema.

Migrering ved bruk av lagrede prosedyrer i Synapse dedikert SQL-pool

Dette alternativet bruker lagrede prosedyrer for å utføre migreringen til Fabric datalager.

Du kan få kodeeksempler på microsoft/fabric-migration på GitHub.com. Denne koden deles som åpen kilde, så du kan gjerne bidra til å samarbeide og hjelpe fellesskapet.

Hva Fabric Migrations lagrede prosedyrer kan gjøre:

• Konverter skjemaet (DDL) til Fabric datalager syntaks.
• Lag skjemaet (DDL) på Fabric datalager.
• Trekk ut data fra synapse dedikert SQL-utvalg til ADLS.
• Flagg ustøttet Fabric-syntaks for T-SQL-koder (lagrede prosedyrer, funksjoner, visninger).

Anbefalt bruk

Dette alternativet er flott for deg hvis du:

• Er kjent med T-SQL.
• Ønsker å bruke et integrert utviklingsmiljø for T-SQL-utvikling.
• Ønsker mer detaljert kontroll over hvilke oppgaver du jobber med.

Du kan utføre den spesifikke lagrede prosedyren for skjemakonvertering, datauttrekking eller T-SQL-kodevurdering.

For datamigreringen, bruk enten COPY INTO eller Fabric Data Factory for å importere dataene til lageret ditt.

Overføre ved hjelp av SQL-databaseprosjekter

Fabric datalager støtter SQL Database Projects-utvidelsen som er tilgjengelig i Visual Studio Code.

Denne utvidelsen er tilgjengelig i Visual Studio Code. Denne funksjonen aktiverer funksjoner for kildekontroll, databasetesting og skjemavalidering.

For mer informasjon om kildekontroll, se oversikt over utvikling og distribusjon.

Anbefalt bruk

Bruk dette alternativet hvis du foretrekker å bruke SQL Database Project for distribusjonen din. Dette alternativet integrerer Fabric Migration-lagrede prosedyrer i SQL-databaseprosjektet for å gi en sømløs migreringsopplevelse.

Et SQL Database Project kan:

• Konverter skjemaet (DDL) til Fabric datalager syntaks.
• Lag skjemaet (DDL) på Fabric datalager.
• Trekk ut data fra synapse dedikert SQL-utvalg til ADLS.
• Flagg ikke-støttet syntaks for T-SQL-koder (lagrede prosedyrer, funksjoner, visninger).

For datamigreringen, bruk enten COPY INTO eller Data Factory for å importere dataene til lageret ditt.

Microsoft Fabric CAT-teamet tilbyr PowerShell-skript for å pakke ut, lage og distribuere skjema (DDL) og databasekode (DML) gjennom et SQL-databaseprosjekt. For en gjennomgang, se microsoft/fabric-migration på GitHub.

For mer informasjon om SQL Database Projects, se Kom i gang med SQL Database Projects-utvidelsen og Bygg et databaseprosjekt fra kommandolinjen.

Overføring av data med CETAS

T-SQL CREATE EXTERNAL TABLE AS SELECT (CETAS)-kommandoen gir den mest kostnadseffektive og optimale metoden for å hente ut data fra Azure Synapse dedikerte SQL-pooler til Azure Data Lake Storage (ADLS) Gen2.

Hva CETAS kan gjøre:

• Pakk ut data i ADLS.
  • Dette alternativet krever at du lager skjemaet (DDL) i lageret ditt før du importerer dataene. Vurder alternativene i denne artikkelen for å overføre skjema (DDL).

Fordelene med dette alternativet er:

• Migreringen sender kun én spørring per tabell mot kilde-Synapse-dedikerte SQL-poolen. Denne spørringen bruker ikke opp alle samtidighetsplassene, og den blokkerer ikke samtidig kundeproduksjons-ETL eller spørringer.
• Du trenger ikke å skalere til DWU6000, siden det kun brukes én samtidighetsplass for hvert bord, så du kan bruke lavere DWU-er.
• Ekstraktet kjører parallelt på tvers av alle beregningsnodene, og denne funksjonen forbedrer ytelsen.

Anbefalt bruk

Bruk CETAS til å trekke ut dataene til ADLS som parkettfiler. Parquet-filer gir fordelen av effektiv datalagring med kolonnekomprimering som krever mindre båndbredde for å flytte over nettverket. Siden Fabric lagrer dataene som Delta parquet-format, er datainntaket 2,5 ganger raskere sammenlignet med tekstfilformat, siden det ikke er noen konvertering til Delta-formatets overhead under innspillingen.

Slik øker du CETAS-gjennomstrømmingen:

• Legg til parallelle CETAS-operasjoner, noe som øker bruken av samtidighetsspor, men tillater mer gjennomstrømming.
• Skaler DWU på synapse dedikert SQL-utvalg.

Overføring via dbt

Denne delen beskriver dbt-alternativet for kunder som allerede bruker dbt i sitt dedikerte SQL-poolmiljø i Synapse.

Hva dbt kan gjøre:

• Konverter skjemaet (DDL) til Fabric datalager syntaks.
• Lag skjemaet (DDL) på Fabric datalager.
• Konverter databasekode (DML) til stoffsyntaks.

DBT-rammeverket genererer DDL og DML (SQL-skript) på farten med hver kjøring. Ved å bruke modellfiler uttrykt i SELECT setninger, oversetter dbt DDL/DML umiddelbart til en hvilken som helst målplattform ved å endre profil (tilkoblingsstreng) og adaptertype.

Anbefalt bruk

DBT-rammeverket bruker en kode-først-tilnærming. Migrer dataene ved å bruke alternativer listet i dette dokumentet, som CETAS eller COPY/Data Factory.

Ved å bruke dbt-adapteren for Microsoft Fabric datalager kan du migrere eksisterende dbt-prosjekter som retter seg mot ulike plattformer som Azure Synapse dedikerte SQL-pooler, Snowflake, Databricks, Google BigQuery eller Amazon Redshift til et lager med en enkel konfigurasjonsendring.

For å komme i gang med et dbt-prosjekt som retter seg mot Fabric datalager, se Veiledning: Sett opp dbt for Fabric datalager. Dette dokumentet viser også et alternativ for å flytte mellom ulike lagre og plattformer.

Datainntak i Fabric datalager

For inntasting i Fabric datalager, bruk COPY INTO eller Fabric Data Factory, avhengig av hva du foretrekker. Begge metodene er de anbefalte og best ytende alternativene, da de har tilsvarende ytelsesgjennomstrømning, gitt forutsetningen at filene allerede er pakket ut til Azure Data Lake Storage (ADLS) Gen2.

Design prosessen din for maksimal ytelse ved å vurdere følgende faktorer:

• Med Fabric er det ingen ressurskonflikt når man laster flere tabeller fra ADLS til Fabric datalager samtidig. Derfor er det ingen ytelsesreduksjon når du laster inn parallelle tråder. Den maksimale inntaksgjennomstrømningen er kun begrenset av beregningskraften til din Fabric-kapasitet.
• Administrasjon av stoffarbeidsbelastning gir fordeling av ressurser som er tildelt for innlasting og spørring. Det er ingen ressurskonkurranse mens spørringer og datalasting utføres samtidig.

Relatert innhold

• Infrastrukturoverføringsassistent for datalager
• Opprette et lager i Microsoft Fabric
• Retningslinjer for fabric data warehouse-ytelse
• Sikkerhet i Fabric datalager
• Blogg: Mapping Azure Synapse dedikerte SQL-pooler til Fabric datalager compute
• Oversikt over Microsoft Fabric-overføring