Progettazione e prestazioni per le migrazioni Teradata

  • Articolo

Questo articolo è la prima 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 progettazione e prestazioni.

Panoramica

Molti utenti esistenti di sistemi di data warehouse Teradata vogliono sfruttare le innovazioni offerte dagli ambienti cloud moderni. Gli ambienti cloud IaaS (Infrastructure-as-a-Service) e PaaS (Platform-as-a-Service) consentono di delegare attività come la manutenzione dell'infrastruttura e lo sviluppo della piattaforma al provider di servizi cloud.

Suggerimento

Oltre a un semplice database, l'ambiente Azure include un set completo di funzionalità e strumenti.

Anche se Teradata e Azure Synapse Analytics sono entrambi database SQL che usano tecniche di elaborazione parallela elevata (MPP) per ottenere prestazioni di query elevate su volumi di dati di dimensioni eccezionali, esistono alcune differenze di base nell'approccio:

  • I sistemi Teradata legacy vengono spesso installati in locale e usano hardware proprietario, mentre Azure Synapse è basato sul cloud e usa archiviazione e risorse di calcolo di Azure.

  • Poiché le risorse di archiviazione e calcolo sono separate nell'ambiente Azure e hanno funzionalità di scalabilità elastica, tali risorse possono essere ridimensionate verso l'alto o verso il basso in modo indipendente.

  • È possibile sospendere o ridimensionare Azure Synapse in base alle esigenze per ridurre l'utilizzo e i costi delle risorse.

  • L'aggiornamento di una configurazione Teradata è un'operazione impegnativa, che richiede hardware fisico aggiuntivo e processi di dump e ricaricamento o di riconfigurazione del database potenzialmente lunghi.

Microsoft Azure è un ambiente cloud disponibile a livello globale, altamente sicuro e scalabile, che include Azure Synapse all'interno di un ecosistema di strumenti e funzionalità di supporto. Il diagramma seguente riepiloga l'ecosistema Azure Synapse.

Chart showing the Azure Synapse ecosystem of supporting tools and capabilities.

Azure Synapse offre prestazioni ottimali del database relazionale usando tecniche come MPP e più livelli di memorizzazione nella cache automatizzata per i dati usati di frequente. I risultati di queste tecniche possono essere verificati in benchmark indipendenti, ad esempio quello eseguito di recente da GigaOm, che confronta Azure Synapse con altre offerte diffuse di data warehouse sul cloud. I clienti che eseguono la migrazione all'ambiente Azure Synapse ottengono molti vantaggi, tra cui:

  • Prestazioni più elevate e rapporto prezzo/prestazioni migliorato.

  • Maggiore agilità e time-to-value più breve.

  • Procedure più rapide di distribuzione di server e sviluppo di applicazioni.

  • Scalabilità elastica, pagando solo per l'utilizzo effettivo.

  • Sicurezza e conformità migliorate.

  • Riduzione dei costi di archiviazione e ripristino di emergenza.

  • Riduzione del costo totale di proprietà, migliore controllo dei costi e riduzione delle spese operative (OPEX).

Per ottimizzare questi vantaggi, eseguire la migrazione di dati e applicazioni nuovi o esistenti alla piattaforma Azure Synapse. In molte organizzazioni la migrazione include lo spostamento di un data warehouse esistente da una piattaforma locale legacy, ad esempio Teradata, ad Azure Synapse. A livello generale, il processo di migrazione include questi passaggi:

    Preparazione 🡆

  • Definire l'ambito, ossia gli elementi di cui eseguire la migrazione.

  • Creare un inventario di dati e processi di cui eseguire la migrazione.

  • Definire le modifiche al modello di dati (se presenti).

  • Definire il meccanismo di estrazione dei dati di origine.

  • Identificare gli strumenti e le funzionalità di Azure e di terze parti appropriati da usare.

  • Eseguire preventivamente il training del personale sulla nuova piattaforma.

  • Configurare la piattaforma di destinazione di Azure.

    Migrazione 🡆

  • Iniziare con un progetto semplice e di piccole dimensioni.

  • Automatizzare laddove possibile.

  • Sfruttare gli strumenti e le funzionalità predefiniti di Azure per ridurre le attività di migrazione.

  • Eseguire la migrazione dei metadati per tabelle e viste.

  • Eseguire la migrazione dei dati cronologici da gestire.

  • Eseguire la migrazione o il refactoring di stored procedure e processi aziendali.

  • Eseguire la migrazione o il refactoring dei processi di caricamento incrementale ETL/ELT.

    Dopo la migrazione

  • Monitorare e documentare tutte le fasi del processo.

  • Usare l'esperienza acquisita per creare un modello per le migrazioni future.

  • Riprogettare il modello di dati se necessario (usando nuove prestazioni e scalabilità della piattaforma).

  • Testare le applicazioni e gli strumenti di query.

  • Eseguire il benchmark delle prestazioni delle query e ottimizzarle.

Questo articolo fornisce informazioni generali e linee guida per l'ottimizzazione delle prestazioni durante la migrazione di un data warehouse da un ambiente Netezza esistente ad Azure Synapse. L'obiettivo dell'ottimizzazione delle prestazioni è ottenere le stesse prestazioni del data warehouse in Azure Synapse dopo la migrazione dello schema.

Considerazioni relative alla progettazione

Ambito migrazione

Quando si prepara la migrazione da un ambiente Teradata, prendere in considerazione le opzioni di migrazione seguenti.

Scegliere il carico di lavoro per la migrazione iniziale

In genere, gli ambienti Teradata legacy si sono evoluti nel tempo per includere più aree soggette e carichi di lavoro misti. Quando si decide dove iniziare un progetto di migrazione, scegliere un'area in cui sarà possibile:

  • Dimostrare l'efficacia della migrazione ad Azure Synapse concretizzando rapidamente i vantaggi del nuovo ambiente.

  • Consentire al personale tecnico interno di acquisire esperienza pertinente con i processi e gli strumenti che userà per eseguire la migrazione di altre aree.

  • Creare un modello per altre migrazioni specifiche per l'ambiente Teradata di origine e gli strumenti e i processi correnti già presenti.

Un buon candidato per una migrazione iniziale da un ambiente Teradata supporta gli elementi precedenti e:

  • Implementa un carico di lavoro BI/Analytics anziché un carico di lavoro OLTP (Online Transaction Processing).

  • Dispone di un modello di dati, ad esempio uno schema star o snowflake, di cui è possibile eseguire la migrazione con una modifica minima.

Suggerimento

Creare un inventario degli oggetti di cui è necessario eseguire la migrazione e documentare il processo di migrazione.

Il volume dei dati trasferiti in una migrazione iniziale deve essere sufficientemente grande da illustrare le funzionalità e i vantaggi dell'ambiente Azure Synapse, ma non troppo grande da dimostrare rapidamente il valore. Una dimensione nell'intervallo da 1 a 10 terabyte è tipica.

Per il progetto di migrazione iniziale, ridurre al minimo il rischio, il lavoro e il tempo di migrazione in modo da poter visualizzare rapidamente i vantaggi dell'ambiente cloud di Azure, limitare l'ambito della migrazione solo ai data mart, ad esempio la parte OLAP DB di un warehouse Teradata. Sia gli approcci di migrazione "lift and shift" che di migrazione in più fasi limitano l'ambito della migrazione iniziale solo ai data mart e non affrontano aspetti di migrazione più ampi, ad esempio la migrazione ETL e la migrazione cronologica dei dati. Tuttavia, è possibile risolvere questi aspetti nelle fasi successive del progetto dopo che il livello data mart migrato viene riempito di dati e dei processi di compilazione necessari.

Migrazione "Lift and shift" e approccio in più fasi

In generale, esistono due tipi di migrazione indipendentemente dallo scopo e dall'ambito della migrazione pianificata: "lift and shift" (così com'è) e un approccio in più fasi che incorpora le modifiche.

Modalità lift-and-shift

In una migrazione "lift and shift", un modello di dati esistente, come uno schema star, viene sottoposto a migrazione senza modifiche alla nuova piattaforma Azure Synapse. Questo approccio riduce al minimo i rischi e i tempi di migrazione diminuendo il lavoro necessario per sfruttare i vantaggi del passaggio all'ambiente cloud di Azure. La migrazione lift-and-shift è ideale per questi scenari:

  • È disponibile un ambiente Teradata esistente con un singolo data mart di cui eseguire la migrazione o
  • Si dispone di un ambiente Teradata esistente con dati già presenti in uno schema star o snowflake ben progettato oppure
  • Si hanno pressioni in termini di tempo e costi per passare a un ambiente cloud moderno.

Suggerimento

L'approccio "lift and shift" è un buon punto di partenza, anche se le fasi successive implementano le modifiche al modello di dati.

Approccio in più fasi che incorpora le modifiche

Se un data warehouse legacy si è evoluto in un lungo periodo di tempo, potrebbe essere necessario riprogettarlo per mantenere i livelli di prestazioni necessari. Potrebbe anche essere necessario riprogettare per supportare nuovi dati, ad esempio flussi IoT (Internet delle cose). Come parte del processo di re-engineering, eseguire la migrazione ad Azure Synapse per ottenere i vantaggi di un ambiente cloud scalabile. La migrazione può includere anche una modifica nel modello di dati sottostante, ad esempio uno spostamento da un modello Inmon a un insieme di credenziali dei dati.

Microsoft consiglia di spostare il modello di dati esistente così com'è in Azure (facoltativamente usando un'istanza Teradata della macchina virtuale in Azure) e di sfruttare le prestazioni e la flessibilità dell'ambiente Azure per applicare le modifiche di nuova progettazione. In questo modo, è possibile usare le funzionalità di Azure per apportare le modifiche senza influire sul sistema di origine esistente.

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

Quando si esegue la migrazione da un ambiente Teradata locale, è possibile sfruttare l'archiviazione cloud e la scalabilità elastica in Azure per creare un'istanza Teradata all'interno di una macchina virtuale. Questo approccio colloca l'istanza di Teradata con l'ambiente Azure Synapse di destinazione. È possibile usare utilità Teradata standard, ad esempio Teradata Parallel Data Transporter, per spostare in modo efficiente il subset di tabelle Teradata di cui viene eseguita la migrazione nell'istanza di macchina virtuale. Quindi, tutte le altre attività di migrazione possono essere eseguite all'interno dell'ambiente Azure. Questo approccio offre diversi vantaggi:

  • Dopo la replica iniziale dei dati, il sistema di origine non è interessato dalle attività di migrazione.

  • Nell'ambiente Azure sono disponibili interfacce, strumenti e utilità Teradata noti.

  • L'ambiente di Azure comporta potenziali problemi con 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 possono chiamare utilità come Teradata Parallel Transporter per eseguire la migrazione dei dati in modo efficiente e rapido.

  • È possibile orchestrare e controllare completamente il processo di migrazione all'interno dell'ambiente Azure.

Suggerimento

Usare le macchine virtuali di Azure per creare un'istanza Teradata temporanea per velocizzare la migrazione e ridurre al minimo l'impatto sul sistema di origine.

Usare Azure Data Factory per implementare una migrazione basata sui metadati

È possibile automatizzare e orchestrare il processo di migrazione usando le funzionalità dell'ambiente Azure. Questo approccio riduce al minimo l'impatto sulle prestazioni nell'ambiente Netezza esistente, che potrebbe essere già aver quasi raggiunto il limite di capacità.

Azure Data Factory è un servizio di integrazione di dati basato sul cloud che consente di creare flussi di lavoro basati sui dati nel cloud che orchestrano e automatizzano lo spostamento e la trasformazione dei dati stessi. È possibile usare Data Factory per creare e pianificare flussi di lavoro basati sui dati (pipeline) che inseriscono dati da archivi dati diversi. Data Factory può elaborare e trasformare i dati usando servizi di calcolo, ad esempio Azure HDInsight Hadoop, Spark, Azure Data Lake Analytics e Azure Machine Learning.

Quando si prevede di usare le funzionalità di Data Factory per gestire il processo di migrazione, creare metadati che elenchino tutte le tabelle di dati di cui eseguire la migrazione e la relativa posizione.

Differenze di progettazione tra Teradata e Azure Synapse

Come accennato in precedenza, esistono alcune differenze di base nell'approccio tra i database Teradata e Azure Synapse Analytics, che vengono illustrate di seguito.

Più database rispetto a un singolo database e schemi

L'ambiente Teradata spesso contiene più database separati. Ad esempio, potrebbero essere presenti database separati per: tabelle di inserimento dati e gestione temporanea, tabelle di core warehouse e data mart (talvolta definiti livello semantico). I processi di pipeline ETL o ELT possono implementare join tra database e spostare i dati tra i database separati.

Al contrario, l'ambiente Azure Synapse contiene un singolo database e usa schemi per separare le tabelle in gruppi separati logicamente. È consigliabile usare una serie di schemi all'interno del database di Azure Synapse di destinazione per simulare i database separati migrati dall'ambiente Teradata. Se si usano già schemi nell'ambiente Teradata, potrebbe essere necessario usare una nuova convenzione di denominazione per spostare le tabelle e le viste Teradata esistenti nel nuovo ambiente. Ad esempio, è possibile concatenare i nomi di tabella e schema Teradata esistenti nel nuovo nome della tabella Azure Synapse e quindi usare i nomi dello schema nel nuovo ambiente per mantenere i nomi originali dei database distinti. Se la denominazione del consolidamento dello schema presenta dei punti, Azure Synapse Spark potrebbe avere problemi. Sebbene sia possibile usare viste SQL sopra le tabelle sottostanti per gestire le strutture logiche, esistono potenziali svantaggi per questo approccio:

  • Le viste in Azure Synapse sono di sola lettura. È quindi necessario apportare eventuali aggiornamenti ai dati nelle tabelle di base sottostanti.

  • Potrebbero essere già presenti uno o più livelli di visualizzazioni e l'aggiunta di un ulteriore livello potrebbe influire sulle prestazioni e sul supporto perché le visualizzazioni annidate sono difficili da gestire in caso di problemi.

Suggerimento

Combinare più database in un database singolo all'interno di Azure Synapse e usare i nomi degli schemi per separare logicamente le tabelle.

Considerazioni sulle tabelle

Quando si esegue la migrazione di tabelle tra ambienti diversi, in genere vengono trasferiti solo i dati non elaborati e i metadati che li descrivono fisicamente. Altri elementi di database del sistema di origine, ad esempio gli indici, in genere non vengono trasferiti perché potrebbero non essere necessari o potrebbero essere implementati in modo diverso nel nuovo ambiente. Le ottimizzazioni delle prestazioni nell'ambiente di origine, ad esempio gli indici, indicano dove è possibile aggiungere l'ottimizzazione delle prestazioni nel nuovo ambiente. Ad esempio, se una tabella all'interno dell'ambiente Teradata di origine ha un indice secondario non univoco (NUSI), ciò suggerisce che deve essere creato un indice non cluster all'interno di Azure Synapse. Altre tecniche di ottimizzazione delle prestazioni native, ad esempio la replica di tabelle, possono essere più applicabili rispetto alla creazione di indici simili a quelle di tipo semplice.

Suggerimento

Gli indici esistenti indicano candidati per l'indicizzazione nel warehouse migrato.

Disponibilità elevata per il database

Teradata supporta la replica dei dati tra i nodi tramite l'opzione FALLBACK, che replica le righe della tabella che risiedono fisicamente in un determinato nodo in un altro nodo all'interno del sistema. Questo approccio garantisce che i dati non andranno persi se si verifica un errore del nodo e fornisce la base per gli scenari di failover.

L'obiettivo dell'architettura a disponibilità elevata in Azure Synapse Analytics è garantire che il database sia attivo e in esecuzione il 99,9% del tempo, senza doversi preoccupare dell'impatto delle operazioni di manutenzione e delle interruzioni. Per altre informazioni sul contratto di servizio, vedere Contratto di servizio per Azure Synapse Analytics. Azure gestisce automaticamente attività di manutenzione critiche, ad esempio l'applicazione di patch, i backup e gli aggiornamenti di Windows e SQL. Azure gestisce automaticamente anche eventi non pianificati, ad esempio errori nell'hardware, nel software o nella rete sottostante.

L'archiviazione dei dati in Azure Synapse viene automaticamente sottoposta a backup con gli snapshot. Questi snapshot sono una funzionalità predefinita del servizio che crea punti di ripristino. Non è necessario abilitare questa funzionalità. Gli utenti non possono attualmente eliminare i punti di ripristino automatici usati dal servizio per mantenere i contratti di servizio per il ripristino.

Il pool SQL dedicato di Azure Synapse acquisisce snapshot del data warehouse nell'arco della giornata per creare punti di ripristino disponibili per sette giorni. La durata di questo periodo di conservazione non può essere modificata. Azure Synapse supporta un obiettivo del punto di ripristino (RPO) di otto ore. È possibile ripristinare il data warehouse nell'area primaria da uno qualsiasi degli snapshot acquisiti negli ultimi sette giorni. Se sono necessari backup più granulari, è possibile usare un'altra opzione definita dall'utente.

Tipi di tabelle Teradata non supportati

Teradata supporta tipi di tabella speciali per dati temporali e serie temporali. La sintassi e alcune delle funzioni per questi tipi di tabella non sono supportate direttamente in Azure Synapse. È tuttavia possibile eseguire la migrazione dei dati in una tabella standard in Azure Synapse eseguendo il mapping a tipi di dati e indicizzazione appropriati o partizionamento della colonna di data/ora.

Suggerimento

Le tabelle standard in Azure Synapse possono supportare le serie temporali e i dati temporali Teradata migrati.

Teradata implementa la funzionalità di query temporale usando la riscrittura delle query per aggiungere altri filtri a una query temporale e limitare l'intervallo di date applicabile. Se si prevede di eseguire la migrazione di questa funzionalità dall'ambiente Teradata di origine, aggiungere il filtro aggiuntivo nelle query temporali pertinenti.

L'ambiente Azure supporta Time Series Insights per analisi complesse sui dati delle serie temporali su larga scala. Questa funzionalità è destinata alle applicazioni di analisi dei dati IoT.

Differenze di sintassi SQL DML

Esistono differenze di sintassi SQL Data Manipulation Language (DML) tra Teradata SQL e Azure Synapse T-SQL:

  • QUALIFY: Teradata supporta l'operatore QUALIFY. Ad esempio:

    SELECT col1
FROM tab1
WHERE col1='XYZ'
QUALIFY ROW_NUMBER () OVER (PARTITION by
col1 ORDER BY col1) = 1;

    Equivalente nella sintassi di Azure Synapse:

    SELECT * FROM (
SELECT col1, ROW_NUMBER () OVER (PARTITION by col1 ORDER BY col1) rn
FROM tab1 WHERE col1='XYZ'
) WHERE rn = 1;

  • Aritmetica delle date: Azure Synapse include operatori come DATEADD e DATEDIFF, che possono essere usati nei campi DATE o DATETIME. Teradata supporta la sottrazione diretta nelle date, ad esempio SELECT DATE1 - DATE2 FROM...

  • GROUP BY: per l'ordinale GROUP BY specificare in modo esplicito un nome di colonna T-SQL.

  • LIKE ANY: Teradata supporta sintassi LIKE ANY, ad esempio:

    SELECT * FROM CUSTOMER
WHERE POSTCODE LIKE ANY
('CV1%', 'CV2%', 'CV3%');

    Equivalente nella sintassi di Azure Synapse:

    SELECT * FROM CUSTOMER
WHERE
(POSTCODE LIKE 'CV1%') OR (POSTCODE LIKE 'CV2%') OR (POSTCODE LIKE 'CV3%');

  • A seconda delle impostazioni di sistema, i confronti tra caratteri in Teradata potrebbero non tenere conto della distinzione tra maiuscole e minuscole per impostazione predefinita. In Azure Synapse i confronti dei caratteri fanno sempre distinzione tra maiuscole e minuscole.

Funzioni, stored procedure, trigger e sequenze

Quando si esegue la migrazione di un data warehouse da un ambiente maturo come Teradata, è probabile che sia necessario eseguire la migrazione di elementi diversi da tabelle e viste semplici. Gli esempi includono funzioni, stored procedure, trigger e sequenze. Controllare se gli strumenti all'interno dell'ambiente Azure possono sostituire le funzionalità di funzioni, stored procedure e sequenze perché in genere è più efficiente usare gli strumenti predefiniti di Azure rispetto a ricodificarli per Azure Synapse.

Come parte della fase di preparazione, creare un inventario di oggetti di cui è necessario eseguire la migrazione, definire un metodo per gestirli e allocare risorse appropriate nel piano di migrazione.

I partner di integrazione dei dati offrono strumenti e servizi in grado di automatizzare la migrazione di funzioni, stored procedure e sequenze.

Le sezioni seguenti illustrano ulteriormente la migrazione di funzioni, stored procedure e sequenze.

Funzioni

Come per la maggior parte dei prodotti di database, Teradata supporta funzioni definite dall'utente e di sistema all'interno di un'implementazione SQL. Quando si esegue la migrazione di una piattaforma di database legacy ad Azure Synapse, è in genere possibile eseguire la migrazione di funzioni di sistema comuni senza modifiche. Alcune funzioni di sistema potrebbero avere una sintassi leggermente diversa, ma tutte le modifiche necessarie possono essere automatizzate.

Per le funzioni di sistema Teradata o le funzioni arbitrarie definite dall'utente che non hanno equivalenti in Azure Synapse, ricodificarle usando un linguaggio di ambiente di destinazione. Azure Synapse usa il linguaggio di programmazione Transact-SQL per implementare le funzioni definite dall'utente.

Stored procedure

La maggior parte dei prodotti di database moderni supporta l'archiviazione delle procedure all'interno del database. Teradata fornisce il linguaggio SPL a questo scopo. Una stored procedure contiene in genere istruzioni SQL e logica procedurale e restituisce dati o uno stato.

Azure Synapse supporta stored procedure con T-SQL, quindi è necessario codificare tutte le stored procedure sottoposte a migrazione in tale linguaggio.

Trigger

Azure Synapse non supporta la creazione di trigger, ma questa può essere implementata usando Azure Data Factory.

Sequenze

Azure Synapse gestisce le sequenze in modo analogo a Teradata ed è possibile implementare sequenze usando colonne IDENTITY o codice SQL che genera il numero di sequenza successivo in una serie. Una sequenza fornisce valori numerici univoci che è possibile usare come valori di chiave surrogata per le chiavi primarie.

Estrarre metadati e dati da un ambiente Teradata

Generazione DDL (Data Definition Language)

Lo standard SQL ANSI definisce la sintassi di base per i comandi DDL (Data Definition Language). Alcuni comandi DDL, ad esempio CREATE TABLE e CREATE VIEW, sono comuni sia a Teradata che ad Azure Synapse, ma forniscono anche funzionalità specifiche dell'implementazione, ad esempio l'indicizzazione, la distribuzione delle tabelle e le opzioni di partizionamento.

È possibile modificare gli script CREATE TABLE e CREATE VIEW Teradata esistenti per ottenere definizioni equivalenti in Azure Synapse. A tale scopo, potrebbe essere necessario usare tipi di dati modificati e rimuovere o modificare clausole specifiche di Teradata, ad esempio FALLBACK.

Tuttavia, tutte le informazioni che specificano le definizioni correnti di tabelle e viste all'interno dell'ambiente Teradata esistente vengono mantenute all'interno delle tabelle del catalogo di sistema. Queste tabelle sono la migliore fonte di queste informazioni, perché sono garantite a livello di aggiornamenti e completezza. La documentazione gestita dall'utente potrebbe non essere sincronizzata con le definizioni di tabella correnti.

All'interno dell'ambiente Teradata, le tabelle del catalogo di sistema specificano la definizione di tabella e vista corrente. A differenza della documentazione gestita dall'utente, le informazioni sul catalogo di sistema sono sempre complete e sincronizzate con le definizioni di tabella correnti. Usando le viste nel catalogo, ad esempio DBC.ColumnsV, è possibile accedere alle informazioni del catalogo di sistema per generare istruzioni DDL CREATE TABLE che creano tabelle equivalenti in Azure Synapse.

Suggerimento

Usare i metadati Teradata esistenti per automatizzare la generazione di DDL CREATE TABLE e CREATE VIEW per Azure Synapse.

È anche possibile usare strumenti di migrazione ed ETL di terze parti che elaborano le informazioni del catalogo di sistema per ottenere risultati simili.

Estrazione dei dati da Teradata

È possibile estrarre dati non elaborati da tabelle Teradata a file delimitati flat, ad esempio file CSV, usando utilità Teradata standard come Basic Teradata Query (BTEQ), Teradata FastExport o Teradata Parallel Transporter (TPT). Usare TPT per estrarre i dati della tabella nel modo più efficiente possibile. TPT usa più flussi FastExport paralleli per ottenere la velocità effettiva più elevata.

Suggerimento

Usare Teradata Parallel Transporter per un'estrazione dei dati più efficiente.

Chiamare TPT direttamente da Azure Data Factory. Questo è l'approccio consigliato per la migrazione dei dati delle istanze locali di Teradata e istanze Teradata eseguite all'interno di una macchina virtuale nell'ambiente Azure.

I file di dati estratti devono contenere testo delimitato in formato CSV, ORC (Optimized Row Columnar) o Parquet.

Per altre informazioni sulla migrazione dei dati e dell'ETL da un ambiente Teradata, vedere Migrazione dei dati, ETL e caricamento per le migrazioni Teradata.

Consigli per le prestazioni per le migrazioni Teradata

L'obiettivo dell'ottimizzazione delle prestazioni è far sì che queste siano identiche o migliori dopo la migrazione ad Azure Synapse.

Suggerimento

Definire la priorità della familiarità con le opzioni di ottimizzazione in Azure Synapse all'inizio di una migrazione.

Differenze nell'approccio di ottimizzazione delle prestazioni

Questa sezione illustra le differenze di implementazione dell'ottimizzazione delle prestazioni di basso livello tra Teradata e Azure Synapse.

Opzioni di distribuzione dei dati

Per le prestazioni, Azure Synapse è stato progettato con l'architettura a più nodi e usa l'elaborazione parallela. Per ottimizzare le prestazioni delle singole tabelle in Azure Synapse, è possibile definire un'opzione di distribuzione dei dati nelle istruzioni CREATE TABLE usando l'istruzione DISTRIBUTION. Ad esempio, è possibile specificare una tabella con distribuzione hash, che distribuisce le righe di tabella tra i nodi di calcolo usando una funzione hash deterministica. L'obiettivo è ridurre la quantità di dati spostati tra i nodi di elaborazione durante l'esecuzione di una query.

Per i join di tabelle di grandi dimensioni, l'hash distribuisce una o, idealmente, entrambe le tabelle in una delle colonne join, con un'ampia gamma di valori per garantire una distribuzione uniforme. Eseguire l'elaborazione di join in locale perché le righe di dati che verranno unite in join vengono collocate nello stesso nodo di elaborazione.

Azure Synapse supporta anche join locali tra una tabella di piccole dimensioni e una tabella di grandi dimensioni tramite la replica di tabelle di piccole dimensioni. Si consideri, ad esempio, una tabella di piccole dimensioni e una tabella dei fatti di grandi dimensioni all'interno di un modello di schema star. Azure Synapse può replicare la tabella delle dimensioni più piccole in tutti i nodi per garantire che il valore di qualsiasi chiave di join per la tabella di grandi dimensioni abbia una riga di dimensione corrispondente disponibile in locale. Il sovraccarico della replica della tabella delle dimensioni è relativamente basso per una di piccole dimensioni. Per le tabelle di grandi dimensioni, un approccio alla distribuzione hash è più appropriato. Per altre informazioni sulle opzioni di distribuzione dei dati, vedere Linee guida sulla progettazione per l'uso di tabelle replicate e Linee guida per la progettazione di tabelle distribuite.

Indicizzazione dei dati

Azure Synapse supporta diverse opzioni di indicizzazione definibili dall'utente diverse dalle opzioni di indicizzazione implementate in Teradata. Per altre informazioni sulle diverse opzioni di indicizzazione in Azure Synapse, vedere Indici nelle tabelle del pool SQL dedicato.

Gli indici esistenti all'interno dell'ambiente Teradata di origine forniscono un'indicazione utile dell'utilizzo dei dati e delle colonne candidate per l'indicizzazione nell'ambiente Azure Synapse.

Partizionamento dei dati

In un data warehouse aziendale le tabelle dei fatti possono contenere miliardi di righe. Il partizionamento ottimizza le prestazioni di manutenzione e query di queste tabelle suddividendole in parti separate per ridurre la quantità di dati elaborati. In Azure Synapse l'istruzione CREATE TABLE definisce la specifica di partizionamento per una tabella. Usare il partizionamento solo su tabelle di dimensioni molto grandi e assicurarsi che ogni partizione contenga almeno 60 milioni di righe.

È possibile usare un solo campo per tabella per il partizionamento. Spesso si tratta di un campo data perché molte query vengono filtrate in base a data o intervallo di date. È possibile modificare il partizionamento di una tabella dopo il caricamento iniziale usando l'istruzione CREATE TABLE AS (CTAS) per ricreare la tabella con una nuova distribuzione. Per una descrizione dettagliata del partizionamento in Azure Synapse, vedere Tabelle di partizionamento nel pool SQL dedicato.

Statistiche delle tabelle dati

È necessario assicurarsi che le statistiche sulle tabelle dati siano aggiornate compilandole in un passaggio statistiche nei processi ETL/ELT.

PolyBase o COPY INTO per il caricamento dei dati

PolyBase supporta un caricamento efficiente di grandi quantità di dati in un data warehouse usando flussi di caricamento paralleli. Per altre informazioni, vedere Strategia di caricamento dei dati PolyBase.

COPY INTO supporta anche l'inserimento dati con velocità effettiva elevata e:

  • Recupero dei dati da tutti i file all'interno di una cartella e sottocartelle.

  • Recupero dei dati da più posizioni nello stesso account di archiviazione. È possibile specificare più posizioni usando percorsi delimitati da virgole.

  • Azure Data Lake Storage (ADLS) e Archiviazione BLOB di Azure.

  • Formati di file CSV, PARQUET e ORC.

Gestione dei carichi di lavoro

L'esecuzione di carichi di lavoro misti può causare problemi di risorse nei sistemi sovraccarichi. Uno schema corretto di gestione del carico di lavoro comporta una gestione efficace delle risorse, ne assicura l'utilizzo altamente efficiente e massimizza il ritorno sugli investimenti. Classificazione del carico di lavoro, importanza del carico di lavoro e isolamento del carico di lavoro per dare maggiore controllo sul modo in cui il carico di lavoro usa le risorse di sistema.

La guida alla gestione del carico di lavoro descrive le tecniche per analizzare il carico di lavoro, gestire e monitorare l'importanza del carico di lavoro e i passaggi per convertire una classe di risorse in un gruppo di carico di lavoro. Usare il portale di Azure e le query T-SQL in DMV per monitorare il carico di lavoro e garantire che le risorse applicabili vengano usate in modo efficiente.

Passaggi successivi

Per informazioni su ETL e caricamento per la migrazione di Teradata, vedere l'articolo successivo di questa serie: Migrazione dei dati, ETL e caricamento per le migrazioni Teradata.