Tämän blogikirjoituksen on kirjoittanut: Sahaj Saini, PM Microsoft Analytics Platform System (APS) -tiimissä.

Tässä blogikirjoituksessa tarjoamme nopean yleiskatsauksen Symmetric Multi-Processing (SMP) vs. Massively Parallel Processing (MPP) -järjestelmistä, siitä, miten tunnistaa SMP:stä MPP:hen siirtymisen laukaisevat tekijät, tärkeimmistä näkökohdista siirryttäessä Microsoft Analytics Platform System (APS) -järjestelmään, ja keskustelemme siitä, miten hyödyntää APS:n kaltaisen MPP-ratkaisun tehoa.

Aloitetaan skenaariolla. Emma on Adventure Works Cyclesin, polkupyöriä valmistavan yrityksen, tietokannan ylläpitäjä. Adventure Worksissa Emma ja hänen tiiminsä käyttävät perinteistä SQL Server SMP:tä tietovarastoratkaisuna. Yritys on kasvanut nopeasti, ja koska kilpailu polkupyöräteollisuudessa lisääntyy, Adventure Works Cyclesin liiketoiminta-analyytikot haluaisivat saada nopeamman käsityksen tiedoistaan. Emmalla on nyt seuraavat haasteet SMP-käyttöönoton kanssa –

• Suuri tietomäärä ja tietojen kasvu: Myynnin ja kasvavan asiakaskunnan myötä tietomäärä on kasvanut nopeasti ja ylittänyt 10 TB:n rajan.
• Pitkät tietojen lataus-/ETL-ajat: Koska johdolle on tuotettava päivittäisiä raportteja, nykyinen ETL-nopeus on Emman mielestä riittämätön muista OLTP- ja ei-relationaalisista järjestelmistä tulevien kasvavien tietomäärien vastaanottoon ja käsittelyyn.
• Hidas kyselyjen suoritus:
• Pitkä kuution käsittelyaika: Nykyisellä kuution käsittelyajalla on vaikea vastata yrityksen reaaliaikaisiin raportointitarpeisiin.

Näiden haasteiden voittamiseksi Emma ja hänen tiiminsä arvioivat suuremman, kalliimman ja tehokkaamman palvelin- ja tallennuslaitteiston hankkimista datakeskukseensa. Tämä lähestymistapa ratkaisisi heidän ongelmansa, mutta vain lyhyellä aikavälillä, sillä datan kasvun odotetaan räjähtävän räjähdysmäisesti seuraavien 12 kuukauden aikana. Adventure Worksin odottamassa datan kasvussa jopa suuremmat ja tehokkaammat SMP-ratkaisut törmäisivät seinään hyvin nopeasti. Emma haluaisi ratkaisun, joka skaalautuu heidän tietotarpeidensa kasvaessa.

Ennen kuin siirrymme ratkaisemaan Emman ongelmia, määritellään nopeasti, mitä SMP ja MPP ovat. Symmetrinen moniprosessointi (Symmetric Multi-Processing, SMP) on tiukasti kytketty moniprosessorijärjestelmä, jossa prosessorit jakavat resursseja – käyttöjärjestelmän (OS) yksittäisiä instansseja, muistia, I/O-laitteita ja ovat yhteydessä toisiinsa yhteisen väylän avulla. SMP on ensisijainen palvelimissa käytetty rinnakkaisarkkitehtuuri, ja se on esitetty seuraavassa kuvassa.

Massiivisesti rinnakkainen prosessointi (MPP, Massively Parallel Processing) on yksittäisen tehtävän koordinoitua käsittelyä useilla prosessoreilla, joista kukin käyttää omaa käyttöjärjestelmäänsä ja muistiään ja jotka kommunikoivat toistensa kanssa jonkinlaista sanomanvälitysrajapintaa käyttäen. MPP voidaan toteuttaa jaetulla ei-mitään- tai jaetulla levyarkkitehtuurilla.

Joustavassa ei-mitään-arkkitehtuurissa ei ole yhtä ainoaa kiistakohtaa koko järjestelmässä, eivätkä solmut jaa muistia tai levytallennustilaa. Tiedot on jaettu solmujen kesken horisontaalisesti siten, että kullakin solmulla on osajoukko rivejä tietokannan kustakin taulusta. Kukin solmu käsittelee vain omilla levyillään olevia rivejä. Tähän arkkitehtuuriin perustuvissa järjestelmissä voidaan saavuttaa massiivinen mittakaava, koska järjestelmää ei hidasta mikään yksittäinen pullonkaula. Tätä Emma etsii.

MPP shared-nothing-arkkitehtuurilla on esitetty seuraavassa kuvassa.

Microsoft Parallel Data Warehouse (PDW), joka toimii Microsoft Analytics Platform System -laitteessa, on toteutettu MPP shared-nothing-arkkitehtuurilla. Se koostuu yhdestä ohjaussolmusta ja tallennukseen liitetyistä laskentasolmuista, jotka on yhdistetty toisiinsa Ethernetin ja Infinibandin avulla. Ohjaussolmussa sijaitsee PDW-moottori – MPP-järjestelmän aivot – joka luo rinnakkaiset kyselysuunnitelmat, koordinoi kyselyjen suorittamista laskentasolmuissa ja tietojen aggregointia koko laitteistossa. Kaikki solmut, myös ohjaus- ja laskentasolmut, isännöivät DMS-palvelua (Data Movement Service), jonka avulla tietoja siirretään solmujen välillä.

Lisätietoja PDW-arkkitehtuurista on Microsoft Analytics Platform System -järjestelmän arkkitehtuuri -postauksessa.

Transitio MPP:hen

Voidakseen realisoida MPP:n tarjoaman lisäarvon Emma ja hänen tiiminsä hankkivat Microsoftin APS-lisäyslaitteen ja aloittavat MPP:n käyttöön siirtymisen. Katsotaanpa, miten he muokkaavat ratkaisunsa niin, että he voivat hyödyntää täysin APS:n shared nothing MPP -arkkitehtuuria.

Taulukkosuunnittelu

Kuten aiemmin mainittiin, APS perustuu shared nothing MPP -arkkitehtuuriin, mikä tarkoittaa, että solmut ovat omavaraisia eivätkä jaa muistia tai levyjä. Arkkitehtuuri edellyttää siis suurten taulukoiden jakamista solmujen kesken, jotta massiivisen rinnakkaiskäsittelyn edut saadaan hyödynnettyä. APS mahdollistaa taulukon määrittelyn joko hajautetuksi tai replikoiduksi. Päätös valita jompikumpi vaihtoehto riippuu datan määrästä ja tarpeesta saada kaikki data käyttöönsä yhdestä solmusta.

Hajotetut taulukot

Hajotetulla taulukolla tarkoitetaan taulukkoa, jossa taulukon sisältämät rivitiedot on jaettu laitteen solmuihin massiivisen skaalautuvuuden mahdollistamiseksi. Jokainen rivi päätyy yhteen jakoon yhteen laskentasolmuun, kuten alla oleva kuva esittää.

Hyödyntääkseen APS:n hajautettua luonnetta Emma muokkaa suuret taulut, tyypillisesti Fact- ja suuret dimensiotaulukot, hajautetuksi APS:ssä seuraavasti:

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

Kuten huomaatte, tämä on tyypillinen taulujen luomista varten laadittu DDL-lauseke, jossa on pieni lisäys hajautetuille taulukoille. Taulukot jaetaan deterministisellä hash-funktiolla, jota sovelletaan kyseiselle taululle valittuun jakelusarakkeeseen. Emma valitsee FactInternetSales-taulukon jakelusarakkeeksi Product Key taulukon suuren kardinaalisuuden ja vinoutumattomuuden vuoksi, jolloin taulukko jakautuu tasaisesti solmujen kesken.

Replikoidut taulukot

Jos kaikki taulukot olisivat hajautettuja, se vaatisi kuitenkin paljon datan siirtelyä solmujen välillä, ennen kuin yhdistämisoperaatioita tehtäisiin kaikkien operaatioiden osalta. Siksi pienemmissä ulottuvuustaulukoissa, kuten kieli, maat jne. on järkevää replikoida koko taulukko jokaiseen laskentasolmuun. Toisin sanoen paikallisten liitosoperaatioiden mahdollistamisesta näille taulukoille saatava hyöty on suurempi kuin ylimääräisestä tallennustilasta aiheutuvat kustannukset. Monistettu taulukko on taulukko, joka on monistettu kaikkiin laskentasolmuihin alla olevan kuvan mukaisesti.

Emma suunnittelee pienet taulukot, tyypillisesti dimensiotaulukot, monistettaviksi seuraavasti:

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

Suunnittelemalla hajautetut ja monistetut taulukot tarkoituksenmukaisella tavalla Emma yhdenmukaistaa ratkaisunsa yleisten MPP-suunnittelun parhaiden käytänteiden mukaiseksi, ja se mahdollistaa suurten tietomäärien tehokkaan käsittelyn. Esimerkiksi SQL Serverin SMP-ympäristössä 100 miljardiin riviin kohdistuva kysely edellyttäisi kaikkien tietojen käsittelyä yhdessä suoritusavaruudessa. MPP:n avulla työ jaetaan useisiin solmuihin, jolloin ongelma voidaan jakaa helpommin hallittaviin ja helpommin suoritettaviin tehtäviin. Neljän solmun laitteessa (ks. kuva yllä) kutakin solmua pyydetään käsittelemään vain noin 25 miljardia riviä – paljon nopeampi tehtävä. Tämän seurauksena Emma havaitsee merkittävää parannusta kyselyjen suoritusaikaan, ja hänen yrityksensä voi nyt tehdä parempia päätöksiä nopeammin. Lisäksi Emma voi kasvattaa tietovarastoa muutamasta teratavusta yli 6 petatavuun lisäämällä APS:ään ”skaalausyksiköitä”.

Tietojen lataaminen

SQL Server SMP:n avulla Emma ja hänen tiiminsä käyttivät ETL-prosesseja SSIS-pakettien avulla tietojen lataamiseksi tietovarastoon: (1) tietojen poimiminen OLTP- ja muista järjestelmistä, (2) tietojen muuntaminen dimensiomuotoiseen muotoon ja (3) tietojen lataaminen tietovaraston dimensio- tai fakta-taulukoihin. Kun tietomäärät kasvavat, keskellä olevasta SSIS severistä tulee pullonkaula muunnoksia suoritettaessa, mikä johtaa tietojen hitaaseen lataamiseen.

APS:n avulla Emma ja hänen tiiminsä voivat sen sijaan käyttää ELT:tä tietojen poimimiseen OLTP:stä ja muista järjestelmistä ja niiden lataamiseen APS:ssä olevaan varastointipaikkaan. Sen jälkeen tiedot voidaan muuntaa ulottuvuusmuotoon ei SSIS:llä vaan APS-moottorilla, jossa hyödynnetään laitteen hajautettua luonnetta ja rinnakkaiskäsittelyn tehoa. Neljän solmun laitteessa neljä palvelinta tekee muunnokset tietojen osajoukoille verrattuna yhden solmun SSIS-palvelimeen.

Tämän rinnakkaiskäsittelyn ansiosta tietojen lataussuorituskyky paranee merkittävästi. Emma voi sitten käyttää Create Table As Select (CTAS) -lauseketta taulukon luomiseen staging-taulusta seuraavasti.

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

Vaihtaessaan ELT-prosessiin Emma hyödyntää APS:n rinnakkaiskäsittelytehoa ja havaitsee suorituskyvyn paranevan tietojen lataamisessa.

Johtopäätöksenä voidaan todeta, että Emma ja hänen tiiminsä ovat löytäneet vastauksen SMP-ongelmiinsa MPP:n avulla. He voivat nyt suhtautua luottavaisesti Adventure Worksin tietomäärään ja kasvuun ja pystyvät skaalaamaan tietovarastoa tarpeen mukaan. ELT:n ja APS:n rinnakkaiskäsittelyn avulla he voivat ladata tietoja APS:ään nopeammin ja odotetun aikaikkunan sisällä. Ja mukauttamalla APS:n MPP-suunnitteluun he voivat saavuttaa läpimurtokykyisen kyselysuorituskyvyn, mikä mahdollistaa reaaliaikaisen raportoinnin ja tietoihin perehtymisen.