Si dice che il 2014 sarà l’anno del Big Data… qualunque cosa questo significhi…
Big Data è una parola che va molto di moda, anche se ognuno di noi ha un’idea diversa sul suo significato. Analizzare “big data” significa estrarre conoscenza da grandi moli di dati, come possono essere i dati generati dal crawling di una gran quantità di siti internet, dai post nei social network di un gruppo cospicuo di persone, dalle variazioni di valore delle azioni in borsa nel corso degli anni per un numero consistente di titoli.
Il problema nasce proprio da qui… quanto grande ? che significa cospicuo ? 1 terabyte può essere considerato “big data” ? e 10 terabyte ?
Opinione di molti è che il limite tra normal data e big data cominci a 4-5 terabyte (Don’t use Hadoop – your data isn’t that big). La ricetta però non è così semplice.
You don’t have a “big data” problem, you have a “big” data problem
Avere un database di 10 TB non implica la necessità di utilizzare dei tool per la gestione di “big data”. Un normale database relazionale può memorizzare una tale quantità di dati ed essere anche più performante di un apposito cluster Hadoop. Tutto dipende da come vengono utilizzati i dati.
Hadoop è un ottimo sistema per l’analisi di grandi quantità di dati, che si tratti di terabyte, petabyte o anche hexabyte. Un cluster Hadoop può essere costituito anche da 4000 macchine con caratteristiche hardware diverse che lavorano parallelamente su dati condivisi.
Un cluster hadoop, però, è necessario quando questi dati devono essere analizzati “tutti” e “insieme”. Se i dati sono partizionati e l’analisi viene fatta sulle singole partizioni in maniera separata, oppure i dati devono essere acceduti tramite indice e via dicendo, hadoop non è una soluzione e non siamo in presenza di “big data”.
Il numero 5 TB nasce da calcoli molto semplici. Considerando il caso in cui tutta la grande mole di dati deve essere elaborata per effettuare un’analisi, il collo di bottiglia del sistema è rappresentato dalla velocità di caricamento dati del disco rigido. Un disco rigido raggiunge normalmente la velocità circa 300 MB/s per il caricamento dei dati, quindi, per caricare ed analizzare 5 TB di dati occorrono 5*1024*1024/300 = 17476 secondi, pari a circa 5 ore. Anche con un disco di velocità superiore, diciamo 600 MB/s non si riuscirà a superare la barriera delle 2,5 ore e, con una configurazione a più dischi, ad esempio, di tipo raid 0, il collo di bottiglia si sposterà sulla RAM, BUS o CPU e sarà difficile scendere sotto l’ora di elaborazione. Anche considerando un sistema RDBMS in cluster, la presenza di una singola macchina che effettua l’elaborazione dei dati può provocare, in maniera del tutto simile, dei rallentamenti forse maggiori a causa dei ritardi di rete.
In queste circostanze, l’unico modo per uscire dall’impasse è un sistema che renda semplice il calcolo distribuito (ad esempio, il pattern map/reduce), magari basato su un file system distribuito (ad esempio, HDFS) e con un sistema di coordinamento efficiente che garantisca le massime prestazioni sfruttando il principio di località dei dati (ad esempio, YARN). Tutto questo, e molto altro, si chiama Hadoop.
Eseguire Hadoop su un singolo nodo per effettuare calcolo pseudo-distribuito è sicuramente una cosa da evitare. Anche su 3 o 4 nodi, Hadoop non sembra un fulmine di guerra, soprattutto se paragonato alle principali soluzioni RDBMS in configurazione cluster. Hadoop, però, garantisce una scalabilità senza eguali in termini di quantità di dati analizzabili grazie alla possibilità di aggiungere migliaia di macchine al cluster.
La sfida che i creatori di Hadoop si pongono attualmente è quella di rendere il sistema sempre più efficace per l’esecuzione di analisi in tempo reale. Uno dei problemi che affligge Hadoop è, infatti, l’elevato tempo di risposta del sistema che, nelle applicazioni di tipo batch, passa inosservato poiché trascurabile rispetto al tempo totale di esecuzione dei job.