Migrace dat, ETL a načítání pro migrace Teradata

Článek
06/01/2023

Tento článek je druhou částí sedmidílné série, která poskytuje pokyny k migraci z Teradata na Azure Synapse Analytics. Tento článek se zaměřuje na osvědčené postupy pro etl a migraci zatížení.

Aspekty migrace dat

Počáteční rozhodnutí o migraci dat z Teradata

Při migraci datového skladu Teradata je potřeba položit několik základních otázek souvisejících s daty. Příklad:

Mají se migrovat nepoužívané struktury tabulek?
Jaký je nejlepší přístup k migraci, aby se minimalizovalo riziko a dopad na uživatele?
Při migraci datových tržítků: Zůstat fyzicky nebo virtuální?

Následující části popisují tyto body v kontextu migrace z Teradata.

Migrovat nepoužívané tabulky?

Tip

Ve starších systémech není neobvyklé, že tabulky budou v průběhu času redundantní – ve většině případů se nemusí migrovat.

Je vhodné migrovat jenom tabulky, které se používají v existujícím systému. Tabulky, které nejsou aktivní, se dají místo migrace archivovat, aby data byla v budoucnu v případě potřeby k dispozici. K určení, které tabulky se používají, je nejlepší místo dokumentace použít systémová metadata a soubory protokolů, protože dokumentace může být za aktuální.

Pokud je tato možnost povolená, obsahují tabulky a protokoly systémového katalogu Teradata informace, které můžou určit, kdy byla daná tabulka naposledy přístupná, a které se pak dají použít k rozhodnutí, jestli je tabulka kandidátem na migraci.

Tady je příklad dotazu s DBC.Tables datem posledního přístupu a poslední úpravou:

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

Pokud je protokolování povolené a historie protokolů je přístupná, jsou v tabulce DBQLogTbl a přidružených tabulkách protokolování k dispozici další informace, například text dotazu SQL. Další informace najdete v tématu Historie protokolu Teradata.

Jaký je nejlepší přístup k migraci, aby se minimalizovalo riziko a dopad na uživatele?

Tato otázka přichází často, protože společnosti mohou chtít snížit dopad změn na datový model datového skladu, aby se zlepšila flexibilita. Společnosti často vidí příležitost k další modernizaci nebo transformaci dat během migrace ETL. Tento přístup s sebou nese vyšší riziko, protože současně mění více faktorů, což ztěžuje porovnání výsledků starého systému s novým. Změny datového modelu v této části by také mohly ovlivnit nadřazené nebo podřízené úlohy ETL do jiných systémů. Vzhledem k tomuto riziku je lepší po migraci datového skladu tento rozsah přepracovat.

I když se datový model v rámci celkové migrace záměrně změní, je vhodné stávající model migrovat tak, jak je, a Azure Synapse, místo aby se na nové platformě přepracovávat. Tento přístup minimalizuje dopad na stávající produkční systémy a zároveň těží z výkonu a elastické škálovatelnosti platformy Azure pro jednorázové přepracování úloh.

Při migraci z Teradata zvažte vytvoření prostředí Teradata na virtuálním počítači v Rámci Azure jako odrazového můstku v procesu migrace.

Tip

Migrace stávajícího modelu tak, jak je, i když se v budoucnu plánuje změna datového modelu.

Použití instance Teradata virtuálního počítače v rámci migrace

Jedním z volitelných přístupů k migraci z místního prostředí Teradata je využít prostředí Azure k vytvoření instance Teradata na virtuálním počítači v rámci Azure, která bude v souladu s cílovým Azure Synapse prostředím. To je možné, protože Azure poskytuje levné cloudové úložiště a elastickou škálovatelnost.

S tímto přístupem je možné použít standardní nástroje Teradata, jako je Teradata Parallel Data Transporter nebo nástroje pro replikaci dat třetích stran, jako je Replikace attunity, k efektivnímu přesunu podmnožin tabulek Teradata, které je potřeba migrovat do instance virtuálního počítače. Všechny úlohy migrace pak můžou probíhat v prostředí Azure. Tento přístup má několik výhod:

Po počáteční replikaci dat nemají úlohy migrace vliv na zdrojový systém.
Prostředí Azure má známá rozhraní, nástroje a nástroje Teradata.
Prostředí Azure poskytuje dostupnost šířky pásma sítě mezi místním zdrojovým systémem a cílovým cloudovým systémem.
Nástroje jako Azure Data Factory můžou efektivně volat nástroje, jako je Teradata Parallel Transporter, a rychle a snadno migrovat data.
Proces migrace se orchestruje a řídí zcela v rámci prostředí Azure.

Při migraci datových tržítků: Zůstat fyzicky nebo virtuální?

Tip

Virtualizace datových tržítků může ušetřit prostředky úložiště a zpracování.

Ve starších prostředích datového skladu Teradata je běžným postupem vytvořit několik datových tržítek, která jsou strukturovaná tak, aby poskytovala dobrý výkon pro ad hoc samoobslužné dotazy a sestavy pro dané oddělení nebo obchodní funkce v rámci organizace. Datové tržiště se proto obvykle skládá z podmnožiny datového skladu a obsahuje agregované verze dat ve formě, která uživatelům umožňuje snadno se na tato data dotazovat s rychlou dobou odezvy pomocí uživatelsky přívětivých dotazovacích nástrojů, jako jsou Microsoft Power BI, Tableau nebo MicroStrategy. Tento formulář je obvykle dimenzionální datový model. Jedním z použití datových tržítků je zveřejnění dat v použitelné podobě, a to i v případě, že podkladový datový model skladu je něco jiného, například trezor dat.

Samostatná datová tržiště pro jednotlivé obchodní jednotky v rámci organizace můžete použít k implementaci robustních režimů zabezpečení dat tím, že uživatelům povolíte přístup pouze ke konkrétním datovým tržinám, která jsou pro ně relevantní, a odstraníte, zamlžujete nebo anonymizujete citlivá data.

Pokud jsou tato datová tržiště implementovaná jako fyzické tabulky, budou k jejich uložení vyžadovat další prostředky úložiště a další zpracování, aby je bylo možné pravidelně sestavovat a aktualizovat. Data v tržině budou také pouze aktuální jako poslední operace aktualizace, a proto mohou být nevhodná pro vysoce nestálé řídicí panely dat.

Tip

Výkon a škálovatelnost Azure Synapse umožňují virtualizaci bez obětování výkonu.

S nástupem relativně levných škálovatelných architektur MPP, jako je Azure Synapse, a inherentních charakteristik výkonu těchto architektur může být možné, že můžete poskytovat funkce datového tržiště, aniž byste museli vytvořit instanci tržiště jako sady fyzických tabulek. Toho lze dosáhnout efektivní virtualizací datových tržítků prostřednictvím zobrazení SQL do hlavního datového skladu nebo prostřednictvím vrstvy virtualizace pomocí funkcí, jako jsou zobrazení v Azure nebo produkty vizualizace partnerů Microsoftu. Tento přístup zjednodušuje nebo eliminuje potřebu dalšího zpracování úložiště a agregace a snižuje celkový počet databázových objektů, které se mají migrovat.

Tento přístup má další potenciální výhodu. Implementací logiky agregace a spojení v rámci vrstvy virtualizace a prezentováním externích nástrojů pro vytváření sestav prostřednictvím virtualizovaného zobrazení se zpracování potřebné k vytvoření těchto zobrazení "posune dolů" do datového skladu, což je obecně nejlepší místo pro spouštění spojení, agregací a dalších souvisejících operací na velkých objemech dat.

Primárními faktory pro výběr implementace virtuálního datového tržiště před fyzickým datovým tržištěm jsou:

Větší flexibilita: Virtuální datové tržiště se snadněji mění než fyzické tabulky a přidružené procesy ETL.
Nižší celkové náklady na vlastnictví: Virtualizovaná implementace vyžaduje méně úložišť dat a kopií dat.
Odstranění úloh ETL za účelem migrace a zjednodušení architektury datového skladu ve virtualizovaném prostředí
Výkon: Přestože fyzická datová tržiště byla v minulosti výkonnější, produkty virtualizace teď implementují inteligentní techniky ukládání do mezipaměti, které zmírňují jejich zmírnění.

Migrace dat z Teradata

Vysvětlení dat

Součástí plánování migrace je podrobné pochopení objemu dat, která je potřeba migrovat, protože to může mít vliv na rozhodování o přístupu k migraci. Pomocí systémových metadat můžete určit fyzický prostor, který "nezpracovaná data" zabírají v tabulkách, které se mají migrovat. V tomto kontextu "nezpracovaná data" znamenají množství místa, které využívají řádky dat v tabulce, s výjimkou režijních nákladů, jako jsou indexy a komprese. To platí zejména pro největší tabulky faktů, protože tyto tabulky obvykle tvoří více než 95 % dat.

Přesný počet dat, která se mají migrovat pro danou tabulku, můžete získat extrahováním reprezentativního vzorku dat – například jednoho milionu řádků – do nekomprimovaného datového souboru ASCII s oddělovači. Potom pomocí velikosti tohoto souboru získáte průměrnou nezpracovanou velikost dat na řádek dané tabulky. Nakonec vynásobte průměrnou velikost celkovým počtem řádků v celé tabulce, abyste získali nezpracovanou velikost dat pro tabulku. Tuto nezpracovanou velikost dat použijte při plánování.

Aspekty migrace ETL

Počáteční rozhodnutí týkající se migrace Teradata ETL

Tip

Naplánujte přístup k migraci ETL předem a v případě potřeby využijte zařízení Azure.

Pro zpracování ETL/ELT můžou starší datové sklady Teradata používat vlastní skripty pomocí nástrojů Teradata, jako jsou BTEQ a Teradata Parallel Transporter (TPT), nebo nástroje ETL třetích stran, jako je Informatica nebo Ab Initio. Někdy datové sklady Teradata používají kombinaci přístupů ETL a ELT, které se v průběhu času vyvíjejí. Při plánování migrace do Azure Synapse musíte určit nejlepší způsob implementace požadovaného zpracování ETL/ELT v novém prostředí a zároveň minimalizovat náklady a rizika. Další informace o zpracování ETL a ELT najdete v tématu Přístup k návrhu ELT vs ETL.

Následující části popisují možnosti migrace a obsahují doporučení pro různé případy použití. Tento vývojový diagram shrnuje jeden přístup:

Vývojový diagram možností migrace a doporučení

Prvním krokem je vždy vytvoření inventáře procesů ETL/ELT, které je potřeba migrovat. Stejně jako u jiných kroků je možné, že díky standardním "integrovaným" funkcím Azure není nutné migrovat některé stávající procesy. Pro účely plánování je důležité porozumět rozsahu migrace, která se má provést.

V předchozím vývojovém diagramu se rozhodnutí 1 týká základního rozhodnutí o tom, jestli provést migraci do zcela nativního prostředí Azure. Pokud přecházíte do zcela nativního prostředí Azure, doporučujeme přepracovat zpracování ETL pomocí kanálů a aktivit v Azure Data Factory nebo Azure Synapse Pipelines. Pokud nepřecháháte do zcela nativního prostředí Azure, pak rozhodnutí 2 spočívá v tom, jestli se už používá existující nástroj ETL třetí strany.

V prostředí Teradata mohou některé nebo všechna zpracování ETL provádět vlastní skripty pomocí nástrojů specifických pro Teradata, jako jsou BTEQ a TPT. V takovém případě byste měli provést přepracování pomocí služby Data Factory.

Tip

Využijte investice do stávajících nástrojů třetích stran ke snížení nákladů a rizika.

Pokud se nástroj ETL třetí strany už používá, a zejména pokud se do dovedností hodně investovalo nebo ho používá několik stávajících pracovních postupů a plánů, pak se rozhoduje 3, jestli nástroj dokáže efektivně podporovat Azure Synapse jako cílové prostředí. V ideálním případě bude tento nástroj obsahovat "nativní" konektory, které můžou využívat služby Azure, jako je PolyBase nebo COPY INTO, k co nejefektivnějšímu načítání dat. Existuje způsob, jak volat externí proces, jako je PolyBase nebo COPY INTO, a předat příslušné parametry. V takovém případě využijte stávající dovednosti a pracovní postupy, Azure Synapse jako nové cílové prostředí.

Pokud se rozhodnete zachovat existující nástroj ETL třetí strany, může mít výhody spuštění tohoto nástroje v prostředí Azure (nikoli na existujícím místním serveru ETL) a Azure Data Factory zpracovávat celkovou orchestraci stávajících pracovních postupů. Jednou z konkrétních výhod je, že z Azure je potřeba stahovat méně dat, zpracovávat je a pak nahrávat zpět do Azure. Rozhodnutí 4 tedy spočívá v tom, jestli nechat stávající nástroj spuštěný tak, jak je, nebo ho přesunout do prostředí Azure, abyste dosáhli výhod nákladů, výkonu a škálovatelnosti.

Přepracování existujících skriptů specifických pro Teradata

Pokud některé nebo veškeré stávající zpracování ETL/ELT datového skladu Teradata zpracovávají vlastní skripty, které využívají nástroje specifické pro Teradata, jako je BTEQ, MLOAD nebo TPT, je potřeba tyto skripty překódovat pro nové prostředí Azure Synapse. Podobně pokud se procesy ETL implementovaly pomocí uložených procedur v Teradata, bude nutné je také překódovat.

Tip

Inventář úloh ETL, které se mají migrovat, by měl obsahovat skripty a uložené procedury.

Některé prvky procesu ETL se dají snadno migrovat, například jednoduchým hromadným načtením dat z externího souboru do pracovní tabulky. Je dokonce možné tyto části procesu automatizovat, například pomocí PolyBase místo rychlého načítání nebo MLOAD. Pokud jsou exportované soubory Parquet, můžete použít nativní čtečku Parquet, což je rychlejší možnost než PolyBase. Další části procesu, které obsahují libovolně složité sql a/nebo uložené procedury, budou trvat delší dobu, než se přepracují.

Jedním ze způsobů, jak otestovat kompatibilitu Teradata SQL s Azure Synapse, je zachytit některé reprezentativní příkazy SQL z protokolů Teradata, pak před tyto dotazy EXPLAINvytvořit předponu a pak (za předpokladu migrovaného datového modelu podobného typu v Azure Synapse) spustit tyto EXPLAIN příkazy v Azure Synapse. Jakýkoli nekompatibilní SQL vygeneruje chybu a informace o chybě můžou určit měřítko přepočítávání úlohy.

Partneři Microsoftu nabízejí nástroje a služby pro migraci teradata SQL a uložených procedur do Azure Synapse.

Použití nástrojů ETL třetích stran

Jak je popsáno v předchozí části, v mnoha případech bude stávající starší systém datového skladu již naplněn a udržován produkty ETL třetích stran. Seznam partnerů microsoftu pro integraci dat pro Azure Synapse najdete v tématu Partneři pro integraci dat.

Načítání dat z Teradata

Tip

Nástroje třetích stran můžou proces migrace zjednodušit a automatizovat, a tím snížit riziko.

Pokud jde o migraci dat z datového skladu Teradata, existuje několik základních otázek souvisejících s načítáním dat, které je potřeba vyřešit. Budete muset rozhodnout, jak se data fyzicky přesunou z existujícího místního prostředí Teradata do Azure Synapse v cloudu a které nástroje se použijí k provedení přenosu a načítání. Zvažte následující otázky, které jsou popsány v dalších částech.

Budete extrahovat data do souborů nebo je přesunout přímo přes síťové připojení?
Budete orchestrovat proces ze zdrojového systému nebo z cílového prostředí Azure?
Které nástroje použijete k automatizaci a správě procesu?

Chcete přenášet data prostřednictvím souborů nebo síťového připojení?

Tip

Seznamte se s objemy dat, které se mají migrovat, a dostupnou šířkou pásma sítě, protože tyto faktory ovlivňují rozhodování o přístupu k migraci.

Po vytvoření databázových tabulek, které se mají migrovat v Azure Synapse, můžete data přesunout a naplnit je ze staršího systému Teradata do nového prostředí. Existují dva základní přístupy:

Extrakce souboru: Extrahujte data z tabulek Teradata do plochých souborů, obvykle ve formátu CSV, prostřednictvím BTEQ, rychlého exportu nebo paralelního transporteru Teradata (TPT). TpT používejte, kdykoli je to možné, protože je to nejúčinnější z hlediska propustnosti dat.

Tento přístup vyžaduje místo pro získání extrahovaných datových souborů. Prostor může být místní pro zdrojovou databázi Teradata (pokud je k dispozici dostatečné úložiště) nebo vzdálené v Azure Blob Storage. Nejlepšího výkonu dosáhnete při místním zápisu souboru, protože se tím vyhnete režii sítě.

Pokud chcete minimalizovat požadavky na úložiště a síťový přenos, je vhodné zkomprimovat extrahované datové soubory pomocí nástroje, jako je gzip.

Po extrahování mohou být ploché soubory přesunuty do Azure Blob Storage (společně s cílovou Azure Synapse instancí) nebo načteny přímo do Azure Synapse pomocí PolyBase nebo COPY INTO. Metoda fyzického přesunu dat z místního úložiště do cloudového prostředí Azure závisí na množství dat a dostupné šířce pásma sítě.

Microsoft nabízí různé možnosti pro přesun velkých objemů dat, včetně AZCopy pro přesun souborů v síti do služby Azure Storage, Azure ExpressRoute pro přesun hromadných dat přes privátní síťové připojení a Azure Data Boxu, kde se soubory přesunou do fyzického paměťového zařízení, které se pak odešle do datacentra Azure k načtení. Další informace najdete v tématu Přenos dat.
Přímé extrakce a načítání přes síť: Cílové prostředí Azure odešle požadavek na extrakci dat, obvykle prostřednictvím příkazu SQL, do staršího systému Teradata, který extrahuje data. Výsledky se odesílají přes síť a načtou se přímo do Azure Synapse, aniž by bylo nutné převést data do přechodných souborů. Omezujícím faktorem v tomto scénáři je obvykle šířka pásma síťového připojení mezi databází Teradata a prostředím Azure. U velmi velkých objemů dat nemusí být tento přístup praktický.

Existuje také hybridní přístup, který používá obě metody. Pro menší tabulky dimenzí a vzorky větších tabulek faktů můžete například použít přístup extrakce přímo ze sítě, abyste rychle poskytli testovací prostředí v Azure Synapse. Pro velké objemy historických tabulek faktů můžete použít přístup k extrakci a přenosu souborů pomocí Azure Data Boxu.

Chcete orchestrovat z Teradata nebo Azure?

Doporučeným přístupem při přechodu na Azure Synapse je orchestrace extrakce a načítání dat z prostředí Azure pomocí služby Azure Synapse Pipelines nebo Azure Data Factory a také přidružených nástrojů, jako je PolyBase nebo COPY INTO, pro co nejefektivnější načítání dat. Tento přístup využívá možnosti Azure a poskytuje snadný způsob vytváření opakovaně použitelných kanálů načítání dat.

Mezi další výhody tohoto přístupu patří menší dopad na systém Teradata během procesu načítání dat, protože proces správy a načítání běží v Azure, a možnost automatizovat proces pomocí kanálů načítání dat založených na metadatech.

Které nástroje je možné použít?

Úkolem transformace a přesunu dat je základní funkcí všech produktů ETL. Pokud se některý z těchto produktů už používá v existujícím prostředí Teradata, může použití existujícího nástroje ETL zjednodušit migraci dat z Teradata do Azure Synapse. Tento přístup předpokládá, že nástroj ETL podporuje Azure Synapse jako cílové prostředí. Další informace o nástrojích, které podporují Azure Synapse, najdete v tématu Partneři pro integraci dat.

Pokud používáte nástroj ETL, zvažte jeho spuštění v prostředí Azure, abyste mohli těžit z výkonu, škálovatelnosti a nákladů cloudu Azure a uvolnit prostředky v datacentru Teradata. Další výhodou je menší přesun dat mezi cloudem a místním prostředím.

Souhrn

Abychom to shrnuli, naše doporučení pro migraci dat a přidružených procesů ETL z Teradata do Azure Synapse jsou:

Naplánujte předem, abyste zajistili úspěšné cvičení migrace.
Vytvořte podrobný inventář dat a procesů, které se mají migrovat co nejdříve.
Pomocí systémových metadat a souborů protokolů můžete přesně porozumět datům a využití procesů. Nespoléhejte na dokumentaci, protože může být za aktuální.
Seznamte se s objemy dat, které se mají migrovat, a šířkou pásma sítě mezi místním datacentrem a cloudovými prostředími Azure.
Zvažte použití instance Teradata na virtuálním počítači Azure jako odrazového můstku pro přesměrování migrace ze staršího prostředí Teradata.
Využijte standardní integrované funkce Azure k minimalizaci úloh migrace.
Identifikujte a seznamte se s nejúčinnějšími nástroji pro extrakci a načítání dat v prostředíCh Teradata i Azure. V každé fázi procesu používejte příslušné nástroje.
Pomocí zařízení Azure, jako jsou Azure Synapse Pipelines nebo Azure Data Factory, můžete orchestrovat a automatizovat proces migrace a zároveň minimalizovat dopad na systém Teradata.

Další kroky

Další informace o operacích zabezpečení přístupu najdete v dalším článku této série: Zabezpečení, přístup a operace pro migrace Teradata.

Sdílet prostřednictvím