Share via

Gegevensmigratie, ETL en laden voor Netezza-migraties

  • Artikel

Dit artikel is deel twee van een zevendelige reeks met richtlijnen voor het migreren van Netezza 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 Netezza

Wanneer u een Netezza-datawarehouse migreert, moet u enkele eenvoudige vragen stellen over gegevens. 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 migratie vanuit Netezza.

Ongebruikte tabellen migreren?

Tip

In oudere 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 in de toekomst indien nodig 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 de documentatie verouderd kan zijn.

Als deze optie is ingeschakeld, bevatten Netezza-querygeschiedenistabellen informatie die kan bepalen wanneer een bepaalde tabel voor het laatst is geopend. Deze tabellen kunnen vervolgens worden gebruikt om te bepalen of een tabel een kandidaat is voor migratie.

Hier volgt een voorbeeldquery die zoekt naar het gebruik van een specifieke tabel binnen een bepaald tijdvenster:

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)

Deze query maakt gebruik van de helperfunctie FORMAT_TABLE_ACCESS en het cijfer aan het einde van de $v_hist_table_access_3 weergave om overeen te komen met de geïnstalleerde versie van de querygeschiedenis.

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

Deze vraag komt vaak naar boven omdat bedrijven mogelijk de impact van wijzigingen op het datawarehouse-gegevensmodel 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. Het aanbrengen van wijzigingen in het gegevensmodel kan ook van invloed zijn op upstream- of downstream ETL-taken naar andere systemen. Vanwege dit risico is het beter om na de datawarehouse-migratie het ontwerp op deze schaal te herontwerpen.

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

Wanneer u migreert vanuit Netezza, is het bestaande gegevensmodel vaak al geschikt voor as-is-migratie naar Azure Synapse.

Tip

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

Datamarts migreren: fysiek blijven of virtueel gaan?

Tip

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

In verouderde Netezza-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. Daarom 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 dimensionale gegevensmodel. Datamarts worden onder andere gebruikt om de gegevens in een bruikbare vorm beschikbaar te maken, 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 systemen voor gegevensbeveiliging te implementeren, door gebruikers alleen toegang te geven tot specifieke datamarts die voor hen relevant zijn en gevoelige gegevens te elimineren, te verbergen 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 in 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 aanpak. 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 plek is om joins, aggregaties en andere gerelateerde bewerkingen uit te voeren op grote gegevensvolumes.

De belangrijkste drivers voor het kiezen van een virtuele datamart-implementatie in plaats van een fysieke datamart zijn:

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

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

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

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

Gegevensmigratie vanuit Netezza

Inzicht in uw gegevens

Een onderdeel van de migratieplanning is het in detail 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 in beslag wordt genomen 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, exclusief overhead, 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 het gegevensvolume dat 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 scheidingsteken gescheiden ASCII-gegevensbestand. Gebruik vervolgens de grootte van dat bestand om een gemiddelde onbewerkte gegevensgrootte 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 te geven. Gebruik die onbewerkte gegevensgrootte in uw planning.

Toewijzing van Netezza-gegevenstypen

Tip

Beoordeel de impact van niet-ondersteunde gegevenstypen als onderdeel van de voorbereidingsfase.

De meeste Netezza-gegevenstypen hebben een direct equivalent in Azure Synapse. In de volgende tabel ziet u deze gegevenstypen, samen met de aanbevolen methode voor het toewijzen ervan.

Netezza-gegevenstype Azure Synapse gegevenstype
BIGINT BIGINT
BINAIR VARIËREND(n) VARBINARY(n)
BOOLEAN BEETJE
BYTEINT TINYINT
TEKEN VARIËREND(n) VARCHAR(n)
TEKEN(n) TEKEN(n)
DATE DATUM(datum)
DECIMAAL(p,s) DECIMAAL(p,s)
DUBBELE PRECISIE FLOAT
FLOAT(n) FLOAT(n)
INTEGER INT
INTERVAL INTERVAL-gegevenstypen worden momenteel niet rechtstreeks ondersteund in Azure Synapse Analytics, maar kunnen worden berekend met tijdelijke functies, zoals DATEDIFF.
GELD GELD
NATIONAAL KARAKTER VARIËREND(n) NVARCHAR(n)
NATIONAAL KARAKTER(n) NCHAR(n)
GETAL(p;s) GETAL(p;s)
REAL REAL
SMALLINT SMALLINT
ST_GEOMETRY(n) Ruimtelijke gegevenstypen zoals ST_GEOMETRY worden momenteel niet ondersteund in Azure Synapse Analytics, maar de gegevens kunnen worden opgeslagen als VARCHAR of VARBINARY.
TIME TIME
TIJD MET TIJDZONE DATETIMEOFFSET
TIMESTAMP DATETIME

Gebruik de metagegevens uit de Netezza-catalogustabellen om te bepalen of een van deze gegevenstypen moet worden gemigreerd en sta dit toe in uw migratieplan. De belangrijke metagegevensweergaven in Netezza voor dit type query zijn:

  • _V_USER: de gebruikersweergave geeft informatie over de gebruikers in het Netezza-systeem.

  • _V_TABLE: de tabelweergave bevat de lijst met tabellen die zijn gemaakt in het Netezza-prestatiesysteem.

  • _V_RELATION_COLUMN: de systeemcatalogusweergave van de relationele kolom bevat de kolommen die beschikbaar zijn in een tabel.

  • _V_OBJECTS: de weergave objecten bevat de verschillende objecten, zoals tabellen, weergaven, functies, enzovoort, die beschikbaar zijn in Netezza.

In deze Netezza SQL-query worden bijvoorbeeld kolommen en kolomtypen weergegeven:

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)

De query kan worden gewijzigd om in alle tabellen te zoeken naar exemplaren van niet-ondersteunde gegevenstypen.

Azure Data Factory kunnen worden gebruikt om gegevens te verplaatsen vanuit een verouderde Netezza-omgeving. Zie IBM Netezza-connector voor meer informatie.

Externe leveranciers bieden hulpprogramma's en services voor het automatiseren van migratie, waaronder de toewijzing van gegevenstypen zoals eerder beschreven. Bovendien kunnen ETL-hulpprogramma's van derden, zoals Informatica of Talend, die al in de Netezza-omgeving worden gebruikt, alle vereiste gegevenstransformaties implementeren. In de volgende sectie wordt de migratie van bestaande ETL-processen van derden besproken.

Overwegingen voor ETL-migratie

Eerste beslissingen met betrekking tot De ETL-migratie van Netezza

Tip

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

Voor ETL/ELT-verwerking kunnen verouderde Netezza-datawarehouses gebruikmaken van op maat gemaakte scripts die gebruikmaken van Netezza-hulpprogramma's zoals nzsql en nzload, of ETL-hulpprogramma's van derden, zoals Informatica of Ab Initio. Soms gebruiken Netezza-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, met minimale kosten en risico's. Zie ELT versus ETL-ontwerpbenadering voor meer informatie over ETL- en ELT-verwerking.

In de volgende secties worden migratieopties besproken en aanbevelingen voor verschillende gebruiksvoorbeelden. 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 het niet nodig maken om bepaalde bestaande processen te migreren. 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 al dan 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 engineeren met behulp van pijplijnen en activiteiten in Azure Data Factory of Azure Synapse Pipelines. Als u niet overstapt op een volledig azure-systeemeigen omgeving, is beslissing 2 of er al een bestaand ETL-hulpprogramma van derden in gebruik is.

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 vooral als er veel wordt geïnvesteerd in vaardigheden of als er een grote investering is in vaardigheden of als er verschillende bestaande werkstromen en planningen gebruikmaken van dat hulpprogramma, is de beslissing 3 of het hulpprogramma efficiënt Azure Synapse als doelomgeving kan ondersteunen. In het ideale gevallen bevat het hulpprogramma 'systeemeigen' connectors die gebruik kunnen maken van Azure-faciliteiten zoals PolyBase of COPY INTO, voor het efficiëntste 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 Netezza-specifieke scripts opnieuw ontwikkelen

Als sommige of alle bestaande ETL/ELT-verwerkingen van Netezza-magazijn worden verwerkt door aangepaste scripts die gebruikmaken van Netezza-specifieke hulpprogramma's, zoals nzsql of nzload, moeten deze scripts opnieuw worden gecodeerd voor de nieuwe Azure Synapse-omgeving. En als ETL-processen zijn geïmplementeerd met behulp van opgeslagen procedures in Netezza, 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 die onderdelen van het proces te automatiseren, bijvoorbeeld door PolyBase te gebruiken in plaats van nzload. 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 Netezza SQL te testen op compatibiliteit met Azure Synapse is door een aantal representatieve SQL-instructies uit de querygeschiedenis van Netezza vast te leggen, die query's vervolgens te voorvoegen met EXPLAIN, en 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 Netezza 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 Netezza

Beschikbare opties bij het laden van gegevens uit Netezza

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 Netezza-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 Netezza-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 Netezza-systeem te vullen naar de nieuwe omgeving. Er zijn twee basismethoden:

  • Bestandsextractie: pak de gegevens uit de Netezza-tabellen uit naar platte bestanden, normaal gesproken in CSV-indeling, via nzsql met de optie -o of via de CREATE EXTERNAL TABLE instructie. Gebruik waar mogelijk een externe tabel, omdat dit de meest efficiënte is in termen van gegevensdoorvoer. In het volgende SQL-voorbeeld wordt een CSV-bestand gemaakt via een externe tabel:

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

    Gebruik een externe tabel als u gegevens exporteert naar een gekoppeld bestandssysteem op een lokale Netezza-host. Als u gegevens exporteert naar een externe computer waarop JDBC, ODBC of OLEDB is geïnstalleerd, is de optie 'remotesource odbc' de USING component.

    Deze benadering vereist ruimte om de geëxtraheerde gegevensbestanden te landen. De ruimte kan lokaal zijn in de Netezza-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 (met de doel-Azure Synapse-instantie) 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 voor bestanden die 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 gegevensextracting, normaal gesproken via een SQL-opdracht, naar het verouderde Netezza-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 Netezza-database en de Azure-omgeving. Voor zeer grote gegevensvolumes is deze benadering mogelijk niet praktisch.

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

Organiseren vanuit Netezza of Azure?

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

Andere voordelen van deze benadering zijn een verminderde impact op het Netezza-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 Netezza-omgeving, kan het gebruik van het bestaande ETL-hulpprogramma de gegevensmigratie van Netezza naar Azure Synapse vereenvoudigen. Bij deze benadering wordt ervan uitgegaan dat het ETL-hulpprogramma Azure Synapse als een doelomgeving ondersteunt. Zie Gegevensintegratiepartners voor meer informatie over hulpprogramma's die ondersteuning bieden voor Azure Synapse.

Als u een ETL-hulpprogramma gebruikt, kunt u overwegen om dat hulpprogramma in de Azure-omgeving uit te voeren om te profiteren van azure-cloudprestaties, schaalbaarheid en kosten, en om resources vrij te maken in het Netezza-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 Netezza naar Azure Synapse:

  • Plan vooraf om een geslaagde migratie te garanderen.

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

  • Gebruik systeemmetagegevens en logboekbestanden om een nauwkeurig inzicht te krijgen in gegevens- en procesgebruik. 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.

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

  • De meest efficiënte hulpprogramma's identificeren en begrijpen voor het extraheren en laden van gegevens in zowel Netezza- 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 automatiseren, terwijl de impact op het Netezza-systeem wordt geminimaliseerd.

Volgende stappen

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