Minimera SQL-problem för Netezza-migreringar

Den här artikeln är del fem i en serie i sju delar som ger 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

År 2003 släppte Netezza sin datalagerlösning. Det minskade inträdeskostnaderna och förbättrade enkel användning av MPP-tekniker (massivt parallell bearbetning) för att möjliggöra databearbetning i stor skala mer effektivt än den befintliga stordatorn eller andra MPP-tekniker som var tillgängliga vid den tidpunkten. Sedan dess har produkten utvecklats och har många installationer bland stora finansinstitut, telekommunikationer och detaljhandelsföretag. Den ursprungliga implementeringen använde egen maskinvara, inklusive fältprogrammerbara gatematriser – 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 övergång till en modern molnmiljö.

Netezza-teknik används ofta för att implementera ett informationslager som stöder komplexa analysfrågor på stora datavolymer med SQL. Dimensionsdatamodeller – star- eller snowflake-scheman – är vanliga, liksom implementeringen av data marts 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 as-is 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öra en första as-is migrering och sedan göra ändringar i Azure-molnmiljön, utnyttja prestanda, elastisk skalbarhet och kostnadsfördelar där.

Sql-språket har standardiserats, men enskilda leverantörer har i vissa fall implementerat patentskyddade tillägg. Det här dokumentet belyser 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

Automatisera och samordna migreringsprocessen genom att använda funktionerna i Azure-miljön. Den här metoden minimerar också migreringens inverkan 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)

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

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 motsvarar alternativet TEMPORARY i Netezzas CREATE TABLE-syntax att lägga till ett "#" inför tabellnamnet 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 interna 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

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:

  • INTEGER kolumner med längd 8 byte eller mindre.
  • Temporala kolonner. Till exempel DATE, TIMEoch TIMESTAMP.
  • CHAR kolumner, om dessa ingår i en materialiserad vy och nämns i ORDER BY-satsen.

  Du kan ta reda på vilka kolumner som har zonkartor med hjälp nz_zonemap av verktyget, som är en del av NZ Toolkit. Azure Synapse inkluderar 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ådan enorm 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 segment. Den här processen skapar även 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 ett fåtal av dessa kolumner används regelbundet i frågor. Systemet underhåller automatiskt materialiserade vyer när data i bastabellen uppdateras.

  Azure Synapse stöder materialiserade vyer med samma funktioner som Netezza.

Netezza-datatypsmappning

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.

Generering av datadefinitionsspråk (DDL)

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, till exempel ORGANIZE ON.

All information som anger aktuella definitioner av tabeller och vyer i den befintliga Netezza-miljön underhålls 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.

Det finns Microsoft-partner som erbjuder verktyg och tjänster för att automatisera migrering, inklusive datatypsmappning. Om ett ETL-verktyg från tredje part, till exempel 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)

ANSI SQL-standarden definierar den grundläggande syntaxen för DML-kommandon som SELECT, INSERT, UPDATEoch DELETE. Både Netezza och Azure Synapse använder 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 Netezza STRPOS returnerar funktionen positionen för en delsträng i en sträng. Motsvarande funktion i Azure Synapse är CHARINDEX, med argumentens ordning omvänd. Till exempel SELECT STRPOS('abcdef','def')... i Netezza motsvarar SELECT CHARINDEX('def','abcdef')... i Azure Synapse.

• AGE: Netezza stöder operatorn AGE för att ge intervallet mellan två temporala värden, till exempel tidsstämplar eller datum. Till exempel SELECT AGE('23-03-1956','01-01-2019') FROM.... I Azure Synapse ger DATEDIFF intervallet. Till exempel SELECT DATEDIFF(day, '1956-03-26','2019-01-01') FROM.... Observera datumrepresentationssekvensen.

• NOW(): Netezza använder NOW() för att representera CURRENT_TIMESTAMP i Azure Synapse.

Funktioner, lagrade procedurer och sekvenser

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 anläggningar i Azure-miljön som ersätter de funktioner som implementeras som antingen funktioner eller lagrade procedurer i Netezza-miljön. I det här fallet är det ofta mer effektivt att använda de inbyggda Azure-funktionerna i stället för att omprogrammera Netezza-funktionerna.

Microsoft-partner erbjuda 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.

Funktionen

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 ändringar. Vissa systemfunktioner kan ha lite annorlunda 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 också 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 skapats via CREATE SEQUENCE som kan ge det unika värdet via metoden NEXT VALUE FOR. 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 inga CREATE SEQUENCE. Sekvenser hanteras med hjälp av IDENTITY för att skapa surrogatnycklar eller hanterad identitet med SQL-kod för att skapa nästa nummer i en sekvens.

Använd EXPLAIN- för att verifiera äldre SQL

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. Prefixa sedan 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 omfattningen av omkodningsuppgiften. 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

Tabellen visar hur IBM Netezza-datatypmappning till T-SQL är kompatibel med Azure Synapse SQL.

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.

Följ dessa rekommendationer för att minimera uppgiften att migrera den faktiska SQL-koden:

• Den inledande migreringen av informationslagret bör vara as-is för att minimera risker och tidsåtgång, även om den slutliga miljön innehåller 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: Tools for Netezza data warehouse migration to Azure Synapse Analytics.