Dela via

Datamigrering, ETL och inläsning för Netezza-migreringar

  • Artikel

Den här artikeln är del två i en serie i sju delar som innehåller 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 om datamigrering från Netezza

När du migrerar ett Netezza-informationslager måste du ställa några grundläggande datarelaterade frågor. 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 dataförråd: är du fysisk eller virtuell?

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

Migrera oanvända tabeller?

Tips

I äldre system är det inte ovanligt att tabeller blir redundanta över tid – de behöver inte migreras i de flesta fall.

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 här alternativet ä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å datamodellen för informationslagret 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 göra ändringar i datamodellen här kan också påverka överordnade eller underordnade ETL-jobb 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 i befintligt fall till Azure Synapse i stället för att göra någon ny teknik 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 migrering till Azure Synapse.

Tips

Migrera den befintliga modellen som den är till en början, även om en ändring av datamodellen planeras i framtiden.

Migrera dataförråd: är du fysisk eller virtuell?

Tips

Virtualisering av dataförråd kan spara på lagrings- och bearbetningsresurser.

I äldre Netezza-informationslagermiljöer är det vanligt att skapa flera dataförråd 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 i en organisation. Därför består ett dataförråd 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 dataförråd är att exponera data i en användbar form, även om den underliggande lagerdatamodellen är något annorlunda, till exempel ett datavalv.

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

Om dessa dataförråd 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 marten bara lika uppdaterade som den senaste uppdateringsåtgärden, och kan därför vara olämpliga för mycket beständiga datainstrumentpaneler.

Tips

Prestanda och skalbarhet för Azure Synapse möjliggör virtualisering utan att offra prestanda.

Med tillkomsten av relativt billiga skalbara MPP-arkitekturer, till exempel Azure Synapse och de inneboende prestandaegenskaperna för sådana arkitekturer, kan det vara så att du kan tillhandahålla funktioner för dataförråd utan att behöva instansiera marten som en uppsättning fysiska tabeller. Detta uppnås genom att effektivt virtualisera dataförråden 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 vanligtvis är den bästa platsen att köra kopplingar, aggregeringar och andra relaterade åtgärder på stora datavolymer.

De primära faktorerna för att välja en implementering av en virtuell datamart över ett fysiskt dataarkiv är:

  • Mer smidighet: ett virtuellt dataarkiv ä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 dataförråd 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 de tabeller 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 den datavolym 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

Tips

Utvärdera effekten av datatyper som inte stöds som en del av förberedelsefasen.

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.

Netezza-datatyp Azure Synapse datatyp
BIGINT BIGINT
BINÄR VARIERANDE(n) VARBINARY(n)
BOOLEAN BIT
BYTEINT TINYINT
CHARACTER VARYING(n) VARCHAR(n)
CHARACTER(n) CHAR(n)
DATE DATE(date)
DECIMAL(p,s) DECIMAL(p,s)
DUBBEL PRECISION FLYTA
FLOAT(n) FLOAT(n)
INTEGER INT
INTERVALL INTERVAL-datatyper stöds för närvarande inte direkt i Azure Synapse Analytics, men kan beräknas med temporala funktioner, till exempel DATEDIFF.
PENGAR PENGAR
NATIONELLT TECKEN VARIERANDE(n) NVARCHAR(n)
NATIONAL CHARACTER(n) NCHAR(n)
NUMERIC(p,s) NUMERIC(p,s)
REAL REAL
SMALLINT SMALLINT
ST_GEOMETRY(n) Rumsliga datatyper som ST_GEOMETRY stöds för närvarande inte i Azure Synapse Analytics, men data kan lagras som VARCHAR eller VARBINARY.
TIME TIME
TID MED TIDSZON DATETIMEOFFSET
TIMESTAMP DATETIME

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 relationskolumnsystem 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-anslutningsprogrammet.

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, till exempel 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 vid ETL-migrering

Inledande beslut om Netezza ETL-migrering

Tips

Planera metoden för ETL-migrering i förväg och utnyttja Azure-anläggningar där det är lämpligt.

För ETL/ELT-bearbetning kan äldre Netezza-informationslager använda specialbyggda skript med hjälp av 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 fastställa 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:

Flödesschema för migreringsalternativ och rekommendationer.

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 det föregående flödesschemat 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 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.

Tips

Utnyttja investeringar i befintliga verktyg från tredje part för att minska kostnader och risker.

Om ett ETL-verktyg från tredje part redan används, och särskilt om det finns en stor investering i färdigheter 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 "interna" anslutningsappar som kan utnyttja Azure-funktioner som PolyBase eller COPY INTO för den mest effektiva datainläsningen. Det finns ett sätt att anropa en extern process, till exempel PolyBase eller COPY INTO, och skicka 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 hantera den övergripande orkestreringen av befintliga arbetsflöden. En särskild fördel är att färre data måste laddas ned från Azure, bearbetas och sedan laddas upp till Azure igen. Beslut 4 handlar alltså om att låta det befintliga verktyget köras som det är 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.

Tips

Inventeringen av ETL-uppgifter som ska migreras bör innehålla skript och lagrade procedurer.

Vissa element i ETL-processen är enkla att migrera, till exempel genom enkel massdatainläsning 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 mer 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-objekt 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

Tips

Verktyg från tredje part kan förenkla och automatisera migreringsprocessen och därmed minska risken.

När det gäller att migrera data från ett Netezza-informationslager finns det några grundläggande frågor som är kopplade till 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 kommer du att använda för att automatisera och hantera processen?

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

Tips

Förstå de datavolymer som ska migreras och den tillgängliga nätverksbandbredden eftersom dessa faktorer påverkar migreringsmetodens beslut.

När databastabellerna som ska migreras har skapats i Azure Synapse kan du flytta data för att fylla i dessa tabeller 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. Den bästa prestandan uppnås när en fil skrivs lokalt, eftersom det undviker nätverksomkostnader.

    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 målinstansen Azure Synapse) eller läsas in direkt i Azure Synapse med PolyBase eller COPY INTO. Metoden för att fysiskt flytta data från lokal 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 över 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 belastning ö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 behöva landa data 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 kanske den här metoden inte är 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å större faktatabeller 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 associerade verktyg, till exempel PolyBase eller COPY INTO, för den mest effektiva datainläsningen. Den här metoden utnyttjar Azure-funktioner och är 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 samt frigöra resurser i Netezza-datacentret. En annan fördel är minskad dataflytt mellan molnet och lokala miljöer.

Sammanfattning

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

  • Planera i förväg 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ändningen. 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 åtgärder för säkerhetsåtkomst finns i nästa artikel i den här serien: Säkerhet, åtkomst och åtgärder för Netezza-migreringar.