Questo post è stato scritto da: Sahaj Saini, PM del team Microsoft Analytics Platform System (APS).

In questo post del blog, forniremo una rapida panoramica del Symmetric Multi-Processing (SMP) vs. Massively Parallel Processing (MPP), come identificare i trigger per la migrazione da SMP a MPP, considerazioni chiave quando si passa a Microsoft Analytics Platform System (APS) e una discussione su come sfruttare la potenza di una soluzione MPP come APS.

Partiamo con uno scenario. Emma è l’amministratore del database di Adventure Works Cycles, un’azienda che produce biciclette. Ad Adventure Works, Emma e il suo team stanno usando il tradizionale SQL Server SMP come soluzione di data warehousing. L’azienda è cresciuta rapidamente e con la crescente concorrenza nel settore delle biciclette, gli analisti di business di Adventure Works Cycles vorrebbero avere una visione più rapida dei loro dati. Emma sta affrontando le seguenti sfide con l’implementazione di SMP –

• Alto volume di dati e crescita dei dati: Con l’aumento delle vendite e una base clienti in crescita, il volume di dati è cresciuto rapidamente fino a superare i 10 TB.
• Tempi di caricamento dati/ETL più lunghi: Con la necessità di produrre report giornalieri per il management, Emma trova l’attuale velocità di ETL inadeguata ad accogliere ed elaborare la crescente quantità di dati che fluiscono da altri sistemi OLTP e non relazionali.
• Esecuzione lenta delle query: I tempi di esecuzione delle query stanno rallentando a causa dell’aumento dei dati e sta diventando sempre più difficile generare insight per il reporting quotidiano in modo tempestivo.
• Tempo di elaborazione del cubo lungo: Con l’attuale tempo di elaborazione del cubo, è difficile soddisfare le esigenze di reporting in tempo reale dell’azienda.

Per superare queste sfide, Emma e il suo team valutano l’acquisto di un set più grande, costoso e potente di server e hardware di storage per il loro datacenter. Questo approccio risolverebbe il loro problema, ma solo per il breve termine, poiché si prevede che la crescita dei dati esploderà nei prossimi 12 mesi. Con la crescita dei dati che Adventure Works si aspetta di vedere, anche le soluzioni SMP più grandi e potenti si scontrerebbero con un muro molto rapidamente. Emma vorrebbe una soluzione che sia scalabile man mano che crescono le loro esigenze di dati.

Prima di passare alla soluzione dei problemi di Emma, definiamo rapidamente cosa sono SMP e MPP. Symmetric Multi-Processing (SMP) è un sistema multiprocessore strettamente accoppiato in cui i processori condividono risorse – singole istanze del sistema operativo (OS), memoria, dispositivi I/O e sono collegati tramite un bus comune. SMP è la principale architettura parallela impiegata nei server ed è rappresentata nell’immagine seguente.

Massively Parallel Processing (MPP) è l’elaborazione coordinata di un singolo compito da parte di più processori, ogni processore utilizza il proprio sistema operativo e la propria memoria e comunica tra loro utilizzando una qualche forma di interfaccia di messaggistica. MPP può essere configurato con un’architettura a disco condiviso o nulla.

In un’architettura nulla condivisa, non c’è un singolo punto di contesa in tutto il sistema e i nodi non condividono la memoria o lo stoccaggio su disco. I dati sono partizionati orizzontalmente tra i nodi, in modo che ogni nodo abbia un sottoinsieme di righe di ogni tabella del database. Ogni nodo quindi elabora solo le righe sui propri dischi. I sistemi basati su questa architettura possono raggiungere una scala massiccia poiché non c’è un singolo collo di bottiglia che rallenti il sistema. Questo è ciò che Emma sta cercando.

MPP con architettura shared-nothing è rappresentato nell’immagine seguente.

Microsoft Parallel Data Warehouse (PDW) in esecuzione su un’appliance Microsoft Analytics Platform System è implementato come architettura MPP shared-nothing. Consiste di un nodo di controllo e di nodi di calcolo collegati allo storage interconnessi da Ethernet e Infiniband. Il nodo di controllo ospita il motore PDW – il cervello del sistema MPP – che crea piani di query paralleli, coordina l’esecuzione delle query sui nodi di calcolo e l’aggregazione dei dati nell’intero dispositivo. Tutti i nodi, compresi quelli di controllo e di calcolo, ospitano un Data Movement Service (DMS) per trasferire i dati tra i nodi.

Per maggiori dettagli sull’architettura PDW, puoi leggere il post Architettura del sistema Microsoft Analytics Platform.

Transizione a MPP

Per realizzare il valore offerto da MPP, Emma e il suo team acquistano un apparecchio Microsoft APS e iniziano la transizione a MPP. Diamo un’occhiata a come adattano la loro soluzione per trarre pieno vantaggio dall’architettura MPP di APS.

Table Design

Come menzionato in precedenza, APS è basato su un’architettura MPP shared nothing, il che significa che i nodi sono autosufficienti e non condividono memoria o dischi. L’architettura, quindi, richiede di distribuire le grandi tabelle sui nodi per ottenere i benefici dell’elaborazione massicciamente parallela. APS permette di definire una tabella come distribuita o replicata. La decisione di scegliere l’una o l’altra dipende dal volume dei dati e dalla necessità di accedere a tutti i dati su un singolo nodo.

Tabelle distribuite

Una tabella distribuita è quella in cui i dati delle righe all’interno della tabella sono distribuiti tra i nodi all’interno dell’appliance per consentire una scala massiccia. Ogni riga finisce in una distribuzione in un nodo di calcolo, come illustrato dall’immagine sottostante.

Per sfruttare la natura distribuita dell’APS, Emma modifica le grandi tabelle, tipicamente le tabelle Fact e di grandi dimensioni, per essere distribuite nell’APS come segue:

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

Come potete vedere, questa è una tipica dichiarazione DDL per la creazione di tabelle con una piccola aggiunta per le tabelle distribuite. Le tabelle sono distribuite da una funzione hash deterministica applicata alla colonna di distribuzione scelta per quella tabella. Emma sceglie Product Key come colonna di distribuzione nella tabella FactInternetSales a causa dell’alta cardinalità e dell’assenza di skew, distribuendo quindi la tabella uniformemente tra i nodi.

Tabelle replicate

Se tutte le tabelle fossero distribuite, tuttavia, sarebbe necessario un grande movimento di dati tra i nodi prima di eseguire operazioni di join per tutte le operazioni. Pertanto, per le tabelle di dimensioni più piccole come la lingua, i paesi ecc. ha senso replicare l’intera tabella su ogni nodo di calcolo. Vale a dire che i benefici di permettere operazioni di join locali con queste tabelle superano il costo dello storage extra consumato. Una tabella replicata è una tabella che viene replicata su tutti i nodi di calcolo, come illustrato di seguito.

Emma progetta le piccole tabelle, tipicamente le tabelle dimensionali, per essere replicate come segue:

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

Progettando in modo appropriato tabelle distribuite e replicate, Emma allinea la sua soluzione alle comuni best practice di progettazione MPP e consente un’elaborazione efficiente di elevati volumi di dati. Per esempio, una query contro 100 miliardi di righe in un ambiente SQL Server SMP richiederebbe l’elaborazione di tutti i dati in un unico spazio di esecuzione. Con MPP, il lavoro è distribuito su molti nodi per rompere il problema in modi più gestibili e facili da eseguire. In un’apparecchiatura a quattro nodi (vedi l’immagine sopra), ad ogni nodo viene chiesto di elaborare solo circa 25 miliardi di righe – un compito molto più rapido. Come risultato, Emma osserva miglioramenti significativi nel tempo di esecuzione delle query e la sua azienda può ora prendere decisioni migliori, più velocemente. Inoltre, Emma può far crescere il data warehouse da pochi terabyte a oltre 6 petabyte di dati aggiungendo “unità di scala” ad APS.

Caricamento dei dati

Con SQL Server SMP, Emma e il suo team utilizzavano processi ETL tramite una serie di pacchetti SSIS per caricare i dati nel data warehouse – (1) Estrazione dei dati dall’OLTP e da altri sistemi; (2) Trasformazione dei dati in formato dimensionale; e (3) Caricamento dei dati nelle tabelle dimensionali o fattuali di destinazione nel data warehouse. Con l’aumento dei volumi di dati, il sever SSIS nel mezzo diventa un collo di bottiglia durante l’esecuzione delle trasformazioni, con conseguente rallentamento del caricamento dei dati.

Con APS, Emma e il suo team possono invece utilizzare ELT, per estrarre i dati dall’OLTP e da altri sistemi e caricarli in un luogo di deposito su APS. Poi, i dati possono essere trasformati in formato dimensionale non con SSIS ma con il motore APS utilizzando la natura distribuita dell’apparecchio e la potenza dell’elaborazione parallela. In un’appliance a 4 nodi, quattro server effettueranno le trasformazioni su sottoinsiemi di dati rispetto al server SSIS a nodo singolo.

Questa elaborazione parallela porta a un aumento significativo delle prestazioni di caricamento dei dati. Emma può quindi utilizzare l’istruzione Create Table As Select (CTAS) per creare la tabella dalla tabella di staging come segue.

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

Passando a un processo ELT, Emma utilizza la potenza di elaborazione parallela di APS per vedere un aumento delle prestazioni nel caricamento dei dati.

In conclusione, Emma e il suo team hanno trovato risposte ai loro problemi di SMP con MPP. Ora possono sentirsi sicuri nel gestire il volume di dati e la crescita di Adventure Works con la capacità di scalare il data warehouse secondo le necessità. Con ELT e la potenza dell’elaborazione parallela in APS, possono caricare i dati in APS più velocemente e nei tempi previsti. E allineandosi con il design MPP di APS, possono ottenere prestazioni di query rivoluzionarie, consentendo la creazione di report in tempo reale e la comprensione dei loro dati.