Minimera SQL-problem för Netezza-migreringar
Den här artikeln är del fem i en serie i sju delar som innehåller vägledning om hur du migrerar från Netezza till Azure Synapse Analytics. Fokus i den här artikeln är metodtips för att minimera SQL-problem.
Översikt
Egenskaper för Netezza-miljöer
Tips
Netezza banade väg för konceptet "informationslagerinstallation" i början av 2000-talet.
2003 släppte Netezza sin produkt för informationslagerinstallationen. Det minskade inträdeskostnaderna och förbättrade enkel användning av MPP-tekniker (massively parallel processing) för att möjliggöra databehandling i stor skala effektivare än den befintliga stordator eller annan MPP-teknik som var tillgänglig vid den tidpunkten. Sedan dess har produkten utvecklats och har många installationer bland stora finansiella institutioner, telekommunikationer och detaljhandelsföretag. Den ursprungliga implementeringen använde egen maskinvara, inklusive fältprogrammabla grindmatriser – eller FPGA:er – och var tillgänglig via ODBC- eller JDBC-nätverksanslutning via TCP/IP.
De flesta befintliga Netezza-installationer är lokala, så många användare överväger att migrera vissa eller alla sina Netezza-data till Azure Synapse Analytics för att få fördelarna med en flytt till en modern molnmiljö.
Tips
Många befintliga Netezza-installationer är informationslager som använder en dimensionell datamodell.
Netezza-teknik används ofta för att implementera ett informationslager som stöder komplexa analysfrågor på stora datavolymer med hjälp av SQL. Dimensionsdatamodeller – star- eller snowflake-scheman – är vanliga, liksom implementeringen av dataförråd för enskilda avdelningar.
Den här kombinationen av SQL och dimensionsdatamodeller förenklar migreringen till Azure Synapse, eftersom de grundläggande begreppen och SQL-färdigheterna kan överföras. Den rekommenderade metoden är att migrera den befintliga datamodellen i befintligt läge för att minska risken och den tid det tar. Även om den slutliga avsikten är att göra ändringar i datamodellen (till exempel flytta till en datavalvsmodell) utför du en inledande migrering i befintligt läge och gör sedan ändringar i Azure-molnmiljön, med hjälp av prestanda, elastisk skalbarhet och kostnadsfördelar där.
Sql-språket har standardiserats, men enskilda leverantörer har i vissa fall implementerat egna tillägg. Det här dokumentet beskriver potentiella SQL-skillnader som du kan stöta på när du migrerar från en äldre Netezza-miljö och tillhandahåller lösningar.
Använda Azure Data Factory för att implementera en metadatadriven migrering
Tips
Automatisera migreringsprocessen med hjälp av Azure Data Factory funktioner.
Automatisera och samordna migreringsprocessen genom att använda funktionerna i Azure-miljön. Den här metoden minimerar också migreringens påverkan på den befintliga Netezza-miljön, som kanske redan körs nära full kapacitet.
Azure Data Factory är en molnbaserad dataintegreringstjänst som gör det möjligt att skapa datadrivna arbetsflöden i molnet för orkestrering och automatisering av dataflytt och datatransformering. Med Data Factory kan du skapa och schemalägga datadrivna arbetsflöden – så kallade pipelines – som kan mata in data från olika datalager. Den kan bearbeta och transformera data med hjälp av beräkningstjänster som Azure HDInsight Hadoop, Spark, Azure Data Lake Analytics och Azure Machine Learning.
Genom att skapa metadata för att lista de datatabeller som ska migreras och deras plats kan du använda Data Factory-anläggningarna för att hantera och automatisera delar av migreringsprocessen. Du kan också använda Azure Synapse Pipelines.
SQL DDL-skillnader mellan Netezza och Azure Synapse
SQL Data Definition Language (DDL)
Tips
SQL DDL-kommandon CREATE TABLE och CREATE VIEW har standardelement men används också för att definiera implementeringsspecifika alternativ.
ANSI SQL-standarden definierar den grundläggande syntaxen för DDL-kommandon som CREATE TABLE och CREATE VIEW. Dessa kommandon används i både Netezza och Azure Synapse, men de har också utökats för att tillåta definition av implementeringsspecifika funktioner som indexering, tabelldistribution och partitioneringsalternativ.
I följande avsnitt beskrivs Netezza-specifika alternativ att överväga under en migrering till Azure Synapse.
Tabellöverväganden
Tips
Använd befintliga index för att ge en indikation på kandidater för indexering i det migrerade lagret.
När du migrerar tabeller mellan olika tekniker flyttas endast rådata och dess beskrivande metadata fysiskt mellan de två miljöerna. Andra databaselement från källsystemet, till exempel index och loggfiler, migreras inte direkt eftersom dessa kanske inte behövs eller kan implementeras på olika sätt i den nya målmiljön. Till exempel TEMPORARY motsvarar alternativet i Netezzas CREATE TABLE syntax prefixet tabellnamnet med tecknet "#" i Azure Synapse.
Det är viktigt att förstå var prestandaoptimeringar, till exempel index, användes i källmiljön. Detta anger var prestandaoptimering kan läggas till i den nya målmiljön. Om zonkartor till exempel har skapats i Netezza-källmiljön kan detta tyda på att ett icke-grupperat index ska skapas i den migrerade Azure Synapse databasen. Andra inbyggda tekniker för prestandaoptimering, till exempel tabellreplikering, kan vara mer tillämpliga än att skapa ett rakt "like-for-like"-index.
Netezza-databasobjekttyper som inte stöds
Tips
Netezza-specifika funktioner kan ersättas av Azure Synapse funktioner.
Netezza implementerar vissa databasobjekt som inte stöds direkt i Azure Synapse, men det finns metoder för att uppnå samma funktioner i den nya miljön:
Zonkartor: i Netezza skapas och underhålls zonkartor automatiskt för vissa kolumntyper och används vid frågetillfället för att begränsa mängden data som ska genomsökas. Zonkartor skapas på följande kolumntyper:
-
INTEGERkolumner med längd 8 byte eller mindre. - Temporala kolumner. Till exempel
DATE,TIME, ochTIMESTAMP. -
CHARkolumner, om dessa är en del av en materialiserad vy och nämns i -ORDER BYsatsen.
Du kan ta reda på vilka kolumner som har zonkartor med hjälp
nz_zonemapav verktyget, som är en del av NZ Toolkit. Azure Synapse innehåller inte zonkartor, men du kan uppnå liknande resultat med hjälp av andra användardefinierade indextyper och/eller partitionering.-
Klustrade bastabeller (CBT): I Netezza används KBT ofta för faktatabeller, som kan ha miljarder poster. Genomsökning av en så stor tabell kräver mycket bearbetningstid, eftersom en fullständig tabellgenomsökning kan behövas för att hämta relevanta poster. Genom att organisera poster på restriktiv CBT kan Netezza gruppera poster i samma eller närliggande utrymmen. Den här processen skapar också zonkartor som förbättrar prestandan genom att minska mängden data som ska genomsökas.
I Azure Synapse kan du uppnå en liknande effekt genom att använda partitionering och/eller användning av andra index.
Materialiserade vyer: Netezza stöder materialiserade vyer och rekommenderar att du skapar en eller flera av dessa över stora tabeller med många kolumner där endast några av dessa kolumner används regelbundet i frågor. Systemet underhåller automatiskt materialiserade vyer när data i bastabellen uppdateras.
Azure Synapse har stöd för materialiserade vyer med samma funktioner som Netezza.
Netezza-datatypsmappning
Tips
Utvärdera effekten av datatyper som inte stöds som en del av förberedelsefasen.
De flesta Netezza-datatyper har en direkt motsvarighet i Azure Synapse. I följande tabell visas dessa datatyper tillsammans med den rekommenderade metoden för att mappa dem.
| Netezza-datatyp | Azure Synapse datatyp |
|---|---|
| BIGINT | BIGINT |
| BINÄR VARIERANDE(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) |
| DUBBEL PRECISION | FLYTA |
| FLOAT(n) | FLOAT(n) |
| INTEGER | INT |
| INTERVALL | INTERVAL-datatyper stöds för närvarande inte direkt i Azure Synapse men kan beräknas med hjälp av temporala funktioner som DATEDIFF. |
| PENGAR | PENGAR |
| NATIONELLT TECKEN VARIERANDE(n) | NVARCHAR(n) |
| NATIONAL CHARACTER(n) | NCHAR(n) |
| NUMERIC(p,s) | NUMERIC(p,s) |
| REAL | REAL |
| SMALLINT | SMALLINT |
| ST_GEOMETRY(n) | Rumsliga datatyper som ST_GEOMETRY stöds för närvarande inte i Azure Synapse, men data kan lagras som VARCHAR eller VARBINARY. |
| TIME | TIME |
| TID MED TIDSZON | DATETIMEOFFSET |
| TIMESTAMP | DATETIME |
Generering av datadefinitionsspråk (DDL)
Tips
Använd befintliga Netezza-metadata för att automatisera genereringen av CREATE TABLE och CREATE VIEW DDL för Azure Synapse.
Redigera befintliga Netezza CREATE TABLE - och CREATE VIEW skript för att skapa motsvarande definitioner med ändrade datatyper enligt beskrivningen tidigare om det behövs. Detta innebär vanligtvis att ta bort eller ändra eventuella extra Netezza-specifika satser, ORGANIZE ONtill exempel .
All information som anger de aktuella definitionerna av tabeller och vyer i den befintliga Netezza-miljön bevaras dock i systemkatalogtabeller. Det här är den bästa källan till den här informationen eftersom den garanterat är uppdaterad och fullständig. Tänk på att användarunderhållen dokumentation kanske inte är synkroniserad med de aktuella tabelldefinitionerna.
Få åtkomst till den här informationen med hjälp av verktyg som nz_ddl_table och generera CREATE TABLE DDL-instruktioner. Redigera dessa instruktioner för motsvarande tabeller i Azure Synapse.
Tips
Verktyg och tjänster från tredje part kan automatisera datamappningsuppgifter.
Det finns Microsoft-partner som erbjuder verktyg och tjänster för att automatisera migreringen, inklusive datatypsmappning. Om ett ETL-verktyg från tredje part som Informatica eller Talend redan används i Netezza-miljön kan verktyget implementera alla nödvändiga datatransformeringar.
SQL DML-skillnader mellan Netezza och Azure Synapse
SQL Data Manipulation Language (DML)
Tips
SQL DML-kommandon SELECT, INSERToch UPDATE har standardelement, men kan även implementera olika syntaxalternativ.
ANSI SQL-standarden definierar den grundläggande syntaxen för DML-kommandon som SELECT, INSERT, UPDATEoch DELETE. Både Netezza och Azure Synapse använda dessa kommandon, men i vissa fall finns det implementeringsskillnader.
I följande avsnitt beskrivs de Netezza-specifika DML-kommandon som du bör överväga under en migrering till Azure Synapse.
Skillnader i SQL DML-syntax
Tänk på dessa skillnader i DML-syntax (SQL Data Manipulation Language) mellan Netezza SQL och Azure Synapse vid migrering:
STRPOS: i NetezzaSTRPOSreturnerar funktionen positionen för en delsträng i en sträng. Motsvarande funktion i Azure Synapse ärCHARINDEX, med omvänd ordning för argumenten. I Netezza motsvarar tillSELECT CHARINDEX('def','abcdef')...exempelSELECT STRPOS('abcdef','def')...i Azure Synapse.AGE: Netezza stöder operatornAGEför att ge intervallet mellan två temporala värden, till exempel tidsstämplar eller datum. Till exempelSELECT AGE('23-03-1956','01-01-2019') FROM.... I Azure SynapseDATEDIFFger intervallet. Till exempelSELECT DATEDIFF(day, '1956-03-26','2019-01-01') FROM.... Observera datumrepresentationssekvensen.NOW(): Netezza använderNOW()för att representeraCURRENT_TIMESTAMPi Azure Synapse.
Funktioner, lagrade procedurer och sekvenser
Tips
Som en del av förberedelsefasen utvärderar du antalet och typen av icke-dataobjekt som migreras.
När du migrerar från en mogen äldre informationslagermiljö, till exempel Netezza, finns det ofta andra element än enkla tabeller och vyer som måste migreras till den nya målmiljön. Exempel på detta är funktioner, lagrade procedurer och sekvenser.
Som en del av förberedelsefasen skapar du en inventering av de objekt som behöver migreras och definierar metoderna för att hantera dem. Tilldela sedan en lämplig allokering av resurser i projektplanen.
Det kan finnas resurser i Azure-miljön som ersätter funktionerna som implementeras som funktioner eller lagrade procedurer i Netezza-miljön. I det här fallet är det ofta mer effektivt att använda de inbyggda Azure-anläggningarna i stället för att återskapa Netezza-funktionerna.
Tips
Produkter och tjänster från tredje part kan automatisera migreringen av icke-dataelement.
Microsoft-partner erbjuder verktyg och tjänster som kan automatisera migreringen, inklusive mappning av datatyper. Dessutom kan ETL-verktyg från tredje part, till exempel Informatica eller Talend, som redan används i IBM Netezza-miljön implementera alla nödvändiga datatransformeringar.
Mer information om vart och ett av dessa element finns i följande avsnitt.
Functions
Precis som med de flesta databasprodukter har Netezza stöd för systemfunktioner och användardefinierade funktioner i SQL-implementeringen. När du migrerar till en annan databasplattform, till exempel Azure Synapse, är vanliga systemfunktioner tillgängliga och kan migreras utan ändring. Vissa systemfunktioner kan ha lite olika syntax, men de nödvändiga ändringarna kan automatiseras. Systemfunktioner där det inte finns någon motsvarighet, till exempel godtyckliga användardefinierade funktioner, kan behöva kodas om med hjälp av de språk som är tillgängliga i målmiljön. Azure Synapse använder det populära Transact-SQL-språket för att implementera användardefinierade funktioner. Användardefinierade netezza-funktioner kodas på nzlua- eller C++-språk.
Lagrade procedurer
De flesta moderna databasprodukter tillåter att procedurer lagras i databasen. Netezza tillhandahåller NZPLSQL-språket, som baseras på Postgres PL/pgSQL. En lagrad procedur innehåller vanligtvis SQL-instruktioner och viss procedurlogik och kan returnera data eller status.
Azure Synapse Analytics har även stöd för lagrade procedurer med T-SQL, så om du måste migrera lagrade procedurer måste du koda om dem i enlighet med detta.
Sekvenser
I Netezza är en sekvens ett namngivet databasobjekt som skapas via CREATE SEQUENCE som kan ge det unika värdet via NEXT VALUE FOR metoden. Använd dessa för att generera unika tal för användning som surrogatnyckelvärden för primärnyckelvärden.
I Azure Synapse finns det ingen CREATE SEQUENCE. Sekvenser hanteras med hjälp av IDENTITY för att skapa surrogatnycklar eller hanterad identitet med hjälp av SQL-kod för att skapa nästa sekvensnummer i en serie.
Använda EXPLAIN för att verifiera äldre SQL
Tips
Hitta potentiella migreringsproblem med hjälp av verkliga frågor från de befintliga systemfrågeloggarna.
Samla in några representativa SQL-instruktioner från de äldre frågehistorikloggarna för att utvärdera äldre Netezza SQL för kompatibilitet med Azure Synapse. Prefixet för dessa frågor med EXPLAIN och – förutsatt att en "like-for-like"-migrerad datamodell i Azure Synapse med samma tabell- och kolumnnamn – kör dessa EXPLAIN instruktioner i Azure Synapse. Alla inkompatibla SQL returnerar ett fel. Använd den här informationen för att fastställa omoderingsaktivitetens skala. Den här metoden kräver inte att data läses in i Azure-miljön, bara att relevanta tabeller och vyer har skapats.
IBM Netezza till T-SQL-mappning
IBM Netezza till T-SQL-kompatibel med Azure Synapse SQL-datatypmappning finns i den här tabellen:
| IBM Netezza-datatyp | Azure Synapse SQL-datatyp |
|---|---|
| matris | Stöds ej |
| bigint | bigint |
| binärt stort objekt [(n[K| M|G])] | nvarchar [(n|max)] |
| blob [(n[K| M|G])] | nvarchar [(n|max)] |
| byte [(n)] | binary [(n)]|varbinary(max) |
| byteint | smallint |
| char varierande [(n)] | varchar [(n|max)] |
| tecken varierande [(n)] | varchar [(n|max)] |
| char [(n)] | char [(n)]|varchar(max) |
| tecken [(n)] | char [(n)]|varchar(max) |
| tecken stort objekt [(n[K| M|G])] | varchar [(n|max) |
| clob [(n[K| M|G])] | varchar [(n|max) |
| Datamängd | Stöds ej |
| datum | datum |
| dec [(p[,s])] | decimal [(p[,s])] |
| decimal [(p[,s])] | decimal [(p[,s])] |
| dubbel precision | float(53) |
| float [(n)] | float [(n)] |
| grafik [(n)] | nchar [(n)]| varchar(max) |
| interval | Stöds ej |
| json [(n)] | nvarchar [(n|max)] |
| långt varchar | nvarchar(max) |
| long vargraphic | nvarchar(max) |
| Mbb | Stöds ej |
| Mbr | Stöds ej |
| number [((p|*)[,s])] | numeriskt [(p[,s])] |
| numeriskt [(p [,s])] | numeriskt [(p[,s])] |
| period | Stöds ej |
| real | real |
| smallint | smallint |
| st_geometry | Stöds ej |
| time | time |
| tid med tidszon | datetimeoffset |
| timestamp | datetime2 |
| tidsstämpel med tidszon | datetimeoffset |
| varbyte | varbinär [(n|max)] |
| varchar [(n)] | varchar [(n)] |
| vargraphic [(n)] | nvarchar [(n|max)] |
| varray | Stöds ej |
| xml | Stöds ej |
| xmltype | Stöds ej |
Sammanfattning
Typiska befintliga äldre Netezza-installationer implementeras på ett sätt som gör migreringen till Azure Synapse enkel. De använder SQL för analysfrågor på stora datavolymer och är i någon form av dimensionsdatamodell. Dessa faktorer gör dem till bra kandidater för migrering till Azure Synapse.
Så här minimerar du uppgiften att migrera den faktiska SQL-koden:
Den inledande migreringen av informationslagret bör vara i sinom tid för att minimera risker och tidsåtgång, även om den slutliga miljön kommer att innehålla en annan datamodell, till exempel datavalv.
Förstå skillnaderna mellan Netezza SQL-implementering och Azure Synapse.
Använd metadata och frågeloggar från den befintliga Netezza-implementeringen för att utvärdera effekten av skillnaderna och planera en metod för att minimera.
Automatisera processen där det är möjligt för att minimera fel, risker och tid för migreringen.
Överväg att använda specialiserade Microsoft-partner och -tjänster för att effektivisera migreringen.
Nästa steg
Mer information om Microsoft- och tredjepartsverktyg finns i nästa artikel i den här serien: Verktyg för migrering av Netezza-informationslager till Azure Synapse Analytics.