Per elaborare grandi ammontari di dati, le aziende devono dotarsi di architetture adeguate e delle skill necessarie per la loro gestione.
Big Data – un po’ di chiarezza
Prima di addentrarci nello specifico tema delle BDA, ovvero delle Big Data Architecture, le architetture informatiche e tecnologiche atte a gestire i Big Data, occorre chiarire alcuni punti.
Erroneamente spesso si classifica come Big Data soltanto una mole di dati che ha la qualità della vastità ovvero del volume, afferendo tipicamente alla locuzione letterale di “big” come “grande ammontare di dati”.
Questa pseudo-definizione però è errata e non ritorna realmente gli elementi di complessità che occorre considerare nella gestione di questa tipologia di dati e nella loro archiviazione.
Big Data, una definizione
Una valida definizione di Big Data ci viene offerta dal paradigma delle 3V (che qui vedremo per maggiore esaustività nella sua versione estesa delle 5V). Il vantaggio di questa definizione è che è pragmaticamente descrittiva delle qualità del dato sottostante l’insieme dei Big Data e anche semplice da ricordare.
Volume: non ci può essere “Big Data” senza l’elemento big, questo è indubbio. Parlando di dimensioni di dati, si fa riferimento tipicamente al volume, quindi allo spazio che l’insieme di dati occupano dal punto di vista dello storage. Ma quanto grande deve essere per essere “big” l’elemento volume? Se fino ai primi anni duemila 1 GB (10^9) era considerato un ammontare rilevante, oggi certamente ragioniamo in ordini di grandezza definiti in terabytes (10^12), petabytes (10^15) o addirittura exabytes (10^18).
Velocity: si stima che nel 2025 l’ammontare di dati generati a livello globale su base annua supererà i 400 exabyte. Oggi ciascun essere umano genera circa 1.7 MB al secondo. Impressionante.
La velocità relativa ai Big Data sottostà proprio a tale parametro: la frequenza con la quale i dati sono generati dalle diversi sorgenti e pertanto si vada a ripercuotere nell’intero data lifecycle: generazione, ricezione, pulizia, stoccaggio, analisi, utilizzo, repeat.
Variety: lo dice la parola stessa, elemento caratterizzante dei Big Data è la varietà. Un grande flow di dati meteo in tempo reale difficilmente verrebbe definito Big Data. Ma i dati meteo in tempo reale, con il numero di persone transitanti un varco in un parco turistico, magari associati agli hashtag generati sui social media per una determinata attrazione, ecco che abbiamo un caso d’uso reale e concreto che tiene in considerazione dati con grande varietà, sia in termini di elementi generanti, che di unità di misura, frequenza, e tipologia di dato stesso.
Variability: le cose si fanno sempre più complesse. Si, perchè lo stream di Big Data tipicamente è volatile, non segue un pattern piatto ma piuttosto un andamento tormentato fatto di picchi e valli. Questo lo vediamo ogni giorno nei media, quando un determinato argomento, diverso su base giornaliera per non dire oraria, schizza in alto e diventa il tema del giorno. Se pensiamo al mondo dell’energia possiamo naturalmente pensare ai momenti di picco, stagionalità, fenomeni avversi quali blackout, onde di gelo o di calore, etc.
Value: last but not least, i dati afferenti l’insieme dei Big Data hanno un valore. Si, gestire queste quantità di dati, sia dal punto di vista della data collection che della data cleaning e data storage richiede importanti investimenti e costi di personale e infrastrutture dedicate. Pertanto occorre assicurarsi che tale insieme di raccolta sia in grado davvero di generare valore per le nostre finalità di business o ricerca, e non si stiano raccogliendo dati sostanzialmente privi di senso.
Possiamo quindi affermare che i Big Data siano tipologie di dati aventi caratteristiche importanti di volume occupato, velocità di generazione, varietà di forma, tipologia e specificità, variabilità, e aventi valore per un utilizzo specifico di business, ricerca e altro.
Big Data Architecture: cos’è?
Le strutture dati tradizionali sono ritenute ormai superate per la gestione di strutture dati complesse, variabili e di grandi dimensioni. Questa evoluzione ha forzosamente portato alla ricerca di elementi più idonei, efficienti e gestibili.
Tali elementi, riuniti in un insieme, danno luogo alla Big Data Architecture.
La definizione di Big Data Architecture
Per Big Data Architecture si intende l’insieme degli strumenti e delle tecnologie utilizzate per gestire i Big Data.
La BDA serve come schema di riferimento per le infrastrutture e le soluzioni in esso operanti, definendone quindi i componenti, il flusso delle informazioni, i flussi logici degli operatori e i dettagli su accessi, sicurezza, uso, archiviazione.
I componenti dell’architettura di Big Data sono generalmente costituiti da diversi livelli logici, talvolta operanti per macro componenti, talvolta con livelli di dettaglio più specifici. Qui ne offriamo uno spaccato con un grado di dettaglio sufficientemente elevato.
I componenti della BDA
L’architettura Big Data si può suddividere in diversi elementi, afferenti ai singoli step del ciclo di vita del dato.
Source Layer: qui vengono enumerate le sorgenti che possono fornire dati all’architettura. Tipicamente si parla di proprietà web, device IoT, social media, applicazioni SaaS, ma anche dati derivanti da transazioni e pagamenti, transiti in negozi, varchi o comunque entità fisiche di ogni tipo, dati meteo, dati di produzione di macchinari, etc.
Storage Layer: è il livello che si occupa degli elementi architetturali deputati allo stoccaggio del dato.
A sua volta può essere ulteriormente classificato in:
- Data Collector Layer: gestisce la connessione tra le sorgenti e la BDA.
- Data Ingestione Layer: esegue una classificazione della tipologia di dati, e si assicura dell’assenza di errori formali o dati invalidi che potrebbero inquinare, alterare o addirittura rendere insicuro il processo.
- Data Storage Layer: le applicazioni che fisicamente sono deputate allo stoccaggio del dato nei diversi formati, tipologie di database.
Processing Layer: è il livello architetturale che si occupa di processare il dato e quindi renderlo fruibile per il suo utilizzo.
A sua volta può essere ulteriormente classificato in:
- Data Processing Layer: dove vengono eseguite operazioni batch e automatismi per classificare il dato secondo le sue caratteristiche.
- Data Query Layer: il dato viene ordinato ulteriormente secondo analogie tipiche dei dati stessi e quindi estraibili mediante appunto interrogazioni sul database.
Consumption Layer: il livello di maggior impatto per l’utente finale del dato, ossia dove il valore viene estratto dai dati fin qui raccolti.
A sua volta può essere ulteriormente classificato in:
- Data Analysis Layer: il livello architetturale dove vengono posti in evidenza elementi significativi a livello analitico, statistico e di pattern sul dato.
- Data Visualization Layer: il livello dove i dati vengono aggregati in modo da poter essere rappresentati graficamente su dashboard, reportistica, elementi di visualizzazione dinamici, siti web e altro.
Administration Layer: il livello che racchiude gli elementi di sicurezza e performance della Big Data Architecture.
Si suddivide in:
- Data Security Layer: il livello di gestione della sicurezza dell’architettura e del dato al suo interno.
- Data Monitoring Layer: il livello relativo alla gestione delle performance, utilizzo efficace e efficiente delle risorse, casi d’uso e allocazioni.
La sfida insita nella creazione di architetture Big Data
Gli specialisti si trovano di fronte a molteplici sfide quando progettano e implementano la loro architettura di Big Data e gestiscono tutta l’infrastruttura di supporto.
- Componenti: l’architettura Big Data è composta di diversi singoli strumenti, rispondenti sia a requisiti di sistema, che operativi, tecnologici, e insiti nella natura stessa del business. Senza contare l’avanzamento costante della tecnologia, che richiede quindi uno sforzo notevole di aggiornamento, e i costi sottesi, che potrebbero rendere alcune componenti fuori budget.
- Integrazione: nel diagramma architetturale gli elementi sono tra loro strettamente interconnessi, integrati e collegati. Inoltre la BDA potrebbe dover dialogare con i sistemi aziendali pregressi o con sorgenti dati atipiche – pensiamo all’immensa mole di dati generata da device IoT o dai social media.
- Iter di produzione: l’architettura una volta in produzione deve essere in grado di rispondere allo stress insito nel flusso operativo di data collection, processing e utilizzo: tempistiche di aggiornamento, volumi dei dati, numero di utenti, dipendenze. Un grande numero di fattori deve essere costantemente analizzato e gestito, anche proattivamente.
- Sicurezza: assicurare sia la sicurezza intrinseca del dato, ossia rendere l’architettura protetta da attacchi informatici di vario tipo, nonché da errori causati da usi errati della tecnologia posti in buona fede dagli utenti, ma anche sicurezza dal punto di vista normativo e regolatorio, ad esempio quanto previsto dalla normativa GDPR.
- Correttezza del dato: il fine ultimo della BDA come già osservato è generare valore per gli utenti finali; pertanto la fiducia nel dato deve essere totale e completa, non possono esistere dubbi sulla sua correttezza.
- Efficienza e cost-controlling: la BDA non è un’architettura statica, ma piuttosto un insieme di elementi in continua evoluzione, un sistema dinamico e in movimento. Pertanto occorre gestire costantemente il costo associato a tale struttura costantemente, e apportare le dovute modifiche dove e quando necessario.
Best Practices per la creazione di Big Data Architecture
Giunti a questo punto comprendiamo quindi che la BDA possa essere un asset differenziante per l’estrazione di valore dai dati, ma d’altra parte non sia ottenibile gratuitamente. Anzi, i rischi insiti in falle architetturali sono molteplici, in termini di sicurezza, efficienza, costi e usabilità.
Quali sono quindi gli step o, meglio, le best practice del settore che è bene considerare prima di avventurarsi concretamente nella realizzazione di questa architettura?
Fase di Pre-analisi
Per prima cosa occorre comprendere l’intero ciclo di vita del dato, quindi dalla sua genesi (tipologia, frequenza, dimensione, etc.) sia nel suo utilizzo. Supponiamo per semplicità che venga usato all’interno dell’azienda (sebbene il concetto di BDA sia proprio anche di ambienti accademici, di ricerca, fini statistici di enti pubblici, e quindi non strettamente legato al concetto di business aziendale).
Quali sono quindi i fattori chiave dell’organizzazione? Quali saranno le risorse che utilizzeranno tale architettura? Possiamo mappare puntualmente le sorgenti dati e tracciarne il flusso logico di massima fino all’esaurimento della loro funzione?
Queste attività sono propedeutiche alla realizzazione di una Big Data Architecture funzionale e priva di ridondanze.
Analisi e definizione dei processi insistenti sul dato
Lo step immediatamente successivo riguarda la definizione delle azioni eseguibili sul dato stesso, percorso che viene comunemente indicato come Big Data ELT.
ELT sta per Extract-Load-Transform, ossia il processo di raccolta dei dati da un numero illimitato di sorgenti e della loro successiva organizzazione e centralizzazione in un unico repository, dopo gli eventuali processi di pulizia, ingegnerizzazione e classificazione del dato. Questo permette di accumulare i dati in forma grezza, lasciando la definizione della trasformazione al loro consumatore finale.
Analisi delle modalità di interrogazione
L’architettura è tanto più funzionale tanto quanto più è immediato per gli utenti interfacciarsi con essa. Occorre quindi comprendere quali saranno gli strumenti usati per lavorare sul dato, come esso sarà visualizzato, distribuito, analizzato, scaricato, manipolato, da ciascuna delle entità aziendali.
Limitazione delle interdipendenze
Va evitata la creazione di un’architettura dove la sostituzione o aggiunta di un singolo elemento determini la necessità di rivederla interamente o, peggio, determini incidenti e malfunzionamenti. Occorre quindi assicurare una limitata se non nulla interdipendenza (decoupling) tra i singoli elementi architetturali.
Gestione di accessi e sicurezza
La sicurezza oggi svolge un ruolo chiave nella gestione delle grandi architetture di dati. Pertanto è necessario dotarsi di strumenti tecnologici adeguati, di processi e procedure inerenti la sicurezza informatica, e maturare e condividere la giusta cultura aziendale affinché vi sia responsabilizzazione dei soggetti agenti sui dati. Come noto, la sicurezza di un’architettura è pari alla sicurezza del suo anello più debole.
Compliance e Data Governance
Occorre dotarsi di adeguati strumenti e processi di compliance, anche eventualmente rappresentati da figure specialistiche specifiche, e di data governance, in modo che non vi siano dubbi sui processi inerenti la gestione e fruizione del dato all’interno dell’azienda.
Rilevanza nel contesto di mercato attuale
Si prevede che le dimensioni del mercato dei Big Data e delle tecnologie satelliti ad esso relative passeranno da 162,6 miliardi di dollari nel 2021 a 273,4 miliardi di dollari nel 2026, con un tasso di crescita annuale dell’11%.
Le motivazioni risiedono principalmente nella:
- Maggior pervasività della tecnologia in ogni fase della vita del prodotto.
- Proliferazione di servizi basati su analisi puntuali del comportamento utenti per la creazione di esperienze personalizzate.
- Generale democratizzazione di strumenti tecnologici, device, sistemi di connettività atti alla generazione, circolazione e fruizione di Big Data.
- Evoluzione delle competenze relative al mondo informatico e della data science in generale.
- Aumento della percentuale di spesa dedicata dalle aziende ai processi IT.
Possiamo sicuramente affermare che la Big Data Architecture sarà la base sulla quale poggeranno le aziende del prossimo futuro, e che il suo corretto design e funzionamento sarà alla base dell’operatività di business stessa.
Il ruolo di Ark nel contesto Big Data
Ark da oltre dieci anni si occupa di fornire consulenza e supporto tecnologico in ambito Big Data, sia grazie al team di professionisti dedicato sia grazie a prodotti proprietari ideati appositamente per semplificare la raccolta e gestione di dati complessi, non strutturati e di difficile visualizzazione, come Artesian.
Contattaci per capire come possiamo esserti di supporto.
