Design och prestanda för Teradata-migreringar

Den här artikeln är en del av en serie i sju delar som ger vägledning om hur du migrerar från Teradata till Azure Synapse Analytics. Fokus i den här artikeln är metodtips för design och prestanda.

Översikt

Många befintliga användare av Teradatas informationslagersystem vill dra nytta av de innovationer som tillhandahålls av moderna molnmiljöer. Med molnmiljöerna Infrastruktur som en tjänst (IaaS) och PaaS (plattform som en tjänst) kan du delegera uppgifter som infrastrukturunderhåll och plattformsutveckling till molnleverantören.

Dricks

Mer än bara en databas – Azure-miljön innehåller en omfattande uppsättning funktioner och verktyg.

Även om Teradata och Azure Synapse Analytics båda är SQL-databaser som använder MPP-tekniker (massivt parallell bearbetning) för att uppnå höga frågeprestanda på exceptionellt stora datavolymer finns det några grundläggande skillnader i metoden:

• Äldre Teradata-system installeras ofta lokalt och använder egen maskinvara, medan Azure Synapse är molnbaserat och använder Azure Storage- och beräkningsresurser.

• Eftersom lagrings- och beräkningsresurser är separata i Azure-miljön och har elastisk skalningskapacitet kan dessa resurser skalas uppåt eller nedåt oberoende av varandra.

• Du kan pausa eller ändra storlek på Azure Synapse efter behov för att minska resursanvändningen och kostnaderna.

• Att uppgradera en Teradata-konfiguration är en viktig uppgift som omfattar extra fysisk maskinvara och potentiellt lång databasomkonfiguration eller omläsning.

Microsoft Azure är en globalt tillgänglig, mycket säker och skalbar molnmiljö som innehåller Azure Synapse och ett ekosystem med stödverktyg och funktioner. Nästa diagram sammanfattar Azure Synapse-ekosystemet.

Azure Synapse ger bästa möjliga relationsdatabasprestanda med hjälp av tekniker som MPP och flera nivåer av automatiserad cachelagring för data som används ofta. Du kan se resultatet av dessa tekniker i oberoende benchmarks, till exempel den som nyligen kördes av GigaOm, som jämför Azure Synapse med andra populära molndatalagererbjudanden. Kunder som migrerar till Azure Synapse-miljön ser många fördelar, bland annat:

• Förbättrad prestanda och pris/prestanda.

• Ökad flexibilitet och kortare tid till värde.

• Snabbare serverdistribution och programutveckling.

• Elastisk skalbarhet – betala endast för faktisk användning.

• Förbättrad säkerhet/efterlevnad.

• Minskade kostnader för lagring och haveriberedskap.

• Lägre total TCO, bättre kostnadskontroll och effektivare driftsutgifter (OPEX).

För att maximera dessa fördelar migrerar du nya eller befintliga data och program till Azure Synapse-plattformen. I många organisationer omfattar migrering att flytta ett befintligt informationslager från en äldre lokal plattform, till exempel Teradata, till Azure Synapse. På hög nivå omfattar migreringsprocessen följande steg:

    Förberedelse 🡆

• Definiera omfång – vad som ska migreras.

• Skapa en inventering av data och processer för migrering.

• Definiera ändringar i datamodellen (om det finns några).

• Definiera mekanismen för källdataextrakt.

• Identifiera lämpliga Verktyg och funktioner från Azure och tredje part som ska användas.

• Utbilda personalen tidigt på den nya plattformen.

• Konfigurera Azure-målplattformen.

    Migrering 🡆

• Börja litet och enkelt.

• Automatisera när det är möjligt.

• Använd inbyggda Azure-verktyg och funktioner för att minska migreringsarbetet.

• Migrera metadata för tabeller och vyer.

• Migrera historiska data som ska underhållas.

• Migrera eller omstrukturera lagrade procedurer och affärsprocesser.

• Migrera eller omstrukturera inkrementella inläsningsprocesser för ETL/ELT.

    Efter migreringen

• Övervaka och dokumentera alla faser i processen.

• Använd upplevelsen för att skapa en mall för framtida migreringar.

• Återskapa datamodellen om det behövs (med nya plattformsprestanda och skalbarhet).

• Testa program och frågeverktyg.

• Prestandatesta och optimera frågeprestanda.

Den här artikeln innehåller allmän information och riktlinjer för prestandaoptimering när du migrerar ett informationslager från en befintlig Netezza-miljö till Azure Synapse. Målet med prestandaoptimering är att uppnå samma eller bättre informationslagerprestanda i Azure Synapse efter schemamigrering.

Utformningsbeaktanden

Migreringsomfång

När du förbereder migreringen från en Teradata-miljö bör du överväga följande migreringsalternativ.

Välj arbetsbelastningen för den första migreringen

Vanligtvis har äldre Teradata-miljöer utvecklats över tid för att omfatta flera ämnesområden och blandade arbetsbelastningar. När du bestämmer var du ska börja med ett migreringsprojekt väljer du ett område där du kan:

• Bevisa hur bra det är att migrera till Azure Synapse genom att snabbt leverera fördelarna med den nya miljön.

• Låt din interna tekniska personal få relevant erfarenhet av de processer och verktyg som de kommer att använda när de migrerar andra områden.

• Skapa en mall för ytterligare migreringar som är specifika för Teradata-källmiljön och de aktuella verktygen och processerna som redan finns.

En bra kandidat för en inledande migrering från en Teradata-omgivningsstöd föregående objekt och:

• Implementerar en BI/Analytics-arbetsbelastning i stället för en arbetsbelastning för onlinetransaktionsbearbetning (OLTP).

• Har en datamodell, till exempel ett star- eller snowflake-schema, som kan migreras med minimal ändring.

Dricks

Skapa en inventering av objekt som behöver migreras och dokumentera migreringsprocessen.

Mängden migrerade data i en inledande migrering bör vara tillräckligt stor för att demonstrera funktionerna och fördelarna med Azure Synapse-miljön, men inte för stor för att snabbt kunna visa värde. En storlek på 1–10 terabyte är typisk.

För ditt första migreringsprojekt minimerar du risken, ansträngningen och migreringstiden så att du snabbt kan se fördelarna med Azure-molnmiljön, begränsa migreringens omfattning till bara data marts, till exempel OLAP DB-delen av ett Teradata-lager. Både lift-and-shift- och stegvisa migreringsmetoder begränsar omfattningen för den inledande migreringen till bara data marts och tar inte upp bredare migreringsaspekter, till exempel ETL-migrering och historisk datamigrering. Du kan dock hantera dessa aspekter i senare faser av projektet när det migrerade data mart-lagret fylls på med data och de nödvändiga byggprocesserna.

Lift and shift-migrering jämfört med stegvis metod

I allmänhet finns det två typer av migrering oavsett syftet med och omfattningen av den planerade migreringen: lift and shift as-is och en stegvis metod som innehåller ändringar.

Lift and Shift

Vid en lift and shift-migrering migreras en befintlig datamodell, till exempel ett star-schema, oförändrad till den nya Azure Synapse-plattformen. Den här metoden minimerar risken och migreringstiden genom att minska det arbete som krävs för att utnyttja fördelarna med att flytta till Azure-molnmiljön. Lift and Shift-migrering passar bra för följande scenarier:

• Du har en befintlig Teradata-miljö med en enda data mart att migrera, eller
• Du har en befintlig Teradata-miljö med data som redan finns i ett väldesignad star- eller snowflake-schema, eller
• Du är under tids- och kostnadsbelastning för att övergå till en modern molnmiljö.

Dricks

Lift and shift är en bra utgångspunkt, även om efterföljande faser implementerar ändringar i datamodellen.

Stegvis metod som innehåller ändringar

Om ett äldre informationslager har utvecklats under en lång tidsperiod kan du behöva återskapa det för att upprätthålla de prestandanivåer som krävs. Du kan också behöva omkonstruera för att stödja nya data som IoT-strömmar (Internet of Things). Som en del av ombyggnadsprocessen migrerar du till Azure Synapse för att få fördelarna med en skalbar molnmiljö. Migrering kan också innehålla en ändring i den underliggande datamodellen, till exempel en flytt från en Inmon-modell till ett datavalv.

Microsoft rekommenderar att du flyttar din befintliga datamodell som den är till Azure (om du vill använda en Teradata-instans för virtuella datorer i Azure) och använder prestanda och flexibilitet i Azure-miljön för att tillämpa de nya tekniska ändringarna. På så sätt kan du använda Azures funktioner för att göra ändringarna utan att påverka det befintliga källsystemet.

Använda en Teradata-instans för virtuell Azure-dator som en del av en migrering

När du migrerar från en lokal Teradata-miljö kan du använda molnlagring och elastisk skalbarhet i Azure för att skapa en Teradata-instans i en virtuell dator. Den här metoden samverkar Teradata-instansen med Azure Synapse-målmiljön. Du kan använda Teradata-standardverktyg, till exempel Teradata Parallel Data Transporter, för att effektivt flytta delmängden av Teradata-tabeller som migreras till den virtuella datorinstansen. Sedan kan alla ytterligare migreringsuppgifter utföras i Azure-miljön. Den här metoden har flera fördelar:

• Efter den inledande replikeringen av data påverkas inte källsystemet av migreringsuppgifterna.

• Välbekanta Teradata-gränssnitt, verktyg och verktyg är tillgängliga i Azure-miljön.

• Azure-miljön kringgår eventuella problem med tillgängligheten för nätverksbandbredd mellan det lokala källsystemet och molnmålsystemet.

• Verktyg som Azure Data Factory kan anropa verktyg som Teradata Parallel Transporter för att effektivt och snabbt migrera data.

• Du kan samordna och styra migreringsprocessen helt i Azure-miljön.

Dricks

Använd virtuella Azure-datorer för att skapa en tillfällig Teradata-instans för att påskynda migreringen och minimera påverkan på källsystemet.

Använda Azure Data Factory för att implementera en metadatadriven migrering

Du kan automatisera och samordna migreringsprocessen med hjälp av funktionerna i Azure-miljön. Den här metoden minimerar prestandan i den befintliga Netezza-miljön, som kanske redan körs nära kapaciteten.

Azure Data Factory är en molnbaserad dataintegreringstjänst som har stöd för att skapa datadrivna arbetsflöden i molnet som samordnar och automatiserar dataflytt och datatransformering. Du kan använda Data Factory för att skapa och schemalägga datadrivna arbetsflöden (pipelines) som matar in data från olika datalager. Data Factory 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.

När du planerar att använda Data Factory-anläggningar för att hantera migreringsprocessen skapar du metadata som visar alla datatabeller som ska migreras och deras plats.

Designskillnader mellan Teradata och Azure Synapse

Som tidigare nämnts finns det några grundläggande skillnader i metod mellan Teradata- och Azure Synapse Analytics-databaser och dessa skillnader diskuteras härnäst.

Flera databaser jämfört med en enskild databas och scheman

Teradata-miljön innehåller ofta flera separata databaser. Det kan till exempel finnas separata databaser för: datainmatning och mellanlagringstabeller, kärnlagertabeller och data marts (kallas ibland semantiska lager). ETL- eller ELT-pipelineprocesser kan implementera kopplingar mellan databaser och flytta data mellan de separata databaserna.

Azure Synapse-miljön innehåller däremot en enkel databas och använder scheman för att dela upp tabeller i logiskt separata grupper. Vi rekommenderar att du använder en serie scheman i Azure Synapse-måldatabasen för att efterlikna de separata databaser som migrerats från Teradata-miljön. Om Teradata-miljön redan använder scheman kan du behöva använda en ny namngivningskonvention när du flyttar de befintliga Teradata-tabellerna och vyerna till den nya miljön. Du kan till exempel sammanfoga det befintliga Teradata-schemat och tabellnamnen till det nya Azure Synapse-tabellnamnet och använda schemanamn i den nya miljön för att underhålla de ursprungliga separata databasnamnen. Om namngivning av schemakonsolidering har punkter kan Azure Synapse Spark ha problem. Även om du kan använda SQL-vyer ovanpå de underliggande tabellerna för att underhålla de logiska strukturerna finns det potentiella nackdelar med den metoden:

• Vyer i Azure Synapse är skrivskyddade, så alla uppdateringar av data måste ske i de underliggande bastabellerna.

• Det kan redan finnas ett eller flera skikt av vyer och att lägga till ett extra lager vyer kan påverka prestanda och support eftersom kapslade vyer är svåra att felsöka.

Dricks

Kombinera flera databaser till en enskild databas i Azure Synapse och använd schemanamn för att logiskt separera tabellerna.

Tabellöverväganden

När du migrerar tabeller mellan olika miljöer är det vanligtvis bara rådata och metadata som beskriver dem fysiskt migrera. Andra databaselement från källsystemet, till exempel index, migreras vanligtvis inte eftersom de kan vara onödiga eller implementerade på olika sätt i den nya miljön. Prestandaoptimeringar i källmiljön, till exempel index, anger var du kan lägga till prestandaoptimering i den nya miljön. Om en tabell i Teradata-källmiljön till exempel har ett icke-unikt sekundärt index (NUSI) föreslår det att ett icke-grupperat index ska skapas i Azure Synapse. Andra inbyggda tekniker för prestandaoptimering som tabelreplikering kan vara mer tillämpliga än att skapa ett direkt index som liknar varandra.

Dricks

Befintliga index anger kandidater för indexering i det migrerade lagret.

Hög tillgänglighet för databasen

Teradata stöder datareplikering mellan noder via FALLBACK alternativet, som replikerar tabellrader som finns fysiskt på en viss nod till en annan nod i systemet. Den här metoden garanterar att data inte går förlorade om det uppstår ett nodfel och utgör grunden för redundansscenarier.

Målet med arkitekturen för hög tillgänglighet i Azure Synapse Analytics är att garantera att databasen är igång 99,9 % av tiden, utan att behöva bekymra dig om effekten av underhållsåtgärder och avbrott. Mer information om serviceavtalet finns i SLA för Azure Synapse Analytics. Azure hanterar automatiskt kritiska serviceuppgifter som korrigeringar, säkerhetskopieringar och Windows- och SQL-uppgraderingar. Azure hanterar också automatiskt oplanerade händelser, till exempel fel i den underliggande maskinvaran, programvaran eller nätverket.

Datalagring i Azure Synapse säkerhetskopieras automatiskt med ögonblicksbilder. Dessa ögonblicksbilder är en inbyggd funktion i tjänsten som skapar återställningspunkter. Du behöver inte aktivera den här funktionen. Användare kan för närvarande inte ta bort automatiska återställningspunkter som tjänsten använder för att underhålla serviceavtal (SLA) för återställning.

Azure Synapse Dedicated SQL-pool tar ögonblicksbilder av informationslagret hela dagen för att skapa återställningspunkter som är tillgängliga i sju dagar. Det går inte att ändra kvarhållningsperioden. Azure Synapse stöder ett mål för åtta timmars återställningspunkt (RPO). Du kan återställa informationslagret i den primära regionen från någon av ögonblicksbilderna som tagits under de senaste sju dagarna. Om du behöver fler detaljerade säkerhetskopior kan du använda ett annat användardefinierat alternativ.

Teradata-tabelltyper som inte stöds

Teradata stöder särskilda tabelltyper för tidsserier och tidsdata. Syntaxen och några av funktionerna för dessa tabelltyper stöds inte direkt i Azure Synapse. Du kan dock migrera data till en standardtabell i Azure Synapse genom att mappa till lämpliga datatyper och indexera eller partitionera kolumnen date/time.

Dricks

Standardtabeller i Azure Synapse kan stödja migrerade Teradata-tidsserier och tidsdata.

Teradata implementerar temporal frågefunktioner med hjälp av frågeskrivning för att lägga till ytterligare filter i en temporal fråga för att begränsa det tillämpliga datumintervallet. Om du planerar att migrera den här funktionen från Teradata-källmiljön lägger du till ytterligare filtrering i relevanta temporala frågor.

Insikter om tidsserier i Azure omgivningsstöd för komplex analys av tidsseriedata i stor skala. Den här funktionen riktar sig till IoT-dataanalysprogram.

Skillnader i SQL DML-syntax

Syntaxskillnader i SQL Data Manipulation Language (DML) finns mellan Teradata SQL och Azure Synapse T-SQL:

• QUALIFY: Teradata stöder operatorn QUALIFY . Till exempel:

  SELECT col1
  FROM tab1
  WHERE col1='XYZ'
  QUALIFY ROW_NUMBER () OVER (PARTITION by
  col1 ORDER BY col1) = 1;
  

  Motsvarande Azure Synapse-syntax är:

  SELECT * FROM (
  SELECT col1, ROW_NUMBER () OVER (PARTITION by col1 ORDER BY col1) rn
  FROM tab1 WHERE col1='XYZ'
  ) WHERE rn = 1;
  

• Datumaritmetik: Azure Synapse har operatorer som DATEADD och DATEDIFF, som kan användas på DATE eller DATETIME fält. Teradata stöder direkt subtraktion på datum som t.ex. SELECT DATE1 - DATE2 FROM...

• GROUP BY: Ange uttryckligen GROUP BY ett T-SQL-kolumnnamn för ordningstalet.

• LIKE ANY: Teradata stöder LIKE ANY syntax som:

  SELECT * FROM CUSTOMER
  WHERE POSTCODE LIKE ANY
  ('CV1%', 'CV2%', 'CV3%');
  

  Motsvarigheten i Azure Synapse-syntaxen är:

  SELECT * FROM CUSTOMER
  WHERE
  (POSTCODE LIKE 'CV1%') OR (POSTCODE LIKE 'CV2%') OR (POSTCODE LIKE 'CV3%');
  

• Beroende på systeminställningar kan teckenjämförelser i Teradata vara skiftlägesokänsliga som standard. I Azure Synapse är teckenjämförelser alltid skiftlägeskänsliga.

Funktioner, lagrade procedurer, utlösare och sekvenser

När du migrerar ett informationslager från en mogen miljö som Teradata måste du förmodligen migrera andra element än enkla tabeller och vyer. Exempel är funktioner, lagrade procedurer, utlösare och sekvenser. Kontrollera om verktyg i Azure-miljön kan ersätta funktionerna i funktioner, lagrade procedurer och sekvenser eftersom det vanligtvis är mer effektivt att använda inbyggda Azure-verktyg än att koda om dessa element för Azure Synapse.

Som en del av förberedelsefasen skapar du en inventering av objekt som behöver migreras, definierar en metod för att hantera dem och allokerar lämpliga resurser i migreringsplanen.

Dataintegreringspartner erbjuder verktyg och tjänster som kan automatisera migreringen av funktioner, lagrade procedurer och sekvenser.

I följande avsnitt beskrivs vidare migrering av funktioner, lagrade procedurer och sekvenser.

Funktioner

Precis som med de flesta databasprodukter stöder Teradata system- och användardefinierade funktioner i en SQL-implementering. När du migrerar en äldre databasplattform till Azure Synapse kan vanliga systemfunktioner vanligtvis migreras utan ändringar. Vissa systemfunktioner kan ha en något annorlunda syntax, men alla nödvändiga ändringar kan automatiseras.

För Teradata-systemfunktioner eller godtyckliga användardefinierade funktioner som inte har någon motsvarighet i Azure Synapse ska du koda om dessa funktioner med hjälp av ett målmiljöspråk. Azure Synapse använder transact-SQL-språket för att implementera användardefinierade funktioner.

Lagrade procedurer

De flesta moderna databasprodukter stöder lagring av procedurer i databasen. Teradata tillhandahåller SPL-språket för detta ändamål. En lagrad procedur innehåller vanligtvis både SQL-instruktioner och procedurlogik och returnerar data eller status.

Azure Synapse stöder lagrade procedurer med T-SQL, så du måste koda om alla migrerade lagrade procedurer på det språket.

Utlösare

Azure Synapse stöder inte skapande av utlösare, men utlösarskapande kan implementeras med Hjälp av Azure Data Factory.

Sekvenser

Azure Synapse hanterar sekvenser på ett liknande sätt som Teradata, och du kan implementera sekvenser med hjälp av IDENTITY-kolumner eller SQL-kod som genererar nästa sekvensnummer i en serie. En sekvens innehåller unika numeriska värden som du kan använda som surrogatnyckelvärden för primära nycklar.

Extrahera metadata och data från en Teradata-miljö

Generering av datadefinitionsspråk (DDL)

ANSI SQL-standarden definierar den grundläggande syntaxen för DDL-kommandon (Data Definition Language). Vissa DDL-kommandon, till exempel CREATE TABLE och CREATE VIEW, är gemensamma för både Teradata och Azure Synapse men tillhandahåller även implementeringsspecifika funktioner som indexering, tabelldistribution och partitioneringsalternativ.

Du kan redigera befintliga Teradata CREATE TABLE och CREATE VIEW skript för att uppnå motsvarande definitioner i Azure Synapse. För att göra det kan du behöva använda ändrade datatyper och ta bort eller ändra Teradata-specifika satser som FALLBACK.

All information som anger de aktuella definitionerna av tabeller och vyer i den befintliga Teradata-miljön bevaras dock i systemkatalogtabeller. Dessa tabeller är den bästa källan till den här informationen, eftersom den garanterat är uppdaterad och fullständig. Användarunderhållen dokumentation kanske inte är synkroniserad med de aktuella tabelldefinitionerna.

I Teradata-miljön anger systemkatalogtabeller den aktuella tabellen och vydefinitionen. Till skillnad från användarunderhållen dokumentation är systemkataloginformationen alltid fullständig och synkroniserad med aktuella tabelldefinitioner. Genom att använda vyer i katalogen, till exempel DBC.ColumnsV, kan du komma åt systemkataloginformation för att generera CREATE TABLE DDL-instruktioner som skapar motsvarande tabeller i Azure Synapse.

Dricks

Använd befintliga Teradata-metadata för att automatisera genereringen av CREATE TABLE och CREATE VIEW DDL för Azure Synapse.

Du kan också använda migrering från tredje part och ETL-verktyg som bearbetar systemkataloginformation för att uppnå liknande resultat.

Dataextrahering från Teradata

Du kan extrahera rådata från Teradata-tabeller till platta avgränsade filer, till exempel CSV-filer, med hjälp av Teradata-standardverktyg som Basic Teradata Query (BTEQ), Teradata FastExport eller Teradata Parallel Transporter (TPT). Använd TPT för att extrahera tabelldata så effektivt som möjligt. TPT använder flera parallella FastExport-strömmar för att uppnå det högsta dataflödet.

Dricks

Använd Teradata Parallel Transporter för det mest effektiva dataextraktet.

Anropa TPT direkt från Azure Data Factory. Det här är den rekommenderade metoden för datamigrering av lokala Teradata-instanser och Teradata-instanser som körs i en virtuell dator i Azure-miljön.

Extraherade datafiler ska innehålla avgränsad text i CSV-, Optimerad radkolumn (ORC) eller Parquet-format.

Mer information om hur du migrerar data och ETL från en Teradata-miljö finns i Datamigrering, ETL och inläsning för Teradata-migreringar.

Prestandarekommendationer för Teradata-migreringar

Målet med prestandaoptimering är samma eller bättre prestanda för informationslagret efter migreringen till Azure Synapse.

Dricks

Prioritera kunskaper om justeringsalternativen i Azure Synapse i början av en migrering.

Skillnader i prestandajusteringsmetod

Det här avsnittet visar skillnader i implementering av prestandajustering på låg nivå mellan Teradata och Azure Synapse.

Alternativ för datadistribution

För prestanda har Azure Synapse utformats med arkitektur med flera noder och använder parallell bearbetning. Om du vill optimera enskilda tabellprestanda i Azure Synapse kan du definiera ett alternativ för datadistribution i CREATE TABLE instruktioner med hjälp av -instruktionen DISTRIBUTION . Du kan till exempel ange en hash-distribuerad tabell som distribuerar tabellrader mellan beräkningsnoder med hjälp av en deterministisk hash-funktion. Syftet är att minska mängden data som flyttas mellan bearbetningsnoder när en fråga körs.

För stora tabell-till-stora tabellkopplingar distribuerar hash en eller, helst, båda tabellerna på en av kopplingskolumnerna – som har ett brett utbud av värden för att säkerställa en jämn fördelning. Utför kopplingsbearbetning lokalt eftersom de datarader som ska kopplas samman är sorterade på samma bearbetningsnod.

Azure Synapse stöder även lokala kopplingar mellan en liten tabell och en stor tabell via liten tabellreplikering. Tänk dig till exempel en liten dimensionstabell och en stor faktatabell i en star-schemamodell. Azure Synapse kan replikera den mindre dimensionstabellen över alla noder för att säkerställa att värdet för en kopplingsnyckel för den stora tabellen har en matchande, lokalt tillgänglig dimensionsrad. Omkostnaderna för replikering av dimensionstabeller är relativt låga för en liten dimensionstabell. För stora dimensionstabeller är en hashdistributionsmetod mer lämplig. Mer information om alternativ för datadistribution finns i Designvägledning för att använda replikerade tabeller och vägledning för att utforma distribuerade tabeller.

Dataindexering

Azure Synapse stöder flera användardefinierbara indexeringsalternativ som skiljer sig från de indexeringsalternativ som implementeras i Teradata. Mer information om de olika indexeringsalternativen i Azure Synapse finns i Index för dedikerade SQL-pooltabeller.

Befintliga index i Teradata-källmiljön ger en användbar indikation på dataanvändning och kandidatkolumnerna för indexering i Azure Synapse-miljön.

Datapartitionering

I ett informationslager för företag kan faktatabeller innehålla miljarder rader. Partitionering optimerar underhåll och frågeprestanda för dessa tabeller genom att dela upp dem i separata delar för att minska mängden data som bearbetas. I Azure Synapse definierar -instruktionen CREATE TABLE partitioneringsspecifikationen för en tabell. Partitionering av mycket stora tabeller och se till att varje partition innehåller minst 60 miljoner rader.

Du kan bara använda ett fält per tabell för partitionering. Det fältet är ofta ett datumfält eftersom många frågor filtreras efter datum eller datumintervall. Det går att ändra partitioneringen av en tabell efter den första inläsningen med hjälp av CTAS-instruktionen CREATE TABLE AS för att återskapa tabellen med en ny distribution. En detaljerad beskrivning av partitionering i Azure Synapse finns i Partitionering av tabeller i en dedikerad SQL-pool.

Statistik för datatabeller

Du bör se till att statistiken för datatabeller är uppdaterad genom att skapa ett statistiksteg till ETL/ELT-jobb.

PolyBase eller COPY INTO för datainläsning

PolyBase stöder effektiv inläsning av stora mängder data till ett informationslager med hjälp av parallella inläsningsströmmar. Mer information finns i PolyBase-datainläsningsstrategi.

COPY INTO stöder också datainmatning med högt dataflöde och:

• Datahämtning från alla filer i en mapp och undermappar.

• Datahämtning från flera platser i samma lagringskonto. Du kan ange flera platser med hjälp av kommaavgränsade sökvägar.

• Azure Data Lake Storage (ADLS) och Azure Blob Storage.

• CSV-, PARQUET- och ORC-filformat.

Arbetsbelastningshantering

Att köra blandade arbetsbelastningar kan innebära resursutmaningar i upptagna system. Ett lyckat arbetsbelastningshanteringsschema hanterar effektivt resurser, säkerställer högeffektiv resursanvändning och maximerar avkastningen på investeringen (ROI). Arbetsbelastningsklassificering, arbetsbelastningsbetydelse och arbetsbelastningsisolering ger mer kontroll över hur arbetsbelastningen använder systemresurser.

Guiden för arbetsbelastningshantering beskriver de tekniker som används för att analysera arbetsbelastningen, hantera och övervaka arbetsbelastningens betydelse samt stegen för att konvertera en resursklass till en arbetsbelastningsgrupp. Använd Azure-portalen och T-SQL-frågor på DMV:er för att övervaka arbetsbelastningen för att säkerställa att tillämpliga resurser används effektivt.

Nästa steg

Mer information om ETL och inläsning för Teradata-migrering finns i nästa artikel i den här serien: Datamigrering, ETL och inläsning för Teradata-migreringar.