Architettura Big Data: questo sconosciuto

Continuiamo con la serie di articoli che hanno al centro il tema dei Big Data in ottica di Digital Transformation. Dopo tanti articoli scritti nel mio blog, molti di voi mi chiedono un aggiornamento dell’architettura dei Big Data, visto che – come sappiamo – è in continuo movimento e risente della rapida evoluzione tecnologica in corso.

(1) INTRODUZIONE

Ma come si trasformano in informazioni di valore per il business? La risposta è nell’architettura e in questo bell’articolo che ho trovato in rete: mettiamoci nei panni di un Data Scientist  e di dover analizzare un insieme di dati la cui grandezza è maggiore del disco fisso del nostro computer: cosa facciamo? Non è così banale, potremmo sfruttare la potenza di linguaggi di programmazione come Python e R, ma rimarremmo comunque vincolati dalla potenza di calcolo e dallo spazio di archiviazione del nostro pc; potremmo rivolgerci al dipartimento IT chiedendo un computer più performante, ma rischieremmo di ritrovarci nella stessa situazione quando, tra alcuni mesi, dovremo analizzare una mole di dati ancora superiore.

E allora cosa fare?

Come dicevamo, la risposta è nell’architettura. Quello che ci serve è un’infrastruttura che ci permetta di immagazzinare ed analizzare i big data: un posto sicuro e durevole in cui salvare i nostri grandi file senza preoccuparci della loro dimensione attuale e futura e un computer sufficientemente potente per analizzarli.

Dove li troviamo questi spazi? Dove lo trovo un supercomputer? Compiere questa missione può sembrare impossibile, ma in realtà ad oggi piattaforme cloud come Amazon Web Services, Google Cloud Platform e Microsoft Azure (alcuni tra i tanti disponibili) permettono di farlo in maniera veloce ed efficiente. Tra i vari servizi, offrono spazi in cui salvare i nostri dati e dei server con cui elaborarli. Possiamo immaginare queste piattaforme come dei veri e propri “noleggi” di servizi a cui possiamo accedere direttamente dal nostro computer, pagando una tariffa.

Una volta scelti i servizi che calzano al meglio la tipologia del dato e l’analisi da svolgere, non ci resta che scrivere del codice che legga ed analizzi i nostri dati. Il linguaggio di programmazione è spesso a nostra discrezione (probabilmente saremo indecisi tra Python ed R). Una volta scritto ed eseguito il codice sul server non ci resterà che aspettare. Ma quanto tempo?

Anche se riuscissimo effettivamente ad analizzare tutto, i tempi potrebbero risultare davvero lunghi. Ma non solo: se per qualsiasi ragione il server sul quale stiamo lavorando dovesse cadere, perderemmo tutto quanto fatto fino ad ora.

La soluzione è il cluster

Eureka! Invece di utilizzare un solo server possiamo noleggiarne tanti per farli lavorare insieme. Ed è proprio così che da una singola macchina passiamo ad un cluster: un insieme di server collegati tra loro il cui scopo è quello di distribuire il lavoro tra tutti i partecipanti, velocizzando l’analisi.

Per distribuire il lavoro e sincronizzare tutti i server, possiamo fare uso di alcuni framework in grado di suddividere la mole dei dati da analizzare e quindi di ripartire lo sforzo. In questo senso, ci vengono in aiuto framework come Spark, in grado di offrire API in linguaggi come Python, R, Scala o Java.

Finalmente, è davvero arrivato il momento di aspettare i nostri risultati.

Vediamo ora una definizione di Big data e analytics

Con l’espressione Big Data ci si riferisce a insiemi di dati che sono così grandi in volume e così complessi che i software e le architetture informatiche tradizionali non sono in grado di catturarli, gestirli ed elaborarli in un tempo ragionevole.

Se un database tradizionale può gestire tabelle magari composte di milioni di righe, ma su decine o poche centinaia di colonne, i big data richiedono strumenti in grado di gestire lo stesso numero di record, ma con migliaia di colonne.

In più, spesso i dati non sono nemmeno disponibili in forma strutturata, facilmente incasellabile in righe e colonne appunto, ma sono presenti sotto forma di documenti, meta dati, posizioni geografiche, valori rilevati da sensori IoT e numerose altre forme, dal semi-strutturato al completamente destrutturato.

La quantità e la complessità che fanno sì che un insieme di dati si possa definire “Big Data” è un tema dibattuto. In molti prendono il petabyte (1.000 terabyte) come soglia, e diversi progetti operano nel campo degli exabyte (1.000 petabyte). Considerare solo le dimensioni della base di dati è però ritenuto da molti un errore che può essere fuorviante per le aziende che, pur non disponendo di archivi così vasti, possono trarre comunque un vantaggio dall’uso di tecnologie e approcci big data, per esempio per estrarre valore da dati non strutturati, o che devono essere elaborati in tempi velocissimi (approccio chiamato a volte “Little Data”).

Si tende quindi a definire i contorni di un progetto Big Data analizzandolo per tre diversi aspetti, a cui ci si riferisce come le “tre V dei Big Data”:

  1. Il Volume di dati
  2. La grande Varietà nei tipi di dati
  3. La Velocità con cui i dati devono essere acquisiti o analizzati

A cui se ne sono aggiunte ultimamente altre 2, ovvero Veracity (corrispondenza o meno alla verità) e Variability (suscettibilità del dato ad essere modificato)

I dati che compongono gli archivi Big Data possono provenire da fonti eterogenee, come dati di navigazione di siti web, social media, applicazioni desktop e mobile, esperimenti scientifici e – sempre più spesso – sensori e dispositivi di tipo Internet of Things.

Il concetto di Big Data porta con sé diversi elementi e componenti che permettono ad aziende e organizzazioni di sfruttare i dati per risolvere in modo pratico numerosi problemi di business. I diversi componenti da considerare sono:

(2) INFRASTRUTTURA

L’infrastruttura IT per i Big Data;

  • L’organizzazione e la struttura di archiviazione dei dati
  • Gli strumenti analitici per Big Data
  • Le competenze tecniche e matematiche
  • Non ultimo, un reale caso di business in cui i Big Data possano apportare valore

Un aspetto importante è che l’architettura di Big Data non ha senso che nasca e viva per contro proprio in azienda, ma integri e si affianchi a quella attuale. Nello specifico a fianco ai dati strutturati (DataWarehouse) in cui una azienda ha investito nelle ultime due decadi con l’obiettivo di ottenere un repository contenente i dati di sintesi aziendali “certificati” utili al Top Management per prendere decisioni di Business, si affianca oggi un sistema capace di gestire una grande mole di dati destrutturato (file di testo, IoT etc..) dovuto dall’evolversi tecnologico in maniera esponenziale degli ultimi anni e che generano per forza di cose una mole di dati molto più grande del passato.

Una azienda quindi deve saper affiancare ed integrare questi due aspetti in un’unica architecture landscape per poter fruire i dati in modo più completo e on-line:

Una architettura unificata può così contare sui seguenti componenti logici:

  1. Big Data Sources
  2. Data Massaging and Store Layer
  3. Analysis Layer
  4. Consumption Layer

Che deve tenere conto dei seguenti aspetti:

  1. Information Integration
  2. Big Data Governance: che svilupperemo in un articolo ad hoc
  3. Systems Management
  4. Quality of Service layer aspetto molto importante e spesso trascurato perché lasciato per ultimo (vedi mio articolo sul fallimento dei big data)

Affinché un progetto Big Data possa avere successo, le aziende hanno bisogno di dedicare a questo carico di lavoro un’infrastruttura adeguata e spesso molto specifica, in grado di raccogliere, archiviare ed elaborare i dati per presentarli in una forma utile. Il tutto garantendo la sicurezza delle informazioni mentre sono archiviate e in transito.

Al livello più alto, questo include sistemi di storage e server progettati per i Big dataframework software, database, tool, software di analytics e integrazioni tra i Big Data e altre applicazioni. Molto spesso, questa infrastruttura è presente on-premise, o comunque in forma di macchine hardware collocate in un data center remoto. Cloud e virtualizzazione, considerate a ragione due architetture IT pratiche ed efficienti, spesso non si rivelano la scelta migliore per trattare i Big Data, soprattutto per quanto riguarda la fase di elaborazione dei dati.

Tra le opzioni di archiviazione più usate in ambito Big Data troviamo i tradizionali data warehouse, i data lake (hvedi mio articolo) e il cloud storage.

  • Data warehouse: I tradizionali sistemi su cui le applicazioni aziendali registrano i propri dati, dall’ERP al CRM, possono ovviamente costituire una delle fonti da cui le applicazioni Big Data attingono le informazioni.
  • Data lake: I data lake sono repository di informazioni in grado di contenere volumi di dati estremamente grandi nel loro formato nativo, almeno fino al momento in cui è necessario effettuare elaborazioni e ricavare informazioni per le applicazioni di business. In quel caso, e solo a quel punto, i sistemi Big Data si occuperanno di estrarre da quei dati le informazioni via via richieste. La Internet of Things e le iniziative di trasformazione digitale, con la raccolta di informazioni dettagliate sui singoli clienti, stanno alimentando sempre più i data lake.
  • Cloud Storage per Big Data: Sempre più dati aziendali sono archiviati nel cloud, talvolta in modalità object-storage, ed è spesso necessario far confluire questi dati nelle applicazioni Big Data.

Inoltre, abbiamo bisogno di Tecnologie specifiche per Big Data, infatti oltre all’infrastruttura IT generica appena descritta, esistono alcune tecnologie specifiche che sono essenziali alla riuscita di qualsiasi progetto di Big Data.

L’ecosistema Hadoop

La libreria software Hadoop, un progetto open source della Apache Foundation, è un framework che permette la gestione di grandi set di dati, strutturati e non, e la loro elaborazione distribuita su cluster di computer usando modelli di programmazione molto semplici. È progettata per scalare da un singolo server fino a migliaia, ciascuno composto delle componenti di elaborazione e storage.

Il framework include diversi moduli:

  • Hadoop Common: Le utility di base che supportano altri moduli Hadoop
  • Hadoop Distributed File System: Fornisce accesso ad alta velocità ai dati, strutturati e non. Permette di “montare” qualsiasi fonte dati raggiungibile con un url.
  • Hadoop YARN: Un framework per la schedulazione dei job e la gestione delle risorse del cluster
  • Hadoop MapReduce: Un Sistema basato su YARN per l’elaborazione in parallelo di grandi data set

Apache Spark

Anch’esso parte dell’ecosistema Hadop, Apache Spark è un framework open source per le elaborazioni in cluster che serve come motore per la gestione di Big Data nel contesto di Hadoop. Spark è diventato uno dei principali framework di questo tipo e può essere utilizzato in molti modi diversi. Offre collegamenti nativi con diversi linguaggi di programmazione come Java, Scala, Python (specialmente la distribuzione Python Anaconda) e R, e supporta SQL, i dati streaming, il machine learning e l’elaborazione con database a grafo.

I database NoSQL

I database SQL tradizionali sono progettati per transazioni affidabili e per rispondere a query ad-hoc su dati ben strutturati. Questa rigidità rappresenta però un ostacolo per alcuni tipi di applicazioni. I database NoSQL superano questi ostacoli, memorizzando e gestendo i dati con modalità che permettono una grande flessibilità e velocità operativa. Diversamente dai database relazionali tradizionali, molti dei database NoSQL possono scalare in orizzontale su centinaia o migliaia di server.

Database In-memory

Un database in memoria (IMDB, da non confondere con l’Internet Movie Data Base) è un DBMS che utilizza principalmente la memoria RAM, e non l’hard disk, per archiviare i dati. Questo consente ovviamente una velocità di esecuzione molto maggiore, che rende possibili applicazioni di real time analytics su Big Data altrimenti impensabili.

(3)  LE COMPETENZE PER I BIG DATA

Le difficoltà tecniche, teoriche e pratiche per la progettazione e l’esecuzione di applicazioni di Big Data richiedono competenze specifiche, che non sempre sono presenti nei reparti IT delle aziende che si sono formati su tecnologie differenti da quelle odierne.

Molte di queste competenze sono relative gli specifici strumenti per i Big Data, come Hadoop, Spark, NoSQL, i database in-memory e i software analitici. Altre competenze sono invece relative a discipline come data science, statistica, data mining, analisi quantitativa, visualizzazione dei dati, programmazione in generale e per gli specifici linguaggi (Python, R, Scala), strutturazione dei dati e algoritmi.

Affinché un progetto Big Data abbia successo, occorrono anche competenze manageriali, in particolare per quanto riguarda la progettazione e pianificazione delle risorse e la gestione dei conti, che con la crescita del volume di dati rischiano di crescere senza controllo.

Al giorno d’oggi, molte delle figure che abbiamo indicato nelle righe precedenti sono tra le più richieste del mercato. Se avete una laurea in matematica o statistica ma vi mancano competenze informatiche, è il momento giusto per colmarle con corsi e formazione specifici per i Big Data. Ci sono enormi opportunità di lavoro.

(4)  CASI D’USO PER I BIG DATA

I Big Data si possono impiegare per risolvere numerosi  problemi di business, o per aprire nuove opportunità. Ecco alcuni esempi.

Customer analytics: Le aziende possono analizzare il comportamento dei consumatori in ottica di marketing multicanale per migliorare l’esperienza del cliente, aumentare i tassi di conversione, le vendite collaterali, offrire servizi e aumentare la fidelizzazione.

Analytics operazionale: Migliorare le prestazioni operative e fare un uso migliore degli asset aziendali sono l’obiettivo di molte organizzazioni. I Big Data posson aiutare le imprese a trovare nuovi modi per operare in modo più efficiente.

Prevenzione delle frodi e dei crimini: Aziende e governi possono individuare attività sospette attraverso il riconoscimento di pattern che possano indicare un comportamento fraudolento, prevenendone il manifestarsi o individuando il colpevole.

Ottimizzazione dei prezzi: Le aziende possono usare i dati per ottimizzare i prezzi applicati a prodotti e servizi, espandendo il proprio mercato o aumentando i ricavi.

(5)  SITUAZIONE ATTUALE

Big Data, ancora poco conosciuti, poco sfruttati (soprattutto nel settore FSI Banche e Assicurazioni) … e abbastanza temuti, dato che quale strategia bisogna adottare per non fallire? Una ricerca del Digital Transformation Institute e del CFMT rivela quanto ancora poco siano colte le opportunità offerte dai Big Data sia da parte degli utenti che delle aziende.

Fonte articolo di Francesco Destri (6 Mar 2019)

Big Data è un termine entrato ormai nel vocabolario comune ma, nonostante questo, sono ancora poche le persone che dichiarano di sapere con esattezza di cosa si stia parlando (15%), con un timido 28% che dichiara di averne sentito parlare ma che preferisce non sbilanciarsi sul significato. Alla richiesta di descrivere con parole proprie il termine Big Data, c’è chi lo associa alla personalizzazione di servizi e chi invece, un po’ preoccupato e dice che sia sinonimo di “affari nostri nelle mani degli altri”.

La ricerca Retail Transformation, realizzata dal Digital Transformation Institute e dal CFMT in collaborazione con SWG e Assintel, mette in evidenza anche alcune incongruenze dei consumatori rispetto ai Big Data. Se a fronte di un 70% di persone interessate ad avere una app che consenta di sapere, partendo dalla foto di un prodotto, qual è il negozio più vicino in cui poterlo acquistare, c’è un 52% di intervistati che si dichiara poco o per niente intenzionato a cedere i propri dati.

C’è insomma il desiderio di vedere personalizzato un servizio, ma c’è anche la preoccupazione rispetto alla cessione dei dati necessari a fornire informazioni mirate. Preoccupazione confermata anche dal 49% degli intervistati dichiaratisi, però, interessati ad avere una app in grado di creare un capo di vestiario o un servizio su misura in base alle informazioni sul proprio stile di vita raccolte tramite profilazione.

Altra contraddizione in termini quella che si registra a fronte della scelta tra privacy (e quindi mancata cessione di dati) e sconti, con il 50% degli intervistati (magari le stesse che usano servizi gratuiti a fronte di concessione di dati) che dicono di preferire la riservatezza. A provare servizi e applicazioni che sfruttano i Big Data per personalizzare l’interazione con i negozi è solo il 47% degli intervistati, con un 39% che dichiara di non aver mai fatto una esperienza simile, anche se nel 37% dei casi c’è interesse.

Big Data in azienda

Lata azienda la situazione rispetto all’uso di Big Data non è certo rosea. Il 41% delle persone intervistate, infatti, dichiara che nelle proprie aziende si fa un uso nullo o molto limitato di applicazioni che li utilizzano, con un altro 41% che afferma di farne un utilizzo medio. Situazione diversa nel caso in cui si chieda cosa riservi il futuro, visto che in circa un’azienda su due è previsto l’ingresso di applicazioni basate sui Big Data, mentre solo un 19% pensano di non investirci per niente.

Con un panorama temporale che va oltre i tre anni, le aziende affermano di voler utilizzare Big Data in particolare in marketing, comunicazione e assistenza clienti (14%), contabilità, controllo di gestione, finanza (11%) e produzione di beni ed erogazione del servizio. Prendendo a riferimento periodi più brevi, entro l’anno le aziende intendono usare Big Data in progettazione, ricerca e sviluppo (46%) e in gestione personale e organizzazione (35%) oltre che nel controllo di qualità (32%).

Quando si indaga il grado di complessità dell’integrazione dei Big Data in azienda, particolari problemi si evidenziano in progettazione, ricerca e sviluppo (62%), controllo di qualità e produzione di beni ed erogazione di servizi (57%).

“La contraddizione che emerge dai dati di ricerca, commenta Stefano Epifani, presidente Digital Transformation Institute, esprime tutta la complessità del momento rispetto alla relazione tra le persone e questo universo di tecnologie che affacciandosi con prepotenza nella società apre opportunità ma, contestualmente, ci pone di fronte a nuove minacce. Chi dice di essere preoccupato per l’uso che le piattaforme fanno dei dati degli utenti e contestualmente li cede per ottenere sconti è un po’ come chi si dice preoccupato dell’inquinamento ma va in automobile a comprare il giornale. La nostra società è sempre più complessa e le persone reagiscono a questa complessità spesso con comportamenti contraddittori, nei quali il “voler essere” non di rado è profondamente diverso da come i comportamenti quotidiani esprimono ciò che siamo in realtà. Ciò dipende dal fatto che se il “voler essere” è collegato a percezione che sentiamo giuste ma riferite a rischi che vediamo lontani, l’essere risponde ad un sistema di bisogni che percepiamo come più immediato. E quindi ecco che possiamo contemporaneamente dirci preoccupati del clima, e andare a comprare la frutta in automobile per non fare 100 metri a piedi. Lo stesso succede con i big data: non ci rendiamo conto degli impatti immediati e concreti che ha la cessione dei nostri dati”.

(6) ORA VEDIAMO COSA DICE MICROSOFT AZURE SU QUESTO TEMA

Un’architettura per Big Data è progettata per gestire l’inserimento, l’elaborazione e l’analisi di dati troppo grandi o complessi per i sistemi di database tradizionali.

Le soluzioni per i Big Data implicano in genere uno o più dei seguenti tipi di carico di lavoro:

  • L’elaborazione batch di origini di Big Data inattivi
  • L’elaborazione in tempo reale di Big Data in movimento
  • L’esplorazione interattiva di Big Data
  • L’analisi predittiva e il Machine Learning

La maggior parte delle architetture per i Big Data include alcuni o tutti i seguenti componenti:

  • Origini dati: Il punto di partenza di tutte le soluzioni per Big Data è costituito da una o più origini dati. Tra gli esempi sono inclusi:
    • Archivi dati di applicazioni, ad esempio database relazionali
    • File statici generati dalle applicazioni, ad esempio file di log di server Web
    • Origini dati in tempo reale, ad esempio dispositivi IoT
  • Archiviazione dati. I dati per le operazioni di elaborazione batch vengono in genere inseriti in un archivio di file distribuito che può contenere volumi elevati di file di grandi dimensioni in vari formati. Questo tipo di archivio viene spesso chiamato data lake. Alcune opzioni per l’implementazione di questo tipo di archiviazione sono Azure Data Lake Store o i contenitori BLOB in Archiviazione di Azure
  • Elaborazione batch. Poiché i set di dati hanno dimensioni considerevoli, una soluzione per Big Data deve spesso elaborare i file di dati mediante processi batch con esecuzione prolungata per filtrare, aggregare e preparare in altro modo i dati per l’analisi. In genere questi processi prevedono la lettura dei file di origine, la relativa elaborazione e la scrittura dell’output in nuovi file. Le opzioni includono l’esecuzione di processi U-SQL in Azure Data Lake Analytics, l’utilizzo di Hive, Pig o di processi MapReduce personalizzati in un cluster HDInsight Hadoop o l’utilizzo di programmi Java, Scala o Python in un cluster HDInsight Spark
  • Inserimento di messaggi in tempo reale. Se la soluzione include origini in tempo reale, l’architettura deve includere un modo per acquisire e archiviare i messaggi in tempo reale per l’elaborazione del flusso. Potrebbe trattarsi di un archivio dati semplice in cui i messaggi in ingresso vengono rilasciati in una cartella per l’elaborazione. Tuttavia, molte soluzioni richiedono che un archivio di inserimento dei messaggi funga da buffer per i messaggi e supporti l’elaborazione scale-out, il recapito affidabile e altri tipi di semantica di accodamento dei messaggi. Le opzioni includono Hub eventi di Azure, hub IoT di Azure e Kafka
  • Elaborazione del flusso. Dopo avere acquisito i messaggi in tempo reale, la soluzione deve elaborarli filtrando, aggregando e preparando in altro modo i dati per l’analisi. I dati del flusso elaborati vengono quindi scritti in un sink di output. Analisi di flusso di Azure offre un servizio di elaborazione del flusso gestito basato su query SQL in esecuzione perenne che operano su flussi non associati. È possibile anche usare tecnologie di streaming open source di Apache, come Storm e Spark Streaming in un cluster HDInsight
  • Archivio dati analitici. Numerose soluzioni per Big Data preparano i dati per l’analisi e quindi servono i dati elaborati in un formato strutturato su cui è possibile eseguire query con strumenti analitici. L’archivio dati analitici usato per rispondere a queste query può essere un data warehouse relazionale in stile Kimball, come nella maggior parte delle soluzioni di business intelligence (BI) tradizionali. In alternativa, i dati possono essere presentati tramite una tecnologia NoSQL a bassa latenza come HBase o un database Hive interattivo che fornisce un’astrazione di metadati sui file di dati nell’archivio dati distribuito. Azure SQL Data Warehouse fornisce un servizio gestito per il data warehousing su larga scala basato su cloud. HDInsight supporta Interactive Hive, HBase e Spark SQL, che possono anche essere usati per fornire dati per l’analisi
  • Analisi e creazione di report. L’obiettivo della maggior parte delle soluzioni per Big Data è fornire informazioni dettagliate sui dati tramite strumenti di analisi e report. Per consentire agli utenti di analizzare i dati, l’architettura può includere un livello di modellazione dei dati, ad esempio un cubo OLAP multidimensionale o un modello di dati tabulari in Azure Analysis Services. Potrebbe inoltre supportare la business intelligence in modalità self-service, usando le tecnologie di modellazione e visualizzazione in Microsoft Power BI o Microsoft Excel. L’analisi e il reporting possono anche assumere la forma di esplorazione interattiva dei dati da parte di data scientist o analisti di dati. Per questi scenari, molti servizi di Azure supportano notebook analitici come Jupyter, consentendo a questi utenti di sfruttare le proprie competenze esistenti con Python o R. Per l’esplorazione di dati su larga scala, è possibile usare Microsoft R Server, sia autonomo che con Spark
  • Orchestrazione. La maggior parte delle soluzioni per Big Data consiste in operazioni ripetute di elaborazione dei dati, incapsulate in flussi di lavoro, che trasformano i dati di origine, spostano i dati tra più origini e sink, caricano i dati elaborati in un archivio dati analitico o li inseriscono direttamente in un report o in un dashboard. Per automatizzare questi flussi di lavoro, è possibile usare una tecnologia di orchestrazione come Azure Data Factory o Apache Oozie e Sqoop

Azure include molti servizi che possono essere usati in un’architettura per Big Data. Si dividono approssimativamente in due categorie:

  • Servizi gestiti, tra cui Azure Data Lake Store, Azure Data Lake Analytics, Azure Data Warehouse, Analisi di flusso di Azure, Azure Event Hub, Hub IoT e Azure Data Factory.
  • Tecnologie open source basate sulla piattaforma Apache Hadoop, tra cui Hadoop Distributed File System, HBase, Hive, Pig, Spark, Storm, Oozie, Sqoop e Kafka. Queste tecnologie sono disponibili in Azure nel servizio Azure HDInsight.

Queste opzioni non si escludono a vicenda e molte soluzioni combinano le tecnologie open source con i servizi Azure

Quando usare questa architettura

Prendere in considerazione questo stile di architettura quando è necessario:

  • Archiviare ed elaborare i dati in volumi troppo grandi per un database tradizionale.
  • Trasformare i dati non strutturati per consentire l’analisi e il reporting.
  • Acquisire, elaborare e analizzare i flussi di dati non associati in tempo reale o con una latenza bassa.
  • Usare Microsoft Azure Machine Learning o Servizi cognitivi Microsoft.

Vantaggi

  • Scelte tecnologiche. È possibile combinare i servizi gestiti Azure e le tecnologie Apache nei cluster HDInsight per sfruttare appieno le competenze o gli investimenti tecnologici esistenti.
  • Prestazioni tramite il parallelismo. Le soluzioni per i Big Data sfruttano i vantaggi del parallelismo, consentendo soluzioni ad alte prestazioni che si adattano a grandi volumi di dati.
  • Scalabilità elastica. Tutti i componenti dell’architettura per Big Data supportano il provisioning scale-out che consente di adattare la soluzione a carichi di lavoro piccoli o grandi e pagare solo per le risorse usate.
  • Interoperabilità con soluzioni esistenti. I componenti dell’architettura per Big Data vengono usati anche per l’elaborazione IoT e le soluzioni di BI enterprise, consentendo di creare una soluzione integrata tra i carichi di lavoro di dati.

Problematiche

  • Complessità. Le soluzioni per Big Data possono essere estremamente complesse, con numerosi componenti per gestire l’inserimento di dati da più origini dati. Può essere difficile compilare, testare e risolvere i problemi relativi ai processi con Big Data. Inoltre potrebbe esistere un numero elevato di impostazioni di configurazione tra più sistemi che devono essere usate per ottimizzare le prestazioni.
  • Competenze. Molte tecnologie per Big Data sono altamente specializzate e usano framework e linguaggi che non sono tipici di architetture applicative più generali. D’altra parte, le tecnologie per i Big Data stanno evolvendo nuove API basate su altri linguaggi consolidati. Ad esempio, il linguaggio U-SQL in Azure Data Lake Analytics si basa su una combinazione di Transact-SQL e C#.Analogamente, le API basate su SQL sono disponibili per Hive, HBase e Spark.
  • Maturità tecnologica. Molte tecnologie usate per i Big Data sono in continua evoluzione. Mentre le tecnologie Hadoop principali come Hive e Pig sono ormai stabili, le tecnologie emergenti come Spark introducono numerosi cambiamenti e miglioramenti in ogni nuova versione. I servizi gestiti come Azure Data Lake Analytics e Azure Data Factory sono relativamente recenti rispetto ad altri servizi Azure e probabilmente si evolveranno ancora nel tempo.
  • Sicurezza. Le soluzioni per Big Data di solito si basano sull’archiviazione di tutti i dati statici in un data lake centralizzato. Garantire l’accesso sicuro a questi dati può essere difficile, specialmente quando i dati devono essere inseriti e usati da più applicazioni e piattaforme.

Procedure consigliate

  • Sfruttare il parallelismo. La maggior parte delle tecnologie di elaborazione per i Big Data distribuisce il carico di lavoro su più unità di elaborazione. È necessario che i file di dati statici vengano creati e archiviati in un formato divisibile. I file system distribuiti come HDFS possono ottimizzare le prestazioni in lettura e in scrittura e l’elaborazione effettiva viene eseguita da più nodi del cluster in parallelo, riducendo i tempi complessivi del processo.
  • Dati di partizione. L’elaborazione batch di solito si verifica in base a una pianificazione ricorrente, ad esempio, settimanale o mensile. Partizionare i file di dati e le strutture di dati come tabelle, in base a periodi temporali corrispondenti alla pianificazione di elaborazione. Ciò semplifica l’inserimento dei dati e la pianificazione dei processi e quindi la risoluzione dei problemi. Inoltre, le tabelle delle partizioni usate nelle query Hive, U-SQL o SQL possono migliorare significativamente le prestazioni delle query.
  • Applicare la semantica dello schema in lettura. L’utilizzo di un data lake consente di combinare l’archiviazione per i file in più formati, siano essi strutturati, semi-strutturati o non strutturati. Usare la semantica dello schema in lettura che applica uno schema sui dati in fase di elaborazione e non in fase di archiviazione. In questo modo aumenta la flessibilità della soluzione e si prevengono colli di bottiglia durante l’inserimento dei dati a causa della convalida dei dati e del controllo del tipo.
  • Elaborare i dati sul posto. Le soluzioni tradizionali di business intelligence usano spesso un processo di estrazione, trasformazione e (ETL) per trasferire i dati in un data warehouse. Con volumi di dati di dimensioni maggiori e una gamma di formati più ampia, in genere le soluzioni per Big Data usano variazioni del processo ETL, ad esempio trasformazione, estrazione e caricamento (TEL). Con questo approccio i dati vengono elaborati all’interno dell’archivio dati distribuito, trasformandoli nella struttura richiesta, prima di spostare i dati trasformati in un archivio dati analitici.
  • Bilanciare il costo unitario e il costo per l’utilizzo. Per i processi di elaborazione batch, è importante considerare due fattori: il costo unitario dei nodi di calcolo e il costo al minuto dell’uso di tali nodi per completare il processo. Ad esempio, un processo batch può richiedere otto ore con quattro nodi cluster. Tuttavia, potrebbe risultare che il processo usi tutti e quattro i nodi solo durante le prime due ore e, successivamente, siano necessari solo due nodi. In tal caso, eseguire l’intero lavoro su due nodi aumenterebbe il tempo totale del lavoro, ma non lo raddoppierebbe e quindi il costo totale sarebbe inferiore. In alcuni scenari aziendali, un tempo di elaborazione più lungo può essere preferibile al costo più elevato dell’utilizzo di risorse cluster sottoutilizzate.
  • Separare le risorse del cluster. Quando si distribuiscono cluster HDInsight, di solito si ottengono prestazioni migliori mediante il provisioning di risorse cluster separate per ogni tipo di carico di lavoro. Ad esempio, sebbene i cluster Spark includano Hive, se è necessario eseguire un’elaborazione estesa con Hive e Spark, è consigliabile considerare l’implementazione di cluster Spark e Hadoop dedicati separati. Analogamente, se si usa HBase e Storm per l’elaborazione di flussi a bassa latenza e Hive per l’elaborazione batch, considerare l’utilizzo di cluster separati per Storm, HBase e Hadoop.
  • Orchestrare l’inserimento di dati. In alcuni casi, le applicazioni aziendali esistenti possono scrivere file di dati per l’elaborazione batch direttamente nei contenitori BLOB di archiviazione di Azure, dove possono essere usati da HDInsight o Azure Data Lake Analytics. Tuttavia sarà spesso necessario orchestrare l’inserimento di dati da origini dati locali o esterne nel data lake. Usare un flusso di lavoro o una pipeline di orchestrazione, ad esempio quelli supportati da Azure Data Factory oppure Oozie, per ottenere questo risultato in modo prevedibile e gestibile a livello centrale.
  • Eseguire lo scrubbing dei dati sensibili in anticipo. Il flusso di lavoro per l’inserimento dei dati dovrebbe eseguire lo scrubbing dei dati sensibili all’inizio del processo, per evitare di archiviarli nel data lake

Architettura IoT

Internet delle cose (IoT) è un subset specifico di soluzioni per Big Data. Il diagramma seguente mostra una possibile architettura logica per IoT. Il diagramma evidenzia i componenti del flusso di eventi dell’architettura.

Il gateway cloud inserisce gli eventi di dispositivo in corrispondenza dei limiti del cloud, usando un sistema di messaggistica a bassa latenza affidabile.

I dispositivi possono inviare eventi direttamente al gateway cloud oppure attraverso un gateway sul campo. Un gateway sul campo è un dispositivo o un software specializzato che si trova in genere nella stessa posizione dei dispositivi e che riceve gli eventi e li inoltra al gateway cloud. Il gateway sul campo può anche pre-elaborare gli eventi di dispositivo non elaborati, eseguendo funzioni come l’applicazione di filtri, l’aggregazione o la trasformazione del protocollo.

Dopo l’inserimento, gli eventi passano da uno o più elaboratori di flussi, che possono instradare i dati (ad esempio all’archiviazione) o eseguire analisi e altri tipi di elaborazione.

Di seguito vengono indicati alcuni tipi comuni di elaborazione. Naturalmente, l’elenco non è esaustivo.

  • Scrittura dei dati di evento nell’archiviazione offline sicura per l’analisi batch.
  • Analisi Percorso critico, che analizza il flusso di eventi (quasi) in tempo reale, per rilevare le anomalie, riconoscere i modelli in base a intervalli di tempo ricorrenti o attivare avvisi quando si verifica una condizione specifica nel flusso.
  • Gestione di tipi speciali di messaggi non di telemetria dai dispositivi, come le notifiche e gli allarmi.
  • Machine Learning.

Le caselle in grigio mostrano i componenti di un sistema IoT non direttamente correlati al flusso di eventi, ma che sono stati inclusi per completezza.

  • Il registro dei dispositivi è un database dei dispositivi di cui è stato effettuato il provisioning e include gli ID dispositivo e in genere i metadati dei dispositivi, come la posizione.
  • L’API di provisioning è un’interfaccia esterna comune per il provisioning e la registrazione di nuovi dispositivi.
  • Alcune soluzioni IoT consentono l’invio di messaggi di comando e controllo ai dispositivi.

Questa sezione ha presentato una visualizzazione di livello notevolmente elevato di uno scenario IoT, in cui potrebbe essere necessario tenere presenti alcune sottigliezze e problematiche. Per un’analisi più approfondita dell’architettura di riferimento, con tutte le considerazioni correlate, vedere Microsoft Azure IoT Reference Architecture (Architettura di riferimento di Microsoft Azure IoT).

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *