Migrationsplanering: Teradata till Fabric Data Warehouse

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

Att flytta ett företags Teradata-arv till Fabric Data Warehouse innebär mer än schema- och dataöverföring. Planera för SQL- och BTEQ-kod, laddningsprocesser, säkerhet, rapportering, drift och prestanda.

Denna artikel organiserar arbetet i fem steg. Använd stegen som en återanvändbar körbok för varje migrationsvåg. För rekommenderad implementering, se Migrationsmetoder för Teradata. För kodsanering, se Översätt Teradata SQL för Fabric Data Warehouse.

Rekommenderat tillvägagångssätt

Använd selektiv modernisering för de flesta arbetsbelastningar:

• Bevara validerade affärsmodeller och logik.
• Använd Migration Assistant för att översätta och distribuera stödd metadata.
• Ersätt Teradata-specifika SQL, verktyg och operationer med Fabric-native mönster.
• Omdesigna endast de arbetsbelastningar som blockeras av ostödda beroenden eller befintliga arkitektoniska problem.

Migrera i vågor per affärsdomän, datamarknad eller arbetsbelastningskluster. Undvik en enda stor migrering på en gång.

Bedöm och utvärdera

Jämför dessa arbetsflöden tillsammans så att du inte missar några beroenden:

Definiera affärsmål, omfattning, ansvariga, framgångskriterier och förväntningar på återställning. Skapa ett objektinventarie, beroendekarta, arbetsbelastningsbaslinje, kompatibilitetsregister och vågplan.

Planera och utforma

Förvandla bedömningen till en exekverbar design:

1. Bekräfta att Warehouse är målet för SQL-centrerad relationsanalys.
2. Definiera utvecklings-, test- och produktionsarbetsytor, kapacitet, namn och ägande.
3. Mappa Teradata-objekt och datatyper till Fabric-mål. Registrera icke-stödda objekt och godkända alternativ. Använd Migration Assistant för metadata-översättning.
4. Designa historisk och inkrementell datarörelse separat.
5. Gör om åtkomsthanteringen utifrån Microsoft Entra ID, arbetsyteroller, objektbehörigheter och SQL-behörigheter för Warehouse.
6. Definiera kriterier för utrullning, validering, övergång och återställning.

Föredra en dimensionsmodell, batchorienterad belastning, modulär ELT och styrd återanvändning via OneLake i måldesignen.

Migrate

Utför varje våg i denna ordning:

1. Tillhandahålla målarbetsytor, identiteter, anslutningar och distributionsväg.
2. Ladda upp extraherade Teradata SQL-filer till Migration Assistant, översätt metadata och åtgärda objekt som kräver uppmärksamhet.
3. Kopiera en representativ datamängd och verifiera genomströmning, mappningar, fel och omstartbeteende.
4. Slutför den historiska belastningen och etablera inkrementell synkronisering när det behövs.
5. Återskapa säkerhets- och operativa processer.
6. Validera data, SQL-beteende, rapporter, applikationer och representativ prestanda.
7. Omdirigera anslutningar och gör övergången när acceptanskriterierna är uppfyllda.

Använd inte framgång för objektskapandet som enda signal för fullbordan. En våg är endast komplett när data, beteende, säkerhet, drift och nedströms konsumtion uppfyller sina acceptanskriterier.

Övervaka och styra

Kör källa och mål parallellt under den period som krävs enligt arbetsbelastningens riskprofil.

• Jämför datafärskhet, radantal, affärsaggregat och rapportresultat mellan miljöer.
• Övervaka laddningslängd, frågelängd, fel, omförsök, kapacitetsanvändning, aktiva sessioner och användarrapporterade problem.
• Gå igenom åtkomsttilldelningar, privilegierade identiteter, lagertillstånd och säkerhetstestresultat.
• Behåll översatt kod, driftsättningsresurser, mappningsbeslut, testunderlag och undantag i källkodshanteringen.
• Följ migreringsberedskap per arbetsbelastning och acceptansgrind, inte bara efter migrerat objektantal.
• Dokumentera återkommande översättnings- och laddningsproblem som vägledning som kan återanvändas för senare vågor.
• Etablera eskalerings-, återhämtnings-, rollback- och hypercare-rutiner innan produktionsavstängning.

Styrning inkluderar härstamning, ägande, klassificering, behållning, revision och operativt ansvarstagande. Tillämpa dessa kontroller under migreringen istället för efter den slutliga övergången.

Optimera och modernisera

När du har fastställt korrekthet och stabilitet, ta bort temporära kompatibilitetsmönster och använd Fabric-native funktioner.

• Refaktorera bokstavliga SQL-översättningar till modulär T-SQL.
• Förenkla djupt inbäddade vyer och monolitiska procedurjobb.
• Standardisera högvolymsinhämtning med effektiva, filbaserade mönster som kan startas om.
• Justera genom att använda Fabric Data Warehouse prestandariktlinjer och representativa samtidighetstester.
• Minska onödiga datakopior genom att använda styrd OneLake-åtkomst där det passar arkitekturen.
• Integrera Data Factory, Power BI, anteckningsböcker och andra Fabric-arbetsbelastningar där de minskar duplicering eller operativ komplexitet.
• Granska kapacitet, säkerhet, tillförlitlighet och kostnad efter att arbetsbelastningens beteende stabiliserats.
• Förvandla den färdiga vågen till en återanvändbar mall för nästa domän.

Checklista för acceptans av migrationsvåger

Innan övergången, kontrollera att:

• Objektinventariet och beroendekartan är kompletta för vågen.
• Blockerande T-SQL-begränsningar har godkänt åtgärder.
• Schema och kod distribueras upprepade gånger i varje målmiljö.
• Historiska och inkrementella datavägar klarar skalnings- och återhämtningstester.
• Dataavstämning och företagsvalidering uppfyller de överenskomna tröskelvärdena.
• Säkerheten återskapas och valideras med representativa identiteter.
• Rapporter, semantiska modeller, applikationer och operativa jobb klarar tester.
• Prestanda och samtidighet uppfyller arbetsbelastningens mål.
• Övervaknings-, stöd-ägande-, rollback- och hypercare-planer är aktiva.
• Företags- och tekniska ägare godkänner övergång.

Relaterat innehåll

• Migrationsmetoder för Teradata
• Översätt Teradata SQL för Fabric Data Warehouse
• Migrera genom att ladda upp en fil
• Datalagring i Microsoft Fabric
• Infoga data i datalagret
• Skydda ditt Fabric-datalager
• Versionshantering med Warehouse