Ridurre al minimo i problemi di SQL per le migrazioni Teradata

Questo articolo è la quinta parte di una serie in sette parti che offre indicazioni su come eseguire la migrazione da Teradata ad Azure Synapse Analytics. L'obiettivo di questo articolo è illustrare le procedure consigliate per ridurre al minimo i problemi di SQL.

Panoramica

Caratteristiche degli ambienti Teradata

Nel 1984, Teradata ha inizialmente rilasciato il proprio prodotto database. Ha introdotto tecniche di elaborazione parallela massiva (MPP, Massive Parallel Processing) 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 ed è stato installato in numerose realtà, tra cui grandi istituzioni finanziarie, società di telecomunicazioni e di vendita al dettaglio. L'implementazione originale usava un hardware proprietario ed era collegata a mainframe, in genere 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 (schemi snowflake o a stella) 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 trasferibili. L'approccio consigliato consiste nell'eseguire la migrazione del modello di dati esistente così com'è per ridurre i rischi e i tempi impiegati. Anche se l'intenzione finale è quella di apportare modifiche al modello di dati (ad esempio, il passaggio a un modello di insieme di credenziali dei dati), eseguire una migrazione iniziale così com'è 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 di 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.

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

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

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 di dati basato sul cloud che consente di creare flussi di lavoro basati sui dati nel cloud per orchestrare e automatizzare lo spostamento e la trasformazione dei dati stessi. Con Data Factory è possibile creare e pianificare flussi di lavoro basati sui dati, denominati pipeline, che possono inserire dati da archivi dati eterogenei. Azure 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.

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 pipeline di Azure Synapse.

Differenze di SQL DDL tra Teradata e Azure Synapse

SQL Data Definition Language (DDL)

Lo standard SQL ANSI definisce la sintassi di base per i comandi DDL, ad esempio CREATE TABLE 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 CREATE TABLE di Teradata.

È importante comprendere dove sono state usate ottimizzazioni delle prestazioni, ad esempio 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, ad esempio la replica di tabelle, possono essere più applicabili rispetto alla creazione di indici simili a quelle di tipo semplice.

Tipi di tabelle Teradata non supportati

Teradata supporta tipi di tabelle speciali per i dati temporali e le 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 usando la riscrittura delle query per aggiungere altri filtri a una query temporale e 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.

L'ambiente Azure include anche funzionalità specifiche per l'analisi complessa sui dati delle serie temporali su larga scala. denominata informazioni dettagliate sulle serie temporali. Questa è destinata alle applicazioni di analisi dei dati IoT e potrebbe essere più appropriata per questo caso d'uso.

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. Il tipo di colonna Teradata all'interno della tabella corrisponde al 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;

Vi sono 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 di Teradata CREATE TABLE e CREATE VIEW esistenti per creare le definizioni equivalenti con i tipi di dati modificati, come descritto in precedenza, se necessario. In genere, ciò comporta la rimozione di clausole aggiuntive specifiche di Teradata, ad esempio FALLBACK 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. Queste sono la migliore fonte di queste informazioni, perché sono garantite a livello di aggiornamenti e completezza. Si ricorda che la documentazione gestita dall'utente potrebbe non essere sincronizzata con le definizioni di tabella correnti.

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

Esistono 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, questi strumenti possono implementare qualsiasi trasformazione dei dati necessaria.

Differenze SQL DML tra Teradata e Azure Synapse

SQL Data Manipulation Language (DML)

Lo standard SQL ANSI definisce la sintassi di base per i comandi DDL, ad esempio 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. 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...

• In GROUP BY ordinale, specificare in modo esplicito il nome della 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.

Usare EXPLAIN per convalidare SQL legacy

Un modo per testare SQL Teradata legacy per la compatibilità con Azure Synapse consiste nell'acquisire alcune istruzioni SQL rappresentative dai log di query di sistema legacy, anteporre tali query con EXPLAINe (presupponendo un modello di dati migrato "like-for-like" in Azure Synapse con gli stessi nomi di tabella e colonna) eseguire tali istruzioni EXPLAIN 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, stored procedure, 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. Gli esempi includono funzioni, stored procedure, 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 Azure possono essere presenti strutture che sostituiscono la funzionalità implementata 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.

Funzioni

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 ricodificate usando le lingue disponibili nell'ambiente di destinazione. Azure Synapse usa il noto linguaggio di programmazione Transact-SQL per implementare le funzioni definite dall'utente.

Stored procedure

La maggior parte dei prodotti di database moderni consente di archiviare le procedure all'interno del database. Teradata offre il linguaggio SPL a questo scopo. Una stored procedure contiene in genere istruzioni SQL e una logica procedurale e può 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, ricodificarle di conseguenza.

Trigger

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

Sequenze

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

Mapping da Teradata a T-SQL

Questa tabella illustra il mapping dei tipi di dati da Teradata a T-SQL conformi al mapping dei tipi di dati SQL di Azure Synapse:

Riepilogo

Le tipiche installazioni Teradata legacy esistenti vengono implementate in modo da semplificare la migrazione ad Azure Synapse. Usano SQL per le query analitiche su volumi di dati di grandi dimensioni e si presentano sotto forma di modello di dati dimensionale. Questi fattori le rendono candidate valide 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 essere così com'è, per ridurre al minimo i rischi e i tempi impiegati, anche se l'ambiente finale incorpora un modello di dati diverso, ad esempio l'insieme di credenziali dei dati.

• 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 di mitigazione.

• 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 Microsoft e servizi 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 di data warehouse Teradata ad Azure Synapse Analytics.