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

Questo articolo è la seconda parte di una serie in sette parti che fornisce indicazioni su come eseguire la migrazione da Netezza ad Azure Synapse Analytics. L'obiettivo di questo articolo è 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 porre alcune domande di base relative ai dati. Per 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 degli utenti?

• Quando si esegue la migrazione dei data mart: rimanere fisici o andare virtuali?

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

Eseguire la migrazione delle tabelle inutilizzate?

È opportuno eseguire la migrazione solo delle tabelle in uso nel sistema esistente. Le tabelle non attive possono essere archiviate anziché migrate, 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 abilitata, le tabelle della cronologia delle query di Netezza contengono informazioni che possono determinare quando è stato eseguito l'ultimo accesso a una determinata tabella, che a sua volta può essere usata per decidere se una tabella è un candidato 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 utilizza la funzione aiutante FORMAT_TABLE_ACCESS e la cifra alla fine della vista $v_hist_table_access_3 per corrispondere alla versione della cronologia delle 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 su questa scala 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 as-is 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 attività di ricompilazione.

Quando si esegue la migrazione da Netezza, spesso il modello di dati esistente è già adatto per as-is migrazione ad Azure Synapse.

Eseguire la migrazione dei data mart: rimanere fisici o virtuali?

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 un determinato reparto o funzione aziendale 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, ad esempio 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 utilizzabile, anche se il modello di dati del data warehouse sottostante è diverso, ad esempio un data vault.

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

Se questi data mart vengono implementati come tabelle fisiche, richiedono risorse di archiviazione aggiuntive per archiviarle e altre elaborazioni per compilarle e aggiornarle regolarmente. Inoltre, i dati nel mart saranno aggiornati solo fino all'ultima operazione di aggiornamento e quindi potrebbero non essere adatti per dashboard di dati altamente volatili.

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, 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 rispetto a un data mart fisico sono:

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

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

• Eliminazione di processi ETL per eseguire la migrazione e semplificare l'architettura del data warehouse 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

Comprendere i tuoi dati

Parte della pianificazione della migrazione è 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, "dati non elaborati" 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ù di 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 non compresso delimitato. 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 la dimensione dei dati non elaborati nella pianificazione.

Mappatura dei tipi di dati Netezza

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.

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 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 della tabella contiene la lista delle tabelle create nel sistema di prestazioni di 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 NETezza SQL 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

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 e 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:

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 è se uno strumento ETL di terze parti esistente è già in uso.

Se uno strumento ETL di terze parti è già in uso e soprattutto se è presente un grande investimento in competenze o in diversi flussi di lavoro e pianificazioni esistenti, la decisione 3 è se lo strumento può 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 conservare 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 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 è se lasciare lo strumento esistente in esecuzione as-is o spostarlo nell'ambiente Azure per ottenere vantaggi di costo, prestazioni e scalabilità.

Riprogettare gli script esistenti specifici di Netezza

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, questi script devono essere ricodificati per il nuovo ambiente Azure Synapse. Analogamente, se i processi ETL sono stati implementati usando stored procedure in Netezza, questi dovranno anche essere ricodificati.

Alcuni elementi del processo ETL sono facili da migrare, ad esempio tramite semplice caricamento di dati in blocco in una tabella di staging 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 SQL arbitrariamente complessi e/o stored procedures richiederanno più tempo per la ri-progettazione.

Un modo per testare Netezza SQL per la compatibilità con Azure Synapse consiste nell'acquisire alcune istruzioni SQL rappresentative dalla cronologia delle query netezza, quindi anteporre tali query a EXPLAINe quindi, presupponendo un modello di dati di tipo like-for-like in Azure Synapse, eseguire tali EXPLAIN istruzioni in Azure Synapse. Qualsiasi SQL incompatibile genererà un errore e le informazioni sull'errore possono determinare la scala dell'attività di recoding.

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

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 risolte. È 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?

Dopo aver creato le tabelle di database da migrare 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 di file: estrarre i dati dalle tabelle Netezza ai file flat, in genere in formato CSV, tramite nzsql con l'opzione -o o tramite l'istruzione CREATE EXTERNAL TABLE . Usare una tabella esterna ogni volta che è 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 stai esportando dati in un computer remoto in cui sono installati JDBC, ODBC o OLEDB, l'opzione "remotesource odbc" è quella specifica per 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 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 Azure Blob Storage (collocati insieme all'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 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 i file che passano a 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 in rete: 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 direct network extract per tabelle delle dimensioni più piccole e esempi 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 da 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 il 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 e la possibilità di automatizzare il processo usando 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.

Sommario

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 di Netezza.