Megosztás a következőn keresztül:

Adatmigrálás, ETL és betöltés a Teradata-migrálásokhoz

  • Cikk

Ez a cikk egy hétrészes sorozat második része, amely útmutatást nyújt a Teradata-ból Azure Synapse Analyticsbe való migráláshoz. A cikk középpontjában az ETL és a terhelés migrálásának ajánlott eljárásai áll.

Adatmigrálási szempontok

Kezdeti döntések a Teradata-ból történő adatmigrálással kapcsolatban

Teradata-adattárház migrálásakor fel kell tennie néhány alapvető, adatokkal kapcsolatos kérdést. Például:

  • Át kell migrálni a nem használt táblastruktúrát?

  • Mi a legjobb migrálási módszer a kockázat és a felhasználói hatás minimalizálása érdekében?

  • Adatpiacok migrálásakor: maradjon fizikai vagy virtuális?

A következő szakaszok ezeket a pontokat tárgyalják a Teradata-ból való migrálás kontextusában.

Migrálja a nem használt táblákat?

Tipp

Az örökölt rendszerekben nem szokatlan, hogy a táblák idővel redundánssá válnak – ezeket a legtöbb esetben nem kell migrálni.

Célszerű csak a meglévő rendszerben használt táblákat migrálni. A nem aktív táblák archiválhatók a migrálás helyett, így az adatok szükség esetén a jövőben elérhetők lesznek. A legjobb, ha a rendszer metaadatait és naplófájljait használja a dokumentáció helyett annak meghatározásához, hogy mely táblák vannak használatban, mert a dokumentáció elavult lehet.

Ha engedélyezve van, a Teradata rendszerkatalógus-táblái és -naplói olyan információkat tartalmaznak, amelyek meghatározzák, hogy egy adott tábla mikor volt utoljára elérve – ezzel pedig eldönthető, hogy a tábla migrálásra alkalmas-e.

Íme egy példa lekérdezés, DBC.Tables amely az utolsó hozzáférés dátumát és az utolsó módosítást tartalmazza:

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

Ha a naplózás engedélyezve van, és a naplóelőzmények elérhetők, más információk, például az SQL-lekérdezés szövege is elérhető a DBQLogTbl táblában és a kapcsolódó naplózási táblákban. További információ: Teradata-naplóelőzmények.

Mi a legjobb migrálási módszer a kockázatok és a felhasználókra gyakorolt hatás minimalizálása érdekében?

Ez a kérdés gyakran merül fel, mert előfordulhat, hogy a vállalatok csökkenteni szeretnék a változások hatását az adattárház-adatmodellre az agilitás javítása érdekében. A vállalatok gyakran látnak lehetőséget adataik további modernizálására vagy átalakítására az ETL-migrálás során. Ez a megközelítés nagyobb kockázatot jelent, mivel egyszerre több tényezőt módosít, ami megnehezíti a régi rendszer és az új eredményeinek összehasonlítását. Az adatmodell itt történő módosítása hatással lehet a felsőbb vagy alsóbb rétegbeli ETL-feladatokra más rendszerekre is. Emiatt a kockázat miatt érdemesebb újratervezni ezt a méretet az adattárház migrálása után.

Még ha az adatmodellt szándékosan is megváltoztatják a teljes migrálás részeként, célszerű a meglévő modellt úgy migrálni, hogy Azure Synapse, és ne az új platformon végezze el az újratervezést. Ez a megközelítés minimálisra csökkenti a meglévő éles rendszerekre gyakorolt hatást, miközben kihasználja az Azure-platform teljesítményét és rugalmas méretezhetőségét az egyszeri újratervezési feladatokhoz.

A Teradata-ból való migrálás során érdemes lehet egy Teradata-környezetet létrehozni egy Azure-beli virtuális gépen a migrálási folyamat ugródeszkajaként.

Tipp

A meglévő modell migrálása kezdetben még akkor is, ha az adatmodellt a jövőben módosítani tervezik.

Virtuálisgép-teradata-példány használata migrálás részeként

A helyszíni Teradata-környezetből való migrálás egyik választható módszere, ha az Azure-környezettel hoz létre egy Teradata-példányt egy Azure-beli virtuális gépen, amely a cél Azure Synapse környezettel van társítva. Ez azért lehetséges, mert az Azure olcsó felhőalapú tárolást és rugalmas méretezhetőséget biztosít.

Ezzel a módszerrel a szabványos Teradata-segédprogramok, például a Teradata párhuzamos adattovábbító vagy külső adatreplikációs eszközök, például az Attunity Replication segítségével hatékonyan áthelyezhetők a virtuálisgép-példányba migrálni kívánt Teradata-táblák részhalmaza. Ezután az összes migrálási feladat elvégezhető az Azure-környezetben. Ennek a megközelítésnek számos előnye van:

  • Az adatok kezdeti replikálása után a migrálási feladatok nem lesznek hatással a forrásrendszerre.

  • Az Azure-környezet ismerős Teradata-felületekkel, -eszközökkel és -segédprogramokkal rendelkezik.

  • Az Azure-környezet hálózati sávszélességet biztosít a helyszíni forrásrendszer és a felhőbeli célrendszer között.

  • Az Azure Data Factory-hoz hasonló eszközök hatékonyan hívhatják meg az olyan segédprogramokat, mint a Teradata Parallel Transporter, hogy gyorsan és egyszerűen migrálják az adatokat.

  • A migrálási folyamat vezénylése és vezérlése teljes egészében az Azure-környezetben történik.

Adatpiacok migrálásakor: maradjon fizikai vagy virtuális?

Tipp

Az adatpiacok virtualizálása mentheti a tárolási és feldolgozási erőforrásokat.

Az örökölt Teradata-adattárház-környezetekben gyakori eljárás több olyan adatpiac létrehozása, amelyek úgy vannak strukturálva, hogy megfelelő teljesítményt nyújtsanak egy adott részleg vagy üzleti funkció alkalmi önkiszolgáló lekérdezéseihez és jelentéseihez egy szervezeten belül. Így az adatpiacok általában az adattárház egy részhalmazából származnak, és olyan formában tartalmazzák az adatok összesített verzióit, amely lehetővé teszi a felhasználók számára, hogy gyorsan lekérdezhetik ezeket az adatokat gyors válaszidővel olyan felhasználóbarát lekérdezési eszközökkel, mint a Microsoft Power BI, a Tableau vagy a MicroStrategy. Ez az űrlap általában egy dimenziós adatmodell. Az adatpiacok egyik célja, hogy az adatokat használható formában tegye elérhetővé, még akkor is, ha az alapul szolgáló adattárház adatmodellje valami más, például egy adattároló.

A szervezeten belüli különálló üzleti egységekhez különálló adatpiacokat használhat robusztus adatbiztonsági rendszerek implementálásához, ha csak a felhasználók számára engedélyezi a számukra releváns adatpiacokhoz való hozzáférést, valamint a bizalmas adatok megszüntetését, elrejtését vagy anonimizálását.

Ha ezek az adatpiacok fizikai táblákként vannak implementálva, további tárolási erőforrásokra lesz szükségük a tárolásukhoz, valamint további feldolgozásra a rendszeres létrehozásukhoz és frissítésükhöz. Emellett a martban lévő adatok csak az utolsó frissítési művelethez lesznek naprakészek, így nem alkalmasak a rendkívül volatilis adat irányítópultokra.

Tipp

A Azure Synapse teljesítménye és méretezhetősége a teljesítmény feláldozása nélkül teszi lehetővé a virtualizálást.

A viszonylag alacsony költségű, skálázható MPP-architektúrák, például a Azure Synapse megjelenésével és az ilyen architektúrák eredendő teljesítményjellemzőivel lehetséges, hogy anélkül biztosíthatja az adatpiac funkcióit, hogy fizikai táblák készleteként kellene példányosítania a martot. Ez úgy érhető el, hogy hatékonyan virtualizálja az adatpiacokat SQL-nézeteken keresztül a fő adattárházra, vagy egy virtualizálási rétegen keresztül olyan funkciókkal, mint az Azure-beli nézetek vagy a Microsoft-partnerek vizualizációs termékei. Ez a megközelítés leegyszerűsíti vagy szükségtelenné teszi a további tárolás és összesítés feldolgozását, és csökkenti az áttelepítendő adatbázis-objektumok teljes számát.

Ennek a megközelítésnek egy másik lehetséges előnye is lehet. Az összesítési és illesztési logika virtualizálási rétegen belüli implementálásával és a külső jelentéskészítő eszközök virtualizált nézeten keresztüli bemutatásával az ilyen nézetek létrehozásához szükséges feldolgozást "leküldi" az adattárházba, amely általában a legjobb hely az illesztések, aggregációk és más kapcsolódó műveletek nagy adatmennyiségeken való futtatásához.

A virtuális adatpiac implementációjának fizikai adatpiacon való kiválasztásához az elsődleges illesztőprogramok a következők:

  • Nagyobb rugalmasság: a virtuális adatpiacok könnyebben módosíthatók, mint a fizikai táblák és a kapcsolódó ETL-folyamatok.

  • Alacsonyabb teljes bekerülési költség: a virtualizált implementáció kevesebb adattárat és adatpéldányt igényel.

  • Az ETL-feladatok megszüntetése az adattárház architektúrájának virtualizált környezetben történő migrálásához és egyszerűsítéséhez.

  • Teljesítmény: bár a fizikai adatpiacok korábban sokkal nagyobb teljesítményűek voltak, a virtualizálási termékek mostantól intelligens gyorsítótárazási technikákat alkalmaznak a mérséklés érdekében.

Adatmigrálás a Teradata-ból

Az adatok értelmezése

A migrálás megtervezésének része az áttelepítendő adatok mennyiségének részletes megismerése, mivel ez hatással lehet a migrálási megközelítéssel kapcsolatos döntésekre. Használja a rendszer metaadatait a migrálni kívánt táblákban lévő "nyers adatok" által elfoglalt fizikai terület meghatározásához. Ebben az összefüggésben a "nyers adatok" a tábla adatsorai által felhasznált térközt jelentik, az olyan többletterhelések nélkül, mint az indexek és a tömörítés. Ez különösen igaz a legnagyobb ténytáblákra, mivel ezek általában az adatok több mint 95%-át teszik ki.

Egy adott táblához migrálandó adatok mennyiségének pontos számát úgy kaphatja meg, hogy kinyer egy reprezentatív mintát az adatokból – például egymillió sort – egy tömörítetlen, tagolt, egybesimított ASCII-adatfájlba. Ezután a fájl méretével lekérheti a tábla soronkénti átlagos nyers adatméretét. Végül szorozza meg ezt az átlagos méretet a teljes táblázat sorainak teljes számával, hogy nyers adatméretet adjon a táblának. Használja ezt a nyers adatméretet a tervezés során.

Az ETL migrálási szempontjai

A Teradata ETL migrálásával kapcsolatos kezdeti döntések

Tipp

Előre tervezze meg az ETL-migrálás megközelítését, és szükség esetén használja ki az Azure-beli létesítményeket.

Az ETL-/ELT-feldolgozáshoz az örökölt Teradata-adattárházak egyénileg létrehozott szkripteket használhatnak Olyan Teradata-segédprogramokkal, mint a BTEQ és a Teradata Parallel Transporter (TPT), vagy külső ETL-eszközök, például az Informatica vagy az Ab Initio. A Teradata-adattárházak néha az ETL és az ELT megközelítések kombinációját használják, amelyek idővel fejlődnek. A Azure Synapse-be történő migrálás tervezésekor meg kell határoznia a szükséges ETL/ELT-feldolgozás új környezetben való megvalósításának legjobb módját, ugyanakkor minimalizálnia kell az ezzel járó költségeket és kockázatokat. Az ETL- és ELT-feldolgozással kapcsolatos további információkért lásd: ELT és ETL tervezési megközelítés.

A következő szakaszok a migrálási lehetőségeket ismertetik, és javaslatokat adnak a különböző használati esetekre. Ez a folyamatábra egy megközelítést foglal össze:

A migrálási lehetőségek és javaslatok folyamatábraja.

Az első lépés mindig a migrálni kívánt ETL-/ELT-folyamatok leltárának összeállítása. A többi lépéshez hasonlóan lehetséges, hogy a szabványos "beépített" Azure-funkciók szükségtelenek egyes meglévő folyamatok migrálásához. Tervezési célokból fontos megérteni a migrálás skáláját.

Az előző folyamatábra 1. döntése egy magas szintű döntéshez kapcsolódik, amely azt határozza meg, hogy teljesen natív Azure-környezetbe szeretne-e migrálni. Ha teljesen natív Azure-környezetbe költözik, javasoljuk, hogy a folyamatok és tevékenységek használatával újra tervezhesse az ETL-feldolgozást Azure Data Factory vagy Azure Synapse Pipelinesban. Ha nem egy teljesen natív Azure-környezetbe költözik, akkor a 2. döntés az, hogy már használatban van-e egy meglévő külső ETL-eszköz.

A Teradata-környezetben az ETL-feldolgozás egy részét vagy egészét egyéni szkriptek hajthatják végre a Teradata-specifikus segédprogramokkal, például a BTEQ-vel és a TPT-vel. Ebben az esetben a Data Factory használatával kell újraterveződnie.

Tipp

A költségek és a kockázatok csökkentése érdekében használja ki a meglévő külső eszközökbe történő befektetést.

Ha egy harmadik féltől származó ETL-eszköz már használatban van, és különösen, ha jelentős befektetés történik a készségekbe, vagy több meglévő munkafolyamat és ütemezés használja ezt az eszközt, akkor a 3. döntés az, hogy az eszköz képes-e hatékonyan támogatni a Azure Synapse célkörnyezetként. Ideális esetben az eszköz olyan "natív" összekötőket tartalmaz, amelyek a leghatékonyabb adatbetöltéshez használhatnak olyan Azure-beli létesítményeket, mint a PolyBase vagy a COPY INTO. Meg lehet hívni egy külső folyamatot, például a PolyBase-t vagy COPY INTOa -t, és átadni a megfelelő paramétereket. Ebben az esetben használja ki a meglévő készségeket és munkafolyamatokat, és Azure Synapse az új célkörnyezet.

Ha úgy dönt, hogy megtart egy meglévő, harmadik féltől származó ETL-eszközt, előfordulhat, hogy az eszközt az Azure-környezetben (és nem egy meglévő helyszíni ETL-kiszolgálón) futtatja, és Azure Data Factory kezeli a meglévő munkafolyamatok általános vezénylését. Az egyik előnye, hogy kevesebb adatot kell letölteni az Azure-ból, feldolgozni, majd újra feltölteni az Azure-ba. A 4. döntés tehát az, hogy a meglévő eszközt változatlan állapotban hagyja-e, vagy áthelyezi az Azure-környezetbe a költségek, a teljesítmény és a méretezhetőség előnyeinek elérése érdekében.

Meglévő Teradata-specifikus szkriptek újratervezője

Ha a Meglévő Teradata-raktár ETL/ELT-feldolgozását teradata-specifikus segédprogramokat (például BTEQ, MLOAD vagy TPT) használó egyéni szkriptek kezelik, ezeket a szkripteket újra kell kódolni az új Azure Synapse környezethez. Hasonlóképpen, ha az ETL-folyamatokat tárolt eljárásokkal implementálták a Teradata-ban, akkor ezeket is újra kell kódolni.

Tipp

Az áttelepítendő ETL-feladatok leltárának szkripteket és tárolt eljárásokat kell tartalmaznia.

Az ETL-folyamat egyes elemei könnyen migrálhatóak, például egyszerű tömeges adatbetöltéssel egy külső fájlból egy előkészítési táblába. Akár a folyamat ezen részeit is automatizálhatja, például a PolyBase használatával a gyors terhelés vagy az MLOAD helyett. Ha az exportált fájlok Parquet-fájlok, használhat natív Parquet-olvasót, amely gyorsabb megoldás, mint a PolyBase. A folyamat más részei, amelyek tetszőleges összetett SQL- és/vagy tárolt eljárásokat tartalmaznak, több időt vesz igénybe az újratervező folyamat.

A Teradata SQL Azure Synapse való kompatibilitásának tesztelésének egyik módja, ha rögzít néhány reprezentatív SQL-utasítást a Teradata-naplókból, majd előtaggal telepíti ezeket a lekérdezéseket EXPLAINa , majd – feltételezve egy hasonló migrált adatmodellt a Azure Synapse-ben – futtatja ezeket az EXPLAIN utasításokat Azure Synapse. Minden inkompatibilis SQL hibát fog generálni, és a hibainformációk meghatározhatják az újrabehozási feladat skáláját.

A Microsoft-partnerek eszközöket és szolgáltatásokat kínálnak a Teradata SQL és a tárolt eljárások Azure Synapse való migrálásához.

Külső ETL-eszközök használata

Az előző szakaszban leírtak szerint a meglévő örökölt adattárházrendszert sok esetben már külső ETL-termékek töltik ki és tartják karban. Az Azure Synapse microsoftos adatintegrációs partnereinek listáját lásd: Adatintegrációs partnerek.

Adatok betöltése a Teradata-ból

A Teradata adatainak betöltésekor elérhető választási lehetőségek

Tipp

A külső eszközök leegyszerűsíthetik és automatizálhatják a migrálási folyamatot, és ezáltal csökkenthetik a kockázatot.

Az adatok Teradata-adattárházból való migrálásával kapcsolatban néhány alapvető kérdést meg kell oldani az adatbetöltéssel kapcsolatban. El kell döntenie, hogy az adatok hogyan lesznek fizikailag áthelyezve a meglévő helyszíni Teradata-környezetből a felhőben Azure Synapse, és mely eszközökkel végzi el az átvitelt és a terhelést. Vegye figyelembe a következő kérdéseket, amelyeket a következő szakaszokban tárgyalunk.

  • Kinyeri az adatokat fájlokba, vagy közvetlenül hálózati kapcsolaton keresztül helyezi át?

  • A folyamatot a forrásrendszerből vagy az Azure-célkörnyezetből fogja összehangolni?

  • Milyen eszközöket fog használni a folyamat automatizálásához és kezeléséhez?

Adatok átvitele fájlokon vagy hálózati kapcsolaton keresztül?

Tipp

Ismerje meg a migrálni kívánt adatmennyiségeket és a rendelkezésre álló hálózati sávszélességet, mivel ezek a tényezők befolyásolják a migrálási megközelítés döntését.

Miután létrehozta az áttelepítendő adatbázistáblákat Azure Synapse, áthelyezheti az adatokat, hogy feltöltse ezeket a táblákat az örökölt Teradata rendszerből és az új környezetbe. Két alapvető megközelítés létezik:

  • Fájlkivonat: bontsa ki az adatokat a Teradata-táblákból egybesimított fájlokba, általában CSV formátumban a BTEQ, a Fast Export vagy a Teradata Parallel Transporter (TPT) használatával. Amikor csak lehetséges, használja a TPT-t, mivel ez a leghatékonyabb az adatátmenet szempontjából.

    Ehhez a megközelítéshez hely szükséges a kinyert adatfájlok landzásához. A hely lehet helyi a Teradata forrásadatbázisban (ha elegendő tárterület áll rendelkezésre), vagy távoli lehet Azure Blob Storage. A legjobb teljesítmény akkor érhető el, ha a fájl helyileg van megírva, mivel ez elkerüli a hálózati terhelést.

    A tárolási és hálózatátviteli követelmények minimalizálása érdekében érdemes a kinyert adatfájlokat egy olyan segédprogrammal tömöríteni, mint a gzip.

    A kinyerés után az egybesimított fájlok áthelyezhetők Azure Blob Storage (a cél Azure Synapse példánysal együtt), vagy közvetlenül betölthetők Azure Synapse a PolyBase vagy a COPY INTO használatával. Az adatok helyi helyszíni tárolóból az Azure-felhőkörnyezetbe való fizikai áthelyezésének módja az adatok mennyiségétől és a rendelkezésre álló hálózati sávszélességtől függ.

    A Microsoft különböző lehetőségeket biztosít a nagy mennyiségű adat áthelyezésére, például az AZCopyt a fájlok az Azure Storage-ba való áthelyezéséhez, az Azure ExpressRoute-ot a tömeges adatok magánhálózati kapcsolaton keresztüli áthelyezéséhez, valamint az Azure Data Boxot, ahol a fájlokat áthelyezik egy fizikai tárolóeszközre, amelyet aztán egy Azure-adatközpontba szállítanak betöltés céljából. További információ: Adatátvitel.

  • Közvetlen kinyerés és betöltés a hálózaton keresztül: a cél Azure-környezet adatkivonat-kérést küld az adatok kinyeréséhez az örökölt Teradata-rendszernek, általában egy SQL-paranccsal. Az eredményeket a rendszer a hálózaton keresztül küldi el, és közvetlenül a Azure Synapse tölti be, és nem kell köztes fájlokba helyeznie az adatokat. Ebben a forgatókönyvben a korlátozó tényező általában a Teradata-adatbázis és az Azure-környezet közötti hálózati kapcsolat sávszélessége. A nagyon nagy adatmennyiségek esetében ez a megközelítés nem feltétlenül praktikus.

Van egy hibrid megközelítés is, amely mindkét módszert használja. Használhatja például a közvetlen hálózatkivonat-megközelítést a kisebb dimenziótáblákhoz és a nagyobb ténytáblák mintáihoz, hogy gyorsan biztosítson tesztkörnyezetet Azure Synapse. A nagy volumenű előzménytáblák esetében a fájlkivonat és -átvitel módszerét az Azure Data Box használatával használhatja.

Vezénylés a Teradata-ból vagy az Azure-ból?

A Azure Synapse való áttérés során az ajánlott módszer az adatok kinyerése és betöltése az Azure-környezetből Azure Synapse Pipelines vagy Azure Data Factory, valamint a kapcsolódó segédprogramok, például a PolyBase vagy a COPY INTO használatával történő vezénylése a leghatékonyabb adatbetöltés érdekében. Ez a megközelítés kihasználja az Azure képességeit, és egyszerű módszert biztosít az újrahasználható adatbetöltési folyamatok létrehozásához.

A módszer további előnyei közé tartozik a Teradata rendszerre gyakorolt kisebb hatás az adatbetöltési folyamat során, mivel a felügyeleti és betöltési folyamat az Azure-ban fut, valamint a folyamat metaadat-alapú adatbetöltési folyamatok használatával történő automatizálásának képessége.

Mely eszközök használhatók?

Az adatátalakítás és -áthelyezés feladata az összes ETL-termék alapvető funkciója. Ha ezen termékek egyike már használatban van a meglévő Teradata-környezetben, akkor a meglévő ETL-eszköz használata leegyszerűsítheti a Teradata-ból Azure Synapse való adatmigrálást. Ez a megközelítés feltételezi, hogy az ETL-eszköz célkörnyezetként támogatja a Azure Synapse. A Azure Synapse támogató eszközökkel kapcsolatos további információkért lásd: Adatintegrációs partnerek.

Ha ETL-eszközt használ, fontolja meg az eszköz Azure-környezetben való futtatását, hogy kihasználhassa az Azure felhőbeli teljesítményét, méretezhetőségét és költségeit, és erőforrásokat szabadítson fel a Teradata adatközpontban. Egy másik előny a felhő és a helyszíni környezetek közötti adatmozgás csökkentése.

Összefoglalás

Összefoglalva, az adatok és a kapcsolódó ETL-folyamatok Teradata-ból Azure Synapse való migrálására vonatkozó javaslataink a következők:

  • Tervezze meg előre a sikeres migrálást.

  • Készítsen részletes leltárt a migrálandó adatokról és folyamatokról, amint lehetséges.

  • A rendszer metaadatainak és naplófájljainak használatával pontos képet kaphat az adatokról és a folyamatok használatáról. Ne támaszkodj a dokumentációra, mert lehet, hogy elavult.

  • Megismerheti a migrálni kívánt adatköteteket, valamint a helyszíni adatközpont és az Azure-felhőkörnyezetek közötti hálózati sávszélességet.

  • Érdemes lehet egy Teradata-példányt használni egy Azure-beli virtuális gépen az örökölt Teradata-környezetből való migrálás kiszervezéséhez.

  • A migrálási számítási feladat minimálisra csökkentése érdekében használja a standard "beépített" Azure-funkciókat.

  • Megismerheti és megismerheti az adatkinyerés és -betöltés leghatékonyabb eszközeit Mind a Teradata, mind az Azure-környezetekben. A folyamat minden fázisában használja a megfelelő eszközöket.

  • Azure-beli létesítmények, például Azure Synapse Pipelines vagy Azure Data Factory használatával vezényelheti és automatizálhatja a migrálási folyamatot, miközben minimalizálja a Teradata rendszerre gyakorolt hatást.

Következő lépések

A biztonsági hozzáférési műveletekkel kapcsolatos további információkért tekintse meg a következő cikket ebben a sorozatban: Biztonság, hozzáférés és műveletek a Teradata-migrálásokhoz.