Datamigrering, ETL och dataladdning för Netezza-migreringar

Den här artikeln är del två i en serie i sju delar som ger vägledning om hur du migrerar från Netezza till Azure Synapse Analytics. Fokus i den här artikeln är metodtips för ETL- och belastningsmigrering.

Överväganden för datamigrering

Inledande beslut för datamigrering från Netezza

När du migrerar ett Netezza-informationslager måste du ställa några grundläggande datarelaterade frågor. Till exempel:

• Ska oanvända tabellstrukturer migreras?

• Vilken är den bästa migreringsmetoden för att minimera risker och användarpåverkan?

• När du migrerar data marts: ska de vara fysiska eller virtuella?

I nästa avsnitt beskrivs dessa punkter inom ramen för migreringen från Netezza.

Migrera oanvända tabeller?

Det är klokt att bara migrera tabeller som används i det befintliga systemet. Tabeller som inte är aktiva kan arkiveras i stället för att migreras, så att data blir tillgängliga om det behövs i framtiden. Det är bäst att använda systemmetadata och loggfiler i stället för dokumentation för att avgöra vilka tabeller som används, eftersom dokumentationen kan vara inaktuell.

Om det är aktiverat innehåller Netezza-frågehistoriktabeller information som kan avgöra när en viss tabell senast användes, vilket i sin tur kan användas för att avgöra om en tabell är en kandidat för migrering.

Här är en exempelfråga som söker efter användningen av en specifik tabell inom ett angivet tidsfönster:

SELECT FORMAT_TABLE_ACCESS (usage),
  hq.submittime
FROM "$v_hist_queries" hq
  INNER JOIN "$hist_table_access_3" hta USING
(NPSID, NPSINSTANCEID, OPID, SESSIONID)
WHERE hq.dbname = 'PROD'
AND hta.schemaname = 'ADMIN'
AND hta.tablename = 'TEST_1'
AND hq.SUBMITTIME > '01-01-2015'
AND hq.SUBMITTIME <= '08-06-2015'
AND
(
  instr(FORMAT_TABLE_ACCESS(usage),'ins') > 0
  OR instr(FORMAT_TABLE_ACCESS(usage),'upd') > 0
  OR instr(FORMAT_TABLE_ACCESS(usage),'del') > 0
)
AND status=0;

| FORMAT_TABLE_ACCESS | SUBMITTIME
----------------------+---------------------------
ins                   | 2015-06-16 18:32:25.728042
ins                   | 2015-06-16 17:46:14.337105
ins                   | 2015-06-16 17:47:14.430995
(3 rows)

Den här frågan använder hjälpfunktionen FORMAT_TABLE_ACCESS och siffran i slutet av $v_hist_table_access_3 vyn för att matcha den installerade frågehistorikversionen.

Vilken är den bästa migreringsmetoden för att minimera risker och påverkan på användare?

Den här frågan uppstår ofta eftersom företag kanske vill minska effekten av ändringar på datalagrets datamodell för att förbättra flexibiliteten. Företag ser ofta en möjlighet att ytterligare modernisera eller transformera sina data under en ETL-migrering. Den här metoden medför en högre risk eftersom den ändrar flera faktorer samtidigt, vilket gör det svårt att jämföra resultatet av det gamla systemet jämfört med det nya. Att ändra datamodellen här kan också påverka ETL-jobb uppströms eller nedströms till andra system. På grund av den risken är det bättre att designa om på den här skalan efter migreringen av informationslagret.

Även om en datamodell avsiktligt ändras som en del av den övergripande migreringen är det bra att migrera den befintliga modellen som den är till Azure Synapse i stället för att göra någon omkonstruktion på den nya plattformen. Den här metoden minimerar effekten på befintliga produktionssystem, samtidigt som du drar nytta av prestanda och elastisk skalbarhet för Azure-plattformen för enstaka omkonstruktionsuppgifter.

När du migrerar från Netezza är den befintliga datamodellen ofta redan lämplig för as-is migrering till Azure Synapse.

Migrera data marts: stanna fysisk eller bli virtuell?

I äldre Netezza-informationslagermiljöer är det vanligt att skapa flera data marts som är strukturerade för att ge bra prestanda för ad hoc-självbetjäningsfrågor och rapporter för en viss avdelning eller affärsfunktion inom en organisation. Därför består en data mart vanligtvis av en delmängd av informationslagret och innehåller aggregerade versioner av data i ett formulär som gör det möjligt för användare att enkelt köra frågor mot dessa data med snabba svarstider via användarvänliga frågeverktyg som Microsoft Power BI, Tableau eller MicroStrategy. Det här formuläret är vanligtvis en dimensionell datamodell. En användning av data marts är att exponera data i en användbar form, även om den underliggande lagerdatamodellen är något annat, till exempel ett datavalv.

Du kan använda separata data marts för enskilda affärsenheter inom en organisation för att implementera robusta datasäkerhetsregimer, genom att endast tillåta användare att komma åt specifika data marts som är relevanta för dem, och eliminera, dölja eller anonymisera känsliga data.

Om dessa data marts implementeras som fysiska tabeller behöver de ytterligare lagringsresurser för att lagra dem och ytterligare bearbetning för att skapa och uppdatera dem regelbundet. Dessutom är data i datalagret bara lika aktuella som den senaste uppdateringsoperationen, och kan därför vara olämpliga för mycket flyktiga data-dashboardar.

Med tillkomsten av relativt billiga skalbara MPP-arkitekturer, till exempel Azure Synapse och de inbyggda prestandaegenskaperna för sådana arkitekturer, kan det vara så att du kan tillhandahålla data mart-funktioner utan att behöva instansiera marten som en uppsättning fysiska tabeller. Detta uppnås genom att effektivt virtualisera data marts via SQL-vyer till huvudinformationslagret eller via ett virtualiseringslager med hjälp av funktioner som vyer i Azure eller visualiseringsprodukter från Microsoft-partner. Den här metoden förenklar eller eliminerar behovet av ytterligare lagrings- och aggregeringsbearbetning och minskar det totala antalet databasobjekt som ska migreras.

Det finns en annan potentiell fördel med den här metoden. Genom att implementera aggregerings- och kopplingslogik i ett virtualiseringslager, och presentera externa rapporteringsverktyg via en virtualiserad vy, "pushas den bearbetning som krävs för att skapa dessa vyer" till informationslagret, vilket i allmänhet är det bästa stället att köra kopplingar, aggregeringar och andra relaterade åtgärder på stora datavolymer.

De främsta drivkrafterna för att välja en virtuell data mart-implementering framför en fysisk data mart är:

• Mer smidighet: en virtuell data mart är enklare att ändra än fysiska tabeller och associerade ETL-processer.

• Lägre total ägandekostnad: en virtualiserad implementering kräver färre datalager och kopior av data.

• Eliminering av ETL-jobb för att migrera och förenkla informationslagerarkitekturen i en virtualiserad miljö.

• Prestanda: Även om fysiska data marts historiskt sett har varit mer högpresterande, implementerar virtualiseringsprodukter nu intelligenta cachelagringstekniker för att minimera.

Datamigrering från Netezza

Förstå dina data

En del av migreringsplaneringen är att i detalj förstå mängden data som behöver migreras eftersom det kan påverka beslut om migreringsmetoden. Använd systemmetadata för att fastställa det fysiska utrymme som tas upp av "rådata" i tabellerna som ska migreras. I det här sammanhanget innebär "rådata" mängden utrymme som används av dataraderna i en tabell, exklusive omkostnader som index och komprimering. Detta gäller särskilt för de största faktatabellerna eftersom dessa vanligtvis består av mer än 95% av data.

Du kan få ett korrekt tal för mängden data som ska migreras för en viss tabell genom att extrahera ett representativt urval av data , till exempel en miljon rader, till en okomprimerad avgränsad platt ASCII-datafil. Använd sedan filens storlek för att få en genomsnittlig rådatastorlek per rad i tabellen. Multiplicera slutligen den genomsnittliga storleken med det totala antalet rader i den fullständiga tabellen för att ge en rådatastorlek för tabellen. Använd den rådatastorleken i planeringen.

Netezza-datatypsmappning

De flesta Netezza-datatyper har en direkt motsvarighet i Azure Synapse. I följande tabell visas dessa datatyper tillsammans med den rekommenderade metoden för att mappa dem.

Använd metadata från Netezza-katalogtabellerna för att avgöra om någon av dessa datatyper behöver migreras och tillåta detta i din migreringsplan. Viktiga metadatavyer i Netezza för den här typen av fråga är:

• _V_USER: Användarvyn ger information om användarna i Netezza-systemet.

• _V_TABLE: Tabellvyn innehåller listan över tabeller som skapats i Netezza-prestandasystemet.

• _V_RELATION_COLUMN: Katalogvyn för relationskolumnsystemet innehåller de kolumner som är tillgängliga i en tabell.

• _V_OBJECTS: objektvyn visar de olika objekten, till exempel tabeller, vyer, funktioner och så vidare, som är tillgängliga i Netezza.

Den här Netezza SQL-frågan visar till exempel kolumner och kolumntyper:

SELECT
tablename,
  attname AS COL_NAME,
  b.FORMAT_TYPE AS COL_TYPE,
  attnum AS COL_NUM
FROM _v_table a
  JOIN _v_relation_column b
  ON a.objid = b.objid
WHERE a.tablename = 'ATT_TEST'
AND a.schema = 'ADMIN'
ORDER BY attnum;

TABLENAME | COL_NAME    | COL_TYPE             | COL_NUM
----------+-------------+----------------------+--------
ATT_TEST  | COL_INT     | INTEGER              | 1
ATT_TEST  | COL_NUMERIC | NUMERIC(10,2)        | 2
ATT_TEST  | COL_VARCHAR | CHARACTER VARYING(5) | 3
ATT_TEST  | COL_DATE    | DATE                 | 4
(4 rows)

Frågan kan ändras för att söka i alla tabeller efter förekomster av datatyper som inte stöds.

Azure Data Factory kan användas för att flytta data från en äldre Netezza-miljö. Mer information finns i IBM Netezza Connector.

Tredjepartsleverantörer erbjuder verktyg och tjänster för att automatisera migreringen, inklusive mappning av datatyper enligt tidigare beskrivning. Dessutom kan ETL-verktyg från tredje part, som Informatica eller Talend, som redan används i Netezza-miljön implementera alla nödvändiga datatransformeringar. I nästa avsnitt går vi igenom migreringen av befintliga ETL-processer från tredje part.

Överväganden för ETL-migrering

Inledande beslut om Netezza ETL-migrering

För ETL/ELT-bearbetning kan äldre Netezza-informationslager använda specialbyggda skript med Netezza-verktyg som nzsql och nzload eller ETL-verktyg från tredje part, till exempel Informatica eller Ab Initio. Ibland använder Netezza-informationslager en kombination av ETL- och ELT-metoder som har utvecklats över tid. När du planerar en migrering till Azure Synapse måste du bestämma det bästa sättet att implementera den nödvändiga ETL/ELT-bearbetningen i den nya miljön, samtidigt som du minimerar kostnaden och risken. Mer information om ETL- och ELT-bearbetning finns i designmetoden ELT vs ETL.

I följande avsnitt beskrivs migreringsalternativ och rekommendationer för olika användningsfall. Det här flödesschemat sammanfattar en metod:

Det första steget är alltid att skapa en inventering av ETL/ELT-processer som måste migreras. Precis som med andra steg är det möjligt att de "inbyggda" Azure-standardfunktionerna gör det onödigt att migrera vissa befintliga processer. I planeringssyfte är det viktigt att förstå omfattningen av migreringen som ska utföras.

I föregående flödesschema gäller beslut 1 ett beslut på hög nivå om huruvida du ska migrera till en helt Azure-intern miljö. Om du flyttar till en helt Azure-intern miljö rekommenderar vi att du återskapar ETL-bearbetningen med hjälp av pipelines och aktiviteter i Azure Data Factory eller Azure Synapse Pipelines. Om du inte flyttar till en helt Azure-intern miljö är beslut 2 om ett befintligt ETL-verktyg från tredje part redan används.

Om ett ETL-verktyg från tredje part redan används, och särskilt om det finns en stor investering i kunskaper eller flera befintliga arbetsflöden och scheman använder verktyget, är beslut 3 om verktyget effektivt kan stödja Azure Synapse som målmiljö. Helst innehåller verktyget "inbyggda" anslutningsappar som kan utnyttja Azure-funktioner som PolyBase eller COPY INTO för att möjliggöra en mer effektiv datainläsning. Det finns ett sätt att anropa en extern process, till exempel PolyBase eller COPY INTO, och skicka in lämpliga parametrar. I det här fallet använder du befintliga kunskaper och arbetsflöden med Azure Synapse som den nya målmiljön.

Om du bestämmer dig för att behålla ett befintligt ETL-verktyg från tredje part kan det finnas fördelar med att köra verktyget i Azure-miljön (i stället för på en befintlig lokal ETL-server) och att Azure Data Factory hanterar den övergripande orkestreringen av befintliga arbetsflöden. En särskild fördel är att mindre data måste laddas ned från Azure, bearbetas och sedan laddas upp till Azure igen. Beslut 4 är alltså om du vill låta det befintliga verktyget köras as-is eller flytta det till Azure-miljön för att uppnå fördelar med kostnad, prestanda och skalbarhet.

Återskapa befintliga Netezza-specifika skript

Om vissa eller alla befintliga Netezza-lager ETL/ELT-bearbetning hanteras av anpassade skript som använder Netezza-specifika verktyg, till exempel nzsql eller nzload, måste dessa skript kodas om för den nya Azure Synapse-miljön. Om ETL-processer implementerades med lagrade procedurer i Netezza måste dessa också kodas om.

Vissa element i ETL-processen är enkla att migrera, till exempel genom enkel massinläsning av data till en mellanlagringstabell från en extern fil. Det kan till och med vara möjligt att automatisera dessa delar av processen, till exempel genom att använda PolyBase i stället för nzload. Andra delar av processen som innehåller godtyckliga komplexa SQL- och/eller lagrade procedurer tar längre tid att återskapa.

Ett sätt att testa Netezza SQL för kompatibilitet med Azure Synapse är att samla in några representativa SQL-instruktioner från Netezza-frågehistoriken och sedan prefixa dessa frågor med EXPLAINoch sedan – förutsatt att en liknande migrerad datamodell i Azure Synapse – kör dessa EXPLAIN instruktioner i Azure Synapse. Alla inkompatibla SQL genererar ett fel, och felinformationen kan fastställa omoderingsaktivitetens skala.

Microsoft-partner erbjuder verktyg och tjänster för att migrera Netezza SQL och lagrade procedurer till Azure Synapse.

Använda ETL-verktyg från tredje part

Som beskrivs i föregående avsnitt kommer det befintliga äldre informationslagersystemet i många fall redan att fyllas i och underhållas av ETL-produkter från tredje part. En lista över Microsofts dataintegreringspartner för Azure Synapse finns i Dataintegreringspartner.

Datainläsning från Netezza

Tillgängliga alternativ vid inläsning av data från Netezza

När det gäller att migrera data från ett Netezza-informationslager finns det några grundläggande frågor som är associerade med datainläsning som måste lösas. Du måste bestämma hur data ska flyttas fysiskt från den befintliga lokala Netezza-miljön till Azure Synapse i molnet och vilka verktyg som ska användas för att utföra överföringen och belastningen. Tänk på följande frågor som beskrivs i nästa avsnitt.

• Kommer du att extrahera data till filer eller flytta dem direkt via en nätverksanslutning?

• Kommer du att samordna processen från källsystemet eller från Azure-målmiljön?

• Vilka verktyg använder du för att automatisera och hantera processen?

Vill du överföra data via filer eller nätverksanslutningar?

När databastabellerna som ska migreras har skapats i Azure Synapse kan du flytta data för att fylla i tabellerna från det äldre Netezza-systemet och till den nya miljön. Det finns två grundläggande metoder:

• Filextrakt: extrahera data från Netezza-tabellerna till flata filer, vanligtvis i CSV-format, via nzsql med alternativet -o eller via -instruktionen CREATE EXTERNAL TABLE . Använd en extern tabell när det är möjligt eftersom det är det mest effektiva dataflödesflödet. I följande SQL-exempel skapas en CSV-fil via en extern tabell:

  CREATE EXTERNAL TABLE '/data/export.csv' USING (delimiter ',')
  AS SELECT col1, col2, expr1, expr2, col3, col1 || col2 FROM your table;
  

  Använd en extern tabell om du exporterar data till ett monterat filsystem på en lokal Netezza-värd. Om du exporterar data till en fjärrdator som har JDBC, ODBC eller OLEDB installerat är USING alternativet "remotesource odbc" -satsen.

  Den här metoden kräver utrymme för att landa de extraherade datafilerna. Utrymmet kan vara lokalt för Netezza-källdatabasen (om tillräckligt med lagringsutrymme är tillgängligt) eller fjärranslutet i Azure Blob Storage. Bästa prestanda uppnås när en fil skrivs lokalt, eftersom det undviker nätverksbelastning.

  För att minimera kraven på lagring och nätverksöverföring är det bra att komprimera de extraherade datafilerna med hjälp av ett verktyg som gzip.

  När de flata filerna har extraherats kan de antingen flyttas till Azure Blob Storage (sorterade med Azure Synapse-målinstansen) eller läsas in direkt i Azure Synapse med hjälp av PolyBase eller COPY INTO. Metoden för att fysiskt flytta data från lokal lagring till Azure-molnmiljön beror på mängden data och den tillgängliga nätverksbandbredden.

  Microsoft erbjuder olika alternativ för att flytta stora mängder data, inklusive AzCopy för att flytta filer över nätverket till Azure Storage, Azure ExpressRoute för att flytta massdata via en privat nätverksanslutning och Azure Data Box för filer som flyttas till en fysisk lagringsenhet som sedan skickas till ett Azure-datacenter för inläsning. Mer information finns i dataöverföring.

• Direkt extrahering och inläsning över nätverket: Azure-målmiljön skickar en begäran om dataextrakt, vanligtvis via ett SQL-kommando, till det äldre Netezza-systemet för att extrahera data. Resultaten skickas över nätverket och läses in direkt i Azure Synapse, utan att data behöver landas i mellanliggande filer. Den begränsande faktorn i det här scenariot är normalt bandbredden för nätverksanslutningen mellan Netezza-databasen och Azure-miljön. För mycket stora datavolymer är den här metoden kanske inte praktisk.

Det finns också en hybridmetod som använder båda metoderna. Du kan till exempel använda metoden för direkt nätverksextrakt för mindre dimensionstabeller och exempel på de större faktatabellerna för att snabbt tillhandahålla en testmiljö i Azure Synapse. För historiska faktatabeller för stora volymer kan du använda metoden för att extrahera och överföra filer med hjälp av Azure Data Box.

Orkestrera från Netezza eller Azure?

Den rekommenderade metoden när du flyttar till Azure Synapse är att samordna dataextrahering och inläsning från Azure-miljön med hjälp av Azure Synapse Pipelines eller Azure Data Factory, samt tillhörande verktyg, till exempel PolyBase eller COPY INTO, för den mest effektiva datainläsningen. Den här metoden utnyttjar Azure-funktioner och ger en enkel metod för att skapa återanvändbara pipelines för datainläsning.

Andra fördelar med den här metoden är minskad påverkan på Netezza-systemet under datainläsningsprocessen eftersom hanterings- och inläsningsprocessen körs i Azure och möjligheten att automatisera processen med hjälp av metadatadrivna datainläsningspipelines.

Vilka verktyg kan användas?

Uppgiften med datatransformering och förflyttning är den grundläggande funktionen för alla ETL-produkter. Om någon av dessa produkter redan används i den befintliga Netezza-miljön kan det förenkla datamigreringen från Netezza till Azure Synapse med det befintliga ETL-verktyget. Den här metoden förutsätter att ETL-verktyget stöder Azure Synapse som målmiljö. Mer information om verktyg som stöder Azure Synapse finns i Dataintegreringspartner.

Om du använder ett ETL-verktyg bör du överväga att köra verktyget i Azure-miljön för att dra nytta av Azures molnprestanda, skalbarhet och kostnad och frigöra resurser i Netezza-datacentret. En annan fördel är minskad dataflytt mellan molnet och lokala miljöer.

Sammanfattning

För att sammanfatta är våra rekommendationer för migrering av data och associerade ETL-processer från Netezza till Azure Synapse:

• Planera framåt för att säkerställa en lyckad migreringsövning.

• Skapa en detaljerad inventering av data och processer som ska migreras så snart som möjligt.

• Använd systemmetadata och loggfiler för att få en korrekt förståelse för data- och processanvändning. Förlita dig inte på dokumentation eftersom den kan vara inaktuell.

• Förstå de datavolymer som ska migreras och nätverksbandbredden mellan det lokala datacentret och Azure-molnmiljöerna.

• Använd "inbyggda" Azure-standardfunktioner för att minimera migreringsarbetsbelastningen.

• Identifiera och förstå de mest effektiva verktygen för extrahering och inläsning av data i både Netezza- och Azure-miljöer. Använd lämpliga verktyg i varje fas av processen.

• Använd Azure-anläggningar, till exempel Azure Synapse Pipelines eller Azure Data Factory, för att orkestrera och automatisera migreringsprocessen samtidigt som påverkan på Netezza-systemet minimeras.

Nästa steg

Mer information om säkerhetsåtkomståtgärder finns i nästa artikel i den här serien: Säkerhet, åtkomst och åtgärder för Netezza-migreringar.