Migrationsplanlægning: Teradata til Fabric data warehouse

Gælder for:✅ Warehouse i Microsoft Fabric

At flytte en virksomheds-Teradata-boboet til Fabric data warehouse indebærer mere end skema- og dataoverførsel. Planlæg for SQL- og BTEQ-kode, indlæsning af processer, sikkerhed, rapportering, drift og ydeevne.

Denne artikel organiserer arbejdet i fem faser. Brug banerne som en gentagelig runbook for hver migrationsbølge. For den anbefalede implementering, se Migrationsmetoder for Teradata. For kodeudbedring, se Translate Teradata SQL for Fabric data warehouse.

Vigtig

Bekræft nuværende Fabric data warehouse begrænsninger og T-SQL-overfladeareal før hver migrationsbølge. Tildel en ejer og en oprydningsplan til hver blokeringsforskel.

Brug selektiv modernisering til de fleste arbejdsbelastninger:

  • Bevar validerede forretningsmodeller og logik.
  • Brug Migration Assistant til at oversætte og implementere understøttet metadata.
  • Erstat Teradata-specifikke SQL, værktøjer og operationer med Fabric-native mønstre.
  • Redesign kun de arbejdsbyrder, der er blokeret af ikke-understøttede afhængigheder eller eksisterende arkitektoniske problemer.

Migrer i bølger efter forretningsdomæne, datamarked eller arbejdsbelastningsklynge. Undgå en enkelt big bang-migration.

Vurder og evaluer

Sammenlign disse arbejdsstrømme, så du ikke overser nogen afhængigheder:

Arbejdsstrøm Vurdering
Design og ydeevne Datamodel, volumen, vækst, skævhed, tabelbredde, samtidighed, runtime og servicemål
ETL og indlæsning FastLoad, MultiLoad, Teradata Parallel Transporter, BTEQ import/eksport, tidsplaner, genstartsadfærd og inkrementelle indlæsninger
Sikkerhed og drift Brugere, roller, tilladelser, servicekonti, revision, gendannelse, overvågning og supportejerskab
Visualisering og rapportering Rapporter, semantiske modeller, applikationer, eksport, opdateringsplaner og forbindelsesafhængigheder
SQL-kompatibilitet Tabeller, visninger, makroer, procedurer, funktioner, datatyper, QUALIFY, flygtige tabeller, PERIOD, og BTEQ kontrolflow
Migrationsværktøjer Metadata-udtrækning, Migration Assistant-parathed, dataflytning, versionskontrol og implementeringsautomatisering
Ud over migrationen Cutover, rollback, optimering, træning, decommissioning og genanvendelige praksisser til senere bølger

Definer forretningsresultater, omfang, ejere, succesmål og forventninger til rollback. Lav et objektinventar, afhængighedskort, arbejdsbelastningsbaseline, kompatibilitetsregister og bølgeplan.

Plan og design

Gør vurderingen til et eksekverbart design:

  1. Bekræft Warehouse som mål for SQL-centreret relationel analyse.
  2. Definér udviklings-, test- og produktionsarbejdsområder, kapacitet, navngivning og ejerskab.
  3. Kortlæg Teradata-objekter og datatyper til Fabric-mål. Optag uunderstøttede elementer og godkendte alternativer. Brug Migration Assistant til metadata-oversættelse.
  4. Design historisk og inkrementel databevægelse separat.
  5. Redesign adgang omkring Microsoft Entra ID, arbejdsområder, varetilladelser og Warehouse SQL-tilladelser.
  6. Definer kriterier for udrulning, validering, cutover og rollback.

Foretræk en dimensionel model, batchorienteret belastning, modulær ELT og kontrolleret genbrug gennem OneLake i måldesignet.

Migrer

Udfør hver bølge i denne rækkefølge:

  1. Tilsidesæt målarbejdsområder, identiteter, forbindelser og deployeringssti.
  2. Upload udpakkede Teradata SQL-filer til Migration Assistant, oversæt metadata og ret objekter, der kræver opmærksomhed.
  3. Kopier et repræsentativt datasæt og valider gennemstrømning, kortlægninger, fejl og genstartsadfærd.
  4. Fuldfør den historiske belastning og etabler inkrementel synkronisering, når det er nødvendigt.
  5. Genskab sikkerheds- og driftsprocesser.
  6. Valider data, SQL-adfærd, rapporter, applikationer og repræsentativ ydeevne.
  7. Omlæg forbindelser og klip over, når acceptkriterierne er overstået.

Brug ikke objektoprettelsen som det eneste fuldførelsessignal. En bølge er kun fuldendt, når data, adfærd, sikkerhed, drift og downstream forbrug opfylder deres acceptkriterier.

Overvåge og styre

Kør kilde og mål parallelt i den periode, som arbejdsbelastningens risikoprofil kræver.

  • Sammenlign dataaktualisering, rækketal, forretningsaggregater og rapporter resultater mellem miljøer.
  • Overvåg belastningsvarighed, forespørgselsvarighed, fejl, gentagelser, kapacitetsforbrug, aktive sessioner og brugerrapporterede problemer.
  • Gennemgå adgangstildelinger, privilegerede identiteter, lagertilladelser og sikkerhedstestresultater.
  • Behold oversat kode, deployment-assets, kortlægningsbeslutninger, testbeviser og undtagelser i versionskontrol.
  • Spor migrationsparathed efter arbejdsbelastning og acceptgate, ikke kun efter antal migrerede objekter.
  • Optag tilbagevendende oversættelses- og belastningsproblemer som genanvendelig vejledning til senere bølger.
  • Etabler eskalations-, recovery-, rollback- og hypercare-procedurer før produktionscutover.

Ledelse omfatter linje, ejerskab, klassificering, fastholdelse, revision og operationelt ansvar. Anvend disse kontroller under migrationen i stedet for efter den endelige cutover.

Optimer og moderniser

Når du har etableret korrekthed og stabilitet, fjern midlertidige kompatibilitetsmønstre og brug Fabric-native funktioner.

  • Refaktorere literal SQL-oversættelser til modulær T-SQL.
  • Forenkle dybt indlejrede visninger og monolitiske procedureopgaver.
  • Standardiser højkapacitetsindtagelse på effektive, genstartbare filbaserede mønstre.
  • Juster ved at bruge Fabric data warehouse performance-retningslinjer og repræsentative samtidighedstests.
  • Reducer unødvendige datakopier ved at bruge reguleret OneLake-adgang, hvor det passer til arkitekturen.
  • Integrer Data Factory, Power BI, notebooks og andre Fabric-arbejdsbelastninger, hvor de reducerer duplikation eller operationel kompleksitet.
  • Gennemgå kapacitet, sikkerhed, pålidelighed og omkostninger, efter at arbejdsbelastningens adfærd stabiliseres.
  • Lav den færdige bølge om til en genanvendelig skabelon til det næste domæne.

Tjekliste for acceptering af migrationsbølger

Før du skifter over, skal du sikre at:

  • Objektinventaret og afhængighedskortet er komplette for bølgen.
  • Blokering af T-SQL-begrænsninger har godkendt udbedringer.
  • Skema og kode deployeres gentagne gange i alle målmiljøer.
  • Historiske og inkrementelle datastier består skalerings- og genopretningstests.
  • Dataafstemning og forretningsvalidering opfylder de aftalte tærskler.
  • Sikkerhed genskabes og valideres med repræsentative identiteter.
  • Rapporter, semantiske modeller, applikationer og operationelle job består testning.
  • Ydelse og samtidighed opfylder arbejdsbelastningens mål.
  • Overvågning, støtteejerskab, tilbagerulning og hypercare-planer er aktive.
  • Virksomhedsejere og tekniske ejere godkender cutover.

Relateret indhold

  • Last updated on