Big Data: miti e considerazioni

Big Data è un termine che in IT è utilizzato fin dagli anni ’90. Oggi è diventato di moda, ma ci sono ancora troppi miti da sfatare.

Big Data è un termine che in Information Technology è utilizzato fin dagli anni ’90; le sue origini sono abbastanza contese, anche se qualche autore come Steve Lohr (The Origins of ‘Big Data’: An Etymological Detective Story) preferisce attribuirlo a John Mashey e ai suoi numerosi talk sull’argomento, per l’appunto negli anni ’90.

Tuttavia, si tratta di un concetto che è diventato particolarmente di moda in questi ultimi due o tre anni, con la relativa diffusione di una serie di miti che probabilmente non stanno rendendo un buon servizio.
Ma che cos’è Big Data esattamente?
Oggi quando si parla di Big Data si intende la combinazione di tre concetti, laddove per “grande” si intende sostanzialmente “troppo grande per essere gestito dalla tecnologia tradizionale disponibile”.

– Grandi volumi di dati: si parla di Terabyte, Petabyte, Zettabyte, a seconda della tecnologia a disposizione in un dato momento

– Grande velocità di crescita dei dati

– Grande varietà di formati: dati disponibili in una quantità di formati differenti, e prevalentemente non strutturati (files di log, testi, immagini…)

I database relazionali sono già una tecnologia matura in grado di gestire volumi importanti di dati. Ma con l’aumento esponenziale delle fonti (social network, IoT, rilevamenti climatici, dati genetici…) disponibili nei formati più disparati si è reso sempre più necessario un drastico cambio di approccio.

“Big Data è una tecnologia”

Il primo mito da sfatare è che Big Data fa riferimento a una specifica tecnologia.

Giusto per dare un’idea, l’immagine di sotto è una fotografia indicativa del panorama Big Data nello scorso anno, divisa per aree (infrastrutture, analytics, applicazioni, API)

Big Data non è “una tecnologia”, ma piuttosto un approccio a un insieme di problematiche che non sono risolvibili con i metodi tradizionali, e comprende un ecosistema di tecnologie e sistemi, che come si può vedere in questa particolare fase sta conoscendo una proliferazione senza precedenti.

“Big Data costa poco”

Questa convinzione deriva dal fatto che (come già detto), la maggior parte dei tool sono open source, ed è fattibile assemblando cluster fatti con hardware relativamente economico.

Il problema però risiede nel fatto che le architetture Big Data non sono assolutamente banali da configurare e mantenere in modo efficiente, e sebbene i tool di sviluppo siano piuttosto avanzati, le figure professionali in possesso degli skill richiesti per costruire modelli di analisi efficaci sono tutt’altro che facili da trovare.

Non solo: mentre Big Data rimane effettivamente poco costoso da mettere in piedi finché si tratta di esperimenti esplorativi, la musica può cambiare radicalmente quando si tratta di fare il salto in produzione.

In produzione infatti, se il rischio non è stato opportunamente analizzato Big Data rischia di diventare un cavallo di Troia, introducendo una quantità di costi imprevisti.

Per esempio, l’assunzione che basti aggiungere una manciata di nodi costituiti da ferraglia d’avanzo si rivela per quello che è quando si inizia ad avere una quantità di nodi offline dovuti a problemi hardware.

Inutile dire che affidandosi invece a server più robusti e di qualità i costi iniziano a incidere in maniera rilevante, e una decina di nodi (il minimo per giustificare la scelta) possono tranquillamente arrivare a costare centinaia di migliaia di euro.

Per quanto riguarda il software invece, anche se open source, diventa praticamente indispensabile affidarsi a distribuzioni commerciali come Cloudera o HortonWorks, e anche qui i costi di licenza non sono indifferenti.

Se poi la soluzione adottata è on premise, allora occorre aggiungere anche i costi di manutenzione e di upgrade del software.

“Big Data riguarda solo il team IT”

Convinzione diffusa in molti ambiti è che Big Data in fondo sia un tema prettamente tecnico, che coinvolge solo il dipartimento IT.

In realtà molti degli step necessari per implementare Big Data richiedono il coinvolgimento di molte figure aziendali:

– Planning: in questa fase sono prevalentemente Business analysts ad occuparsi della definizione degli obiettivi di business del progetto, identificare i partecipanti di Business e IT, individuare i dataset rilevanti

–  Setup: definiti scope e partecipanti, si tratta di valutare tool e prodotti adeguati al progetto; qui oltre alla parte commerciale è dove si affrontano anche eventuali problemi legali relativi ai dati.

– Implementazione: qui è dove il team IT è maggiormente coinvolto: si mette fisicamente in piedi il sistema, si configura e ottimizza.

– Operation: qui è dove Big Data inizia a tirar fuori valore aziendale, e dove viene coinvolto maggiormente anche il business.

L’implementazione di Big Data è un progetto ad ampio respiro che richiede un cambio di approccio radicale e deve per forza coinvolgere quasi tutta l’azienda.

“Con Big Data non dovremo più preoccuparci dei problemi di Data Quality”

Big Data è formato principalmente da data lakes con “schema on read”. Che significa? Schema on read vuole sostanzialmente dire che i dati sono immagazzinati in modo non strutturato, e la “struttura” non è altro di fatto che un’interpretazione data in lettura, da qualcuno che ovviamente conosce il genere di dati che sta leggendo. Da qui la convinzione che la qualità dei dati diventi poco importante e che vi si possa sopperire “aggiustandoli” in elaborazione.

Questa però è un’illusione, perché una cattiva qualità di dati rende spesso difficilmente esplorabili i dati, o peggio ancora inattendibili.

“Big Data sostituirà i database relazionali”

È difficile pensare che Big Data “sostituisca” qualche tecnologia, visto che per definizione serve ad approcciare problemi “non risolvibili con le tecnologie attuali”

Nello specifico, Big Data non prenderà il posto dei database relazionali, semplicemente perché hanno due utilizzi differenti: I database contengono informazioni altamente strutturate, sono e rimangono indispensabili per gestire qualsiasi cosa riguardi transazioni (I sistemi Big Data sono non transazionali per natura), e anche il tipo di reportistica e interrogazioni possibili con i Data Warehouse classici non sono possibili con Big Data.

Come già detto, Big data crea vero valore quando si tratta di gestire grandi quantità di dati non strutturati, spesso in continuo aumento, quindi non l’universo Big Data non è in contrapposizione ai sistemi di BI tradizionali.

“I sistemi Big Data sono veloci”

Questo non è esattamente un mito, ma sta diventando piuttosto una necessità.

Big Data nella sua prima accezione significava sostanzialmente caricare i dati in vari formati su un file system distribuito (come HDFS di Hadoop), e poi effettuare le analisi con programmi ad-hoc costruiti su MapReduce.

MapReduce in sintesi è un algoritmo che consente di fare ricerche di tipo chiave-valore, splittando la fase di conteggio (map) tra i diversi nodi, seguita poi da una fase di aggregazione (reduce), anch’essa eseguita in parallelo. Il “problema” di MapReduce è che è un algoritmo di tipo batch-oriented: si prepara, si schedula e si aspetta che venga eseguito; inoltre, per quanto possa essere ragionevolmente veloce a processare grandi quantità di dati se hardware e nodi lo supportano, processa *sempre* tutti i dati a disposizione, rendendolo inadeguato a ricerche semplici o limitate nello scope.

Il problema con la situazione illustrata sopra è che se da una parte abbiamo uno stream di dati in arrivo ad alta velocità, dall’altra abbiamo un magazzino di dati a volume continuamente crescente di dati che fondamentalmente rimangono lì in attesa di essere utilizzati.

La nuova frontiera quindi diventa “Fast Data”, non in sostituzione ma complementare a Big Data; problema che ha dato origine a una ulteriore fioritura di soluzioni, da stream processors (elaborazione di stream di dati on-the-fly) come Apache Storm, a database distribuiti ottimizzati per dati ad alta velocità, come ad esempio ScaleDB.