Viviamo nell’era dell’informazione e questa non è una novità. Da qualche anno siamo abituati a sentire parlare di Gigabyte e da un po’ sono spuntati i Terabyte — e nell’uso domestico, per un po’ di tempo, almeno qualche anno, le unità di riferimento rimarranno queste. Le prospettive cambiano quando ci si addentra nel mondo del calcolo intensivo, non propriamente diffuso in ambito domestico ma piuttosto in quello scientifico o industriale. Si sale senza inibizioni a ordini di magnitudine ben più accattivanti (Petabyte, un milione di Giga). Qualche esempio concreto:
Trattare Petabyte di dati è una sfida per la ricerca sia a livello tecnico, sia a livello teorico. Da un punto di vista tecnico si è tutti testimoni dell’alta velocità in cui la tecnologia avanza — si pensi alla Legge di Moore. Tuttavia il problema dei dati non è gestibile pensando di aumentare all’infinito la potenza e la capacità dei singoli componenti o dei calcolatori. La tecnologia semplicemente non riesce a far fronte all’esigenza di potenza di calcolo e capacità di memoria (soprattutto volatile, es. banchi di Ram) che l’esplosione dei dati ha prodotto — inoltre, seppure fosse possibile sviluppare determinato Hardware ad alta prestazione, il risultato sarebbe tremendamente costoso e non alla portata di tutti.
È necessaria pertanto affrontare la gestione di grandi moli di dati cercando strategie teoriche che, ad esempio, ammettano l’uso parallelo di più macchine permettendo un certo grado di scalabilità. Da un punto di vista teorico il ricercatore informatico deve affrontare il problema — almeno secondo Jimmy Lin et al. nell’introduzione del suo libro Data-intensive Text Processing with MapReduce – su tre piani:
- Dati in sé (come ricavarli, quindi tutta l’area del crawling e della costruzione di corpora…)
- Rappresentazione dei dati (dove e come rappresentarli in supporti di memoria centralizzati o distribuiti, volatili o non, quindi: strutture dati, modelli relazionali, SQL o NoSQL, metadati, semantica…)
- Elaborazione dei dati (come trattarli, quindi algoritmi paralleli e distribuiti, data mining, cloud computing ecc.)
Chiaramente le aree non sono compartimentate, ma presentano un’ampia sovrapposizione. Ad esempio, si pensi alle strutture dati utilizzate per una sessione di crawling: il ricercatore dovrà considerare come ricavare i dati grezzi (punto 1) ma anche occuparsi di come rappresentarli (punto 2) in attesa dell’elaborazione. Come al solito nelle scienze è difficile tratteggiare linee di frontiera tra le varie aree di ricerca, soprattutto quando all’interno di una stessa macro-area (in questo caso, l’informatica). Tuttavia, tutto ciò che ruota attorno ai dati per comodità può essere visto come un campo di ricerca a sé stante. Molti la chiamano Information Retrieval (IR) — ma forse un termine più generico è quello di Scienza dei dati (in inglese, Data Science).
Fare ricerca nel campo della Data Science non è più privilegio di grandi aziende con cospicui capitali da investire. Oggigiorno, anche il singolo ricercatore (o persino uno studente curioso!) può lavorare in ambienti liberamente fruibili (come il framework Hadoop, che, come vedremo, offre strumenti programmativi per l’analisi distribuita di dati), e lanciarli in cluster grandi a piacere grazie ai servizi elastici di cloud computing on demand (ad esempio il servizio Amazon EC2, ove si paga ciò che si consuma).
Nelle prossime puntate vi racconterò del modello MapReduce, proposto da Google Labs nel 2004 — che offre un modello programmativo per l’elaborazione distribuita di dati — e di Hadoop — un framework libero offerto da Apache che lo implementa.
—
Jacopo O. (twitter)
Commenti recenti