Dette blogindlæg er forfattet af: Sahaj Saini, PM på Microsoft Analytics Platform System (APS)-teamet.

I dette blogindlæg giver vi en hurtig oversigt over Symmetric Multi-Processing (SMP) vs. Massively Parallel Processing (MPP) systemer, hvordan man identificerer triggere til at migrere fra SMP til MPP, vigtige overvejelser ved flytning til Microsoft Analytics Platform System (APS) og en diskussion om, hvordan man udnytter styrken i en MPP-løsning som APS.

Lad os begynde med et scenarie. Emma er databaseadministrator hos Adventure Works Cycles, en virksomhed, der fremstiller cykler. Hos Adventure Works bruger Emma og hendes team traditionel SQL Server SMP som deres data warehousing-løsning. Virksomheden er vokset hurtigt, og med den voksende konkurrence i cykelindustrien vil forretningsanalytikerne hos Adventure Works Cycles gerne have hurtigere indsigt i deres data. Emma står nu over for følgende udfordringer med SMP-implementeringen –

• Stor datamængde og datavækst: Med stigende salg og en voksende kundebase er datamængden vokset hurtigt til over 10 TB.
• Længere dataindlæsnings-/ETL-tider: Med behovet for at producere daglige rapporter til ledelsen finder Emma den nuværende ETL-hastighed utilstrækkelig til at modtage og behandle den stigende mængde data, der strømmer fra andre OLTP- og ikke-relationelle systemer.
• Langsom udførelse af forespørgsler: Det bliver stadig vanskeligere at generere indsigt til den daglige rapportering i tide.
• Lang Cube Processing Time: Med den nuværende Cube Processing Time er det vanskeligt at opfylde virksomhedens behov for rapportering i realtid.

For at overvinde disse udfordringer evaluerer Emma og hendes team købet af et større, dyrere og mere kraftfuldt sæt af server- og lagerhardware til deres datacenter. Denne fremgangsmåde ville løse deres problem, men kun på kort sigt, da datavæksten forventes at eksplodere i de næste 12 måneder. Med den datavækst, som Adventure Works forventer at se, vil selv de større og kraftigere SMP-løsninger meget hurtigt støde ind i en mur. Emma vil gerne have en løsning, der kan skaleres i takt med, at deres databehov vokser.

Hvor vi kaster os ud i løsningen af Emmas problemer, skal vi hurtigt definere, hvad SMP og MPP er. Symmetric Multi-Processing (SMP) er et tæt koblet multiprocessorsystem, hvor processorer deler ressourcer – enkelte instanser af operativsystemet (OS), hukommelse, I/O-enheder og er forbundet ved hjælp af en fælles bus. SMP er den primære parallelle arkitektur, der anvendes i servere, og er vist på følgende billede.

Massively Parallel Processing (MPP) er den koordinerede behandling af en enkelt opgave af flere processorer, hvor hver processor anvender sit eget operativsystem og sin egen hukommelse og kommunikerer med hinanden ved hjælp af en form for messaging-interface. MPP kan opstilles med en shared nothing- eller shared disk-arkitektur.

I en shared nothing-arkitektur er der ikke et enkelt stridspunkt på tværs af systemet, og noderne deler ikke hukommelse eller disklagring. Data er horisontalt partitioneret på tværs af knuder, således at hver knude har en delmængde af rækker fra hver tabel i databasen. Hver knude behandler derefter kun de rækker, der er på dens egne diske. Systemer, der er baseret på denne arkitektur, kan opnå massiv skala, da der ikke er nogen enkelt flaskehals, der kan bremse systemet. Det er det, Emma er på udkig efter.

MPP med shared-nothing-arkitektur er afbildet på følgende billede.

Microsoft Parallel Data Warehouse (PDW), der kører på en Microsoft Analytics Platform System-appliance, er implementeret som en MPP shared-nothing-arkitektur. Den består af en kontrolnode og lagringstilknyttede beregningsnoder, der er forbundet med hinanden via Ethernet og Infiniband. Kontrolknuden er vært for PDW-motoren – hjernen i MPP-systemet – som skaber parallelle forespørgselsplaner, koordinerer udførelsen af forespørgsler på beregningsnoderne og dataaggregation på tværs af hele apparatet. Alle noder, herunder kontrol- og beregningsnoder, er vært for en Data Movement Service (DMS) til overførsel af data mellem noder.

For at få flere oplysninger om PDW-arkitekturen kan du læse indlægget Architecture of the Microsoft Analytics Platform System.

Overgang til MPP

For at realisere den værdi, som MPP tilbyder, køber Emma og hendes team en Microsoft APS-appliance og begynder at overgå til MPP. Lad os se på, hvordan de tilpasser deres løsning for at drage fuld fordel af APS’ shared nothing MPP-arkitektur.

Tabeldesign

Som tidligere nævnt er APS baseret på en shared nothing MPP-arkitektur, hvilket betyder, at knudepunkterne er selvforsynende og ikke deler hukommelse eller diske. Arkitekturen kræver derfor, at du fordeler dine store tabeller på tværs af noder for at få fordelene ved den massivt parallelle behandling. APS gør det muligt at definere en tabel som enten distribueret eller replikeret. Beslutningen om at vælge det ene kontra det andet afhænger af datamængden og behovet for adgang til alle dataene på en enkelt knude.

Distribuerede tabeller

En distribueret tabel er en tabel, hvor række data i tabellen er distribueret på tværs af knuderne i apparatet for at give mulighed for massiv skalering. Hver række ender i én fordeling i én compute node, som det fremgår af billedet nedenfor.

For at udnytte den distribuerede karakter af APS ændrer Emma de store tabeller, typisk Fact- og store dimensionstabeller, til at blive distribueret i APS som følger:

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

Som du kan se, er dette en typisk DDL-anvisning til oprettelse af tabeller med en mindre tilføjelse for distribuerede tabeller. Tabellerne distribueres ved hjælp af en deterministisk hash-funktion, der anvendes på den distributionskolonne, der er valgt for den pågældende tabel. Emma vælger Product Key som distributionskolonne i tabellen FactInternetSales på grund af den høje kardinalitet og fraværet af skævhed, hvilket derfor fordeler tabellen jævnt på tværs af knuder.

Replicerede tabeller

Hvis alle tabeller blev distribueret, ville det imidlertid kræve en stor databevægelse mellem knuder, før der udføres join-operationer for alle operationer. Derfor giver det for mindre dimensionstabeller som f.eks. sprog, lande osv. mening at replikere hele tabellen på hver beregningsnode. Det vil sige, at fordelene ved at muliggøre lokale sammenføjningsoperationer med disse tabeller opvejer omkostningerne ved det ekstra forbrug af lagerplads. En replikeret tabel er en tabel, der replikeres på tværs af alle compute-noder som vist nedenfor.

Emma designer de små tabeller, typisk dimensionstabeller, til at blive replikeret på følgende måde:

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

Gennem at designe distribuerede og replikerede tabeller på passende vis tilpasser Emma sin løsning til almindelig bedste praksis for MPP-design og muliggør effektiv behandling af store datamængder. For eksempel ville en forespørgsel mod 100 milliarder rækker i et SQL Server SMP-miljø kræve behandling af alle dataene i et enkelt eksekveringsområde. Med MPP spredes arbejdet over mange knudepunkter for at opdele problemet i mere håndterbare og lettere måder at udføre opgaver på. I et apparat med fire knudepunkter (se billedet ovenfor) bliver hver knudepunkt kun bedt om at behandle ca. 25 milliarder rækker – en meget hurtigere opgave. Som følge heraf kan Emma konstatere betydelige forbedringer af forespørgselsudførelsestiden, og hendes virksomhed kan nu træffe bedre beslutninger hurtigere. Desuden kan Emma udvide datawarehouset til alt fra et par terabyte til over 6 petabyte data ved at tilføje “skaleringsenheder” til APS.

Dataindlæsning

Med SQL Server SMP brugte Emma og hendes team ETL-processer via et sæt SSIS-pakker til at indlæse data i datawarehouset – (1) Udtrække data fra OLTP og andre systemer; (2) Omdanne dataene til dimensionelt format; og (3) Indlæse dataene til mål-dimensions- eller faktabeller i datawarehouset. Med stigende datamængder bliver SSIS sever i midten en flaskehals, mens der udføres transformationer, hvilket resulterer i langsom indlæsning af data.

Med APS kan Emma og hendes team i stedet bruge ELT til at udtrække dataene fra OLTP- og andre systemer og indlæse dem til en staging location på APS. Derefter kan dataene transformeres til dimensionelt format, ikke med SSIS, men med APS-motoren, der udnytter apparatets distribuerede karakter og kraften i parallelbehandling. I et apparat med fire knudepunkter vil fire servere udføre transformationerne på delmængder af data i forhold til SSIS-serveren med en enkelt knudepunkt.

Denne parallelle behandling resulterer i et betydeligt løft i dataindlæsningspræstationen. Emma kan derefter bruge CTAS-anvisningen (Create Table As Select) til at oprette tabellen fra staging-tabellen som følger.

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

Gennem at skifte til en ELT-proces udnytter Emma den parallelle behandlingskraft i APS til at se ydelsesforbedringer ved indlæsning af data.

Sammenfattende har Emma og hendes team fundet svar på deres SMP-smerter med MPP. De kan nu føle sig trygge ved at håndtere datamængden og væksten hos Adventure Works med mulighed for at skalere datawarehouset efter behov. Med ELT og kraften i parallelbehandling i APS kan de indlæse data i APS hurtigere og inden for det forventede tidsvindue. Og ved at tilpasse sig APS’s MPP-design kan de opnå banebrydende forespørgselsydelse, hvilket giver mulighed for realtidsrapportering og indsigt i deres data.