Tra data silos e data lakes

Abbiamo menzionato i termini “data silos” e “data lakes” nel post Big data e smart data, di qualche giorno fa. Si tratta di concetti importanti nell’ottica di una maggiore integrità e fruibilità dei dati. Per questo vale la pena di approfondirli. Iniziamo con le relative definizioni, oggi abbastanza uniformemente accettate:

Un Data Silos è un archivio di dati fissi che rimane sotto il controllo di un reparto aziendale e viene isolato dal resto dell’organizzazione. L’origine di un silo può essere tecnica o culturale.

Un Data Lake è un archivio che “contiene dati grezzi, nel loro formato nativo, fino a quando non è necessario”; questo termine fu coniato da James Dixon, CTO della società Pentaho.

Entriamo nel dettaglio.

Negli ambiti di business management ed information technology il concetto di silo è associato – in modo estensivo – a qualunque sistema che non sia in grado di interagire con altri sistemi della stessa azienda, ossia un sistema chiuso rispetto ad essi, in modo da creare un ambiente individuale e tipicamente diverso. Si può usare, passando dai dati alle applicazioni, il concetto di siloed application.

Un silo si verifica ogni volta che un sistema di dati è compatibile o poco integrato con altri sistemi di dati. Questa incompatibilità può verificarsi a tre livelli architetturali: tecnico, applicativo, dei dati in sé. È già stato dimostrato che le scelte alla base della modellazione sono la causa principale dei problemi di integrazione tra dati e, di conseguenza, la maggior parte dei sistemi di gestione sono incompatibili tra loro a partire dallo strato di base, quello della architettura dei dati stessi.

In definitiva possiamo vedere un silos di dati come un sistema di gestione dati isolato, incapace di interagire reciprocamente con altri sistemi correlati. Un limite mica da ridere. Tutto questo all’interno di una azienda è tipicamente associato a una mentalità che consente questa segregazione, come tra gli scompartimenti di un sottomarino.

I dati fissi (alternativamente indicati come dati permanenti, dati di riferimento, dati d’archivio, o fixed-content data) sono dati che – in circostanze normali – non sono soggetti a variazioni. Esempi: le rilevazioni atmosferiche del passato, i risultati di ricerche di mercato ora chiuse, dati di cartelle cliniche, dati finanziari di qualunque fonte ormai storici. Sono, insomma, informazioni immutabili.

Silos di dati tendono a nascere in modo naturale – nelle grandi aziende – in quanto ogni dipartimento, divisione o unità organizzativa ha obiettivi, priorità e responsabilità diverse oppure quando i servizi aziendali sono in concorrenza tra di loro invece di lavorare in sinergia con obiettivi di business condivisi e comuni.

Per inciso la attuale strategia di implementazione dei PLM (Product Lifecycle Management, cioè software per la gestione del ciclo di vita dei prodotti) comprende esplicitamente l’obiettivo di “eliminare i silos di dati”. La catena di trattamento del dato da parte di un PLM – progettazione, ingegnerizzazione, produzione, supply chain, supporto ecc. – e la necessità di gestire dati relativi al prodotto sparpagliati tra vari silos sono tematiche tipiche di ogni implementazione PLM.

La presenza di silos oggi è generalmente vista come un ostacolo ad efficaci attività di business. Le aziende cercano di adottare strategia per abbatterli, con l’obiettivo di rimuovere questi ostacoli strutturali e tecnici alla collaborazione, all’accessibilità e all’efficienza.

Le critiche ai silos isolati sono crescenti e sono riassumibili in questo concetto: non solo tendono a ostacolare la produttività, come detto prima, ma sono passibili anche di avere un impatto negativo verso l’integrità dei dati. Il motivo è evidente: quando sono presenti due o più silos per gli stessi dati, il loro contenuto è probabilmente diverso, disallineato, fonte di potenziale entropia e di errori (si pensi ad esempio a sovrascritture accidentali tra versioni o istanze diverse dello stesso set di dati più o meno aggiornati tra le due fonti, effettuati in momenti diversi).

Da questo punto di vista, per questo specifico problema, una strategia di cloud storage può aiutare le aziende a dotarsi di una visione più matura, più unitaria dei propri dati, puntando a migliori percorsi di aggiornamento ed accesso degli stessi, oltre che ad un potenziale maggior coerenza. Inoltre si possono valutare introduzioni di componenti delle infrastrutture di cloud backup per offrire una ragionevole alternativa ai silos di dati, in particolare per le piccole e medie moli di dati e in caso di accesso irregolare o poco frequente. Un archivio esterno, sul cloud, piuttosto che più silos interni può assicurare una maggiore integrazione e coesistenza tra i soggetti consumatori del dato stesso dell’azienda.

Per queste ragioni, molte organizzazioni hanno cominciato ad allontanarsi da silos di dati e in soluzioni di backup e archiviazione cloud-based.

Oggi i data lakes possono anche essere visti come “una dei metodi più controversi di gestire i Big Data” ma, secondo gli analisti di PricewaterhouseCoopers potrebbero comunque porre fine all’esistenza dei silos. Non si confonda un data lake con il probabilmente più noto concetto di data warehouse. Mentre “data warehouse gerarchico” organizza i dati in tabelle o cartelle e file, un data lake utilizza una architettura piatta dove ad ogni elemento viene assegnato un identificativo univoco ed è contrassegnato con una serie di tag associati ai metadati del dato stesso.

In sintesi, senza entrare nel tecnico: vediamo i data lake come piattaforme per la gestione dei dati dell’intera azienda che servono ad analizzarli, pur provenendo da fonti diverse, nei loro formati nativi. Al posto di inserire i dati in un data warehouse – un magazzino –  costruito ad hoc, e popolato con apposite tecniche, gli ETL, li si sposta in un data lake nel loro formato originale.

Un primo evidente vantaggio è l’eliminazione dei costi iniziali dell’inserimento e trasformazione dei dati stessi, cioè le onerose operazioni sottese alle attività classificate come ETL: extract – transform – load – di dati dalle fonti originarie al data warehouse. Una volta che i dati sono nel date lake essi diventano disponibili per l’analisi per ogni attore all’interno dell’azienda.

Sintetizziamo ora in cinque punti le fondamentali caratteristiche, capacità, di un data lake:

1) Deve essere dotato di una struttura di indici centralizzata, che copra dati e metadati, comprese informazioni su fonti, versioning, veridicità e livello di accuratezza

2) Deve garantire l’accesso in forma sicura a sottoinsiemi di dati, comprendendo funzionalità di auditing.

3) Deve abilitare i propri amministrare a una governance IT del dato contenuto del data lake con l’utilizzo di politiche di conservazione e di cancellazione del dato stesso.

4) Deve garantire la protezione dei dati includendo gli stringenti requisiti di business continuity e di disaster recovery.

5) Deve fornire possibilità di svolgere analisi sui dati e relativi flussi utilizzando più metodi di approccio analitici (cioè non solo il paradigma, metodo, principale: Hadoop).

Attualmente – secondo Gartner – quando si parla di data lake, i manager IT che gestiscono le informazioni hanno ancora le idee confuse su come ottimizzare le strategie aziendali sul tema e lo scenario è ulteriormente complicato dal fatto che differenti vendor stanno inglobando i data lake – o, meglio, i propri prodotti per trattarli – come componente fondamentale delle strategie Big Data. E verso una civiltà legata ai Big Data, volenti o nolenti, sembra che ci si stia andando a gran velocità.

Ma manca ancora uniformità tra i diversi fornitori su che cosa esattamente un data lake, e i dettagli sappiamo che sono ciò che fa la differenza, e come estrarne valore. Mentre i vendor – tirando acqua al mulino del proprio prodotto – sostengono che tutti gli utenti dell’azienda trarranno vantaggio dai propri data lake, Gartner mette in guardia su questo punto fondamentale: non è scontato che tutti abbiano le competenze per la manipolazione e analisi dei dati. Inoltre, i data lake si concentrano sullo strato della conservazione di dati da fonti disparate e non su come o perché i dati sono definiti, utilizzati, governati, protetti.

Comunque, l’azione di unire dati nel lake, anche senza una gestione e governance mature, è un primo modo per risolvere il problema dei silos isolati, tagliando pure i costi ed aumentando, almeno in teoria, utilizzo e condivisione del dato.

Il paradigma dei data lake viene incontro alle tematiche tecnologiche legate ai temi dei Big Data, che richiedono grandi quantità di informazioni di differente provenienza e, quindi, almeno nel breve periodo i data lake dovrebbero rivelarsi un beneficio per l’IT.

ll tema caldo, quello di estrarre valore dai dati resta compito dell’utente dedicato a tale task. Probabile campo di azione per un data scientist. È necessaria una governance dell’informazione oppure i data lake finiranno – in breve – nel trasformarsi in una raccolta di dati sconnessi oppure aggregatori di silos.

Quali sono i rischi associati ai data lake? Il principale è l’impossibilità di determinare la qualità del dato presente (poiché, per definizione, un data lake deve accettare qualunque dato che vi si voglia inserire) o di risalire a precedenti analisi su uno stesso dato. Altri rischi secondari sono legati al controllo degli accessi e alle performance. Ma questo passa in secondo piano quando osserviamo che un data lake presuppone che l’utente fruitore dell’informazione capisca il contesto in cui il dato è stato generato e che sappia come unire e riconciliare dati tra differenti fonti. Come sempre, a strumenti evoluti vanno associate capacita evolute.

Probabilmente questi pre-requisiti all’uso sono soddisfatti per figure che si occupano professionalmente di trattamento dati come i data scientist, ma non lo si può dare per scontato per tutti i consultatori del dato.

Assistere gli utenti per garantire una corretta fruizione del dato diventerà una operazione standard? Essa avrà un costo e tale costo andrà messo nel calcolo di valutazione della convenienza o meno alla creazione ed uso di un data lake. Le piattaforme di trattamento del dato – e non tutte sono di alto livello – senza competenze per usarle sono inutili e, a loro volta secondo me, senza competenze i data lake non sono altro che evoluzioni di silos senza nuovo significato e valore aggiunto.

L’esigenza di archiviare, proteggere, mettere in sicurezza, amministrare, gestire, analizzare e mostrare i dati – strutturati o meno, tabellari o in nuovi formati più esotici, con prestazioni sempre più impressionanti se confrontate con le moli trattate – continua ad affascinarmi oggi come ieri e probabilmente anche domani.