Tecniche di scale-out

Elaborazione parallela: Tecniche di Scale-Out

Una delle maggiori sfide nell'ambito dei Big Data è come gestire le grandi quantità di dati in modo efficiente e scalabile. Il tema della scalabilità è particolarmente delicato nel mondo Big Data in quanto, come noto, i dati spesso crescono in modo molto veloce, e quindi occorre predisporre una soluzione architetturale in grado di rispondere a questa crescita in modo flessibile.

Per affrontare queste sfide l’approccio più diffuso è quello dell’elaborazione parallela del carico di lavoro: l’idea di fondo è quella di suddividere il carico tra le diverse componenti del sistema in modo che ciascuna possa operare in autonomia, parallelizzando quindi un lavoro che altrimenti dovrebbe essere eseguito procedendo serialmente,un passo alla volta.

La tecnica di Scale-Out è una delle soluzioni architetturali che sta dimostrando di essere particolarmente efficiente in questo ambito: si tratta di una architettura a scalabilità orizzontale che prevede l’aggiunta progressiva di “nodi”, ciascuno in grado di fornire al sistema nuove risorse di calcolo e di memorizzazione delle informazioni.

In questo tipo di architetture il carico di lavoro viene suddiviso tra i vari nodi in modo da permettere un’elaborazione parallela: ciascun nodo elabora i dati localmente e ritorna al sistema il proprio risultato parziale; i risultati parziali sono poi riaggregati ottenendo il risultato finale.

Si parla in questo caso di Massive Parallel Processing (MPP): se tutti i nodi sono equivalenti ci troviamo di fronte ad un MPP simmetrico, mentre se alcuni nodi ricoprono un ruolo differente si parla di MPP asimmetrico.  La distinzione non è puramente accademica: in un sistema asimmetrico infatti è possibile che alcuni nodi arrivino alla saturazione mentre altri nodi risultino invece scarichi; un classico caso è dato dai sistemi nei quali i nodi sono distinti tra front-end e back-end: in queste architetture è abbastanza comune che si arrivi alla saturazione del sistema quando una delle due componenti giunge al 100% di utilizzo (spesso è il front-end), anche se le restanti componenti avrebbero, almeno in teoria, ancora diversa capacità di poter erogare. Il fatto di aver “specializzato” i nodi non permette di poter (ri)utilizzare la capacità residua. Alcune soluzioni asimmetriche permettono di inserire nuovi nodi in modo indipendente (alimentando ad esempio il front-end o il back-end), mentre in altri casi occorre far crescere tutto sistema anche se la saturazione riguardava solo una delle sue parti.

Un sistema simmetrico garantisce la distribuzione del lavoro fra tutte le componenti, rendendo possibile una scalabilità quasi lineare. In questo caso la saturazione viene raggiunta quando tutte le componenti raggiungono  il 100% di utilizzo: l’aggiunta di nuovi nodi permette qui di crescere in modo controllato e progressivo, senza il “problema” di avere nodi sottoutilizzati.

La presenza di nodi sottoutilizzati, frequente nel mondo asimmetrico, è un problema non solo tecnico, in quanto causa una saturazione “prematura” del sistema, ma anche economico: il cliente infatti ha acquistato nodi che non riescono ad operare al 100%, e allo stesso tempo consumano corrente elettrica e soprattutto licenze software.  

La scelta della corretta architettura è ovviamente un aspetto critico di ogni soluzione Big Data: non esiste un'unica ricetta per tutte le necessità quindi il consiglio è di non fidarsi delle proposte “one size fits all”  ma valutare invece quali soluzioni il mercato metta a disposizione.

Un esempio di MPP simmetrico in casa EMC: Geenplum Database.

L’architettura MPP simmetrica è alla base di Greenplum Database, una soluzione disegnata per la Business Intelligence e l’analisi dei Big Data. Il principio centrale del Greenplum Database è quello di spostare le capacità di elaborazione il più vicino possibile ai dati: l’architettura MPP permette di eseguire le operazioni in modo pienamente parallelo, utilizzando contemporaneamente tutte le connessioni verso lo storage. Il parallelismo viene usato non solo in fase di “lettura” dei dati, ma anche nella fase di caricamento dei dati stessi, che in tutte le altre soluzioni presenti nel mercato risulta invece necessariamente seriale. Nel sistema Greenplum i dati fluiscono dai sistemi sorgente verso tutti i nodi del database, senza richiedere la presenza di un singolo punto di accesso (che diventa ovviamente un collo di bottiglia). In questo modo Greenplum Database è in grado di raggiungere velocità di caricamento di più di 10TB/ora per rack (e una velocità di scansione dei dati di 24GB/sec).

La scalabilità del sistema Greenplum è ottenuta in modo lineare aggiungendo nuovi nodi: ogni nodo porta con sé le risorse di elaborazione e di memorizzazione dei dati. Partendo da un minimo di quattro nodi è così possibile analizzare universi dati di alcune centinaia di gigabytes, per raggiungere progressivamente dimensioni che possono arrivare all’ordine di multi-petabytes.

GZ

Per maggiori su Greenplum Database potete visitare la pagina descrittiva della soluzione nelsito Pivotal.