Dit blogbericht is geschreven door: Sahaj Saini, PM in het Microsoft Analytics Platform System (APS) team.

In deze blogpost geven we een kort overzicht van Symmetric Multi-Processing (SMP) vs. Massively Parallel Processing (MPP)-systemen, hoe triggers voor de migratie van SMP naar MPP kunnen worden geïdentificeerd, de belangrijkste overwegingen bij de overstap naar Microsoft Analytics Platform System (APS), en een discussie over hoe u kunt profiteren van de kracht van een MPP-oplossing zoals APS.

Laten we beginnen met een scenario. Emma is de databasebeheerder bij Adventure Works Cycles, een bedrijf dat fietsen maakt. Bij Adventure Works gebruiken Emma en haar team de traditionele SQL Server SMP als hun data warehousing oplossing. Het bedrijf is snel gegroeid en met de groeiende concurrentie in de fietsindustrie willen de bedrijfsanalisten bij Adventure Works Cycles sneller inzicht in hun gegevens. Emma wordt nu geconfronteerd met de volgende uitdagingen met de SMP implementatie –

  • Hoge Data Volume en Data Groei: Met toenemende verkopen en een groeiend klantenbestand is het datavolume snel gegroeid tot meer dan 10 TB.
  • Langere Data Loading/ETL tijden: Met de noodzaak om dagelijkse rapporten aan het management te produceren, vindt Emma de huidige ETL snelheid onvoldoende om de toenemende hoeveelheid gegevens die uit andere OLTP en niet-relationele systemen stromen op te nemen en te verwerken.
  • Trage Query Uitvoering: Query uitvoeringstijden worden vertraagd als gevolg van de toename van gegevens en het wordt steeds moeilijker om inzichten te genereren voor de dagelijkse rapportage in een tijdige manier.
  • Lange Cube Processing Time: Met de huidige kubus verwerkingstijd, is het moeilijk om te voldoen aan de real-time rapportage behoeften van het bedrijf.

Om deze uitdagingen te overwinnen, Emma en haar team evalueren de aankoop van een grotere, duurdere en krachtigere set van server-en opslaghardware aan hun datacenter. Deze aanpak zou hun probleem oplossen, maar alleen voor de korte termijn, omdat de datagroei naar verwachting de komende 12 maanden zal exploderen. Met de datagroei die Adventure Works verwacht, zouden zelfs de grotere en krachtigere SMP-oplossingen heel snel tegen een muur aanlopen. Emma zou graag een oplossing zien die meeschaalt met de groei van hun gegevensbehoeften.

Voordat we ons gaan bezighouden met het oplossen van Emma’s problemen, laten we eerst even definiëren wat SMP en MPP zijn. Symmetric Multi-Processing (SMP) is een strak gekoppeld multiprocessorsysteem waarbij processoren middelen delen – afzonderlijke instanties van het besturingssysteem (OS), geheugen, I/O-apparaten en verbonden via een gemeenschappelijke bus. SMP is de primaire parallelle architectuur die wordt gebruikt in servers en wordt weergegeven in de volgende afbeelding.

Massively Parallel Processing (MPP) is de gecoördineerde verwerking van een enkele taak door meerdere processoren, waarbij elke processor zijn eigen besturingssysteem en geheugen gebruikt en met elkaar communiceert via een of andere vorm van berichteninterface. MPP kan worden opgezet met een gedeelde-niets- of gedeelde-schijfarchitectuur.

In een gedeelde-niets-architectuur is er geen enkel twistpunt in het systeem en delen de nodes geen geheugen of schijfopslag. De gegevens worden horizontaal verdeeld over de knooppunten, zodat elk knooppunt een subset van rijen van elke tabel in de database heeft. Elk knooppunt verwerkt dan alleen de rijen op zijn eigen schijven. Systemen op basis van deze architectuur kunnen een enorme schaal bereiken omdat er geen enkel knelpunt is dat het systeem kan vertragen. Dit is waar Emma naar op zoek is.

MPP met shared-nothing architectuur is afgebeeld in de volgende afbeelding.

Microsoft Parallel Data Warehouse (PDW) dat draait op een Microsoft Analytics Platform System appliance is geïmplementeerd als een MPP shared-nothing architectuur. Het bestaat uit een controleknooppunt en aan opslag gekoppelde computernodes die via Ethernet en Infiniband met elkaar zijn verbonden. Het besturingsknooppunt bevat de PDW-engine – het brein van het MPP-systeem – die parallelle queryplannen maakt, de uitvoering van query’s op compute knooppunten coördineert en gegevens aggregeert over het hele apparaat. Alle nodes, inclusief control en compute, hosten een Data Movement Service (DMS) om gegevens tussen nodes over te brengen.

Voor meer details over de PDW-architectuur kunt u de post Architecture of the Microsoft Analytics Platform System lezen.

Omzetting naar MPP

Om de waarde van MPP te realiseren, schaffen Emma en haar team een Microsoft APS-appliance aan en beginnen ze met de overgang naar MPP. Laten we eens kijken hoe ze hun oplossing aanpassen om ten volle te profiteren van APS’s gedeelde niets MPP architectuur.

Tafelontwerp

Zoals eerder vermeld, is APS gebaseerd op een gedeelde niets MPP architectuur, wat betekent dat nodes zelfvoorzienend zijn en geen geheugen of schijven delen. De architectuur vereist daarom dat u uw grote tabellen over nodes verdeelt om de voordelen van de massaal parallelle verwerking te benutten. APS maakt het mogelijk een tabel te definiëren als gedistribueerd of gerepliceerd. De keuze voor het een of het ander hangt af van het volume van de gegevens en de behoefte aan toegang tot alle gegevens op één knooppunt.

Gedistribueerde tabellen

Een gedistribueerde tabel is een tabel waarbij de rijgegevens in de tabel worden gedistribueerd over de knooppunten binnen het apparaat om massale schaal mogelijk te maken. Elke rij komt terecht in één distributie in één computerknooppunt, zoals de onderstaande afbeelding laat zien.

Om te profiteren van het gedistribueerde karakter van APS, past Emma de grote tabellen, meestal Fact en large dimension tabellen, als volgt aan om gedistribueerd te worden in APS:

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

Zoals u kunt zien, is dit een typisch DDL-statement voor het maken van tabellen met een kleine toevoeging voor gedistribueerde tabellen. Tabellen worden gedistribueerd door een deterministische hash-functie toegepast op de Distributiekolom die voor die tabel is gekozen. Emma kiest Product Key als distributiekolom in de FactInternetSales tabel vanwege de hoge cardinaliteit en afwezigheid van skew, waardoor de tabel gelijkmatig over de knooppunten wordt verdeeld.

Gedistribueerde tabellen

Als alle tabellen gedistribueerd zouden worden, zou het echter veel dataverplaatsing tussen knooppunten vergen voordat join operaties voor alle operaties worden uitgevoerd. Daarom is het voor kleinere dimensie-tabellen, zoals taal, landen enz. zinvol de volledige tabel op elk computerknooppunt te repliceren. Dat wil zeggen dat de voordelen van het mogelijk maken van lokale join operaties met deze tabellen opwegen tegen de kosten van de extra verbruikte opslag. Een gerepliceerde tabel is een tabel die op alle compute nodes wordt gerepliceerd, zoals hieronder is afgebeeld.

Emma ontwerpt de kleine tabellen, meestal dimensie-tabellen, als volgt om te worden gerepliceerd:

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

Door gedistribueerde en gerepliceerde tabellen op de juiste manier te ontwerpen, brengt Emma haar oplossing op één lijn met gangbare best practices voor MPP-ontwerp en maakt ze efficiënte verwerking van grote gegevensvolumes mogelijk. Bijvoorbeeld, een query tegen 100 miljard rijen in een SQL Server SMP omgeving zou de verwerking van alle gegevens in een enkele uitvoeringsruimte vereisen. Met MPP wordt het werk gespreid over vele nodes om het probleem op te splitsen in beter beheersbare en eenvoudiger uit te voeren taken. In een apparaat met vier knooppunten (zie de afbeelding hierboven), wordt elk knooppunt slechts gevraagd om ruwweg 25 miljard rijen te verwerken – een veel snellere taak. Als gevolg daarvan ziet Emma aanzienlijke verbeteringen in de uitvoeringstijd van query’s en kan haar bedrijf nu sneller betere beslissingen nemen. Bovendien kan Emma het datawarehouse uitbreiden van enkele terabytes tot meer dan 6 petabytes aan gegevens door “schaaleenheden” aan APS toe te voegen.

Gegevens laden

Met SQL Server SMP, gebruikten Emma en haar team ETL processen via een set van SSIS pakketten om gegevens in het data warehouse te laden – (1) Gegevens extraheren uit de OLTP en andere systemen; (2) De gegevens transformeren naar dimensioneel formaat; en (3) De gegevens laden naar doel dimensie of feit tabellen in het Data Warehouse. Met toenemende gegevensvolumes wordt de SSIS sever in het midden een knelpunt bij het uitvoeren van transformaties, wat resulteert in traag laden van gegevens.

Met APS kunnen Emma en haar team in plaats daarvan ELT gebruiken om de gegevens uit de OLTP en andere systemen te extraheren en deze naar een opslaglocatie op APS te laden. Dan kunnen de gegevens worden omgezet in dimensionaal formaat, niet met SSIS, maar met de APS Engine, gebruikmakend van de gedistribueerde aard van het apparaat en de kracht van parallelle verwerking. In een apparaat met 4 knooppunten zouden vier servers de transformaties uitvoeren op subsets van gegevens in tegenstelling tot de SSIS-server met één knooppunt.

Deze parallelle verwerking resulteert in een aanzienlijke verbetering van de gegevenslaadprestaties. Emma kan vervolgens het Create Table As Select (CTAS)-statement gebruiken om de tabel als volgt op te stellen vanuit de staging-tabel.

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

Door over te schakelen op een ELT-proces maakt Emma gebruik van de parallelle verwerkingskracht van APS om prestatieverbeteringen te zien bij het laden van gegevens.

Concluderend hebben Emma en haar team met MPP een oplossing gevonden voor hun SMP-ellende. Ze kunnen nu met een gerust hart omgaan met het datavolume en de groei bij Adventure Works, met de mogelijkheid om het datawarehouse naar behoefte te schalen. Met ELT en de kracht van parallelle verwerking in APS kunnen ze gegevens sneller en binnen de verwachte tijd in APS laden. En door af te stemmen op het MPP-ontwerp van APS kunnen ze baanbrekende queryprestaties bereiken, waardoor real-time rapportage en inzicht in hun gegevens mogelijk worden.

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.