Detta blogginlägg författades av: Sahaj Saini, PM on the Microsoft Analytics Platform System (APS) team.

I det här blogginlägget ger vi en snabb översikt över Symmetric Multi-Processing (SMP) vs. Massively Parallel Processing (MPP) system, hur man identifierar utlösande faktorer för att migrera från SMP till MPP, viktiga överväganden när man flyttar till Microsoft Analytics Platform System (APS) och en diskussion om hur man drar nytta av kraften i en MPP-lösning som APS.

Låt oss börja med ett scenario. Emma är databasadministratör på Adventure Works Cycles, ett cykeltillverkningsföretag. På Adventure Works använder Emma och hennes team traditionell SQL Server SMP som datalagringslösning. Företaget har vuxit snabbt och med ökande konkurrens inom cykelbranschen vill affärsanalytikerna på Adventure Works Cycles ha snabbare insikt i sina data. Emma står nu inför följande utmaningar med SMP-installationen –

• Hög datavolym och datatillväxt: Med ökande försäljning och en växande kundbas har datavolymen vuxit snabbt till över 10 TB.
• Längre datainläsning/ETL-tider: Med behovet av att producera dagliga rapporter till ledningen anser Emma att den nuvarande ETL-hastigheten är otillräcklig för att ta emot och bearbeta den ökande mängden data som flödar från andra OLTP-system och icke-relationella system.
• Långsam utförande av frågor: Det blir allt svårare att generera insikter för den dagliga rapporteringen i tid.
• Lång behandlingstid för kuben: Med den nuvarande behandlingstiden för kuben är det svårt att tillgodose företagets behov av rapportering i realtid.

För att övervinna dessa utmaningar utvärderar Emma och hennes team inköpet av en större, dyrare och kraftfullare uppsättning av server- och lagringshårdvara till deras datacenter. Detta tillvägagångssätt skulle lösa deras problem, men bara på kort sikt eftersom datatillväxten förväntas explodera under de kommande 12 månaderna. Med den datatillväxt som Adventure Works förväntar sig skulle till och med de större och kraftfullare SMP-lösningarna snabbt få problem. Emma skulle vilja se en lösning som skalar i takt med att deras databehov växer.

Innan vi börjar lösa Emmas problem ska vi snabbt definiera vad SMP och MPP är. Symmetric Multi-Processing (SMP) är ett tätt kopplat multiprocessorsystem där processorerna delar resurser – enskilda instanser av operativsystemet (OS), minne, I/O-enheter och är anslutna med hjälp av en gemensam buss. SMP är den primära parallella arkitekturen som används i servrar och visas i följande bild.

Massively Parallel Processing (MPP) är den samordnade bearbetningen av en enda uppgift av flera processorer, där varje processor använder sitt eget operativsystem och minne och kommunicerar med varandra med hjälp av någon form av meddelandegränssnitt. MPP kan ställas in med en arkitektur med delat ingenting eller delad disk.

I en arkitektur med delat ingenting finns det ingen enskild punkt för konkurrens i hela systemet och noderna delar inte minne eller disklagring. Data delas horisontellt mellan noderna, så att varje nod har en delmängd av rader från varje tabell i databasen. Varje nod behandlar sedan endast de rader som finns på dess egna diskar. System som bygger på den här arkitekturen kan uppnå storskalighet eftersom det inte finns någon enskild flaskhals som kan sakta ner systemet. Detta är vad Emma är ute efter.

MPP med shared-nothing-arkitektur visas i följande bild.

Microsoft Parallel Data Warehouse (PDW) som körs på en Microsoft Analytics Platform System-appliance implementeras som en MPP shared-nothing-arkitektur. Den består av en kontrollnod och lagringsanslutna beräkningsnoder som är sammankopplade via Ethernet och Infiniband. Kontrollnoden är värd för PDW-motorn – hjärnan i MPP-systemet – som skapar parallella frågeplaner, koordinerar utförandet av frågor på beräkningsnoderna och aggregerar data över hela apparaten. Alla noder, inklusive kontroll- och beräkningsnoder, är värdar för en Data Movement Service (DMS) för att överföra data mellan noderna.

För mer information om PDW-arkitekturen kan du läsa inlägget Arkitektur för Microsoft Analytics Platform System.

Övergången till MPP

För att realisera det värde som MPP erbjuder köper Emma och hennes team en Microsoft APS-apparatur och börjar övergå till MPP. Låt oss ta en titt på hur de anpassar sin lösning för att dra full nytta av APS:s shared nothing MPP-arkitektur.

Tabelldesign

Som tidigare nämnts bygger APS på en shared nothing MPP-arkitektur, vilket innebär att noderna är självförsörjande och inte delar minne eller diskar. Arkitekturen kräver därför att du distribuerar dina stora tabeller över noderna för att få fördelarna med den massivt parallella bearbetningen. APS gör det möjligt att definiera en tabell som antingen distribuerad eller replikerad. Beslutet att välja det ena mot det andra beror på datamängden och behovet av tillgång till alla data på en enda nod.

Distribuerade tabeller

En distribuerad tabell är en tabell där raddata i tabellen distribueras över noderna i apparaten för att möjliggöra massiv skalbarhet. Varje rad hamnar i en distribution i en beräkningsnod enligt bilden nedan.

För att dra nytta av den distribuerade karaktären hos APS ändrar Emma de stora tabellerna, vanligtvis Fact- och stora dimensionstabeller, så att de distribueras i APS på följande sätt:

CREATE TABLE .( NOT NULL, NOT NULL, . . NULL) WITH( DISTRIBUTION = HASH(ProductKey),CLUSTERED COLUMNSTORE INDEX);

Som du kan se är det här ett typiskt DDL-uttalande för skapande av tabeller med ett mindre tillägg för distribuerade tabeller. Tabellerna distribueras med hjälp av en deterministisk hashfunktion som tillämpas på den distributionskolumn som valts för den tabellen. Emma väljer Product Key som distributionskolumn i tabellen FactInternetSales på grund av den höga kardinaliteten och avsaknaden av skevhet, och distribuerar därför tabellen jämnt över noderna.

Replikerade tabeller

Om alla tabeller distribuerades skulle det dock krävas mycket dataförflyttning mellan noderna innan man utförde sammanfogningar för alla operationer. För tabeller med mindre dimensioner som språk, länder osv. är det därför vettigt att replikera hela tabellen på varje beräkningsnod. Det vill säga, fördelarna med att möjliggöra lokala sammanfogningsoperationer med dessa tabeller uppväger kostnaden för extra lagringsutrymme. En replikerad tabell är en tabell som replikeras över alla beräkningsnoder enligt bilden nedan.

Emma utformar de små tabellerna, vanligtvis dimensionstabeller, så att de ska replikeras på följande sätt:

 CREATE TABLE .( NOT NULL, . . (10) NOT NULL,)WITH(CLUSTERED COLUMNSTORE INDEX);

Genom att utforma distribuerade och replikerade tabeller på lämpligt sätt anpassar Emma sin lösning till gängse bästa praxis för MPP-utformning och möjliggör en effektiv bearbetning av stora datavolymer. Till exempel skulle en fråga mot 100 miljarder rader i en SQL Server SMP-miljö kräva behandling av alla data i ett enda exekveringsutrymme. Med MPP sprids arbetet över många noder för att dela upp problemet i mer hanterbara och enklare sätt att utföra uppgifter. I en apparat med fyra noder (se bilden ovan) behöver varje nod bara bearbeta ungefär 25 miljarder rader – en mycket snabbare uppgift. Som ett resultat av detta kan Emma konstatera betydande förbättringar i fråga om tid för att utföra frågor och hennes företag kan nu fatta bättre beslut snabbare. Dessutom kan Emma utöka datalagret till allt från några terabyte till över 6 petabyte data genom att lägga till ”skalenheter” till APS.

Datainsamling

Med SQL Server SMP använde Emma och hennes team ETL-processer via en uppsättning SSIS-paket för att ladda in data till datalagret – (1) Extrahera data från OLTP- och andra system, (2) omvandla data till dimensionellt format och (3) ladda in data till måldimensionella eller faktatabeller i datalagret. Med ökande datamängder blir SSIS-servicen i mitten en flaskhals när den utför omvandlingar, vilket resulterar i långsam dataladdning.

Med APS kan Emma och hennes team i stället använda ELT för att extrahera data från OLTP- och andra system och ladda in dem till en mellanlagringsplats på APS. Därefter kan data omvandlas till dimensionellt format, inte med SSIS utan med APS-motorn som utnyttjar apparatens distribuerade karaktär och kraften i parallellbearbetning. I en apparat med fyra noder skulle fyra servrar göra omvandlingarna på delmängder av data jämfört med SSIS-servern med en enda nod.

Denna parallella bearbetning resulterar i en avsevärd ökning av prestandan för dataladdning. Emma kan sedan använda CTAS-anvisningen (Create Table As Select) för att skapa tabellen från stagingtabellen enligt följande.

CREATE TABLE . WITH( CLUSTERED COLUMN INDEX, DISTRIBUTION = HASH (CustomerKey))ASSELECT * FROM .;

Då Emma byter till en ELT-process utnyttjar hon parallellbearbetningen i APS för att se prestandaförbättringar vid dataladdning.

Slutsatsen är att Emma och hennes team har funnit svar på sina SMP-problem med MPP. De kan nu känna sig trygga med att hantera datavolymen och tillväxten på Adventure Works med möjlighet att skala datalagret efter behov. Med ELT och kraften i den parallella bearbetningen i APS kan de ladda in data i APS snabbare och inom det förväntade tidsfönstret. Och genom att anpassa sig till APS:s MPP-design kan de uppnå banbrytande sökprestanda, vilket möjliggör rapportering i realtid och insikt i deras data.