Ridurre al minimo i problemi di SQL per le migrazioni Teradata

Questo articolo fa parte di cinque di una serie in sette parti che fornisce indicazioni su come eseguire la migrazione da Teradata ad Azure Synapse Analytics. L'attenzione di questo articolo è costituita dalle procedure consigliate per ridurre al minimo i problemi di SQL.

Informazioni generali

Caratteristiche degli ambienti Teradata

Nel 1984, Teradata ha inizialmente rilasciato il prodotto di database. Ha introdotto tecniche di elaborazione parallela massiva (MPP) per consentire l'elaborazione dei dati su larga scala in modo più efficiente rispetto alle tecnologie mainframe esistenti disponibili al momento. Da allora, il prodotto si è evoluto e ha molte installazioni tra grandi istituzioni finanziarie, telecomunicazioni e società di vendita al dettaglio. L'implementazione originale utilizzava apparecchiature proprietarie ed era connessa tramite canale ai mainframe, tipicamente processori IBM o compatibili con IBM.

Anche se gli annunci più recenti hanno incluso la connettività di rete e la disponibilità dello stack di tecnologie Teradata nel cloud (incluso Azure), la maggior parte delle installazioni esistenti è in locale, quindi molti utenti stanno valutando la migrazione di alcuni o tutti i dati Teradata ad Azure Synapse Analytics per ottenere i vantaggi di un passaggio a un ambiente cloud moderno.

La tecnologia Teradata viene spesso usata per implementare un data warehouse, supportando query analitiche complesse su volumi di dati di grandi dimensioni tramite SQL. I modelli di dati dimensionali, ovvero schemi star o snowflake, sono comuni, come l'implementazione di data mart per singoli reparti.

Questa combinazione di modelli di dati SQL e dimensionali semplifica la migrazione ad Azure Synapse, poiché i concetti di base e le competenze SQL sono trasferiscibili. L'approccio consigliato consiste nel eseguire la migrazione del modello di dati esistente as-is per ridurre il rischio e il tempo impiegato. Anche se l'intenzione finale consiste nell'apportare modifiche al modello di dati (ad esempio, passando a un modello di insieme di credenziali dei dati), eseguire una migrazione iniziale as-is e quindi apportare modifiche all'interno dell'ambiente cloud di Azure, sfruttando le prestazioni, la scalabilità elastica e i vantaggi dei costi.

Mentre il linguaggio SQL è stato standardizzato, i singoli fornitori hanno in alcuni casi implementato estensioni proprietarie. Questo documento evidenzia le potenziali differenze SQL che possono verificarsi durante la migrazione da un ambiente Teradata legacy e offre soluzioni alternative.

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

Sfruttare l'ambiente Azure quando si esegue una migrazione da un ambiente Teradata locale. Azure offre risorse di archiviazione cloud e scalabilità elastiche convenienti per creare un'istanza Teradata all'interno di una macchina virtuale in Azure, collocata con l'ambiente Azure Synapse di destinazione.

Con questo approccio, è possibile usare utilità Teradata standard come Teradata Parallel Data Transporter (o strumenti di replica di dati di terze parti, ad esempio Attunity Replicate) per spostare in modo efficiente il subset di tabelle Teradata di cui eseguire la migrazione nell'istanza della macchina virtuale e quindi tutte le 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.

• Le interfacce, gli strumenti e le utilità Teradata familiari sono disponibili all'interno dell'ambiente Azure.

• Una volta nell'ambiente Azure non sono presenti 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 in modo efficiente utilità come Teradata Parallel Transporter per eseguire la migrazione dei dati in modo rapido e semplice.

• Il processo di migrazione viene orchestrato e controllato interamente all'interno dell'ambiente Azure.

Usare Azure Data Factory per implementare una migrazione basata sui metadati

Automatizzare e orchestrare il processo di migrazione usando le funzionalità nell'ambiente Azure. Questo approccio riduce anche al minimo l'impatto della migrazione sull'ambiente Teradata esistente, che potrebbe essere già in esecuzione vicino alla capacità completa.

Azure Data Factory è un servizio di integrazione dei dati basato sul cloud che consente la creazione di flussi di lavoro basati sui dati nel cloud per orchestrare e automatizzare lo spostamento e la trasformazione dei dati. Usando Data Factory, è possibile creare e pianificare flussi di lavoro basati sui dati, denominati pipeline, che possono inserire dati da archivi dati diversi. Può elaborare e trasformare i dati usando servizi di calcolo come Azure HDInsight Hadoop, Spark, Azure Data Lake Analytics e Azure Machine Learning.

Creando metadati per elencare le tabelle dati di cui eseguire la migrazione e la relativa posizione, è possibile usare le funzionalità di Data Factory per gestire e automatizzare parti del processo di migrazione. È anche possibile usare le pipeline di Azure Synapse.

Differenze di DDL SQL tra Teradata e Azure Synapse

Linguaggio DDL (SQL Data Definition Language)

Lo standard SQL ANSI definisce la sintassi di base per i comandi DDL, CREATE TABLE ad esempio e CREATE VIEW. Questi comandi vengono usati sia in Teradata che in Azure Synapse, ma sono stati estesi anche per consentire la definizione di funzionalità specifiche dell'implementazione, ad esempio l'indicizzazione, la distribuzione delle tabelle e le opzioni di partizionamento.

Le sezioni seguenti illustrano le opzioni specifiche di Teradata da considerare durante una migrazione ad Azure Synapse.

Considerazioni sulle tabelle

Quando si esegue la migrazione di tabelle tra tecnologie diverse, solo i dati non elaborati e i relativi metadati descrittivi vengono spostati fisicamente tra i due ambienti. Altri elementi di database del sistema di origine, ad esempio indici e file di log, non vengono migrati direttamente perché potrebbero non essere necessari o potrebbero essere implementati in modo diverso all'interno del nuovo ambiente di destinazione. Ad esempio, non esiste un equivalente dell'opzione MULTISET all'interno della sintassi di CREATE TABLE Teradata.

È importante comprendere dove sono state usate ottimizzazioni delle prestazioni, ad esempio gli indici, nell'ambiente di origine. Indica dove è possibile aggiungere l'ottimizzazione delle prestazioni nel nuovo ambiente di destinazione. Ad esempio, se è stato creato un indice secondario non univoco (NUSI) nell'ambiente Teradata di origine, questo potrebbe indicare che nel database azure Synapse migrato deve essere creato un indice non cluster. Altre tecniche di ottimizzazione delle prestazioni native, come ad esempio la replica delle tabelle, potrebbero risultare più appropriate rispetto a una creazione diretta di indici.

Tipi di tabella Teradata non supportati

Teradata include il supporto per tipi di tabella speciali per i dati temporali e delle serie temporali. La sintassi e alcune delle funzioni per questi tipi di tabella non sono supportate direttamente in Azure Synapse, ma i dati possono essere migrati in una tabella standard con tipi di dati appropriati e indicizzazione o partizionamento nella colonna data/ora.

Teradata implementa la funzionalità di query temporale tramite la riscrittura delle query per aggiungere altri filtri all'interno di una query temporale per limitare l'intervallo di date applicabile. Se questa funzionalità è attualmente in uso all'interno dell'ambiente Teradata di origine e deve essere eseguita la migrazione, sarà necessario aggiungere questo filtro aggiuntivo alle query temporali pertinenti.

Tipi di dati Teradata non supportati

La maggior parte dei tipi di dati Teradata ha un equivalente diretto in Azure Synapse. La tabella seguente illustra i tipi di dati Teradata non supportati in Azure Synapse insieme al mapping consigliato. Nella tabella il tipo di colonna Teradata è il tipo archiviato nel catalogo di sistema, ad esempio in DBC.ColumnsV.

Usare i metadati delle tabelle del catalogo Teradata per determinare se eseguire la migrazione di uno di questi tipi di dati e consentire questa operazione nel piano di migrazione. Ad esempio, usare una query SQL come questa per trovare eventuali occorrenze di tipi di dati non supportati che richiedono attenzione.

SELECT
ColumnType, CASE
WHEN ColumnType = '++' THEN 'TD_ANYTYPE' 
WHEN ColumnType = 'A1' THEN 'ARRAY' WHEN 
ColumnType = 'AN' THEN 'ARRAY' WHEN 
ColumnType = 'BO' THEN 'BLOB'
WHEN ColumnType = 'CO' THEN 'CLOB'
WHEN ColumnType = 'DH' THEN 'INTERVAL DAY TO HOUR' WHEN 
ColumnType = 'DM' THEN 'INTERVAL DAY TO MINUTE' WHEN 
ColumnType = 'DS' THEN 'INTERVAL DAY TO SECOND' WHEN
ColumnType = 'DT' THEN 'DATASET'
WHEN ColumnType = 'DY' THEN 'INTERVAL DAY'
WHEN ColumnType = 'HM' THEN 'INTERVAL HOUR TO MINUTE' WHEN
ColumnType = 'HR' THEN 'INTERVAL HOUR'
WHEN ColumnType = 'HS' THEN 'INTERVAL HOUR TO SECOND' WHEN
ColumnType = 'JN' THEN 'JSON'
WHEN ColumnType = 'MI' THEN 'INTERVAL MINUTE' WHEN 
ColumnType = 'MO' THEN 'INTERVAL MONTH'
WHEN ColumnType = 'MS' THEN 'INTERVAL MINUTE TO SECOND' WHEN
ColumnType = 'PD' THEN 'PERIOD(DATE)'
WHEN ColumnType = 'PM' THEN 'PERIOD (TIMESTAMP WITH TIME ZONE)'
WHEN ColumnType = 'PS' THEN 'PERIOD(TIMESTAMP)' WHEN 
ColumnType = 'PT' THEN 'PERIOD(TIME)'
WHEN ColumnType = 'PZ' THEN 'PERIOD (TIME WITH TIME ZONE)' WHEN
ColumnType = 'SC' THEN 'INTERVAL SECOND'
WHEN ColumnType = 'SZ' THEN 'TIMESTAMP WITH TIME ZONE' WHEN
ColumnType = 'XM' THEN 'XML'
WHEN ColumnType = 'YM' THEN 'INTERVAL YEAR TO MONTH' WHEN
ColumnType = 'YR' THEN 'INTERVAL YEAR'
END AS Data_Type,
COUNT (*) AS Data_Type_Count FROM
DBC.ColumnsV
WHERE DatabaseName IN ('UserDB1', 'UserDB2', 'UserDB3') -- select databases to be migrated
GROUP BY 1,2
ORDER BY 1;

Esistono fornitori di terze parti che offrono strumenti e servizi per automatizzare la migrazione, incluso il mapping dei tipi di dati. Se uno strumento ETL di terze parti, ad esempio Informatica o Talend, è già in uso nell'ambiente Teradata, questi strumenti possono implementare qualsiasi trasformazione dei dati necessaria.

Generazione DDL (Data Definition Language)

Modificare gli script Teradata esistenti CREATE TABLE e CREATE VIEW per creare le definizioni equivalenti con tipi di dati modificati, come descritto in precedenza, se necessario. In genere, ciò comporta la rimozione di clausole aggiuntive specifiche di Teradata, FALLBACK ad esempio o MULTISET.

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. Questa è la migliore fonte di queste informazioni perché è garantita l'aggiornamento e il completamento. Tenere presente che la documentazione gestita dall'utente potrebbe non essere sincronizzata con le definizioni di tabella correnti.

Accedere a queste informazioni tramite viste nel catalogo, DBC.ColumnsV ad esempio e generare le istruzioni DDL equivalenti per le tabelle equivalenti CREATE TABLE in Azure Synapse.

Sono disponibili partner Microsoft che offrono strumenti e servizi per automatizzare la migrazione, incluso il mapping dei tipi di dati. Inoltre, se uno strumento ETL di terze parti, ad esempio Informatica o Talend, è già in uso nell'ambiente Teradata, tale strumento può implementare qualsiasi trasformazione dei dati necessaria.

Differenze DML di SQL tra Teradata e Azure Synapse

Linguaggio di manipolazione dei dati SQL (DML)

Lo standard SQL ANSI definisce la sintassi di base per i comandi DML, come SELECT, INSERT, UPDATE e DELETE. Sia Teradata che Azure Synapse usano questi comandi, ma in alcuni casi esistono differenze di implementazione.

Le sezioni seguenti illustrano i comandi DML specifici di Teradata da considerare durante una migrazione ad Azure Synapse.

Differenze di sintassi sql DML

Tenere presente queste differenze nella sintassi DML (Sql Data Manipulation Language) tra Teradata SQL e Azure Synapse (T-SQL) durante la migrazione:

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

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

  La sintassi equivalente 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 della data: Azure Synapse include operatori come DATEADD e DATEDIFF che possono essere usati in DATE o DATETIME campi. Teradata supporta la sottrazione diretta nelle date, ad esempio SELECT DATE1 - DATE2 FROM...

• In GROUP BY ordinale specificare in modo esplicito il nome della colonna T-SQL.

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

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

  L'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 tra caratteri fanno sempre distinzione tra maiuscole e minuscole.

Usare EXPLAIN per convalidare SQL legacy

Un modo per testare la compatibilità del SQL legacy di Teradata con Azure Synapse consiste nell'acquisire alcune istruzioni SQL rappresentative dai log di query del sistema legacy, anteporre tali query a EXPLAIN e, presupponendo un modello di dati "like-for-like" in Azure Synapse con gli stessi nomi di tabella e colonna, eseguire tali EXPLAIN istruzioni in Azure Synapse. Qualsiasi SQL incompatibile genererà un errore: usare queste informazioni per determinare la scala dell'attività di recoding. Questo approccio non richiede che i dati vengano caricati nell'ambiente Azure, ma solo che siano state create le tabelle e le viste pertinenti.

Funzioni, procedure memorizzate, trigger e sequenze

Quando si esegue la migrazione da un ambiente data warehouse legacy maturo, ad esempio Teradata, spesso sono presenti elementi diversi da tabelle e viste semplici di cui è necessario eseguire la migrazione al nuovo ambiente di destinazione. Ad esempio, funzioni, procedure memorizzate, trigger e sequenze.

Come parte della fase di preparazione, creare un inventario degli oggetti di cui è necessario eseguire la migrazione e definire i metodi per gestirli. Assegnare quindi un'allocazione appropriata delle risorse nel piano di progetto.

Nell'ambiente di Azure possono essere presenti funzionalità che sostituiscono le funzionalità già implementate come funzioni o stored procedure nell'ambiente Teradata. In questo caso, è spesso più efficiente usare le strutture di Azure predefinite anziché ricreare le funzioni Teradata.

I partner Microsoft offrono strumenti e servizi che possono automatizzare la migrazione.

Per altre informazioni su ognuno di questi elementi, vedere le sezioni seguenti.

Functions

Come per la maggior parte dei prodotti di database, Teradata supporta funzioni di sistema e funzioni definite dall'utente all'interno dell'implementazione di SQL. Quando si esegue la migrazione a un'altra piattaforma di database, ad esempio Azure Synapse, sono disponibili funzioni di sistema comuni e possono essere migrate senza modifiche. Alcune funzioni di sistema possono avere una sintassi leggermente diversa, ma le modifiche necessarie possono essere automatizzate. Le funzioni di sistema in cui non esistono funzioni equivalenti, ad esempio funzioni arbitrarie definite dall'utente, potrebbero dover essere riecoded usando le lingue disponibili nell'ambiente di destinazione. Azure Synapse usa il linguaggio di Transact-SQL più diffuso per implementare funzioni definite dall'utente.

Procedure memorizzate

La maggior parte dei prodotti di database moderni consente di archiviare le procedure all'interno del database. Teradata fornisce il linguaggio SPL a questo scopo. Una stored procedure contiene in genere istruzioni SQL e una logica procedurale e possono restituire dati o uno stato.

I pool SQL dedicati di Azure Synapse Analytics supportano anche stored procedure con T-SQL, quindi se è necessario eseguire la migrazione delle stored procedure, ricodicerle di conseguenza.

Attivatori

Azure Synapse non supporta la creazione di trigger, ma è possibile implementarli in Azure Data Factory.

Sequences

Le sequenze di Azure Synapse vengono gestite in modo analogo a Teradata, usando IDENTITY per creare chiavi surrogate o identità gestite.

Mapping da Teradata a T-SQL

Questa tabella mostra il mapping tra il tipo di dati Teradata e T-SQL, in linea con Azure Synapse SQL:

Riassunto

Le tipiche installazioni Teradata legacy esistenti vengono implementate in modo da semplificare la migrazione ad Azure Synapse. Usano SQL per le query analitiche su grandi volumi di dati, che sono strutturati in un qualche tipo di modello di dati dimensionale. Questi fattori li rendono candidati validi per la migrazione ad Azure Synapse.

Per ridurre al minimo l'attività di migrazione del codice SQL effettivo, seguire queste indicazioni:

• La migrazione iniziale del data warehouse deve avvenire così com'è per ridurre al minimo i rischi e i tempi impiegati, anche se l'ambiente finale incorporerà un modello di dati diverso, come il data vault.

• Prendere in considerazione l'uso di un'istanza di Teradata in una macchina virtuale di Azure come parte del processo di migrazione.

• Comprendere le differenze tra l'implementazione di Teradata SQL e Azure Synapse.

• Usare i metadati e i log di query dall'implementazione Teradata esistente per valutare l'impatto delle differenze e pianificare un approccio per attenuare.

• Automatizzare il processo, laddove possibile, per ridurre al minimo gli errori, i rischi e il tempo per la migrazione.

• Prendere in considerazione l'uso di partner e servizi Microsoft specializzati per semplificare la migrazione.

Passaggi successivi

Per altre informazioni sugli strumenti Microsoft e di terze parti, vedere l'articolo successivo di questa serie: Strumenti per la migrazione del data warehouse Teradata ad Azure Synapse Analytics.