Delen via

Gegevensmigratie, ETL en laden voor Teradata-migraties

  • Artikel

Dit artikel is deel twee van een zevendelige reeks met richtlijnen voor het migreren van Teradata naar Azure Synapse Analytics. De focus van dit artikel ligt op best practices voor ETL- en belastingmigratie.

Overwegingen voor gegevensmigratie

Eerste beslissingen voor gegevensmigratie vanuit Teradata

Wanneer u een Teradata-datawarehouse migreert, moet u enkele eenvoudige gegevensgerelateerde vragen stellen. Bijvoorbeeld:

  • Moeten ongebruikte tabelstructuren worden gemigreerd?

  • Wat is de beste migratiebenadering om risico's en gebruikersimpact te minimaliseren?

  • Bij het migreren van datamarts: fysiek blijven of virtueel gaan?

In de volgende secties worden deze punten besproken in de context van de migratie vanuit Teradata.

Ongebruikte tabellen migreren?

Tip

In verouderde systemen is het niet ongebruikelijk dat tabellen na verloop van tijd overbodig worden. Deze hoeven in de meeste gevallen niet te worden gemigreerd.

Het is zinvol om alleen tabellen te migreren die in het bestaande systeem worden gebruikt. Tabellen die niet actief zijn, kunnen worden gearchiveerd in plaats van gemigreerd, zodat de gegevens zo nodig in de toekomst beschikbaar zijn. U kunt het beste metagegevens en logboekbestanden van het systeem gebruiken in plaats van documentatie om te bepalen welke tabellen in gebruik zijn, omdat documentatie mogelijk verouderd is.

Indien ingeschakeld, bevatten teradata-systeemcatalogustabellen en -logboeken informatie die kan bepalen wanneer een bepaalde tabel voor het laatst is geopend. Deze tabel kan vervolgens worden gebruikt om te bepalen of een tabel een kandidaat is voor migratie.

Hier volgt een voorbeeldquery op DBC.Tables die de datum van laatste toegang en laatste wijziging biedt:

SELECT TableName, CreatorName, CreateTimeStamp, LastAlterName,
LastAlterTimeStamp, AccessCount, LastAccessTimeStamp 
FROM DBC.Tables t
WHERE DataBaseName = 'databasename'

Als logboekregistratie is ingeschakeld en de logboekgeschiedenis toegankelijk is, is andere informatie, zoals SQL-querytekst, beschikbaar in de tabel DBQLogTbl en de bijbehorende logboekregistratietabellen. Zie Geschiedenis van Teradata-logboeken voor meer informatie.

Wat is de beste migratiebenadering om risico's en gevolgen voor gebruikers te minimaliseren?

Deze vraag komt vaak naar boven omdat bedrijven de impact van wijzigingen op het datawarehouse-gegevensmodel mogelijk willen verlagen om de flexibiliteit te verbeteren. Bedrijven zien vaak een kans om hun gegevens verder te moderniseren of te transformeren tijdens een ETL-migratie. Deze benadering brengt een hoger risico met zich mee, omdat er meerdere factoren tegelijk worden gewijzigd, waardoor het moeilijk is om de resultaten van het oude systeem te vergelijken met het nieuwe. Als u hier wijzigingen in het gegevensmodel aanbrengt, kan dit ook van invloed zijn op upstream- of downstream ETL-taken naar andere systemen. Vanwege dat risico is het beter om het ontwerp op deze schaal te herontwerpen na de migratie van het datawarehouse.

Zelfs als een gegevensmodel opzettelijk wordt gewijzigd als onderdeel van de algehele migratie, is het raadzaam om het bestaande model ongewijzigd te migreren naar Azure Synapse, in plaats van het nieuwe platform opnieuw te ontwerpen. Deze benadering minimaliseert het effect op bestaande productiesystemen en profiteert van de prestaties en elastische schaalbaarheid van het Azure-platform voor eenmalige her-engineeringtaken.

Wanneer u migreert vanuit Teradata, kunt u overwegen om een Teradata-omgeving te maken in een VIRTUELE machine in Azure als een stap in het migratieproces.

Tip

Migreer het bestaande model in eerste instantie zoals het is, zelfs als er in de toekomst een wijziging in het gegevensmodel is gepland.

Een Teradata-exemplaar van een VM gebruiken als onderdeel van een migratie

Een optionele benadering voor het migreren vanuit een on-premises Teradata-omgeving is het gebruik van de Azure-omgeving om een Teradata-exemplaar te maken in een VIRTUELE machine in Azure, die is gecolocatied met de doel-Azure Synapse-omgeving. Dit is mogelijk omdat Azure goedkope cloudopslag en elastische schaalbaarheid biedt.

Met deze benadering kunnen standaardhulpprogramma's van Teradata, zoals Teradata Parallel Data Transporter, of hulpprogramma's voor gegevensreplicatie van derden, zoals Attunity Replication, worden gebruikt om de subset van Teradata-tabellen die moeten worden gemigreerd naar het VM-exemplaar efficiënt te verplaatsen. Vervolgens kunnen alle migratietaken plaatsvinden binnen de Azure-omgeving. Deze aanpak heeft verschillende voordelen:

  • Na de eerste replicatie van gegevens hebben migratietaken geen invloed op het bronsysteem.

  • De Azure-omgeving heeft vertrouwde Teradata-interfaces, -hulpprogramma's en -hulpprogramma's.

  • De Azure-omgeving biedt beschikbaarheid van netwerkbandbreedte tussen het on-premises bronsysteem en het clouddoelsysteem.

  • Hulpprogramma's zoals Azure Data Factory kunnen hulpprogramma's zoals Teradata Parallel Transporter efficiënt aanroepen om snel en eenvoudig gegevens te migreren.

  • Het migratieproces wordt volledig binnen de Azure-omgeving ingedeeld en beheerd.

Bij het migreren van datamarts: fysiek blijven of virtueel gaan?

Tip

Het virtualiseren van datamarts kan besparen op opslag- en verwerkingsresources.

In verouderde Teradata-datawarehouse-omgevingen is het gebruikelijk om verschillende datamarts te maken die zijn gestructureerd om goede prestaties te bieden voor ad-hoc selfservicequery's en rapporten voor een bepaalde afdeling of bedrijfsfunctie binnen een organisatie. Als zodanig bestaat een datamart doorgaans uit een subset van het datawarehouse en bevat het geaggregeerde versies van de gegevens in een vorm waarmee gebruikers eenvoudig query's kunnen uitvoeren op die gegevens met snelle reactietijden via gebruiksvriendelijke queryhulpprogramma's zoals Microsoft Power BI, Tableau of MicroStrategy. Dit formulier is doorgaans een dimensional gegevensmodel. Datamarts worden onder andere gebruikt om de gegevens beschikbaar te maken in een bruikbare vorm, zelfs als het onderliggende gegevensmodel van het warehouse iets anders is, zoals een gegevenskluis.

U kunt afzonderlijke datamarts gebruiken voor afzonderlijke bedrijfseenheden binnen een organisatie om robuuste gegevensbeveiligingsregimes te implementeren, door gebruikers alleen toegang te geven tot specifieke datamarts die voor hen relevant zijn en gevoelige gegevens te elimineren, te verdoezelen of anoniem te maken.

Als deze datamarts worden geïmplementeerd als fysieke tabellen, hebben ze extra opslagresources nodig om ze op te slaan, en extra verwerking om ze regelmatig te bouwen en te vernieuwen. Bovendien zijn de gegevens in de mart alleen zo up-to-date als de laatste vernieuwingsbewerking en zijn ze mogelijk niet geschikt voor zeer vluchtige gegevensdashboards.

Tip

De prestaties en schaalbaarheid van Azure Synapse maken virtualisatie mogelijk zonder dat dit ten koste gaat van de prestaties.

Met de komst van relatief goedkope schaalbare MPP-architecturen, zoals Azure Synapse, en de inherente prestatiekenmerken van dergelijke architecturen, kan het zijn dat u datamart-functionaliteit kunt bieden zonder de mart te instantiëren als een set fysieke tabellen. Dit wordt bereikt door de datamarts effectief te virtualiseren via SQL-weergaven op het hoofddatawarehouse of via een virtualisatielaag met behulp van functies zoals weergaven in Azure of de visualisatieproducten van Microsoft-partners. Deze aanpak vereenvoudigt of elimineert de noodzaak van aanvullende opslag- en aggregatieverwerking en vermindert het totale aantal databaseobjecten dat moet worden gemigreerd.

Er is nog een potentieel voordeel van deze benadering. Door de aggregatie- en joinlogica binnen een virtualisatielaag te implementeren en hulpprogramma's voor externe rapportage te presenteren via een gevirtualiseerde weergave, wordt de verwerking die nodig is voor het maken van deze weergaven 'gepusht' naar het datawarehouse, wat over het algemeen de beste plaats is om joins, aggregaties en andere gerelateerde bewerkingen uit te voeren op grote gegevensvolumes.

De belangrijkste factoren voor het kiezen van een implementatie van een virtuele datamart boven een fysieke datamart zijn:

  • Meer flexibiliteit: een virtuele datamart is eenvoudiger te wijzigen dan fysieke tabellen en de bijbehorende ETL-processen.

  • Lagere totale eigendomskosten: voor een gevirtualiseerde implementatie zijn minder gegevensarchieven en kopieën van gegevens vereist.

  • Afschaffing van ETL-taken voor het migreren en vereenvoudigen van de architectuur van een datawarehouse in een gevirtualiseerde omgeving.

  • Prestaties: hoewel fysieke datamarts van oudsher beter presteren, implementeren virtualisatieproducten nu intelligente cachingtechnieken om dit te verhelpen.

Gegevensmigratie van Teradata

Inzicht in uw gegevens

Een onderdeel van de migratieplanning is het gedetailleerd begrijpen van de hoeveelheid gegevens die moeten worden gemigreerd, omdat dit van invloed kan zijn op beslissingen over de migratiebenadering. Gebruik systeemmetagegevens om de fysieke ruimte te bepalen die wordt ingenomen door de 'onbewerkte gegevens' in de tabellen die moeten worden gemigreerd. In deze context betekent 'onbewerkte gegevens' de hoeveelheid ruimte die wordt gebruikt door de gegevensrijen in een tabel, met uitzondering van overheads zoals indexen en compressie. Dit geldt met name voor de grootste feitentabellen, omdat deze doorgaans meer dan 95% van de gegevens bevatten.

U kunt een nauwkeurig getal verkrijgen voor de hoeveelheid gegevens die moet worden gemigreerd voor een bepaalde tabel door een representatieve steekproef van de gegevens, bijvoorbeeld één miljoen rijen, te extraheren naar een niet-gecomprimeerd, met scheidingstekens gescheiden ASCII-gegevensbestand. Gebruik vervolgens de grootte van dat bestand om een gemiddelde grootte van onbewerkte gegevens per rij van die tabel op te halen. Vermenigvuldig ten slotte die gemiddelde grootte met het totale aantal rijen in de volledige tabel om een onbewerkte gegevensgrootte voor de tabel weer te geven. Gebruik die onbewerkte gegevensgrootte in uw planning.

Overwegingen voor ETL-migratie

Eerste beslissingen met betrekking tot Teradata ETL-migratie

Tip

Plan de aanpak van ETL-migratie van tevoren en maak waar nodig gebruik van Azure-faciliteiten.

Voor ETL/ELT-verwerking kunnen verouderde Teradata-datawarehouses gebruikmaken van aangepaste scripts die gebruikmaken van Teradata-hulpprogramma's zoals BTEQ en TPT (Teradata Parallel Transporter) of ETL-hulpprogramma's van derden, zoals Informatica of Ab Initio. Soms gebruiken Teradata-datawarehouses een combinatie van ETL- en ELT-benaderingen die in de loop van de tijd zijn ontwikkeld. Wanneer u een migratie naar Azure Synapse plant, moet u bepalen wat de beste manier is om de vereiste ETL/ELT-verwerking in de nieuwe omgeving te implementeren en tegelijkertijd de kosten en het risico te minimaliseren. Zie ELT vs ETL-ontwerpbenadering voor meer informatie over ETL- en ELT-verwerking.

In de volgende secties worden migratieopties besproken en worden aanbevelingen voor verschillende gebruiksvoorbeelden beschreven. In dit stroomdiagram wordt één benadering samengevat:

Stroomdiagram met migratieopties en aanbevelingen.

De eerste stap is altijd het maken van een inventaris van ETL/ELT-processen die moeten worden gemigreerd. Net als bij andere stappen is het mogelijk dat de standaard 'ingebouwde' Azure-functies ervoor zorgen dat sommige bestaande processen niet meer moeten worden gemigreerd. Voor planningsdoeleinden is het belangrijk om inzicht te hebben in de schaal van de migratie die moet worden uitgevoerd.

In het voorgaande stroomdiagram heeft beslissing 1 betrekking op een beslissing op hoog niveau over het wel of niet migreren naar een volledig azure-systeemeigen omgeving. Als u overstapt naar een volledig eigen Azure-omgeving, raden we u aan de ETL-verwerking opnieuw te ontwerpen met behulp van pijplijnen en activiteiten in Azure Data Factory of Azure Synapse Pipelines. Als u niet overstapt op een volledig eigen Azure-omgeving, is beslissing 2 of er al een bestaand ETL-hulpprogramma van derden in gebruik is.

In de Teradata-omgeving kunnen sommige of alle ETL-verwerkingen worden uitgevoerd door aangepaste scripts met teradata-specifieke hulpprogramma's zoals BTEQ en TPT. In dit geval moet uw aanpak zijn om opnieuw te ontwerpen met behulp van Data Factory.

Tip

Maak gebruik van investeringen in bestaande hulpprogramma's van derden om kosten en risico's te verminderen.

Als een ETL-hulpprogramma van derden al in gebruik is, en met name als er een grote investering is in vaardigheden of als er een grote investering is in vaardigheden of als verschillende bestaande werkstromen en schema's dat hulpprogramma gebruiken, is de beslissing 3 of het hulpprogramma efficiënt Azure Synapse als doelomgeving kan ondersteunen. Idealiter bevat het hulpprogramma 'systeemeigen' connectors die gebruik kunnen maken van Azure-faciliteiten zoals PolyBase of COPY INTO voor het efficiënt laden van gegevens. Er is een manier om een extern proces aan te roepen, zoals PolyBase of COPY INTO, en de juiste parameters door te geven. Maak in dit geval gebruik van bestaande vaardigheden en werkstromen, met Azure Synapse als de nieuwe doelomgeving.

Als u besluit om een bestaand ETL-hulpprogramma van derden te behouden, kan het uitvoeren van dat hulpprogramma in de Azure-omgeving (in plaats van op een bestaande on-premises ETL-server) voordelen hebben en Azure Data Factory de algehele indeling van de bestaande werkstromen afhandelen. Een bijzonder voordeel is dat er minder gegevens uit Azure moeten worden gedownload, verwerkt en vervolgens weer moeten worden geüpload naar Azure. Beslissing 4 is dus of het bestaande hulpprogramma wordt uitgevoerd zoals het is of verplaatst naar de Azure-omgeving om kosten-, prestatie- en schaalbaarheidsvoordelen te behalen.

Bestaande Teradata-specifieke scripts opnieuw ontwerpen

Als sommige of alle bestaande ETL/ELT-verwerkingen van Teradata-magazijn worden verwerkt door aangepaste scripts die gebruikmaken van teradata-specifieke hulpprogramma's, zoals BTEQ, MLOAD of TPT, moeten deze scripts opnieuw worden gecodeerd voor de nieuwe Azure Synapse-omgeving. Als ETL-processen zijn geïmplementeerd met behulp van opgeslagen procedures in Teradata, moeten deze ook opnieuw worden gecodeerd.

Tip

De inventaris van ETL-taken die moeten worden gemigreerd, moet scripts en opgeslagen procedures bevatten.

Sommige elementen van het ETL-proces zijn eenvoudig te migreren, bijvoorbeeld door gegevens bulksgewijs vanuit een extern bestand in een faseringstabel te laden. Het kan zelfs mogelijk zijn om deze onderdelen van het proces te automatiseren, bijvoorbeeld door PolyBase te gebruiken in plaats van snel laden of MLOAD. Als de geëxporteerde bestanden Parquet zijn, kunt u een systeemeigen Parquet-lezer gebruiken. Dit is een snellere optie dan PolyBase. Andere onderdelen van het proces die willekeurige complexe SQL- en/of opgeslagen procedures bevatten, nemen meer tijd in beslag om opnieuw te ontwerpen.

Een manier om Teradata SQL te testen op compatibiliteit met Azure Synapse is het vastleggen van een aantal representatieve SQL-instructies uit Teradata-logboeken, het voorvoegsel van die query's met EXPLAINen vervolgens, uitgaande van een vergelijkbaar gemigreerd gegevensmodel in Azure Synapse, deze EXPLAIN instructies in Azure Synapse uit te voeren. Elke incompatibele SQL genereert een fout en de foutgegevens kunnen de schaal van de heroderende taak bepalen.

Microsoft-partners bieden hulpprogramma's en services voor het migreren van Teradata SQL en opgeslagen procedures naar Azure Synapse.

ETL-hulpprogramma's van derden gebruiken

Zoals beschreven in de vorige sectie, wordt het bestaande verouderde datawarehousesysteem in veel gevallen al ingevuld en onderhouden door ETL-producten van derden. Zie Gegevensintegratiepartners voor een lijst met Microsoft-partners voor gegevensintegratie voor Azure Synapse.

Gegevens laden vanuit Teradata

Beschikbare opties bij het laden van gegevens uit Teradata

Tip

Hulpprogramma's van derden kunnen het migratieproces vereenvoudigen en automatiseren en zo het risico verminderen.

Als het gaat om het migreren van gegevens vanuit een Teradata-datawarehouse, zijn er enkele basisvragen met betrekking tot het laden van gegevens die moeten worden opgelost. U moet bepalen hoe de gegevens fysiek worden verplaatst van de bestaande on-premises Teradata-omgeving naar Azure Synapse in de cloud en welke hulpprogramma's worden gebruikt om de overdracht en het laden uit te voeren. Houd rekening met de volgende vragen, die in de volgende secties worden besproken.

  • Extraheer je de gegevens naar bestanden of verplaats je deze rechtstreeks via een netwerkverbinding?

  • Wilt u het proces organiseren vanuit het bronsysteem of vanuit de Azure-doelomgeving?

  • Welke hulpprogramma's gebruikt u om het proces te automatiseren en te beheren?

Gegevens overdragen via bestanden of netwerkverbinding?

Tip

Inzicht in de gegevensvolumes die moeten worden gemigreerd en de beschikbare netwerkbandbreedte, omdat deze factoren van invloed zijn op de beslissing over de migratiebenadering.

Zodra de databasetabellen die moeten worden gemigreerd in Azure Synapse zijn gemaakt, kunt u de gegevens verplaatsen om deze tabellen vanuit het verouderde Teradata-systeem te vullen naar de nieuwe omgeving. Er zijn twee basismethoden:

  • Bestandsextract: extraheer de gegevens uit de Teradata-tabellen naar platte bestanden, normaal gesproken in CSV-indeling, via BTEQ, Fast Export of Teradata Parallel Transporter (TPT). Gebruik TPT waar mogelijk, omdat dit de meest efficiënte gegevensdoorvoer is.

    Deze benadering vereist ruimte om de geëxtraheerde gegevensbestanden te landen. De ruimte kan lokaal zijn in de Teradata-brondatabase (als er voldoende opslagruimte beschikbaar is) of extern in Azure Blob Storage. De beste prestaties worden bereikt wanneer een bestand lokaal wordt geschreven, omdat hierdoor netwerkoverhead wordt vermeden.

    Om de vereisten voor opslag en netwerkoverdracht te minimaliseren, is het raadzaam om de geëxtraheerde gegevensbestanden te comprimeren met behulp van een hulpprogramma zoals gzip.

    Zodra de platte bestanden zijn uitgepakt, kunnen ze worden verplaatst naar Azure Blob Storage (in een colocatie met het doelexemplaar Azure Synapse) of rechtstreeks in Azure Synapse worden geladen met behulp van PolyBase of COPY INTO. De methode voor het fysiek verplaatsen van gegevens van lokale on-premises opslag naar de Azure-cloudomgeving is afhankelijk van de hoeveelheid gegevens en de beschikbare netwerkbandbreedte.

    Microsoft biedt verschillende opties voor het verplaatsen van grote hoeveelheden gegevens, waaronder AZCopy voor het verplaatsen van bestanden via het netwerk naar Azure Storage, Azure ExpressRoute voor het verplaatsen van bulkgegevens via een privénetwerkverbinding en Azure Data Box waar de bestanden worden verplaatst naar een fysiek opslagapparaat dat vervolgens naar een Azure-datacenter wordt verzonden om te worden geladen. Zie Gegevensoverdracht voor meer informatie.

  • Direct extraheren en laden via het netwerk: de Azure-doelomgeving verzendt een aanvraag voor het ophalen van gegevens, normaal gesproken via een SQL-opdracht, naar het verouderde Teradata-systeem om de gegevens te extraheren. De resultaten worden via het netwerk verzonden en rechtstreeks in Azure Synapse geladen, zonder dat de gegevens in tussenliggende bestanden hoeven te worden geplaatst. De beperkende factor in dit scenario is normaal gesproken de bandbreedte van de netwerkverbinding tussen de Teradata-database en de Azure-omgeving. Voor zeer grote gegevensvolumes is deze aanpak mogelijk niet praktisch.

Er is ook een hybride benadering waarbij beide methoden worden gebruikt. U kunt bijvoorbeeld de benadering voor direct netwerkextract gebruiken voor kleinere dimensietabellen en voorbeelden van de grotere feitentabellen om snel een testomgeving te bieden in Azure Synapse. Voor de historische feitentabellen met grote volumes kunt u de methode voor het uitpakken en overdragen van bestanden gebruiken met behulp van Azure Data Box.

Wilt u organiseren vanuit Teradata of Azure?

De aanbevolen aanpak bij het overstappen naar Azure Synapse is het extraheren en laden van gegevens uit de Azure-omgeving te organiseren met behulp van Azure Synapse Pipelines of Azure Data Factory, evenals de bijbehorende hulpprogramma's, zoals PolyBase of COPY INTO, voor het efficiënt laden van gegevens. Deze benadering maakt gebruik van de mogelijkheden van Azure en biedt een eenvoudige methode voor het bouwen van herbruikbare pijplijnen voor het laden van gegevens.

Andere voordelen van deze aanpak zijn een verminderde impact op het Teradata-systeem tijdens het laden van gegevens omdat het beheer- en laadproces in Azure wordt uitgevoerd, en de mogelijkheid om het proces te automatiseren met behulp van pijplijnen voor het laden van metagegevens.

Welke hulpprogramma's kunnen worden gebruikt?

De taak van gegevenstransformatie en -verplaatsing is de basisfunctie van alle ETL-producten. Als een van deze producten al in gebruik is in de bestaande Teradata-omgeving, kan het gebruik van het bestaande ETL-hulpprogramma de gegevensmigratie van Teradata naar Azure Synapse vereenvoudigen. Bij deze benadering wordt ervan uitgegaan dat het ETL-hulpprogramma Azure Synapse als doelomgeving ondersteunt. Zie Partners voor gegevensintegratie voor meer informatie over hulpprogramma's die ondersteuning bieden voor Azure Synapse.

Als u een ETL-hulpprogramma gebruikt, kunt u overwegen dat hulpprogramma uit te voeren in de Azure-omgeving om te profiteren van azure-cloudprestaties, schaalbaarheid en kosten, en resources vrij te maken in het Teradata-datacenter. Een ander voordeel is een verminderde gegevensverplaatsing tussen de cloud en on-premises omgevingen.

Samenvatting

Samenvattend zijn onze aanbevelingen voor het migreren van gegevens en bijbehorende ETL-processen van Teradata naar Azure Synapse:

  • Plan vooruit om een geslaagde migratie te garanderen.

  • Maak een gedetailleerde inventaris van gegevens en processen die zo snel mogelijk moeten worden gemigreerd.

  • Gebruik systeemmetagegevens en logboekbestanden om een nauwkeurig inzicht te krijgen in het gebruik van gegevens en processen. Vertrouw niet op documentatie, omdat deze mogelijk verouderd is.

  • Inzicht in de gegevensvolumes die moeten worden gemigreerd en de netwerkbandbreedte tussen het on-premises datacenter en Azure-cloudomgevingen.

  • Overweeg het gebruik van een Teradata-exemplaar in een Virtuele Azure-machine als stap voor het offloaden van migratie vanuit de verouderde Teradata-omgeving.

  • Maak gebruik van standaard 'ingebouwde' Azure-functies om de migratieworkload te minimaliseren.

  • Identificeer en begrijp de meest efficiënte hulpprogramma's voor het extraheren en laden van gegevens in zowel Teradata- als Azure-omgevingen. Gebruik de juiste hulpprogramma's in elke fase van het proces.

  • Gebruik Azure-faciliteiten, zoals Azure Synapse Pipelines of Azure Data Factory, om het migratieproces te organiseren en te automatiseren terwijl de impact op het Teradata-systeem wordt geminimaliseerd.

Volgende stappen

Zie het volgende artikel in deze reeks voor meer informatie over beveiligingstoegangsbewerkingen: Beveiliging, toegang en bewerkingen voor Teradata-migraties.