Big Data... oggi

Too Big Data

Io preferisco restare sull'oggi, invece dei Big Data, vorrei affrontare l'argomento "too Big Data".

Come per la temperatura, che c'è quella vera, e quella percepita, anche per i big data possiamo dire che spesso sembra di aver di fronte una montagna di dati, anche se si trovano in database assolutamente standard, e - paragonati ai repository di Google - microscopici.

Ma se, dal confronto, i nostri dati appaiono minuscoli, questo non significa affatto che il nostro problema sia marginale !

Prendete come esempio quelle statistiche, che, per averle finalmente aggiornate, bisogna aspettare ore ed ore.

Ho conosciuto personalmente aziende che non lesinavano nel budget dell'IT, ma ugualmente dovevano aspettare più di un giorno, prima di avere certi dati "pubblicati".

Si tratta di situazioni molto più frequenti di quanto non sembri, perché spesso, un po' per amor proprio,  non se ne parla. Il problema poi emerge, tristemente, in occasione di acquisizioni aziendali, quando qualcuno "mette il naso" nei processi di consuntivazione, e comincia a stupirsi...

Eppure, prendere le decisioni con un giorno di ritardo, non è mai senza conseguenze.

Per questo chiedo scusa se ho barato un po' con il titolo di questo articolo, giacché l'argomento che affronterò è decisamente prosaico. 

Vorrei parlare, infatti, di come è possibile affrontare questi scogli.  Non sono assolutamente riconducibili al tema "Big Data", ma spesso affliggono i sistemi di Business Intelligence, che si trovano in coda ad un processo che, nel suo complesso, all’utente finale appare mastodontico.

Pensiamoci un attimo:  abbiamo processori che eseguono miliardi di operazioni al secondo;  elaboratori che montano processori in parallelo: in un'ora, quante operazioni fanno ?  E come mai, allora, la nostra elaborazione dura ore e ore ?  Così, a spanne, dovrebbe sorgere il dubbio: "magari c'è qualche problema di metodo", no ?

Elaborazioni incrementali

Se al tassista chiedessimo di fare il giro dell'isolato, sicuramente sarebbe contento, ma non avrebbe una grande opinione di noi. Questo però è quello che noi spesso chiediamo al nostro ETL, perché continuiamo ad estrarre sempre gli stessi dati.

Una delle caratteristiche importanti di alcuni ETL, è la capacità di elaborare in modo incrementale. Significa, per esempio, che i dati dei mesi "chiusi" non occorre estrarli ogni volta, perché sono gli stessi dell'estrazione precedente.

Il ruolo di "accumulatore" spesso viene svolto dal datawarehouse; però questa soluzione è accettabile solo se i tempi di accesso a quel database sono brevissimi.  I sistemi che effettuano la persistenza dei dati statici in strutture ottimizzate per il caricamento in memoria (in files "binari") sono sicuramente i vincitori in questa competizione.

Approssimazioni successive

Le load incrementali non sono l'unica soluzione ai "Too big data".

Spesso lo scoglio si nasconde nella natura dei dati da estrarre, che deriva da una serie di processi, ciascuno con le sue precise esigenze computazionali.

Un esempio tipico sono le famigerate "chiusure".

Contabilità, magazzino, produzione ed analitica... che altro ? Ciascun processo deve dare il suo consenso "definitivo" al dato, prima di darlo in pasto al "tritacarne" della consuntivazione di fine mese.

Sono certo che molti di voi, leggendo queste righe, rivivono dei piccoli drammi.

Non si può fare 1 + 1 se non si è certi del primo e del secondo addendo.  Come risultato, sembra che non sappiamo fare le somme.

A tutti quelli che soffrono di questa sindrome, suggerisco un rimedio omeopatico... chiediamoci: "cosè che nuoce ?" la risposta è facile: "il ritardo della consegna di pochi dati".

Bene, la terapia è proprio quella: diamo subito la maggior parte dei dati; e diamo in ritardo quei pochi dati che arrivano in ritardo (ben diluiti).

Nella prima elaborazione li sostituiremo con delle stime (placebo).

La metafora è un po' estrema, ma in realtà la maggior parte degli shareholder preferisce dati tempestivi, con una piccola imprecisione, rispetto a dati definitivi, ma in ritardo. Il dato definitivo arriverà il mese successivo, come rettifica: alla fine tutto quadra alla perfezione.

Il problema spesso siamo noi, che non osiamo abbastanza.

Alleggerire i preliminari

L'ultima considerazione che l'esperienza mi suggerisce, riguarda i trattamenti preliminari alle informazioni.  In pratica, la presentazione del dato, fatta con lo strumento di Business Intelligence, è preceduta da numerosi passi di elaborazione preliminari, con varie finalità: incrocio di fonti diverse, calcolo di informazioni derivate, controlli, preparazione di dati aggregati. 

Il codice che istruisce queste elaborazioni, spesso è sparso: si parte dal DBMS stesso, per finire nello strumento di ETL.  L'esperienza insegna che in questo codice si possono annidare stratificazioni di logiche, talvolta inutili o ripetitive, o addirittura interventi manuali, di qualche operatore sottopagato, e demotivato.  Il suggerimento, è di alimentare il sistema di Business Intelligence, quanto più possibile, con i dati originali, riducendo al minimo i passaggi intermedi. Ci guadagnano la velocità, e la trasparenza. 

Qualche anno fa era impensabile, ma oggi le tecniche computazionali di alcuni strumenti di analisi dati, consentono di snellire i passi preliminari: approfittiamone !