Ridurre al minimo i problemi di SQL per le migrazioni di Netezza

  • Articolo

Questo articolo è la parte cinque 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 è illustrare le procedure consigliate per ridurre al minimo i problemi di SQL.

Panoramica

Caratteristiche degli ambienti Netezza

Suggerimento

Netezza ha introdotto il concetto di "appliance data warehouse" nei primi anni 2000.

Nel 2003 Netezza ha inizialmente rilasciato il prodotto dell'appliance data warehouse. Ha ridotto il costo di ingresso e migliorato la facilità d'uso delle tecniche di elaborazione parallela massiva (MPP) per consentire l'elaborazione dei dati su larga scala in modo più efficiente rispetto al mainframe esistente o ad altre tecnologie MPP 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 usava hardware proprietario, tra cui Field Programmable Gate Array, o FPGA, ed era accessibile tramite la connessione di rete ODBC o JDBC su TCP/IP.

La maggior parte delle installazioni Netezza esistenti è locale, quindi molti utenti stanno valutando la migrazione di alcuni o tutti i dati Netezza ad Azure Synapse Analytics per sfruttare i vantaggi di un passaggio a un ambiente cloud moderno.

Suggerimento

Molte installazioni Netezza esistenti sono data warehouse che usano un modello di dati dimensionale.

La tecnologia Netezza viene spesso usata per implementare un data warehouse, supportando query analitiche complesse su volumi di dati di grandi dimensioni usando 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 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 Netezza legacy e offre soluzioni alternative.

Usare Azure Data Factory per implementare una migrazione basata sui metadati

Suggerimento

Automatizzare il processo di migrazione usando le funzionalità di Azure Data Factory.

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

Differenze di DDL SQL tra Netezza e Azure Synapse

SQL Data Definition Language (DDL)

Suggerimento

I comandi SQL DDL CREATE TABLE e CREATE VIEW dispongono di elementi di base standard, ma vengono usati anche per definire opzioni specifiche dell'implementazione.

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 Netezza 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 Netezza da considerare durante una migrazione ad Azure Synapse.

Considerazioni sulle tabelle

Suggerimento

Usare gli indici esistenti per fornire un'indicazione dei candidati per l'indicizzazione nel warehouse migrato.

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, l'opzione TEMPORARY all'interno della sintassi CREATE TABLE di Netezza equivale al prefisso del nome della tabella con un carattere "#" in Azure Synapse.

È 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 le mappe di zona sono state create nell'ambiente Netezza di origine, questo potrebbe indicare che è necessario creare un indice non cluster nel database di Azure Synapse migrato. 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 oggetto di database Netezza non supportati

Suggerimento

Le funzionalità specifiche di Netezza possono essere sostituite dalle funzionalità di Azure Synapse.

Netezza implementa alcuni oggetti di database che non sono supportati direttamente in Azure Synapse, ma esistono metodi per ottenere la stessa funzionalità all'interno del nuovo ambiente:

  • Mappe di zona: in Netezza, le mappe di zona vengono create e mantenute automaticamente per alcuni tipi di colonna e vengono usate in fase di query per limitare la quantità di dati da analizzare. Le mappe di zona vengono create nei tipi di colonna seguenti:

    • INTEGER colonne di lunghezza pari o inferiore a 8 byte.
    • Colonne temporali. Ad esempio DATE, TIME e TIMESTAMP.
    • Colonne CHAR, se fanno parte di una vista materializzata e sono incluse nella clausola ORDER BY.

    È possibile individuare le colonne con mappe di zona usando l'utilità nz_zonemap, inclusa nel toolkit NZ. Azure Synapse non include mappe di zona, ma è possibile ottenere risultati analoghi usando altri tipi di indice definiti dall'utente e/o di partizionamento.

  • Tabelle cluster di base: in Netezza, le tabelle cluster di base vengono comunemente usate per le tabelle dei fatti, che possono avere miliardi di record. L'analisi di una tabella di grandi dimensioni richiede molto tempo di elaborazione perché per ottenere i record pertinenti può essere necessaria una scansione di tabella completa. Organizzando i record in tabelle cluster di base restrittive, Netezza può raggruppare i record in extent simili o identici. Il processo crea anche mappe di zona che migliorano le prestazioni riducendo la quantità di dati da analizzare.

    In Azure Synapse è possibile ottenere un effetto simile usando il partizionamento e/o altri indici.

  • Viste materializzate: Netezza supporta le viste materializzate e consiglia di crearne una o più su tabelle di grandi dimensioni con molte colonne in cui solo alcune di queste colonne vengono usate regolarmente nelle query. Il sistema gestisce automaticamente le viste materializzate quando i dati nella tabella di base vengono aggiornati.

    Azure Synapse supporta le viste materializzate, con la stessa funzionalità di Netezza.

Mapping dei tipi di dati Netezza

Suggerimento

Valutare l'impatto dei tipi di dati non supportati come parte della fase di preparazione.

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.

Tipo di dati Netezza Tipo di dati di Azure Synapse
bigint bigint
BINARY VARYING(n) VARBINARY(n)
BOOLEAN BIT
BYTEINT TINYINT
CHARACTER VARYING(n) VARCHAR(n)
CHARACTER(n) CHAR(n)
DATE DATE(date)
DECIMAL(p,s) DECIMAL(p,s)
DOUBLE PRECISION FLOAT
FLOAT(n) FLOAT(n)
INTEGER INT
INTERVAL I tipi di dati INTERVAL non sono attualmente supportati direttamente in Azure Synapse, ma possono essere calcolati usando funzioni temporali come DATEDIFF.
MONEY MONEY
NATIONAL CHARACTER VARYING(n) NVARCHAR(n)
NATIONAL CHARACTER(n) NCHAR(n)
NUMERIC(p,s) NUMERIC(p,s)
REAL REAL
SMALLINT SMALLINT
ST_GEOMETRY(n) I tipi di dati spaziali, ad esempio ST_GEOMETRY, non sono attualmente supportati in Azure Synapse, ma i dati possono essere archiviati come VARCHAR o VARBINARY.
ORA ORA
TIME WITH TIME ZONE DATETIMEOFFSET
TIMESTAMP DATETIME

Generazione DDL (Data Definition Language)

Suggerimento

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

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

Tuttavia, tutte le informazioni che specificano le definizioni correnti di tabelle e viste all'interno dell'ambiente Netezza 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 usando utilità come nz_ddl_table e generare le istruzioni DDL CREATE TABLE. Modificare queste istruzioni per le tabelle equivalenti in Azure Synapse.

Suggerimento

Strumenti e servizi di terze parti possono automatizzare le attività di mapping dei dati.

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 come Informatica o Talend è già in uso nell'ambiente Netezza, tale strumento può implementare qualsiasi trasformazione dei dati necessaria.

Differenze di SQL DML tra Netezza e Azure Synapse

SQL Data Manipulation Language (DML)

Suggerimento

I comandi DML di SQL SELECT, INSERTe UPDATE hanno elementi di base standard, ma possono anche implementare diverse opzioni di sintassi.

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

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

Differenze di sintassi SQL DML

Tenere presenti queste differenze nella sintassi DML (SQL Data Manipulation Language) tra Netezza SQL e Azure Synapse durante la migrazione:

  • STRPOS: in Netezza la funzione STRPOS restituisce la posizione di una substring all'interno di una stringa. La funzione equivalente in Azure Synapse è CHARINDEX, con l'ordine degli argomenti invertito. Ad esempio, SELECT STRPOS('abcdef','def')... in Netezza è equivalente a SELECT CHARINDEX('def','abcdef')... in Azure Synapse.

  • AGE: Netezza supporta l'operatore AGE per assegnare l'intervallo tra due valori temporali, come timestamp o date. Ad esempio, SELECT AGE('23-03-1956','01-01-2019') FROM.... In Azure Synapse, DATEDIFF assegna l'intervallo. Ad esempio, SELECT DATEDIFF(day, '1956-03-26','2019-01-01') FROM.... Prendere nota della sequenza di rappresentazione della data.

  • NOW(): Netezza usa NOW() per rappresentare CURRENT_TIMESTAMP in Azure Synapse.

Funzioni, stored procedure e sequenze

Suggerimento

Come parte della fase di preparazione, valutare il numero e il tipo di oggetti non dati di cui eseguire la migrazione.

Quando si esegue la migrazione da un ambiente data warehouse legacy maturo, ad esempio Netezza, spesso sono presenti elementi diversi da tabelle e viste semplici di cui è necessario eseguire la migrazione al nuovo ambiente di destinazione. Ad esempio, funzioni, stored procedure 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 Netezza. In questo caso, è spesso più efficiente usare le strutture di Azure predefinite anziché ricodificare le funzioni di Netezza.

Suggerimento

I prodotti e i servizi di terze parti possono automatizzare la migrazione di elementi non dati.

I partner Microsoft offrono strumenti e servizi che possono automatizzare la migrazione, incluso il mapping dei tipi di dati. Inoltre, gli strumenti ETL di terze parti, ad esempio Informatica o Talend, già in uso nell'ambiente IBM Netezza possono implementare qualsiasi trasformazione dei dati necessaria.

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

Funzioni

Come per la maggior parte dei prodotti di database, Netezza 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. Le funzioni di Netezza definite dall'utente vengono codificate in linguaggio nzlua o C++.

Stored procedure

La maggior parte dei prodotti di database moderni consente di archiviare le procedure all'interno del database. Netezza fornisce il linguaggio NZPLSQL, basato su POSTGRES PL/pgSQL. Una stored procedure contiene in genere istruzioni SQL e una logica procedurale e può restituire dati o uno stato.

Azure Synapse Analytics supporta anche stored procedure con T-SQL, quindi se è necessario eseguire la migrazione delle stored procedure, ricodificarle di conseguenza.

Sequenze

In Netezza una sequenza è un oggetto di database denominato creato tramite CREATE SEQUENCE che può fornire il valore univoco tramite il metodo NEXT VALUE FOR. Usare questi valori per generare numeri univoci da usare come valori di chiave sostitutiva per i valori di chiave primaria.

In Azure Synapse non è presente alcun elemento CREATE SEQUENCE. Le sequenze vengono gestite usando IDENTITY per creare chiavi surrogate o identità gestite usando il codice SQL per creare il numero di sequenza successivo in una serie.

Usare EXPLAIN per convalidare SQL legacy

Suggerimento

Individuare potenziali problemi di migrazione usando query reali dai log delle query di sistema esistenti.

Acquisire alcune istruzioni SQL rappresentative dai log della cronologia delle query legacy per valutare Netezza SQL legacy per la compatibilità con Azure Synapse. Aggiungere quindi un prefisso a queste query con EXPLAIN e, presupponendo che un modello di dati "like-for-like" sia stato migrato in Azure Synapse con gli stessi nomi di tabella e colonna, eseguire tali istruzioni EXPLAIN in Azure Synapse. Qualsiasi SQL incompatibile restituirà un errore. Usare queste informazioni per determinare la scalabilità dell'attività di ricodifica. Questo approccio non richiede che i dati vengano caricati nell'ambiente Azure, ma solo che siano state create le tabelle e le viste pertinenti.

Mapping da IBM Netezza a T-SQL

Il mapping dei tipi di dati IBM Netezza a T-SQL conforme al mapping dei tipi di dati SQL di Azure Synapse è disponibile in questa tabella:

Tipo di dati IBM Netezza Tipo di dati Azure Synapse SQL v2
array Non supportato
bigint bigint
binary large object [(n[K|M|G])] nvarchar [(n|max)]
 blob [(n[K|M|G])] nvarchar [(n|max)]
 byte [(n)] binary [(n)]|varbinary(max)
 byteint SMALLINT
 char varying [(n)] varchar [(n|max)]
variante carattere [(n)] varchar [(n|max)]
 char [(n)] char [(n)]|varchar(max)
carattere [(n)] char [(n)]|varchar(max)
 character large object [(n[K|M|G])] varchar [(n|max)
 clob [(n[K|M|G])] varchar [(n|max)
 dataset Non supportato 
 Data Data
 dec [(p[,s])] decimal [(p[,s])]
 decimal [(p[,s])] decimal [(p[,s])]
 double precision float(53)
 float [(n)] float [(n)]
 graphic [(n)] nchar [(n)]| varchar(max)
 interval Non supportato 
 json [(n)] nvarchar [(n|max)]
 long varchar nvarchar(max)
 long vargraphic nvarchar(max)
 mbb Non supportato 
 mbr Non supportato 
 number [((p|*)[,s])] numeric [(p[,s])]
 numeric [(p [,s])]  numeric [(p[,s])]
 period Non supportato 
 real  real
 SMALLINT SMALLINT
 st_geometry(n) Non supportato 
 time time
 time with time zone datetimeoffset
  timestamp  datetime2
 timestamp with time zone datetimeoffset
 varbyte varbinary [(n|max)]
 varchar [(n)]  varchar [(n)]
 vargraphic [(n)] nvarchar [(n|max)]
 varray Non supportato 
 Xml Non supportato 
 xmltype Non supportato 

Riepilogo

Le tipiche installazioni legacy di Netezza 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 sono sotto forma 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 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.

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

  • Usare i metadati e i log di query dall'implementazione Netezza 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 Netezza ad Azure Synapse Analytics.