Acest articol de blog a fost scris de: Sahaj Saini, PM în cadrul echipei Microsoft Analytics Platform System (APS).

În această postare pe blog, vom oferi o scurtă prezentare generală despre Symmetric Multi-Processing (SMP) vs. Symmetric Multi-Processing (MPP). Sistemele de procesare masivă paralelă (MPP), cum să identificăm factorii declanșatori pentru a migra de la SMP la MPP, considerații cheie atunci când se trece la Microsoft Analytics Platform System (APS) și o discuție despre cum să profităm de puterea unei soluții MPP, cum ar fi APS.

Lasă-ne să începem cu un scenariu. Emma este administratorul bazei de date la Adventure Works Cycles, o companie producătoare de biciclete. La Adventure Works, Emma și echipa ei folosesc SQL Server SMP tradițional ca soluție de stocare a datelor. Compania a înregistrat o creștere rapidă și, având în vedere concurența tot mai mare în industria bicicletelor, analiștii de afaceri de la Adventure Works Cycles ar dori să aibă o perspectivă mai rapidă asupra datelor lor. Emma se confruntă acum cu următoarele provocări legate de implementarea SMP –

• Volum mare de date și creștere a datelor: Odată cu creșterea vânzărilor și a bazei de clienți, volumul de date a crescut rapid și a depășit 10 TB.
• Timpuri mai lungi de încărcare a datelor/ETL: Având în vedere necesitatea de a produce rapoarte zilnice pentru conducere, Emma consideră că viteza actuală de ETL este inadecvată pentru a prelua și procesa cantitatea tot mai mare de date care circulă de la alte sisteme OLTP și non-relaționale.
• Execuție lentă a interogărilor: Timpii de execuție a interogărilor încetinesc din cauza creșterii cantității de date și devine din ce în ce mai dificil să se genereze informații pentru raportarea zilnică în timp util.
• Timp lung de procesare a cuburilor: Cu timpul actual de procesare a cuburilor, este dificil să se satisfacă nevoile de raportare în timp real ale companiei.

Pentru a depăși aceste provocări, Emma și echipa sa evaluează achiziționarea unui set mai mare, mai scump și mai puternic de servere și hardware de stocare pentru centrul lor de date. Această abordare le-ar rezolva problema, dar numai pe termen scurt, deoarece se așteaptă ca în următoarele 12 luni creșterea volumului de date să explodeze. Având în vedere creșterea de date la care se așteaptă Adventure Works, chiar și soluțiile SMP mai mari și mai puternice s-ar lovi de un zid foarte repede. Emma ar dori să vadă o soluție care să se adapteze pe măsură ce nevoile lor de date cresc.

Înainte de a trece la rezolvarea problemelor Emmei, să definim rapid ce sunt SMP și MPP. Symmetric Multi-Processing (SMP) este un sistem multiprocesor strâns cuplat în care procesoarele împart resurse – instanțe unice ale sistemului de operare (OS), memorie, dispozitive I/O și conectate folosind un bus comun. SMP este principala arhitectură paralelă utilizată în servere și este reprezentată în imaginea următoare.

Procesarea masiv paralelă (MPP) este procesarea coordonată a unei singure sarcini de către mai multe procesoare, fiecare procesor utilizând propriul sistem de operare și memorie și comunicând între ele folosind o anumită formă de interfață de mesagerie. MPP poate fi configurat cu o arhitectură de tip shared nothing sau shared disk.

Într-o arhitectură de tip shared nothing, nu există un singur punct de contenție în sistem, iar nodurile nu împart memoria sau stocarea pe disc. Datele sunt partiționate orizontal între noduri, astfel încât fiecare nod are un subset de rânduri din fiecare tabel din baza de date. Fiecare nod procesează apoi numai rândurile de pe propriile discuri. Sistemele bazate pe această arhitectură pot atinge o scară masivă, deoarece nu există un singur gât de gâtul de gâtul care să încetinească sistemul. Aceasta este ceea ce caută Emma.

Microsoft Parallel Data Warehouse (PDW) care rulează pe un dispozitiv Microsoft Analytics Platform System appliance este implementat ca o arhitectură MPP cu arhitectură de tip „shared-nothing” (fără partajare) este descrisă în imaginea următoare.

Microsoft Parallel Data Warehouse (PDW) care rulează pe un dispozitiv Microsoft Analytics Platform System este implementat ca o arhitectură MPP cu partajare. Aceasta constă dintr-un nod de control și noduri de calcul atașate la stocare, interconectate prin Ethernet și Infiniband. Nodul de control găzduiește motorul PDW – creierul sistemului MPP – care creează planuri de interogare paralele, coordonează executarea interogărilor pe nodurile de calcul și agregarea datelor pe întregul dispozitiv. Toate nodurile, inclusiv cele de control și de calcul, găzduiesc un Serviciu de Mișcare a Datelor (DMS) pentru a transfera datele între noduri.

Pentru mai multe detalii despre arhitectura PDW, puteți citi postarea Arhitectura sistemului Microsoft Analytics Platform.

Tranziția la MPP

Pentru a realiza valoarea oferită de MPP, Emma și echipa sa achiziționează un dispozitiv Microsoft APS și încep tranziția la MPP. Să aruncăm o privire asupra modului în care își adaptează soluția pentru a profita pe deplin de arhitectura MPP de tip „shared nothing” a APS.

Designul tabelelor

După cum am menționat anterior, APS se bazează pe o arhitectură MPP de tip „shared nothing”, ceea ce înseamnă că nodurile sunt autosuficiente și nu împart memoria sau discurile. Prin urmare, arhitectura vă cere să distribuiți tabelele dvs. mari între noduri pentru a beneficia de avantajele procesării masiv paralele. APS permite definirea unui tabel ca fiind fie distribuit, fie replicat. Decizia de a alege una față de cealaltă depinde de volumul de date și de necesitatea de a avea acces la toate datele pe un singur nod.

Tabele distribuite

Un tabel distribuit este unul în care datele rândurilor din tabel sunt distribuite între nodurile din cadrul dispozitivului pentru a permite extinderea masivă. Fiecare rând sfârșește într-o singură distribuție într-un singur nod de calcul, așa cum este ilustrat de imaginea de mai jos.

Pentru a profita de natura distribuită a APS, Emma modifică tabelele mari, de obicei tabelele Fact și tabelele cu dimensiuni mari, pentru a fi distribuite în APS după cum urmează:

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

După cum puteți vedea, aceasta este o instrucțiune DDL tipică pentru crearea de tabele, cu un adaos minor pentru tabelele distribuite. Tabelele sunt distribuite printr-o funcție hash deterministă aplicată la coloana de distribuție aleasă pentru tabelul respectiv. Emma alege Product Key ca și coloană de distribuție în tabelul FactInternetSales din cauza cardinalității ridicate și a absenței de înclinație, distribuind astfel tabelul în mod egal între noduri.

Tabelele replicate

Dacă toate tabelele ar fi distribuite, totuși, ar fi nevoie de o mare cantitate de deplasare a datelor între noduri înainte de a efectua operațiile de îmbinare pentru toate operațiile. Prin urmare, pentru tabelele de dimensiuni mai mici, cum ar fi limba, țările etc., este logic să se reproducă întregul tabel pe fiecare nod de calcul. Altfel spus, avantajele de a permite operațiuni de îmbinare locală cu aceste tabele depășesc costul de stocare suplimentară consumată. Un tabel replicat este un tabel care este replicat în toate nodurile de calcul, așa cum este descris mai jos.

Emma proiectează tabelele mici, de obicei tabele de dimensiuni, pentru a fi replicate după cum urmează:

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

Prin proiectarea adecvată a tabelelor distribuite și replicate, Emma își aliniază soluția la cele mai bune practici comune de proiectare MPP și permite procesarea eficientă a volumelor mari de date. De exemplu, o interogare asupra a 100 de miliarde de rânduri într-un mediu SQL Server SMP ar necesita procesarea tuturor datelor într-un singur spațiu de execuție. Cu MPP, activitatea este repartizată pe mai multe noduri pentru a împărți problema în moduri mai ușor de gestionat și mai ușor de executat sarcinile. Într-un dispozitiv cu patru noduri (a se vedea imaginea de mai sus), fiecărui nod i se cere să proceseze doar aproximativ 25 de miliarde de rânduri – o sarcină mult mai rapidă. Ca urmare, Emma observă îmbunătățiri semnificative în ceea ce privește timpul de execuție a interogărilor, iar afacerea ei poate lua acum decizii mai bune, mai rapid. În plus, Emma poate crește depozitul de date de la câțiva terabytes la peste 6 petabytes de date prin adăugarea de „unități de scalare” la APS.

Încărcarea datelor

Cu SQL Server SMP, Emma și echipa ei foloseau procese ETL prin intermediul unui set de pachete SSIS pentru a încărca datele în depozitul de date – (1) Extragerea datelor din OLTP și din alte sisteme; (2) Transformarea datelor în format dimensional; și (3) Încărcarea datelor în tabelele țintă de dimensiuni sau de fapte din depozitul de date. Odată cu creșterea volumelor de date, severul SSIS din mijloc devine un gât de gâtul gol în timpul efectuării transformărilor, ceea ce duce la o încărcare lentă a datelor.

Cu APS, Emma și echipa sa pot folosi în schimb ELT, pentru a Extrage datele din OLTP și din alte sisteme și a le Încărca într-o locație de staționare pe APS. Apoi, datele pot fi transformate în format dimensional nu cu SSIS, ci cu motorul APS, utilizând natura distribuită a dispozitivului și puterea de procesare paralelă. Într-un dispozitiv cu 4 noduri, patru servere vor efectua transformările pe subansamble de date față de serverul SSIS cu un singur nod.

Această procesare paralelă duce la o creștere semnificativă a performanțelor de încărcare a datelor. Emma poate folosi apoi instrucțiunea Create Table As Select (CTAS) pentru a crea tabelul din tabelul de staging, după cum urmează.

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

Prin trecerea la un proces ELT, Emma utilizează puterea de procesare paralelă a APS pentru a vedea creșteri de performanță în încărcarea datelor.

În concluzie, Emma și echipa sa au găsit răspunsuri la problemele lor SMP cu MPP. Ei se pot simți acum încrezători în gestionarea volumului de date și a creșterii la Adventure Works, cu capacitatea de a scala depozitul de date în funcție de necesități. Cu ELT și cu puterea de procesare paralelă din APS, pot încărca datele în APS mai repede și în intervalul de timp așteptat. Și, prin alinierea la designul MPP al APS, pot obține performanțe de interogare revoluționare, permițând raportarea în timp real și cunoașterea datelor lor.

.