Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo articolo fa parte di cinque di una serie in sette parti che fornisce indicazioni su come eseguire la migrazione da Netezza 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 Netezza
Suggerimento
Netezza ha introdotto il concetto di "appliance per data warehouse" all'inizio degli anni 2000.
Nel 2003, Netezza ha lanciato inizialmente il loro prodotto appliance di 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 matrici di gate programmabili sul campo, 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 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 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 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 Netezza e Azure Synapse
Linguaggio DDL (SQL Data Definition Language)
Suggerimento
I CREATE TABLE comandi DDL SQL 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, CREATE TABLE ad esempio 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 di 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 di CREATE TABLE 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 gli 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, come ad esempio la replica delle tabelle, potrebbero risultare più appropriate rispetto a una creazione diretta di indici.
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:
-
INTEGERcolonne di lunghezza pari o inferiore a 8 byte. - Colonne temporali. Ad esempio,
DATE,TIMEeTIMESTAMP. -
CHARcolonne, se fanno parte di una vista materializzata e vengono menzionate nellaORDER BYclausola.
È possibile scoprire quali colonne hanno mappe di zona usando l'utilità
nz_zonemap, che fa parte di NZ Toolkit. Azure Synapse non include mappe di zona, ma è possibile ottenere risultati simili usando altri tipi di indice definiti dall'utente e/o partizionamento.-
Tabelle base clusterizzate (CBT): in Netezza, i CBT vengono comunemente usati per le tabelle di fatti, che possono avere miliardi di record. L'analisi di una tabella così enorme richiede molto tempo di elaborazione, perché potrebbe essere necessaria un'analisi completa della tabella per ottenere record pertinenti. L'organizzazione dei record su CBT restrittivo consente a Netezza di raggruppare i record nelle stesse estensioni o nelle vicinanze. Questo 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 l'uso di altri indici.
Viste materializzate: Netezza supporta le viste materializzate e consiglia di creare una o più di queste tabelle 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.
Mappatura 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 |
| Massimo Variabile binario(n) | VARBINARY(n) |
| BOOLEAN | PEZZO |
| BYTEINT | TINYINT |
| CARATTERE VARIABILE(n) | VARCHAR(n) |
| CARATTERE(n) | CHAR(n) |
| DATTERO | DATE(date) |
| DECIMAL(p,s) | DECIMAL(p,s) |
| PRECISIONE DOPPIA | 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. |
| DENARO | DENARO |
| CARATTERE NAZIONALE VARIABILE(n) | NVARCHAR(n) |
| Carattere Nazionale(n) | NCHAR(n) |
| NUMERIC(p,s) | NUMERIC(p,s) |
| REALE | REALE |
| 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. |
| TEMPO | TEMPO |
| ORA CON FUSO ORARIO | DATETIMEOFFSET |
| TIMESTAMP | DATETIME |
Generazione DDL (Data Definition Language)
Suggerimento
Usare i metadati Netezza esistenti per automatizzare la generazione di CREATE TABLE e CREATE VIEW DDL per Azure Synapse.
Modificare gli script Netezza CREATE TABLE e CREATE VIEW esistenti per creare 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, ORGANIZE ONad esempio .
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. 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.
Accedi a queste informazioni usando utilità come nz_ddl_table e genera le CREATE TABLE istruzioni DDL. 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
Linguaggio di manipolazione dei dati SQL (DML)
Suggerimento
I SELECTcomandi DML di SQL , 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, come 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 presente queste differenze nella sintassi DML (Sql Data Manipulation Language) tra Netezza SQL e Azure Synapse durante la migrazione:
STRPOS: in Netezza, laSTRPOSfunzione restituisce la posizione di una sottostringa 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 aSELECT CHARINDEX('def','abcdef')...in Azure Synapse.AGE: Netezza supporta l'operatoreAGEper assegnare l'intervallo tra due valori temporali, ad esempio timestamp o date. Ad esempio:SELECT AGE('23-03-1956','01-01-2019') FROM.... In Azure Synapse assegnaDATEDIFFl'intervallo. Ad esempio:SELECT DATEDIFF(day, '1956-03-26','2019-01-01') FROM.... Prendere nota della sequenza di rappresentazione della data.NOW(): Netezza usaNOW()per rappresentareCURRENT_TIMESTAMPin 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, procedure memorizzate 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 le funzionalità implementate come funzioni o stored procedure nell'ambiente Netezza. In questo caso, è spesso più efficiente usare le strutture di Azure predefinite anziché ricreare 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 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. Le funzioni definite dall'utente netezza sono codificate in linguaggi nzlua o C++.
Procedure memorizzate
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 possono restituire dati o uno stato.
Azure Synapse Analytics supporta anche stored procedure che usano T-SQL, quindi se è necessario eseguire la migrazione delle stored procedure, ricodicerle di conseguenza.
Sequenze
In Netezza una sequenza è un oggetto di database denominato creato tramite CREATE SEQUENCE che può fornire il valore univoco tramite il NEXT VALUE FOR metodo . Usare questi valori per generare numeri univoci da usare come valori di chiave surrogata per i valori di chiave primaria.
In Azure Synapse non è presente alcun CREATE SEQUENCEelemento . 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 Legacy SQL
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 la compatibilità di SQL legacy Netezza 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 EXPLAIN istruzioni in Azure Synapse. Qualsiasi SQL incompatibile restituirà un errore. Usare queste informazioni per determinare la scalabilità 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.
Mapping da IBM Netezza a T-SQL
Il mapping dei tipi di dati IBM Netezza to 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 |
|---|---|
| Matrice | Non supportato |
| Bigint | bigint |
| oggetto binario di grandi dimensioni [(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)] |
| carattere variabile [(n)] | varchar [(n|max)] |
| char [(n)] | char [(n)]|varchar(max) |
| carattere [(n)] | char [(n)]|varchar(max) |
| oggetto grande di caratteri [(n[K|M|G])] | varchar [(n|max) |
| clob [(n[K|M|G])] | varchar [(n|max) |
| Insieme di dati | Non supportato |
| Data | Data |
| dec [(p[,s])] | decimal [(p[,s])] |
| decimale [(p[,s])] | decimal [(p[,s])] |
| precisione doppia | float(53) |
| float [(n)] | flottante [(n)] |
| grafico | nchar [(n)]| varchar(max) |
| Intervallo | 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])] |
| numerico [(p [,s])] | numeric [(p[,s])] |
| Periodo | Non supportato |
| Vero | Vero |
| Smallint | Smallint |
| st_geometry | Non supportato |
| Tempo | Tempo |
| data e ora con fuso orario | Datetimeoffset |
| Marca temporale | datetime2 |
| timestamp con fuso orario | Datetimeoffset |
| varbyte | varbinary [(n|max)] |
| varchar [(n)] | varchar [(n)] |
| vargraphic [(n)] | nvarchar [(n|max)] |
| varray | Non supportato |
| Xml | Non supportato |
| xmltype | Non supportato |
Sommario
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 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.
Comprendere le differenze tra l'implementazione di Netezza SQL e Azure Synapse.
Usare i metadati e i log di query dall'implementazione di Netezza 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 netezza ad Azure Synapse Analytics.