Migrazione dei dati, ETL e caricamento per le migrazioni Teradata

Questo articolo è la seconda parte di una serie in sette parti che fornisce indicazioni su come eseguire la migrazione da Teradata 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 Teradata

Quando si esegue la migrazione di un data warehouse Teradata, è 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 Teradata.

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é 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 abilitati, le tabelle e i log del catalogo di sistema Teradata 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 su DBC.Tables che fornisce la data dell'ultimo accesso e dell'ultima modifica:

SELECT TableName, CreatorName, CreateTimeStamp, LastAlterName,
LastAlterTimeStamp, AccessCount, LastAccessTimeStamp 
FROM DBC.Tables t
WHERE DataBaseName = 'databasename'

Se la registrazione è abilitata e la cronologia dei log è accessibile, altre informazioni, ad esempio il testo della query SQL, sono disponibili nella tabella DBQLogTbl e nelle tabelle di registrazione associate. Per altre informazioni, vedere Cronologia dei log Teradata.

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 Teradata, è consigliabile creare un ambiente Teradata in una macchina virtuale all'interno di Azure come un'istruzione di base nel processo di migrazione.

Usare un'istanza Teradata di macchina virtuale come parte di una migrazione

Un approccio facoltativo per la migrazione da un ambiente Teradata locale consiste nell'usare l'ambiente Azure per creare un'istanza Teradata in una macchina virtuale all'interno di Azure, collocata con l'ambiente Azure Synapse di destinazione. Ciò è possibile perché Azure offre un'archiviazione cloud economica e una scalabilità elastica.

Con questo approccio, è possibile usare utilità Teradata standard, ad esempio Teradata Parallel Data Transporter, o strumenti di replica dati di terze parti, ad esempio Attunity Replicate, per spostare in modo efficiente il subset di tabelle Teradata di cui è necessario eseguire la migrazione all'istanza della macchina virtuale. Quindi, tutte le attività di migrazione possono essere eseguite nell'ambiente Azure. Questo approccio offre diversi vantaggi:

• Dopo la replica iniziale dei dati, le attività di migrazione non influiscono sul sistema di origine.

• L'ambiente Azure include interfacce, strumenti e utilità Teradata familiari.

• L'ambiente di Azure offre la disponibilità della larghezza di banda di rete tra il sistema di origine locale e il sistema di destinazione cloud.

• Strumenti come Azure Data Factory chiamano in modo efficiente utilità, tra cui Teradata Parallel Transporter, per eseguire la migrazione dei dati in modo semplice e rapido.

• Il processo di migrazione viene orchestrato e controllato interamente dall'ambiente Azure.

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

Negli ambienti di data warehouse Teradata 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.

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 Teradata

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.

Considerazioni sulla migrazione ETL

Decisioni iniziali relative alla migrazione ETL di Teradata

Per l'elaborazione ETL/ELT, i data warehouse Teradata legacy possono usare script personalizzati tramite utilità Teradata come BTEQ e Teradata Parallel Transporter (TPT) o strumenti ETL di terze parti, ad esempio Informatica o Ab Initio. In alcuni casi, i data warehouse Teradata 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:

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.

Nell'ambiente Teradata, alcune o tutte le elaborazioni ETL possono essere eseguite da script personalizzati usando utilità specifiche di Teradata, ad esempio BTEQ e TPT. In questo caso, l'approccio deve essere quello di riprogettare l'uso di Data Factory.

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à.

Riprogettare gli script specifici di Teradata esistenti

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

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é il caricamento rapido o MLOAD. Se i file esportati sono Parquet, è possibile usare un lettore Parquet nativo, un'opzione più veloce rispetto a PolyBase. Altre parti del processo che contengono stored procedure e/o SQL complesso arbitrario richiederanno più tempo per la riprogettazione.

Un modo per testare Teradata SQL per la compatibilità con Azure Synapse consiste nell'acquisire alcune istruzioni SQL rappresentative dai log Teradata 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 Teradata 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 Teradata

Scelte disponibili durante il caricamento dei dati da Teradata

Quando si tratta di eseguire la migrazione dei dati da un data warehouse Teradata, 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 Teradata 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 di cui eseguire la migrazione in Azure Synapse, è possibile spostare i dati per popolare tali tabelle dal sistema Teradata legacy e nel nuovo ambiente. Esistono due approcci di base:

• Estrazione di file: estrarre i dati dalle tabelle Teradata ai file flat, in genere in formato CSV, tramite BTEQ, Fast Export o Teradata Parallel Transporter (TPT). Usare TPT quando possibile perché è il più efficiente in termini di velocità effettiva dei dati.

  Questo approccio richiede spazio per spostare i file di dati estratti. Lo spazio potrebbe essere locale per il database di origine Teradata (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 in cui i file vengono spostati 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 Teradata 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 Teradata 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 Teradata 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 Teradata 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 Teradata esistente, l'uso dello strumento ETL esistente può semplificare la migrazione dei dati da Teradata 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 Teradata. 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 Teradata 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.

• Prendere in considerazione l'uso di un'istanza Teradata in una macchina virtuale di Azure come procedura di offload della migrazione dall'ambiente Teradata legacy.

• 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 Teradata 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 Teradata.

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 Teradata.