Menu

Dai Big Data Lake alle Big Data Fabric

Nel concetto di Data Fabric si riassumono l'architettura, le componenti e i servizi - Cloud e On-Premise - necessari a conservare, gestire, analizzare i Big Data. Un netto superamento dei Data Warehouse dai quali prendono le mosse e dei Data Lake che affrontano solo un aspetto del problema.

Di Big Data ho cominciato a scrivere, a usarli, a parlarne in seminari e conferenze ormai una decina di anni fa. Se ancora oggi per alcuni rappresentato un mistero, un tema da affrontare nel futuro, nella gran parte delle aziende di maggior successo sono oggi la norma, un tassello fondamentale sul quale costruire la propria competitività e la generazione di valore aggiunto. Il punto, quindi, non è più valutare se adottarli, ma semmai come farlo in modo efficiente superando i limiti dei primi modelli dai quali si è partiti e, per chi lo avesse già fatto, aggiornare le proprie soluzioni e le proprie architetture IT.

Due punti per chiarire alcuni concetti fondamentali per apprezzare l'attuale evoluzione delle architetture utilizzate in abbinamento ai Big Data:

  1. I Big Data non sono sinonimi di grandi quantità di dati, bensì afferiscono a insiemi di dati strutturati e non - dalle tabelle relazionali alle immagini, dai testi ai filmati - da elaborarsi in modo integrato e in unità di tempo irraggiugnibli usando i tradizionali Data Base o Data Warehouse, indipendentemente dagli strumenti o dalla potenza impiegata.
  2. Se per molti il "motore" di riferimento per elaborare i Big Data è Hadoop, in realtà questo è solo un tassello dell'insieme dovendo infatti acquisire i dati, memorizzarli, gestirne la qualità, oltre che analizzarli e svilupparne tendenze, significati, correlazioni intellegibili a occhio, indicazioni da distribuire su larga scala e in diversi formati, spesso operando persino in tempo reale. Cosa che richiede consistenti incrementi nella potenza di calcolo, nella capacità di storage, oltre che la disponibilità di sofisticati strumenti di analisi (Analytics), di reporting, di controllo e protezione.

Espresso in altre parole,i Big Data stanno segnando la fine della Business Intelligence, della gestione dei dati (data management) e dei più recenti Data Warehouse / Data Mart per come li abbiamo conosciuti e utilizzati nel passato: queste tecnologie non sono infatti in grado di competere con quelle germinate dalla gestione dei Big Data né per capacità di elaborazione, né per qualità dei risultati, segnando così una svolta dirompente per tutta la disciplina della gestione dati sulla quale si costruiscono le moderne "Data Driven Company". Non per nulla, le figure dei Database Administrator - essenzialmente tecniche - sono oggi definitivamente soppiantate dai Data Scientist che alle sofisticate competenze di matematica e statistica, combinate con quelle informatiche, aggiungono le capacità di analisi dei dati in chiave di Business, sviluppando nuovi modelli di comprensione dei fenomeni desumibili dai dati stessi.

A questo proposito, sorgono anche nuovi problemi connessi alla dipendenza dell'azienda dai suoi dati che come fonti non hanno unicamente l'azienda stessa, ma possono provenire dall'intera rete Internet - tipo i canali Social o i siti Web - o dai sensori dell'IoT - Internet of things - posti su apparati, prodotti o anche distribuiti strategicamente nell'ambiente. Il primo problema consiste nel gestire flussi che possono assumere dimensioni davvero rilevanti, il secondo sta nella protezione di tali dati che divengono patrimonio cruciale dell'azienda e in quanto tale risultano molto appetibili da parte dei concorrenti o di altre organizzazioni con implicazioni dirette - anche molto onerose - sul piano legale. Basti pensare al recente caso di Facebook/Cambridge Analytica con i danni economici e di immagine patiti dalle due organizzazioni che vi sono implicate e la conseguente chiusura della compagnia inglese.

Data Warehouse come unica fonte integrata della verità e basi per l'analisi dei dati

Senza voler ripercorrere la storia dei sistemi di gestione dati, dai primi file system, ai Database gerarchici, a quelli relazionali, ai reticolari, nati essenzialmente per eseguire transazioni e aggiornamenti, nel corso degli anni 70, con l'intento di torvare una soluzione più orientata all'analisi dei dati che all'esecuzione di operazioni su di essi, William H. (Bill) Inmon coniò il termine Data Warehouse (DW) definendolo come una piattaforma sulla quale far confluire dati da esaminare, integrandoli tra loro, dopo averli opportunamente resi omogenei e averli arricchiti di metadati che ne incrementassero il significato.

Il DW diventa così il punto di riferimento dei sistemi di supporto alle decisioni, sul quale operare con gli strumenti di Business Intelligence, Data Mining e via dicendo. Il primo volume nel quale Bill codificava l'architettura e la realizzazione dei DW apparve nel 1992 con il titolo Building the Data Warehouse.

In pratica, nel realizzare un DW si passa dalle fasi di acquisizione dei dati, di trasformazione e di distribuzione a chi li esaminerà con gli strumenti di analisi per trarne le proprie conclusioni e decisioni. Per questo, i dati che confluiscono nel DW provenienti dalle diverse fonti - essenzialmente interne all'azienda - dovranno essere integrati, finalizzati ad uno scopo - abbandonando i concetti di normalizzazione e riduzione delle ridondanze in favore della chiarezza e della facilità di comprensione - aggiornati con regolarità in relazione alle esigenze di analisi e corredati di informazioni aggiuntive per realizzare, ad esempio, serie storiche o nuove correlazioni tra fenomeni di natura diversa. Ma soprattutto, il DW doveva rappresentare l'unica fonte di riferimento per le analisi dei dati di tutta l'azienda, cosa nella quale non sempre è riuscito a causa della nascita dei Data Mart - piccoli DW specializzati per dominii o contesti specifici - e per la proliferazione di diversi DW distribuiti all'interno di vari dipartimenti delle aziende.

Nel tempo, Bill Inmon ha rivisto e aggiornato il suo modello iniziale, introducendo ad esempio il concetto di Data Dictionary, sebbene alcuni vincoli di tipo strutturale ne abbiano evidenziato i limiti. Il primo sta nella esigenza di dover aggiornare i dati in modo asincrono rispetto alla loro evoluzione, rendendo impossibile prendere decisioni in tempo reale. Il secondo è imputabile al proliferare delle fonti - non più riconducibili unicamente ai dati aziendali - sulle quali effettuare trasformazioni e integrazioni diventa piuttosto ostico, se non impossibile. Il terzo nelle tecnologie impiegate che a fronte di grandi moli di dati non sono più in grado di dare risposte in tempi ragionevoli.

In sostanza, pur mantenendo la sua assoluta validità, con l'emergere dei Big Data, il DW viene progressivamente soppiantato da altre soluzioni più performanti sia in termini tecnologici, sia sul piano operativo.

I Data Lake per la racolta di tutti i fiumi di Big Data

Il primo passo nel superamento del tradizionale concetto di Data Warehouse va attribuito a James Dixon, all'epoca Direttore Tecnico di Pentaho, che nel 2010 coniò il termine di Data Lake con l'obiettivo di creare un'unica fonte per tutti i dati interessanti per l'azienda, facendovi confluire quelli conservati nei vari Data Mart e nei Data Warehouse germinati nel tempo creando dei silos di dati difficilmente integrabili e analizzabili.

Data Warehouse vs Data LakeLa differenza principale rispetto ai classici Data Warehouse sta nel metodo di conservazione dei dati: invece di estrarre, trasformare e caricare i dati (ETL: Extract, Transform, Load), nel Data Lake i dati vengono Estratti, Caricati e conservati nel loro formato originale - qualunque esso sia, strutturato o no - per poi essere trasformati solo nel momento del loro utilizzo e nelle modalità richieste dalle circostanze (ELT). Questo vuol dire che tutti i dati dovranno confluire in uno stesso lago, mantenendo i propri formati: file non strutturati (e-Mail, documenti, PDF), binari (immagini, video, suoni), tabelle di righe e colonne o semi strutturati (CSV, log, XML, JSON). Un contesto nel quale Hadoop mostra tutta la sua forza e flessibilità specie andando oltre il modello iniziale basato sull'elaborazione batch propria di Map Reduce.

Via via che sono acquisiti, i dati vengono completati da un identificatore e dei dai metadati che li caratterizzano così che quando saranno utilizzati saranno in grado di fornire le informazoni qualificanti per chi li sta analizzando. In altre parole, sarà l'interrogazione che viene fatta a determinare la selezione dei dati significativi utilizzando tutti i dati disponibili indipendentemente dalle fonti di provenienza. In tal modo, evitando le duplicazioni, si riducono le necessità di spazi di archiviazione, potendo inoltre conservare i dati su file system distribuiti (HDFS in cloud), se ne abbreviano i tempi di elaborazione, ma soprattutto si dispone di un'unica bocca della verità scongiurando ogni rischio di incoerenza tra dati provenienti da strade diverse.

Il grande vantaggio dei Data Lake rispetto ai Data Warehouse è che consentono di conservare enormi quantità di dati senza doverli strutturare in fase di acquisizione, ma occorre regolarne gli accessi sia per il rispetto delle normative della privacy, sia per tutelarne il valore per l'impresa.Architettura Data Lake

In analogia alle prime generazioni di Data Warehouse, che venivano analizzati attraverso sofisticati strumenti di Business Intelligence che per difficoltà d'uso non risultavano alla portata di chiunque, i Data Lake vengono normalmente interrogati attraverso gli Analytics e altri strumenti ancor più complessi richiedendo l'intervento di Data Scientist molto ben preparati sulla materia. Non per nulla, nell'impiego di un Data Lake si devono affrontare quattro fasi distinte che richiedono competenze che non si improvvisano facilmente:

  1. Data Ingestion e Storage per acquisire i dati, in funzione delle circostanze, sia in tempo reale che in batch;
  2. Data Processing, che corrisponde alla fase di elaborazione dei dati in modo che risultino successivamente analizzabili;
  3. Data Integration, collegando i flussi di tutte le fonti dei dati scelte, siano essi applicativi propri o di altri, Social Media, pagine Web e altre ancora per generare le informazioni e le correlazioni utile a soddisfare le analisi da svolgere.
  4. Data Analysis che partendo dalla creazione di modelli idonei a fornire le risposte alle questioni aperte, cosa che deve essere fatta a monte del processo per determinare tutte le attività successive, arriva a generare le interrogazioni che servono a dare risposte corrette alle questioni poste utilizzando varie tecniche matematiche, statistice, di intelligenza artificiale e via dicendo.

Al di là delle difficoltà di allestimento e uso, i Data Lake presentano alcuni limiti strutturali per i quali è nato il nuovo concetto di Data Fabric. Il primo sta nell'oggettiva impossibilità di valutare la qualità dei dati dal momento che per la loro stessa impostazione, i Data Lake sono vocati ad accogliere al loro interno tutti i dati che vi arrivano. Il secondo è che sono privi di strutture di gestione della vita dei dati stessi, così come di meccanismi di progezione e controllo degli accessi.

Le Big Data Fabric come superamento dei confini dei Data Lake

A causa della mancanza di meccanismi di automazione, per la gestione della sicurezza e di governance, i Data Lake, intesi come depositi senza confini di dati in qualsiasi formato conservati nella loro forma originale in HDFS e trasformati in base alle necessità al momento del loro uso, per Gartner "Entro la fine del 2018, il 90% dei Data Lake in uso perderanno di valore in quanto poco utili alle imprese che li hanno creati e saranno abbandonati.” Questo anche perché mentre nelle intenzioni iniziali nei Data Lake dovevano confluire tutti i dati dell'impresa per essere gestiti centralmente attraverso Hadoop, nella realtà i silos di dati conservati in altri ambienti hanno continuato a moltiplicarsi spaziando dai Data Warehouse gestiti tramite motori Teradata o Vertica, così come da altre piattaforme tipo Spark o altri Database NoSQL.

In risposta a queste problematiche, come evoluzione del precedente concetto di “information fabric” presentato nel 2013, Noel Yuhanna, analista di Forrester, nel marzo del 2016 ha lanciato il concetto di “Big Data Fabric” strutturandone l'architettura in 6 livelli: Data Ingestion, Processing & Persistence, Orchestration, Data Discovery, Data Management & intelligence e Data Access. Working together, these layers provide seamless, real-time integration of the data in a Big Data system, regardless of data silos.

Le Big Data Fabric apportano ai precedenti Data Lake gli elementi che gli mancavano e che ne hanno segnato il destino tra i quali maggiore coerenza nella organizzazione e nella gestione dei dati, alcune funzioni automatizzate o automatizzabili e vari strumenti di controllo della sicurezza, degli accessi, delle prestazioni indispensabili per porre Hadoop veramente al servizio dei Big Data delle imprese.

Stando allo stesso Yuhanna, "Con le Big Data Fabric si possono gestire infinite quantità di dati strutturati e non, così come con i Data Lake, ma non vengono più posti limiti a livello di piattaforme di gestione, spaziando così da Apache Hadoop, alle Enterprise Data Warehouse MPP, ai motori NoSQL e Apache Spark, alle tecnologie in-memory e alle soluzioni commerciali ed Open Source concepite per la gestione di Big Data. I dati possono inoltre risiedere all'interno dello Storage aziendale, ma anche in ambienti Cloud, utilizzabili anche per le elaborazioni e le analisi."

Da qui si è avuta una progressiva revisione dei prodotti, delle soluzioni e delle proposte di tutti i fornitori sul mercato, alcuni dei quali hanno puntato a fornire delle Suite complete, mentre altri si sono specializzati sono in alcune componenti della nuova architettura, avendo cura di essere in grado di integrarsi con le altre.

In sostanza, in cosa consiste un Big Data Fabric?

Come sempre accade, alla comparsa di una nuova etichetta, i vari fornitori cercano di appropriarsene finalizzandola alla vendita dei propri prodotti e servizi. Ad esempio, per NetApp i Big Data Fabric si incentrano sullo Storage - installato presso le aziende o in Cloud - sul quale vanno registrati tutti i dati da analizzare fornendo gli strumenti per accederli, salvaguardarli, collegarli alle rispettive fonti dalle quali prelevarli sistematicamente. Per Talend, che fornisce essenzialmente piattaforme software realizzate combinando vari componenti Open Source e non, lo Storage passa in secondo piano, superato dagli strumenti di sviluppo delle soluzioni e di integrazione della piattaforma con le applicazioni e le fonti dalle quali estrarre i dati operando batch, in streaming e anche in tempo reale. Entrambi aspetti e punti di vista importanti, che tuttavia non corrispondono a quanto Yuhanna aveva tratteggiato nella sua proiezione tecnologica, riassumibile in queste funzioni/capacità di base:

  1. Combinare dati provenienti da sistemi, applicazioni, fonti eterogenee - tipo i sensori degli apparati IoT, i siti Web, i canali Social - in un unico ambiente integrato;
  2. Garantire le prestazioni in termini di velocità, capacità, scalabilità, affidabilità indispensabili a soddisfare le esigenze delle applicazioni di classe Enterprise;
  3. Supportare ambienti distribuiti anche su larga scala, spaziando dai Data Center delle imprese ai fornitori di servizi Cloud attraverso qualsiasi tipo di connessione in rete;
  4. Consentire l'accesso ai dati per l'alimentazione, l'elaborazione e le interrogazioni da qualsiasi postazione connessa in rete fisica o wireless;
  5. Creare un ambiente unico - non necessariamente integrato - che può essere visto, gestito e acceduto come un unico sistema, sia pure percepibile in modo personalizzato da chiunque vi si rivolga;
  6. Supportare le ridondanza per assicurare elevati livelli di affidabilità e disponibilità.

Da questi punti può derivare la necessità di definire nuovi standard per rendere perfettamente interoperabili tra loro i sistemi basati su diversi sistemi operativi - tipo Android, iOS, Windows, Linux, UNIX - gli ambienti Web e le architetture proprietarie attualmente in uso nei grandi e piccoli Data Center e lo storage in cloud o installato nelle aziende. Una definizione nella quale non si fa riferimento esplicito ad alcuna piattaforma - cloud o on premise - ad alcun motore di gestione dei dati - Hadoop/MapReduce o altri - e via dicendo, sottolineando per contro alcuni aspetti trascurati nelle architetture precedenti tipo le prestazioni o la sicurezza dei sistemi stessi.

Una prospettiva che assicura un futuro importante alla gestione delle soluzioni basate sulla elaborazione dei Big Data che volendo possono essere attivate anche rapidamente - usando tutti servizi cloud - ma che nel tempo rischiano di generare una nuova ondata di silos di informazioni non più analizzabili in modo unitario ed integrato esattamente come accaduto nel recente passato con i Data Warehouse e i Data Mart.

BigData Fabric ArchitetturaEntrando ancor più nel merito, lo studio di Forrester individuava sei livelli sui quali occorre operare per allestire un valido Data Fabric:

  • Data Ingestion: il primo livello della architettura dei Big Data Fabric che oltre a garantire la possibilità di acquisire dati strutturati e non da qualsiasi genere di fonte - database, applicazioni, device, sensori, log, siti web ecc. ecc. - deve permetterne un efficace controllo della qualità, prestazioni coerenti con le esigenze delle analisi e capacità adeguate al contesto nel quale si intende operare.
  • Processing & Persistence: una volta acquisiti, nel secondo livello i dati dovranno essere elaborati conservati in modo sicuro usando motori quali Hadoop, Spark o qualsiasi altra soluzioni appaia sul mercato per ambienti interni alle aziende o di tipo cloud.
  • Orchestration: nella fase di orchestrazione si entra nel merito di come questi dati dovranno essere utilizzati, facendone emergere le tipologie di selezione, trasformazione, uniformazione, integrazione per rispondere alle specifiche interrogazioni e analisi vi verranno fatte.
  • Data Discovery: questo è il livello più critico di tutta l'architettura in quanto da esso dipende il superamento dei famigerati silos di dati. In the data discovery layer, companies employ data modeling, data preparation, data curation, and data virtualization. Data virtualization is critical, as it creates virtual views of the data that can be accessed by consumers in real-time. This means that analysts can query across two “silos” as if they were part of the same dataset.
  • Data Management & Intelligence: come cappello degli strati precedenti abbiamo qullo che si occupa della sicurezza e del governo dei dati. A questo livello si opera anche nella gestione dei metadati, nelle funzioni di search e di coerenza dei dati stessi nel loro insieme.
  • Data Access: alla base di tutto troviamo invece le funzioni per l'accesso ai dati da parte degli analisti, delle applicazioni e degli strumenti utilizzati per trarne significati e indicazioni.

Una soluzione verso la quale si sta orientando tutta la attuale offerta tecnologica, con nuovi e vecchi attori del mercato che si presentano estremamente agguerriti in una competizione che già mostra di avere un enorme potenziale di sviluppo.

Ultima modifica ilDomenica, 01 Luglio 2018 10:02

Aggiungi commento


Codice di sicurezza
Aggiorna

Torna in alto

I cookie rendono più facile per noi fornirti i nostri servizi. Con l'utilizzo dei nostri servizi ci autorizzi a utilizzare i cookie.
Maggiori informazioni Ok