Condividi tramite

Architetture per Big Data

  • Articolo

Un'architettura di Big Data gestisce l'inserimento, l'elaborazione e l'analisi dei dati troppo grandi o complessi per i sistemi di database tradizionali. La soglia per l'ingresso nell'area di autenticazione dei Big Data varia tra le organizzazioni, a seconda degli strumenti e delle funzionalità utente. Alcune organizzazioni gestiscono centinaia di gigabyte di dati e altre organizzazioni gestiscono centinaia di terabyte. Man mano che si evolvono gli strumenti per lavorare con grandi set di dati, la definizione di Big Data passa dall'attenzione esclusivamente alle dimensioni dei dati per sottolineare il valore derivato dall'analisi avanzata. Anche se questi tipi di scenari tendono ad avere grandi quantità di dati.

Nel corso degli anni, il panorama dei dati ha subito varie trasformazioni. Il concetto di ciò che è possibile fare, o si prevede di poter fare, è cambiato. Il costo dell'archiviazione è diminuito drasticamente, mentre i metodi per la raccolta dei dati continuano ad espandersi. Alcuni dati arrivano a un ritmo rapido e richiedono raccolta e osservazione continue. Altri dati arrivano più lentamente, ma in blocchi di grandi dimensioni e spesso sotto forma di decenni di dati cronologici. Potrebbe verificarsi un problema di analisi avanzata o un problema che richiede l'apprendimento automatico per risolvere. Le architetture di Big Data si sforzano di risolvere queste sfide.

Le soluzioni Big Data in genere coinvolgono uno o più dei tipi di carichi di lavoro seguenti:

  • Elaborazione batch di origini Big Data inattive
  • Elaborazione in tempo reale dei Big Data in movimento
  • Esplorazione interattiva dei Big Data
  • Analisi predittiva e Machine Learning

Prendere in considerazione le architetture di Big Data quando è necessario eseguire le attività seguenti:

  • Archiviare ed elaborare i dati in volumi troppo grandi per un database tradizionale
  • Trasformare i dati non strutturati per l'analisi e la creazione di report
  • Acquisire, elaborare e analizzare flussi di dati non associati in tempo reale o con bassa latenza

Componenti di un'architettura per Big Data

Il diagramma seguente illustra i componenti logici di un'architettura di Big Data. Le singole soluzioni potrebbero non contenere tutti gli elementi di questo diagramma.

Diagramma che mostra la pipeline di dati complessiva.

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

  • Origini dati: Tutte le soluzioni Big Data iniziano con una o più origini dati. Gli esempi includono:

    • Archivi dati dell'applicazione, ad esempio database relazionali.
    • File statici prodotti da applicazioni, ad esempio file di log del server Web.
    • Origini dati in tempo reale, ad esempio dispositivi IoT (Internet delle cose).

  • Archiviazione dati: I dati per le operazioni di elaborazione batch vengono in genere archiviati in un archivio file distribuito che può contenere volumi elevati di file di grandi dimensioni in vari formati. Questo tipo di archivio viene spesso chiamato data lake . Le opzioni per l'implementazione di questa risorsa di archiviazione includono Azure Data Lake Store, contenitori BLOB in Archiviazione di Azure o OneLake in Microsoft Fabric.

  • Elaborazione batch: I set di dati sono di grandi dimensioni, quindi una soluzione Big Data spesso elabora i file di dati usando processi batch a esecuzione prolungata per filtrare, aggregare e preparare in altro modo i dati per l'analisi. In genere questi processi comportano la lettura dei file di origine, l'elaborazione e la scrittura dell'output in nuovi file. È possibile usare le opzioni seguenti:

    • Eseguire processi U-SQL in Azure Data Lake Analytics.

    • Usare processi Hive, Pig o MapReduce personalizzati in un cluster Hadoop di Azure HDInsight.

    • Usare programmi Java, Scala o Python in un cluster HDInsight Spark.

    • Usare il linguaggio Python, Scala o SQL nei notebook di Azure Databricks.

    • Usare il linguaggio Python, Scala o SQL nei notebook di Fabric.

  • Inserimento di messaggi in tempo reale: Se la soluzione include origini in tempo reale, l'architettura deve acquisire e archiviare messaggi in tempo reale per l'elaborazione del flusso. Ad esempio, è possibile avere un archivio dati semplice che raccoglie i messaggi in ingresso per l'elaborazione. Tuttavia, molte soluzioni richiedono un archivio di inserimento messaggi per fungere da buffer per i messaggi e per supportare l'elaborazione con scalabilità orizzontale, il recapito affidabile e altre semantiche di accodamento dei messaggi. Questa parte di un'architettura di streaming viene spesso definita il buffering del flusso. Le opzioni includono Hub eventi di Azure, l'hub IoT di Azure e Kafka.

  • Elaborazione del flusso: Dopo che la soluzione acquisisce i messaggi in tempo reale, deve elaborarli filtrandoli, aggregando e preparando i dati per l'analisi. I dati del flusso elaborati vengono quindi scritti in un sink di output.

    • Analisi di flusso di Azure è un servizio di elaborazione dei flussi gestito che usa query SQL in esecuzione continua che operano su flussi non associati.

    • È possibile usare tecnologie di streaming Apache open source, ad esempio Spark Streaming, in un cluster HDInsight o in Azure Databricks.

    • Funzioni di Azure è un servizio di calcolo serverless in grado di eseguire codice basato su eventi, ideale per attività di elaborazione di flussi leggere.

    • Fabric supporta l'elaborazione dei dati in tempo reale usando flussi di eventi ed elaborazione Spark.

  • Apprendimento automatico: Per analizzare i dati preparati dall'elaborazione batch o di flusso, è possibile usare algoritmi di Machine Learning per creare modelli che stimano i risultati o classificano i dati. Questi modelli possono essere sottoposti a training su set di dati di grandi dimensioni. È possibile usare i modelli risultanti per analizzare nuovi dati ed eseguire stime.

    Usare Azure Machine Learning per eseguire queste attività. Machine Learning offre strumenti per creare, eseguire il training e distribuire modelli. In alternativa, è possibile usare le API predefinite dei servizi di intelligenza artificiale di Azure per attività comuni di Machine Learning, ad esempio visione, riconoscimento vocale, linguaggio e processi decisionali.

  • Archivio dati analitici: Molte soluzioni Big Data preparano i dati per l'analisi e quindi gestiscono i dati elaborati in un formato strutturato su cui gli strumenti analitici possono eseguire query. L'archivio dati analitici che gestisce queste query può essere un data warehouse relazionale di tipo Kimball. La maggior parte delle soluzioni di business intelligence (BI) tradizionali usa questo tipo di data warehouse. In alternativa, è possibile presentare i dati tramite una tecnologia NoSQL a bassa latenza, ad esempio HBase o un database Hive interattivo che fornisce un'astrazione dei metadati sui file di dati nell'archivio dati distribuito.

    • Azure Synapse Analytics è un servizio gestito per il data warehouse basato su cloud su larga scala.

    • HDInsight supporta Interactive Hive, HBase e Spark SQL. Questi strumenti possono servire i dati per l'analisi.

    • Fabric offre diversi archivi dati, tra cui database SQL, data warehouse, lakehouse ed eventhouse. Questi strumenti possono servire i dati per l'analisi.

    • Azure offre altri archivi dati analitici, ad esempio Azure Databricks, Esplora dati di Azure, database SQL di Azure e Azure Cosmos DB.

  • Analisi e creazione di report: La maggior parte delle soluzioni Big Data si impegna a fornire informazioni dettagliate sui dati tramite analisi e creazione di report. Per consentire agli utenti di analizzare i dati, l'architettura può includere un livello di modellazione dei dati, ad esempio un cubo di elaborazione analitica online multidimensionale o un modello di dati tabulari in Azure Analysis Services. Può anche supportare la business intelligence self-service usando le tecnologie di modellazione e visualizzazione in Power BI o Excel.

    I data scientist o gli analisti dei dati possono anche analizzare e creare report tramite l'esplorazione interattiva dei dati. Per questi scenari, molti servizi di Azure supportano notebook analitici, ad esempio Jupyter, per consentire a questi utenti di usare le proprie competenze esistenti con Python o Microsoft R. Per l'esplorazione dei dati su larga scala, è possibile usare Microsoft R Server, autonomo o spark. È anche possibile usare Fabric per modificare i modelli di dati, che offre flessibilità ed efficienza per la modellazione e l'analisi dei dati.

  • Orchestrazione: La maggior parte delle soluzioni Big Data è costituita da operazioni ripetute di elaborazione dei dati incapsulate nei flussi di lavoro. Le operazioni eseguono le attività seguenti:

    • Trasformare i dati di origine
    • Spostare i dati tra più origini e destinazioni
    • Caricare i dati elaborati in un archivio dati analitici
    • Inviare i risultati direttamente a un report o dashboard

    Per automatizzare questi flussi di lavoro, usare una tecnologia di orchestrazione come Azure Data Factory, Fabric o Apache Oozie e Apache Sqoop.

Architettura Lambda

Quando si lavora con set di dati di grandi dimensioni, l'esecuzione del tipo di query necessarie ai client può richiedere molto tempo. Queste query non possono essere eseguite in tempo reale. E spesso richiedono algoritmi come MapReduce che operano in parallelo nell'intero set di dati. I risultati della query vengono archiviati separatamente dai dati non elaborati e usati per ulteriori query.

Uno svantaggio di questo approccio è che introduce la latenza. Se l'elaborazione richiede alcune ore, una query potrebbe restituire risultati di diverse ore. Idealmente, è consigliabile ottenere alcuni risultati in tempo reale, potenzialmente con una perdita di accuratezza e combinare questi risultati con i risultati dell'analisi batch.

L'architettura lambda risolve questo problema creando due percorsi per il flusso di dati. Tutti i dati inseriti nel sistema passano attraverso i due percorsi seguenti:

  • Un livello batch (percorso a freddo) archivia tutti i dati in ingresso nel formato non elaborato ed esegue l'elaborazione batch sui dati. Il risultato di questa elaborazione viene archiviato come visualizzazione batch.

  • Un livello veloce (percorso rapido) analizza i dati in tempo reale. Questo livello è stato progettato per offrire una bassa latenza, a scapito della precisione.

Il livello di elaborazione batch confluisce in un livello di gestione che indicizza la visualizzazione batch per un'elaborazione efficiente delle query. Il livello di elaborazione rapida aggiorna in modo incrementale il livello di gestione in base ai dati più recenti.

Diagramma che mostra l'architettura lambda.

I dati che passano al percorso rapido devono essere elaborati rapidamente a causa delle esigenze di latenza imposte dal livello di velocità. L'elaborazione rapida garantisce che i dati siano pronti per l'uso immediato, ma possano introdurre imprecisioni. Si consideri, ad esempio, uno scenario IoT in cui numerosi sensori di temperatura inviano dati di telemetria. Il livello di velocità potrebbe elaborare un intervallo temporale scorrevole dei dati in ingresso.

I dati che passano nel percorso freddo non sono soggetti agli stessi requisiti di latenza bassa. Il percorso a freddo fornisce un calcolo con accuratezza elevata su grandi set di dati, ma può richiedere molto tempo.

I percorsi caldi e freddi convergono infine nell'applicazione client di analisi. Se il client deve visualizzare dati tempestivi, ma potenzialmente meno accurati in tempo reale, acquisisce il risultato dal percorso caldo. In caso contrario, il client seleziona i risultati dal percorso ad accesso sporadico per visualizzare dati meno tempestivi ma più accurati. In altre parole, il percorso ad accesso frequente contiene dati per un intervallo di tempo relativamente breve, dopo il quale i risultati possono essere aggiornati con dati più precisi provenienti dal percorso ad accesso sporadico.

I dati non elaborati archiviati a livello batch non sono modificabili. I dati in ingresso vengono aggiunti ai dati esistenti e i dati precedenti non vengono sovrascritti. Le modifiche apportate al valore di un particolare datum vengono archiviate come nuovo record di eventi con timestamp. I record degli eventi con timestamp consentono la ricompilazione in qualsiasi momento nella cronologia dei dati raccolti. La possibilità di ricompilare la visualizzazione batch dai dati non elaborati originali è importante perché consente la creazione di nuove viste man mano che il sistema evolve.

Architettura Kappa

Uno svantaggio dell'architettura Lambda è la sua complessità. La logica di elaborazione appare in due posizioni diverse, i percorsi a bassa frequenza e ad alta frequenza, attraverso diversi framework. Questo processo comporta la logica di calcolo duplicata e la gestione complessa dell'architettura per entrambi i percorsi.

L'architettura Kappa è un'alternativa all'architettura Lambda. Ha gli stessi obiettivi di base dell'architettura Lambda, ma tutti i dati passano attraverso un singolo percorso tramite un sistema di elaborazione dei flussi.

Diagramma che mostra l'architettura Kappa.

Analogamente al livello batch dell'architettura Lambda, i dati dell'evento non sono modificabili e vengono raccolti tutti anziché un subset di dati. I dati vengono inseriti come flusso di eventi in un log unificato distribuito a tolleranza di errore. Gli eventi vengono ordinati e lo stato corrente di un evento viene modificato solo in caso di accodamento di un nuovo evento. Analogamente al livello di velocità dell'architettura Lambda, tutte le elaborazioni degli eventi vengono eseguite nel flusso di input e rese persistenti come visualizzazione in tempo reale.

Se è necessario ricompilare l'intero set di dati (equivalente a quello che il livello batch esegue nell'architettura Lambda), è possibile riprodurre il flusso. Questo processo usa in genere il parallelismo per completare il calcolo in modo tempestivo.

Architettura del lakehouse

Un data lake è un repository di dati centralizzato che archivia dati strutturati (tabelle di database), dati semistrutturati (file XML) e dati non strutturati (immagini e file audio). Questi dati sono in formato non elaborato e originale e non richiedono uno schema predefinito. Un data lake può gestire grandi volumi di dati, quindi è adatto per l'elaborazione e l'analisi dei Big Data. I data lake usano soluzioni di archiviazione a basso costo, che offrono un modo conveniente per archiviare grandi quantità di dati.

Un data warehouse è un repository centralizzato che archivia dati strutturati e semistrutturati a scopo di creazione di report, analisi e BI. I data warehouse consentono di prendere decisioni informate fornendo una visualizzazione coerente e completa dei dati.

L'architettura Lakehouse combina gli elementi migliori dei data lake e dei data warehouse. Il modello mira a fornire una piattaforma unificata che supporta dati strutturati e non strutturati, che consentono una gestione efficiente dei dati e analisi. Questi sistemi usano in genere l'archiviazione cloud a basso costo in formati aperti, ad esempio Parquet o Optimized Row Columnar (ORC), per l'archiviazione di dati grezzi ed elaborati.

Diagramma che mostra un flusso di dati dall'origine alla fase di trasformazione e archiviazione e quindi alla fase di utilizzo e visualizzazione.

I casi d'uso comuni per un'architettura lakehouse includono:

  • Analisi unificata: Ideale per le organizzazioni che necessitano di una singola piattaforma per l'analisi dei dati cronologica e in tempo reale

  • Apprendimento automatico: Supporta carichi di lavoro avanzati di analisi e Machine Learning grazie all'integrazione delle funzionalità di gestione dei dati

  • Governance dei dati: Garantisce la conformità e la qualità dei dati in set di dati di grandi dimensioni

Internet delle cose

L'IoT rappresenta qualsiasi dispositivo che si connette a Internet e invia o riceve i dati. I dispositivi IoT includono PC, telefoni cellulari, orologi intelligenti, termostati intelligenti, frigoriferi intelligenti, automobili connesse e impianti di monitoraggio del cuore.

Il numero di dispositivi connessi aumenta ogni giorno e quindi la quantità di dati generati. Questi dati vengono spesso raccolti in ambienti con vincoli significativi e talvolta una latenza elevata. In altri casi, migliaia o milioni di dispositivi inviano dati da ambienti a bassa latenza, che richiedono l'inserimento e l'elaborazione rapidi. È necessario pianificare correttamente per gestire questi vincoli e requisiti univoci.

Le architetture guidate dagli eventi sono centrali per le soluzioni IoT. Il diagramma seguente illustra un'architettura logica per IoT. Il diagramma evidenzia i componenti di streaming di eventi dell'architettura.

Diagramma che mostra l'architettura IoT.

Il gateway cloud inserisce gli eventi del dispositivo al limite del cloud tramite un sistema di messaggistica affidabile e a bassa latenza.

I dispositivi possono inviare eventi direttamente al gateway cloud o tramite un gateway sul campo. Un gateway sul campo è un dispositivo o un prodotto software specializzato, in genere collocato insieme ai dispositivi, che riceve gli eventi e li inoltra al gateway cloud. Il gateway può anche preprocessare gli eventi grezzi del dispositivo, inclusi filtraggio, aggregazione o trasformazione del protocollo.

Dopo l'inserimento, gli eventi passano attraverso uno o più processori di flusso che possono instradare i dati alle destinazioni, ad esempio l'archiviazione o eseguire analisi e altre elaborazioni.

I tipi comuni di elaborazione includono:

  • Scrittura dei dati degli eventi nell'archiviazione a freddo per l'archiviazione e l'analisi batch.

  • Analisi dei percorsi ad accesso frequente. Analizzare il flusso di eventi quasi in tempo reale per rilevare anomalie, riconoscere i modelli nelle finestre temporali in sequenza 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.

  • Apprendimento automatico.

Nel diagramma precedente le caselle grigie sono componenti di un sistema IoT che non sono direttamente correlati allo streaming di eventi. Sono inclusi nel diagramma per la completezza.

  • Il registro dei dispositivi è un database dei dispositivi di cui è stato effettuato il provisioning, inclusi gli ID dispositivo e in genere i metadati del dispositivo, ad esempio la posizione.

  • L'API di provisioning è un'interfaccia esterna comune per il provisioning e la registrazione di nuovi dispositivi.

  • Alcune soluzioni IoT consentono di inviare messaggi di comando e controllo ai dispositivi.

Passaggi successivi