Migrasjonsplanlegging: Teradata til Fabric datalager

Gjelder for:✅ Warehouse i Microsoft Fabric

Å flytte en bedrifts-Teradata-eiendom til Fabric datalager innebærer mer enn skjema- og dataoverføring. Planlegg for SQL- og BTEQ-kode, lasting av prosesser, sikkerhet, rapportering, drift og ytelse.

Denne artikkelen organiserer arbeidet i fem faser. Bruk stadiene som en repeterbar runbook for hver migrasjonsbølge. For anbefalt implementering, se Migrasjonsmetoder for Teradata. For kodeutbedring, se Translate Teradata SQL for Fabric datalager.

Important

Bekreft nåværende Fabric datalager begrensninger og T-SQL-overflateareal før hver migreringsbølge. Tildel eier og oppryddingsplan til hver blokkeringsforskjell.

Bruk selektiv modernisering for de fleste arbeidsbelastninger:

  • Bevar validerte forretningsmodeller og logikk.
  • Bruk Migration Assistant for å oversette og distribuere støttet metadata.
  • Erstatt Teradata-spesifikke SQL, verktøy og operasjoner med Fabric-native mønstre.
  • Redesign kun arbeidsbelastningene som er blokkert av ustøttede avhengigheter eller eksisterende arkitektoniske problemer.

Migrer i bølger etter forretningsdomene, datamarked eller arbeidsbelastningsklynge. Unngå en enkelt-big bang-migrasjon.

Vurder og vurder

Sammenlign disse arbeidsstrømmene slik at du ikke overser noen avhengigheter:

Arbeidsstrøm Vurder
Design og ytelse Datamodell, volum, vekst, skjevhet, tabellbredde, samtidighet, kjøretid og tjenestemål
ETL og lasting FastLoad, MultiLoad, Teradata Parallel Transporter, BTEQ import/eksport, tidsplaner, omstartadferd og inkrementelle laster
Sikkerhet og drift Brukere, roller, tillatelser, tjenestekontoer, revisjon, gjenoppretting, overvåking og støtteeierskap
Visualisering og rapportering Rapporter, semantiske modeller, applikasjoner, eksport, oppdateringsplaner og tilkoblingsavhengigheter
SQL-kompatibilitet Tabeller, visninger, makroer, prosedyrer, funksjoner, datatyper, QUALIFY, flyktige tabeller, PERIOD, og BTEQ kontrollflyt
Migreringsverktøy Metadatautvinning, Migration Assistant-beredskap, databevegelse, kildekontroll og automatisering av distribusjon
Utover migrasjon Cutover, rollback, optimalisering, trening, avvikling og gjenbrukbare praksiser for senere bølger

Definer forretningsresultater, omfang, eiere, suksessmål og forventninger til tilbakerulling. Lag et objektinventar, avhengighetskart, arbeidsbelastningsbaseline, kompatibilitetsregister og bølgeplan.

Plan og design

Gjør vurderingen om til et kjørbart design:

  1. Bekreft Warehouse som mål for SQL-sentrert relasjonsanalyse.
  2. Definer utviklings-, test- og produksjonsarbeidsområder, kapasitet, navn og eierskap.
  3. Kartlegg Teradata-objekter og datatyper til Fabric-mål. Registrer ustøttede elementer og godkjente alternativer. Bruk Migration Assistant for metadata-oversettelse.
  4. Design historisk og inkrementell databevegelse separat.
  5. Redesign tilgang rundt Microsoft Entra ID, arbeidsområderoller, varetillatelser og Warehouse SQL-tillatelser.
  6. Definer kriterier for utrulling, validering, cutover og rollback.

Foretrekk en dimensjonsmodell, batchorientert belastning, modulær ELT og styrt gjenbruk gjennom OneLake i måldesignet.

Trekke

Kjør hver bølge i denne rekkefølgen:

  1. Oppfør målarbeidsområdene, identiteter, tilkoblinger og distribusjonsvei.
  2. Last opp utpakkede Teradata SQL-filer til Migration Assistant, oversett metadata og fiks objekter som krever oppmerksomhet.
  3. Kopier et representativt datasett og verifiser gjennomstrømning, kartlegginger, feil og omstartsoppførsel.
  4. Fullfør den historiske belastningen og etabler inkrementell synkronisering når det er nødvendig.
  5. Gjenskape sikkerhets- og driftsprosesser.
  6. Valider data, SQL-atferd, rapporter, applikasjoner og representativ ytelse.
  7. Omdiriger forbindelser og kutt over etter at akseptkriteriene er over.

Ikke bruk suksess i objektopprettelse som det eneste fullføringssignalet. En bølge er fullført bare når data, atferd, sikkerhet, drift og nedstrøms forbruk oppfyller sine akseptkriterier.

Overvåk og styr

Operer kilde og mål parallelt i perioden som kreves av arbeidsbelastningens risikoprofil.

  • Sammenlign dataferskhet, radantall, forretningsaggregater og rapporter resultater mellom miljøer.
  • Overvåk lastetid, spørringsvarighet, feil, reforsøk, kapasitetsforbruk, aktive økter og brukerrapporterte problemer.
  • Gå gjennom tilgangsoppgaver, privilegerte identiteter, lagertillatelser og sikkerhetstestresultater.
  • Behold oversatt kode, distribusjonsressurser, kartleggingsbeslutninger, testbevis og unntak i kildekodekontroll.
  • Spor migrasjonsklarhet etter arbeidsbelastning og akseptport, ikke bare etter migrert antall objekter.
  • Registrer gjentakende oversettelses- og lasteproblemer som gjenbrukbar veiledning for senere bølger.
  • Etabler prosedyrer for eskalering, gjenoppretting, tilbakerulling og hypercare før produksjonsovergang.

Styring inkluderer linje, eierskap, klassifisering, bevaring, revisjon og operasjonelt ansvar. Bruk disse kontrollene under migreringen i stedet for etter den endelige overgangen.

Optimaliser og moderniser

Etter at du har etablert korrekthet og stabilitet, fjern midlertidige kompatibilitetsmønstre og bruk Fabric-native muligheter.

  • Refaktorere bokstavelige SQL-oversettelser til modulær T-SQL.
  • Forenkle dypt nestede visninger og monolittiske prosedyreoppgaver.
  • Standardiser høygjennomstrømming på effektive, restartbare filbaserte mønstre.
  • Juster ved å bruke Fabric datalager ytelsesretningslinjer og representative samtidighetstester.
  • Reduser unødvendige datakopier ved å bruke styrt OneLake-tilgang der det passer arkitekturen.
  • Integrer Data Factory, Power BI, notatbøker og andre Fabric-arbeidsbelastninger hvor de reduserer duplisering eller operasjonell kompleksitet.
  • Gjennomgå kapasitet, sikkerhet, pålitelighet og kostnad etter at arbeidsmengdens atferd har stabilisert seg.
  • Gjør den fullførte bølgen om til en gjenbrukbar mal for neste domene.

Sjekkliste for aksept av migrasjonsbølger

Før overgang, sjekk at:

  • Objektinventaret og avhengighetskartet er komplett for bølgen.
  • Blokkering av T-SQL-begrensninger har godkjente utbedringer.
  • Skjema og kode distribueres gjentatte ganger i alle målmiljøer.
  • Historiske og inkrementelle datastier består skalerings- og gjenopprettingstester.
  • Dataavstemming og forretningsvalidering oppfyller de avtalte tersklene.
  • Sikkerheten gjenskapes og valideres med representative identiteter.
  • Rapporter, semantiske modeller, applikasjoner og operative jobber består testing.
  • Ytelse og samtidighet oppfyller arbeidsmengdens mål.
  • Overvåking, støtteeierskap, tilbakerulling og hypercare-planer er aktive.
  • Bedrifts- og tekniske eiere godkjenner cutover.

Relatert innhold

  • Sist oppdatert