Condividi tramite

Migrazione dei dati, ETL e caricamento per le migrazioni di Netezza

  • Articolo

Questo articolo è la seconda parte di una serie in sette parti che offre indicazioni su come eseguire la migrazione da Netezza ad Azure Synapse Analytics. L'obiettivo di questo articolo è illustrare le procedure consigliate per la migrazione ETL e del carico.

Considerazioni sulla migrazione dei dati

Decisioni iniziali per la migrazione dei dati da Netezza

Quando si esegue la migrazione di un data warehouse Netezza, è necessario porsi alcune domande di base relative ai dati. Ad esempio:

  • È consigliabile eseguire la migrazione delle strutture di tabella inutilizzate?

  • Qual è l'approccio migliore per la migrazione per ridurre al minimo i rischi e l'impatto sugli utenti?

  • Quando si esegue la migrazione dei data mart: scegliere l'approccio fisico o virtuale?

Le sezioni successive illustrano questi punti nel contesto della migrazione da Netezza.

Eseguire la migrazione delle tabelle inutilizzate?

Suggerimento

Nei sistemi legacy non è insolito che le tabelle diventino ridondanti nel tempo. Non è necessario eseguire la migrazione nella maggior parte dei casi.

È opportuno eseguire la migrazione solo delle tabelle in uso nel sistema esistente. Le tabelle non attive possono essere archiviate anziché sottoposte a migrazione, in modo che i dati siano disponibili se necessario in futuro. È consigliabile usare i metadati di sistema e i file di log anziché la documentazione per determinare quali tabelle sono in uso, perché la documentazione può non essere aggiornata.

Se abilitate, le tabelle della cronologia delle query di Netezza contengono informazioni che possono determinare quando è stato eseguito l'ultimo accesso a una determinata tabella, informazione che a sua volta può essere usata per decidere se una tabella sia ideale per la migrazione.

Ecco una query di esempio che cerca l'utilizzo di una tabella specifica all'interno di un determinato intervallo di tempo:

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)

Questa query usa la funzione FORMAT_TABLE_ACCESS helper e la cifra alla fine della vista $v_hist_table_access_3 in modo che corrisponda alla versione della cronologia query installata.

Qual è l'approccio migliore alla migrazione per ridurre al minimo i rischi e l'impatto sugli utenti?

Questa domanda si presenta spesso perché le aziende potrebbero voler ridurre l'impatto delle modifiche sul modello di dati del data warehouse per migliorare l'agilità. Le aziende spesso vedono l'opportunità di modernizzare o trasformare ulteriormente i dati durante una migrazione ETL. Questo approccio comporta un rischio più elevato perché cambia più fattori contemporaneamente, rendendo difficile confrontare i risultati del vecchio sistema rispetto al nuovo. Le modifiche apportate al modello di dati possono influire anche sui processi ETL upstream o downstream in altri sistemi. A causa di questo rischio, è preferibile riprogettare questa scalabilità dopo la migrazione del data warehouse.

Anche se un modello di dati viene intenzionalmente modificato come parte della migrazione complessiva, è consigliabile eseguire la migrazione del modello esistente così com'è ad Azure Synapse, anziché eseguire una nuova progettazione nella nuova piattaforma. Questo approccio riduce al minimo l'effetto sui sistemi di produzione esistenti, sfruttando al contempo le prestazioni e la scalabilità elastica della piattaforma Azure per le attività di ricompilazione una tantum.

Quando si esegue la migrazione da Netezza, spesso il modello di dati esistente è già adatto per la migrazione così come avviene in Azure Synapse.

Suggerimento

Eseguire inizialmente la migrazione del modello esistente così com'è, anche se è prevista una modifica al modello di dati in futuro.

Eseguire la migrazione dei data mart: scegliere l'approccio fisico o virtuale?

Suggerimento

La virtualizzazione dei data mart può far risparmiare sulle risorse di archiviazione ed elaborazione.

Negli ambienti di data warehouse Netezza legacy, è prassi comune creare diversi data mart strutturati per offrire prestazioni ottimali per query e report self-service ad hoc per una determinata funzione di reparto o business all'interno di un'organizzazione. Di conseguenza, un data mart è in genere costituito da un subset del data warehouse e contiene versioni aggregate dei dati in un modulo che consente agli utenti di eseguire facilmente query sui dati con tempi di risposta rapidi tramite strumenti di query semplici, come Microsoft Power BI, Tableau o MicroStrategy. Questo modulo è in genere un modello di dati dimensionale. Un uso dei data mart consiste nell'esporre i dati in un formato fruibile, anche se il modello di dati del warehouse sottostante è di tipo diverso (ad esempio un insieme di credenziali dei dati).

È possibile usare data mart separati per singole business unit all'interno di un'organizzazione per implementare regimi di sicurezza dei dati affidabili, consentendo agli utenti di accedere solo a data mart specifici rilevanti ed eliminando, offuscando o rendendo anonimi i dati sensibili.

Se questi data mart vengono implementati come tabelle fisiche, richiederanno risorse di archiviazione aggiuntive per ospitarli e ulteriore elaborazione per la compilazione e l'aggiornamento regolari. Inoltre, i dati nel mart saranno aggiornati solo come ultima operazione di aggiornamento e quindi potrebbero non essere adatti per i dashboard di dati altamente volatili.

Suggerimento

Le prestazioni e la scalabilità di Azure Synapse consentono una virtualizzazione senza sacrificare le prestazioni.

Con l'avvento di architetture MPP relativamente a basso costo, ad esempio Azure Synapse, e le caratteristiche di prestazioni intrinseche di tali architetture, può essere possibile fornire funzionalità di data mart senza dover creare un'istanza del mart come set di tabelle fisiche. Ciò si ottiene virtualizzando efficacemente i data mart tramite viste SQL nel data warehouse principale o tramite un livello di virtualizzazione usando funzionalità come le visualizzazioni in Azure o i prodotti di visualizzazione dei partner Microsoft. Questo approccio semplifica o elimina la necessità di un'elaborazione aggiuntiva di archiviazione e aggregazione e riduce il numero complessivo di oggetti di database di cui eseguire la migrazione.

C'è un altro potenziale vantaggio per questo approccio. Implementando la logica di aggregazione e join all'interno di un livello di virtualizzazione e presentando strumenti di creazione di report esterni tramite una vista virtualizzata, l'elaborazione necessaria per creare queste viste viene "spostata verso il basso" nel data warehouse, cosa che è in genere è la posizione migliore per eseguire join, aggregazioni e altre operazioni correlate su volumi di dati di grandi dimensioni.

I driver principali per la scelta di un'implementazione del data mart virtuale in un data mart fisico sono:

  • Più agilità: un data mart virtuale è più facile da modificare rispetto alle tabelle fisiche e ai processi ETL associati.

  • Costo totale di proprietà inferiore: un'implementazione virtualizzata richiede meno archivi dati e copie di dati.

  • Eliminazione dei processi ETL di cui eseguire la migrazione e architettura data warehouse semplificata in un ambiente virtualizzato.

  • Prestazioni: anche se i data mart fisici sono storicamente più efficienti, i prodotti di virtualizzazione ora implementano tecniche di memorizzazione nella cache intelligenti per attenuare i problemi.

Migrazione dei dati da Netezza

Informazioni sui dati

Parte della pianificazione della migrazione consiste nel comprendere in dettaglio il volume di dati di cui è necessario eseguire la migrazione, in quanto ciò può influire sulle decisioni relative all'approccio alla migrazione. Usare i metadati di sistema per determinare lo spazio fisico occupato dai "dati non elaborati" all'interno delle tabelle di cui eseguire la migrazione. In questo contesto, per "dati non elaborati" si indica la quantità di spazio usata dalle righe di dati all'interno di una tabella, esclusi i sovraccarichi, ad esempio indici e compressione. Ciò vale soprattutto per le tabelle dei fatti più grandi, perché in genere comprenderanno più del 95% dei dati.

È possibile ottenere un numero accurato per il volume di dati di cui eseguire la migrazione per una determinata tabella estraendo un campione rappresentativo dei dati, ad esempio un milione di righe, in un file di dati ASCII delimitato e non compresso. Usare quindi le dimensioni del file per ottenere una dimensione media dei dati non elaborati per riga di tale tabella. Moltiplicare infine tale dimensione media per il numero totale di righe nella tabella completa per assegnare una dimensione dei dati non elaborata per la tabella. Usare le dimensioni dei dati non elaborate nella pianificazione.

Mapping dei tipi di dati Netezza

Suggerimento

Valutare l'impatto dei tipi di dati non supportati come parte della fase di preparazione.

La maggior parte dei tipi di dati Netezza ha un equivalente diretto in Azure Synapse. La tabella seguente illustra questi tipi di dati insieme all'approccio consigliato per eseguirne il mapping.

Tipo di dati Netezza Tipo di dati di Azure Synapse
bigint bigint
BINARY VARYING(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)
DOUBLE PRECISION FLOAT
FLOAT(n) FLOAT(n)
INTEGER INT
INTERVAL I tipi di dati INTERVAL non sono attualmente supportati direttamente in Azure Synapse Analytics, ma possono essere calcolati usando funzioni temporali come DATEDIFF.
MONEY MONEY
NATIONAL CHARACTER VARYING(n) NVARCHAR(n)
NATIONAL CHARACTER(n) NCHAR(n)
NUMERIC(p,s) NUMERIC(p,s)
REAL REAL
SMALLINT SMALLINT
ST_GEOMETRY(n) I tipi di dati spaziali, ad esempio ST_GEOMETRY, non sono attualmente supportati in Azure Synapse Analytics, ma i dati possono essere archiviati come VARCHAR o VARBINARY.
ORA ORA
TIME WITH TIME ZONE DATETIMEOFFSET
TIMESTAMP DATETIME

Usare i metadati delle tabelle del catalogo Netezza per determinare se è necessario eseguire la migrazione di uno di questi tipi di dati e consentire questa operazione nel proprio piano di migrazione. Le viste di metadati importanti in Netezza per questo tipo di query sono:

  • _V_USER: la visualizzazione utente fornisce informazioni sugli utenti nel sistema Netezza.

  • _V_TABLE: la vista tabella contiene l'elenco delle tabelle create nel sistema di prestazioni Netezza.

  • _V_RELATION_COLUMN: la vista del catalogo di sistema delle colonne di relazione contiene le colonne disponibili in una tabella.

  • _V_OBJECTS: la visualizzazione oggetti elenca i diversi oggetti, ad esempio tabelle, viste, funzioni e così via, disponibili in Netezza.

Ad esempio, questa query SQL Netezza mostra le colonne e i tipi di colonna:

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)

La query può essere modificata per cercare in tutte le tabelle eventuali occorrenze di tipi di dati non supportati.

Azure Data Factory può essere usato per spostare i dati da un ambiente Netezza legacy. Per altre informazioni, vedere Connettore IBM Netezza.

I fornitori di terze parti offrono strumenti e servizi per automatizzare la migrazione, incluso il mapping dei tipi di dati, come descritto in precedenza. Inoltre, gli strumenti ETL di terze parti, come Informatica o Talend, già in uso nell'ambiente Netezza possono implementare tutte le trasformazioni dei dati necessarie. La sezione successiva illustra la migrazione dei processi ETL di terze parti esistenti.

Considerazioni sulla migrazione ETL

Decisioni iniziali relative alla migrazione ETL di Netezza

Suggerimento

Pianificare l'approccio alla migrazione ETL in anticipo e sfruttare le funzionalità di Azure, se appropriato.

Per l'elaborazione ETL/ELT, i data warehouse Netezza legacy possono usare script personalizzati usando utilità Netezza come nzsql e nzload o strumenti ETL di terze parti, ad esempio Informatica o Ab Initio. In alcuni casi, i data warehouse Netezza usano una combinazione di approcci ETL e ELT che si sono evoluti nel tempo. Quando si pianifica una migrazione ad Azure Synapse, è necessario determinare il modo migliore per implementare l'elaborazione ETL/ELT necessaria nel nuovo ambiente riducendo al minimo i costi e i rischi coinvolti. Per altre informazioni sull'elaborazione ETL ed ELT, vedere Approccio di progettazione ELT ed ETL.

Nelle sezioni seguenti vengono illustrate le opzioni di migrazione e vengono fornite raccomandazioni per vari casi d'uso. Questo diagramma di flusso riepiloga un approccio:

Flowchart of migration options and recommendations.

Il primo passaggio consiste sempre nel creare un inventario dei processi ETL/ELT di cui è necessario eseguire la migrazione. Come per altri passaggi, è possibile che le funzionalità standard di Azure "predefinite" rendano superflua la migrazione di alcuni processi esistenti. Ai fini della pianificazione, è importante comprendere la scala della migrazione da eseguire.

Nel diagramma di flusso precedente, la decisione 1 si riferisce a una decisione generale sulla migrazione a un ambiente completamente nativo di Azure. Se si passa a un ambiente completamente nativo di Azure, è consigliabile riconfigurare l'elaborazione ETL usando Pipeline e attività in Azure Data Factory o Azure Synapse Pipelines. Se non si passa a un ambiente completamente nativo di Azure, la decisione 2 riguarda se sia già in uso uno strumento ETL di terze parti esistente.

Suggerimento

Sfruttare gli investimenti negli strumenti di terze parti esistenti per ridurre i costi e i rischi.

Se uno strumento ETL di terze parti è già in uso e soprattutto se è stato effettuato un grande investimento in competenze o in diversi flussi di lavoro e pianificazioni esistenti, la decisione 3 riguarda se lo strumento possa supportare in modo efficiente Azure Synapse come ambiente di destinazione. Idealmente, lo strumento includerà connettori "nativi" che possono sfruttare le funzionalità di Azure come PolyBase o COPY INTO, per il caricamento dei dati più efficiente. È possibile chiamare un processo esterno, ad esempio PolyBase o COPY INTO, e passare i parametri appropriati. In questo caso, sfruttare le competenze e i flussi di lavoro esistenti, con Azure Synapse come nuovo ambiente di destinazione.

Se si decide di mantenere uno strumento ETL di terze parti esistente, l'esecuzione di tale strumento all'interno dell'ambiente Azure (anziché in un server ETL locale esistente) può comportare vantaggi e permettere la gestione dell'orchestrazione complessiva dei flussi di lavoro esistenti da parte di Azure Data Factory. Un vantaggio particolare è che è necessario scaricare meno dati da Azure, elaborarli e quindi caricarli di nuovo in Azure. Quindi, la decisione 4 riguarda se lasciare lo strumento esistente in esecuzione così com'è oppure spostarlo nell'ambiente di Azure per ottenere vantaggi di costo, prestazioni e scalabilità.

Riconfigurare gli script specifici di Netezza esistenti

Se alcune o tutte le elaborazioni ETL/ELT del warehouse Netezza esistenti vengono gestite da script personalizzati che usano utilità specifiche di Netezza, ad esempio nzsql o nzload, allora questi script devono essere codificati nuovamente per il nuovo ambiente Azure Synapse. Analogamente, se i processi ETL sono stati implementati usando stored procedure in Netezza, queste dovranno essere codificate nuovamente.

Suggerimento

L'inventario delle attività ETL di cui eseguire la migrazione deve includere script e stored procedure.

Alcuni elementi del processo ETL sono facili da sottoporre a migrazione, ad esempio tramite semplice caricamento di dati in blocco in una tabella di gestione temporanea da un file esterno. Può anche essere possibile automatizzare tali parti del processo, ad esempio usando PolyBase anziché nzload. Altre parti del processo che contengono stored procedure e/o SQL complesso arbitrario richiederanno più tempo per la riprogettazione.

Un modo per testare Netezza SQL per la compatibilità con Azure Synapse consiste nell'acquisire alcune istruzioni SQL rappresentative dalla cronologia delle query di Netezza e quindi di anteporre tali query con EXPLAIN. In seguito, presupponendo un modello di dati trasferito in modo identico in Azure Synapse, eseguire tali istruzioni EXPLAIN in Azure Synapse. Qualsiasi SQL incompatibile genererà un errore e le informazioni sull'errore possono determinare la scala dell'attività di ricodifica.

I partner Microsoft offrono strumenti e servizi per eseguire la migrazione di Netezza SQL e stored procedure ad Azure Synapse.

Usare strumenti ETL di terze parti

Come descritto nella sezione precedente, in molti casi il sistema di data warehouse legacy esistente sarà già popolato e gestito da prodotti ETL di terze parti. Per un elenco dei partner di integrazione dei dati Microsoft per Azure Synapse, vedere Partner di integrazione dei dati.

Caricamento dei dati da Netezza

Scelte disponibili durante il caricamento dei dati da Netezza

Suggerimento

Gli strumenti di terze parti possono semplificare e automatizzare il processo di migrazione e quindi ridurre i rischi.

Quando si tratta di eseguire la migrazione dei dati da un data warehouse Netezza, esistono alcune domande di base associate al caricamento dei dati che devono essere affrontate. Sarà necessario decidere come i dati verranno spostati fisicamente dall'ambiente Netezza locale esistente in Azure Synapse nel cloud e quali strumenti verranno usati per eseguire il trasferimento e il carico. Considerare le domande seguenti, illustrate nelle sezioni successive.

  • I dati verranno estratti nei file o spostati direttamente tramite una connessione di rete?

  • Il processo verrà orchestrato dal sistema di origine o dall'ambiente di destinazione di Azure?

  • Quali strumenti verranno usati per automatizzare e gestire il processo?

Trasferire dati tramite file o connessioni di rete?

Suggerimento

Comprendere i volumi di dati di cui eseguire la migrazione e la larghezza di banda di rete disponibile, perché questi fattori influenzeranno la decisione dell'approccio alla migrazione.

Dopo aver creato le tabelle di database di cui eseguire la migrazione in Azure Synapse, è possibile spostare i dati per popolare tali tabelle dal sistema Netezza legacy e nel nuovo ambiente. Esistono due approcci di base:

  • Estrazione file: estrarre i dati dalle tabelle Netezza ai file flat, in genere in formato CSV, tramite nzsql con l'opzione -o oppure tramite l'istruzione CREATE EXTERNAL TABLE. Usare una tabella esterna quando possibile perché è la più efficiente in termini di velocità effettiva dei dati. L'esempio SQL seguente crea un file CSV tramite una tabella esterna:

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

    Usare una tabella esterna se si esportano dati in un file system montato in un host Netezza locale. Se si esportano dati in un computer remoto in cui è installato JDBC, ODBC o OLEDB, l'opzione "remotesource odbc" è la clausola USING.

    Questo approccio richiede spazio per spostare i file di dati estratti. Lo spazio potrebbe essere locale per il database di origine Netezza (se è disponibile spazio di archiviazione sufficiente) o remoto in Archiviazione BLOB di Azure. Le prestazioni migliori si ottengono quando un file viene scritto in locale, in quanto si evita il sovraccarico di rete.

    Per ridurre al minimo i requisiti di archiviazione e trasferimento di rete, è consigliabile comprimere i file di dati estratti usando un'utilità come gzip.

    Una volta estratti, i file flat possono essere spostati in Archiviazione BLOB di Azure (collocati con l'istanza di Azure Synapse di destinazione) o caricati direttamente in Azure Synapse usando PolyBase o COPY INTO. Il metodo per spostare fisicamente i dati dall'archiviazione locale all'ambiente cloud di Azure dipende dalla quantità di dati e dalla larghezza di banda di rete disponibile.

    Microsoft offre diverse opzioni per spostare grandi volumi di dati, tra cui AzCopy per lo spostamento di file in rete in Archiviazione di Azure, Azure ExpressRoute per lo spostamento di dati in blocco tramite una connessione di rete privata e Azure Data Box per lo spostamento di file in un dispositivo di archiviazione fisico che viene quindi fornito a un data center di Azure per il caricamento. Per altre informazioni, vedere Trasferimento dei dati.

  • Estrazione diretta e caricamento tra reti: l'ambiente di Azure di destinazione invia una richiesta di estrazione dei dati, in genere tramite un comando SQL, al sistema Netezza legacy per estrarre i dati. I risultati vengono inviati in rete e caricati direttamente in Azure Synapse, senza dover trasferire i dati in file intermedi. Il fattore di limitazione in questo scenario è in genere la larghezza di banda della connessione di rete tra il database Netezza e l'ambiente Azure. Per volumi di dati molto grandi, questo approccio potrebbe non essere pratico.

Esiste anche un approccio ibrido che usa entrambi i metodi. Ad esempio, è possibile usare l'approccio di estrazione diretta dalla rete per tabelle di dimensioni più piccole e per campioni delle tabelle dei fatti più grandi per fornire rapidamente un ambiente di test in Azure Synapse. Per le tabelle dei fatti cronologici di volumi di grandi dimensioni, è possibile usare l'approccio di estrazione e trasferimento dei file usando Azure Data Box.

Orchestrare da Netezza o Azure?

L'approccio consigliato quando si passa ad Azure Synapse consiste nell'orchestrare l'estrazione e il caricamento dei dati dall'ambiente Azure usando Azure Synapse Pipelines o Azure Data Factory, nonché le utilità associate, ad esempio PolyBase o COPY INTO, per un caricamento dei dati più efficiente. Questo approccio sfrutta le funzionalità di Azure e offre un metodo semplice per creare pipeline di caricamento dei dati riutilizzabili.

Altri vantaggi di questo approccio includono una riduzione dell'impatto sul sistema Netezza durante il processo di caricamento dei dati, poiché il processo di gestione e caricamento è in esecuzione in Azure ed è possibile automatizzarlo tramite pipeline di caricamento dei dati basate sui metadati.

Quali strumenti è possibile usare?

L'attività di trasformazione e spostamento dei dati è la funzione di base di tutti i prodotti ETL. Se uno di questi prodotti è già in uso nell'ambiente Netezza esistente, l'uso dello strumento ETL esistente può semplificare la migrazione dei dati da Netezza ad Azure Synapse. Questo approccio presuppone che lo strumento ETL supporti Azure Synapse come ambiente di destinazione. Per altre informazioni sugli strumenti che supportano Azure Synapse, vedere Partner di integrazione dei dati.

Se si usa uno strumento ETL, prendere in considerazione l'esecuzione di tale strumento all'interno dell'ambiente Azure per trarre vantaggio dalle prestazioni, dalla scalabilità e dai costi del cloud di Azure e liberare risorse nel data center Netezza. Un altro vantaggio è la riduzione dello spostamento dei dati tra ambienti cloud e locali.

Riepilogo

Per riepilogare, i suggerimenti per la migrazione dei dati e dei processi ETL associati da Netezza ad Azure Synapse sono:

  • Pianificare in anticipo per garantire un esercizio di migrazione riuscito.

  • Creare un inventario dettagliato dei dati e dei processi di cui eseguire la migrazione il prima possibile.

  • Usare i metadati di sistema e i file di log per ottenere una comprensione accurata dei dati e dell'utilizzo dei processi. Non basarsi sulla documentazione perché potrebbe non essere aggiornata.

  • Comprendere i volumi di dati di cui eseguire la migrazione e la larghezza di banda di rete tra il data center locale e gli ambienti cloud di Azure.

  • Sfruttare le funzionalità di Azure "predefinite" standard per ridurre al minimo il carico di lavoro di migrazione.

  • Identificare e comprendere gli strumenti più efficienti per l'estrazione e il caricamento dei dati in ambienti Netezza e Azure. Usare gli strumenti appropriati in ogni fase del processo.

  • Usare le funzionalità di Azure, ad esempio Azure Synapse Pipelines o Azure Data Factory, per orchestrare e automatizzare il processo di migrazione riducendo al minimo l'impatto sul sistema Netezza.

Passaggi successivi

Per altre informazioni sulle operazioni di accesso alla sicurezza, vedere l'articolo successivo di questa serie: Sicurezza, accesso e operazioni per le migrazioni Netezza.