Big Data…probabilmente avrete letto decine, forse centinaia, di articoli e post ma se ne avete voglia proverò a darne una mia interpretazione molto informale, sperando che possa essere compresa anche dai “non tecnici” (visto che a qualcuno piace ancora chiamarci “tecnici” 🙂 ).

Elaborare ingenti quantità di dati è un aspetto complesso quanto affascinante.

Come in una cassetta degli attrezzi troviamo giraviti, martelli, chiavi, brugole (chi mi conosce sa che ci capisco ben poco di attrezzi), anche nell’elaborazione dei dati dobbiamo valutare lo strumento più adatto, efficace e sicuro per raggiungere il nostro obiettivo.

Il numero dei record, “banalmente”, potrebbe essere uno dei primi fattori discriminanti.

Cosa succederebbe infatti se volessimo elaborare in real-time informazioni di diversa forma che arrivano ai nostri sistemi con un’irrefrenabile, e continua, velocità?

Ecco le famose 3V:

Volume, Varietà e Velocità

Pensiamo ad esempio alle informazioni che possono trasmettere dei sensori…ora immaginiamo di averne una quantità enorme di questi sensori e di volerne valutare i dati immediatamente, ad esempio per classificarli/filtrarli/sommarli/contarli/etc..

Quando dico “tanti” dovete pensare a migliaia, o meglio, decine/centinaia di migliaia di trasmissioni al minuto.

Quello appena descritto è solo uno dei possibili scenari “Big Data” ovvero, tanto per darne una definizione, “non risolvibile attraverso una soluzione/architettura classica“.

Sarebbe come voler avvitare migliaia di viti, da solo, a mano con un giravite e pensare anche di tornare a casa per cena!

Evidentemente dovremo organizzare una squadra di lavoro ed armare ognuno di un ottimo avvitatore. Se vogliamo assicurarci di arrivare a casa in tempo, secondo voi è più efficace chiedere ad altre persone di unirsi alla squadra oppure scegliere un avvitatore ancora più veloce?

Probabilmente verrebbe da rispondere “entrambe le soluzioni”…ma su larga scala non è il fatto che l’avvitatore possa essere un 5% più veloce a far realmente la differenza.

Ecco quindi che la soluzione vien da sè…dovremo reclutare altre persone ad aiutarci e così facendo, lavorando tutti in modo equo, ognuno nella squadra completerà la propria parte di lavoro.

Complessivamente, la somma del lavoro di ognuno corrisponderà alla totalità del lavoro richiesto.

Bene con i dati…”grosso modo” è lo stesso.

Hadoop

Hadoop, di cui si sente parlare sempre più spesso, ci aiuterà a risolvere problemi non comuni. Come? Il principio alla base è tanto semplice quanto potente “Divide et impera” (esattamente come per le nostre viti!).

Invece di cercare di far fare tutto ad una sola macchina, perché non provare a fare in modo che più macchine collaborino in modo efficiente?

Bene, se tutto questo vi torna ora abbiamo come minimo due aspetti da affrontare: in primis dovremo occuparci di dove memorizzare i nostri dati, poi dovremo capire come riuscire a leggerli senza impazzire troppo!

HDFS e MapReduce

HDFS e MapReduce (ma non solo MapReduce) ci vengono in aiuto proprio per risolvere questi problemi.

HDFS, senza complicare eccessivamente le cose, ci permette di pensare a migliaia di dischi come se logicamente ne avessimo uno solo, mentre MapReduce è un motore che esegue il nostro codice in modo parallelo, senza però farci preoccupare della complessità che questo realmente richiede.

Loro sono la nostra squadra e possono elaborare quantità enormi di dati…enormi.

Esistono poi tanti altri strumenti di cui si sente parlare, eccoli velocemente descritti:

• Hive: partiamo dal presupposto che scrivere MapReduce significa scrivere codice Java, quanto sarebbe più bello invece scrivere un’equivalente istruzione SQL per fare lo stesso tipo di elaborazione? Ecco Hive è un interprete. Noi scriviamo una query SQL e lui genera al volo le corrispondenti classi Java che lo rappresentano.
• Pig: quanto considerate vbscript più semplice rispetto a Java? Il paragone non c’entra nulla…ma credo che renda l’idea. Di nuovo noi scriviamo semplici istruzioni logiche e queste vengono tradotte in Java (in realtà smettiamo di pensare in termini di Map e Reduce, ma questo è più complicato da spiegare 🙂 )
• Impala: No, questo non è MapReduce…magari un giorno scriverò qualcosa a suo riguardo
• Spark: di nuovo…non è MapReduce…ma neanche così diverso. In due parole eleviamo MapReduce all’ennesima potenza e rendiamolo molto più veloce, facendolo lavorare in memoria invece che su disco. Banalizzato è dir poco…ci sono tanti aspetti ovviamente da discutere.

Ovviamente questa è un’estrema sintesi, molto molto superficiale…ma vi lascio con una domanda che potrebbe già trovare risposta, se ciò che ho scritto vi risulterà chiaro.

Se invece di migliaia di viti doveste avvitarne solo qualche centinaia, vi preoccupereste di creare un team di persone per avvitarle o forse, nello stesso tempo, avreste risolto il lavoro diversamente ma ottimizzandolo?

La soluzione è nella cassetta degli attrezzi!

Sayed S.

Vuoi imparare ad elaborare elevate moli di dati? Scopri il nostro Corso di Formazione Hadoop – Developer.