Quando iniziavo a muovere i primi passi lavorativi eravamo alla fine degli anni 90. La mia carriera partiva all’interno di una grande azienda multinazionale (la IBM) nell’ambito che dei cosiddetti IT Services (Information Technology Services). Erano gli anni in cui tutto il mondo del business stava cominciando a scommettere seriamente sulle potenzialità di Internet. Certo la strada non è stata lineare, né semplice e senza ostacoli come qualcuno sperava. Basta pensare a quanto è successo con la cosiddetta bolla delle dot-com. Ma si è trattato comunque di un processo incessante e radicale, che ha cambiato la struttura della nostra economia e dunque della nostra società.

Sotto il profilo strettamente tecnico e in particolare per quanto riguarda la gestione e l’elaborazione dei dati, in questa fase si sono definitivamente affermati i database Relazionali o RDBMS (Relational Database Management Systems) ed è nata la fortuna di società come Oracle che quei sistemi producevano. 

In questo stesso periodo si è affermato come standard de facto il linguaggio SQL (Structured Query Language), nato negli anni ‘70 e che ancora oggi rappresenta la “lingua franca” per l’analisi dei dati.

Il forte sviluppo del World Wide Web e la sua trasformazione del Web 2.0 è stato possibile grazie ai database relazionali che consentivano di realizzare siti web “dinamici”, per i quali le informazioni necessarie a comporre le pagine html venivano estratte in base alle interazioni con l’utenteErano gli stessi anni in cui la legge di Moore garantiva potenza di calcolo sempre crescente e in cui fenomeni analoghi supportavano le esigenze di crescenti capacità per la memorizzazione dei dati (memorie di massa e memoria ram) e per la velocità della trasmissione dei dati in rete.

Stiamo quindi parlando di uno scenario in cui l’aumento delle risorse per la trasmissione, memorizzazione e il processo dei dati aumentavano con legge esponenzialeLa regola per l’analisi dei dati era molto semplice: se il tuo computer non è più sufficiente per elaborare i tuoi dati comprane uno più potente!

Questa ascesa apparentemente inarrestabile dei microprocessori, trascinata dai personal computer prima e dai server usati per il web poi, è stata tanto potente da lasciare sul campo vittime illustri come i supercomputer Cray.

Ma la storia ha sempre i sui corsi e ricorsi e le illusioni di crescita illimitata trovano sempre un muro. Nel nostro caso questo muro è stato il limite fisico alla miniaturizzazione e l’aumento del consumo energetico, che impediscono già da diversi anni di raddoppiare la velocità di esecuzione delle istruzioni dei microprocessori semplicemente accelerando il loro orologio interno (il clock).

L’altro fenomeno “imprevisto” è stato quello della crescita del volume dei dati prodotti e della loro velocità di generazione e consumo. In altre parole, il fenomeno ormai noto come Big Data.

La combinazione di questi due fattori ha causato la crisi dei database relazionali. Infatti non era più possibile pensare di analizzare i dati disponibili raccogliendoli ed elaborandoli su un unico server. D’altra parte i database relazionali non erano progettati per funzionare come sistemi distribuiti: che significa sistemi eseguiti su più elaboratori collegati in una rete.

Tra i primi a fare i conti con questi limiti sono stati i motori di ricerca per pagine web e in particolare Google. L’algoritmo di ranking di Google, cioè l’algoritmo che determina l’ordinamento delle pagine web restituita da una ricerca, si basava su un calcolo ricorsivo computazionalmente costoso chiamato Page Rank.

Certo non era possibile memorizzare tutte le pagine web raccolte da google, gli indici delle parole in esse contenuti e le relazioni dei link tra queste all’interno di un database relazionale. Tali dati non erano solo in quantità enormemente superiore rispetto alla capacità dei RDBMS.

Per questa ragione Google applicò un approccio totalmente diverso al problema, basato su alcuni principi chiave: 

  1. I dati dovevano essere memorizzati sotto forma di file e distribuiti su più computer connessi tra loro in una rete a formare un sistema calcolo coordinato (cluster);
  2. Il calcolo non doveva essere eseguito su una sola macchina ma distribuito su tutti i computer del cluster;
  3. I dati si dovevano muovere il meno possibile e quindi l’algoritmo doveva essere eseguito vicino ai dati.

Si tratta di una rivoluzione copernicana rispetto a quanto succedeva in precedenza quando i dati risiedevano ed erano interrogati attraverso un’unica applicazione eseguita su un unico computer molto potente (il data base).

Inoltre i dati elaborabili in questa maniera erano molto più vari e potevano consistere di tabelle, come nel caso dei database relazionali, ma anche di testi, immagini, audio o qualsiasi altro tipo di informazione.

Questa rivoluzione fu introdotta da due paper scientifici pubblicati da Google Research: “The Google File System” (2003) e “MapReduce: Simplified Data Processing on Large Clusters” (2004). Nel primo veniva spiegato come Google avesse realizzato un sistema per memorizzare grandi quantità dati sotto forma di file su un migliaia di computer non specializzati (commodity hardware) in modo distribuito e ottimizzato per l’accesso contemporaneo da parte di centinaia di applicazioni.

Nel secondo paper veniva invece introdotto il nuovo modello di programmazione MapReduce e la sua implementazione per consentire l’elaborazione e la produzione di grandi quantità di dati.

Ovviamente Google disponeva internamente di software e tecnologie basate sui principi esposti nei due paper ma non aveva intenzione di renderle di dominio pubblico. L’effetto dei due paper fu comunque quello di ispirare e guidare la realizzazione di un progetto open source, adottato dalla Apache Software Foundation, che avrebbe rivoluzionato il mercato nel solco tracciato da Google: si trattava di Hadoop. A partire da Hadoop prende corpo e diventa concreto sul mercato un nuovo tipo di sistema informatico in grado di gestire e analizzare i Big Data: il Data Lake.

In un prossimo articolo cercheremo di scoprire insieme quali sono le specificità dei Data Lake e perché sono così importanti per l’analisi dei dati.