Sezione divulgativa IT – 4 – Tra “Data Silos” e “Data Lakes”

Tra “Data Silos” e “Data Lakes”

Verso una maggiore integrità e fruibilità dei dati? Sì, ma con competenza.

 

Riprendiamo un tema che abbiamo iniziato a citare in un precedente post trattando ora i concetti di “Data Silos” e di “Data Lakes” iniziando 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 silos può essere o 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.

Entriamone in dettaglio.

Negli ambiti di business management ed information technology il concetto di silo è associato – in modo estensivo – a qualunque sistema che non è in grado di interagire con altri sistemi della stessa azienda, chiuso rispetto ad essi, creando quindi un ambiente, un sistema, 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 3 livelli architetturali: architettura tecnica, architettura della applicazione, architettura dei dati in sé.

E’ già stato dimostrato che le scelte alla base della modellazione dati sono la causa principale dei problemi di integrazione tra dati e, di conseguenza, la maggior parte dei sistemi di gestione dei dati sono incompatibili tra loro a partire dallo strato di basei, quello della architettura dei dati stessi.

Un silos di dati, di informazioni vediamolo, in sintesi, 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 ad una mentalità che consenta 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 di dati fissi: le rilevazioni atmosferiche del passato, i risultati di ricerche di mercato ora chiuse, dati di cartelle cliniche, dati finanziari di qualunque fonte ormai storici. 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.

Detto come breve inciso – per non spostare eccessivamente il focus dal dato – 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 e 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 ad ostacolare la produttività, come detto prima, ma sono passibili anche di avere un impatto negativo – e la cosa mi punge sul vivo – verso l’integrità dei dati.

Il motivo è evidente: quando sono presenti 2 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).

Sotto 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 ed 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.

Ad oggi, 2015, 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 datawarehouse.

Mentre “data warehouse gerarchico” di dati li organizza 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 5 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 ad 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.

Ma, mentre i vendor – tirando acqua al mulino del proprio prodotto – sostengono che tutti gli utenti dell’azienda trarranno vantaggio dai proprid ata 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 i 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.

Il tema caldo, quello di estrarre valore dai dati resta compito dell’utente dedicato a tale task. Probabile campo di azione per un Data Scientist.

E’ 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 capacità 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. 🙂

Daniele Vanoncini

Annunci
Questa voce è stata pubblicata in divulgazione IT, lavoro e contrassegnata con , , , , , , , , , . Contrassegna il permalink.

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...