Modelli di soluzioni di Analisi di flusso di Azure

Analogamente a molti altri servizi in Azure, Analisi di flusso viene usato meglio con altri servizi per creare una soluzione end-to-end più grande. Questo articolo illustra semplici soluzioni di Analisi di flusso di Azure e vari modelli architetturali. È possibile creare questi modelli per sviluppare soluzioni più complesse. I modelli descritti in questo articolo possono essere usati in un'ampia gamma di scenari. Esempi di modelli specifici dello scenario sono disponibili nelle architetture di soluzioni di Azure.

Creare un processo di Analisi di flusso per potenziare l'esperienza di dashboarding in tempo reale

Con Analisi di flusso di Azure è possibile creare rapidamente dashboard e avvisi in tempo reale. Una soluzione semplice inserisce eventi da Hub eventi o hub IoT e invia al dashboard di Power BI un set di dati di streaming. Per altre informazioni, vedere l'esercitazione dettagliata Analizza i dati delle chiamate fraudolente con Stream Analytics di Azure e visualizza i risultati nella dashboard di Power BI.

È possibile compilare questa soluzione in pochi minuti usando il portale di Azure. Non è necessario scrivere codice in modo esteso. È invece possibile usare il linguaggio SQL per esprimere la logica di business.

Questo modello di soluzione offre la latenza più bassa dall'origine evento al dashboard di Power BI in un browser. Analisi di flusso di Azure è l'unico servizio di Azure che offre questa funzionalità predefinita.

Usare SQL per il dashboard

Il dashboard di Power BI offre bassa latenza, ma non è possibile usarlo per produrre report di Power BI completi. Un modello di creazione di report comune consiste nell'inviare i dati a database SQL prima. Usare quindi il connettore SQL di Power BI per eseguire query su SQL per i dati più recenti.

Quando si usa database SQL, offre maggiore flessibilità, ma a scapito di una latenza leggermente superiore. Questa soluzione è ottimale per i processi con requisiti di latenza maggiori di un secondo. Quando si usa questo metodo, è possibile ottimizzare le funzionalità di Power BI per filtrare ulteriormente i dati per i report e molto più opzioni di visualizzazione. Si ottiene anche la flessibilità dell'uso di altre soluzioni dashboard, ad esempio Tableau.

SQL non è un archivio dati con alta capacità di elaborazione. La velocità effettiva massima verso SQL Database da Azure Stream Analytics è attualmente di circa 24 MB/s. Se le origini degli eventi nella soluzione producono dati a un tasso più elevato, è necessario utilizzare la logica di elaborazione in Analisi di flusso per ridurre il tasso di output per SQL. È possibile usare tecniche come il filtraggio, le aggregazioni finestrate, la ricerca di schemi con join temporali e le funzioni analitiche. È possibile ottimizzare il tasso di output verso SQL usando le tecniche descritte nell'output di Azure Stream Analytics per Azure SQL Database.

Incorporare informazioni dettagliate in tempo reale nell'applicazione con la messaggistica degli eventi

Il secondo utilizzo più diffuso di Analisi di flusso di Azure consiste nella generazione di avvisi in tempo reale. In questo modello di soluzione la logica di business in Analisi di flusso può essere usata per rilevare modelli temporali e spaziali o anomalie, quindi generare segnali di avviso. Tuttavia, a differenza della soluzione dashboard in cui Analisi di flusso usa Power BI come endpoint preferito, è possibile usare altri sink di dati intermedi. Questi sink includono Event Hubs, Service Bus e Funzioni di Azure. Lo sviluppatore dell'applicazione deve decidere quale sink di dati è più adatto allo scenario.

È necessario implementare la logica consumer di eventi downstream per generare avvisi nel flusso di lavoro aziendale esistente. Poiché è possibile implementare logica personalizzata nelle Funzioni di Azure, esse rappresentano il modo più rapido per eseguire questa integrazione. Per un'esercitazione sull'uso di Funzioni di Azure come output per un processo di Analisi di flusso, vedere Eseguire Funzioni di Azure dai processi di Analisi di flusso di Azure. Funzioni di Azure supporta anche vari tipi di notifiche, tra cui SMS ed e-mail. È anche possibile utilizzare Logic Apps per tale integrazione, con Event Hubs tra Stream Analytics e Logic Apps.

Il servizio Hub eventi di Azure offre invece il punto di integrazione più flessibile. Molti altri servizi, come Azure Data Explorer, possono usare eventi da Event Hubs. Per completare la soluzione, è possibile connettere i servizi direttamente al sink di Event Hubs di Azure Stream Analytics. Hub eventi è anche il broker di messaggistica con velocità effettiva più elevata disponibile in Azure per scenari di integrazione di questo tipo.

Applicazioni dinamiche e siti Web

È possibile creare visualizzazioni personalizzate in tempo reale, ad esempio dashboard o visualizzazione mappa, usando Analisi di flusso di Azure e Servizio Azure SignalR. Quando si usa SignalR, i client Web possono essere aggiornati e mostrare contenuto dinamico in tempo reale.

Incorporare informazioni dettagliate in tempo reale nell'applicazione tramite archivi dati

La maggior parte dei servizi Web e delle applicazioni Web attualmente usa un modello di richiesta/risposta per soddisfare il livello di presentazione. Il modello di richiesta/risposta è semplice da compilare e può essere facilmente ridimensionato con tempi di risposta ridotti usando un front-end senza stato e archivi scalabili, ad esempio Azure Cosmos DB.

Un volume di dati elevato spesso crea colli di bottiglia delle prestazioni in un sistema basato su CRUD. Il modello di soluzione di event sourcing viene usato per risolvere i colli di bottiglia delle prestazioni. I modelli temporali e le informazioni dettagliate sono anche difficili e inefficienti da estrarre da un archivio dati tradizionale. Le moderne applicazioni basate sui dati a volumi elevati spesso adottano un'architettura basata su flussi di dati. L'Analisi di flusso di Azure come motore di calcolo per i dati in movimento è un perno in quell'architettura.

In questo modello di soluzione gli eventi vengono elaborati e aggregati in archivi dati da Analisi di flusso di Azure. Il livello applicazione interagisce con gli archivi dati usando il modello di richiesta/risposta tradizionale. Grazie alla capacità di Stream Analytics di elaborare un numero elevato di eventi in tempo reale, l'applicazione è altamente scalabile senza la necessità di ampliare il livello di archiviazione dei dati. Il livello dell'archivio dati è essenzialmente una vista materializzata nel sistema. L'output di Azure Stream Analytics in Azure Cosmos DB descrive come viene utilizzato Azure Cosmos DB come output di Azure Stream Analytics.

Nelle applicazioni reali in cui la logica di elaborazione è complessa e c'è la necessità di aggiornare determinate parti della logica in modo indipendente, più processi di Analisi di flusso possono essere composti insieme a Hub eventi come broker di eventi intermedi.

Questo modello migliora la resilienza e la gestibilità del sistema. Tuttavia, anche se Stream Analytics garantisce l'elaborazione esattamente una volta, esiste una piccola probabilità che gli eventi duplicati vadano a finire nell'hub eventi intermedio. È importante che il processo di Analisi di flusso downstream deduplica gli eventi usando le chiavi logiche in una finestra di lookback. Per altre informazioni sul recapito degli eventi, vedere Informazioni di riferimento sulle garanzie di recapito degli eventi.

Usare i dati di riferimento per la personalizzazione dell'applicazione

La funzionalità dei dati di riferimento di Azure Stream Analytics è progettata specificamente per la personalizzazione dell'utente finale, come soglia di allerta, regole di elaborazione e recinti virtuali. Il livello applicazione può accettare modifiche ai parametri e archiviarle in database SQL. Il processo di Analisi del flusso interroga periodicamente il database per rilevare eventuali modifiche e rende i parametri di personalizzazione accessibili tramite un'unione con i dati di riferimento. Per ulteriori informazioni su come utilizzare i dati di riferimento per la personalizzazione dell'applicazione, vedere dati di riferimento SQL e reference data join.

Questo modello può essere usato anche per implementare un motore regole in cui le soglie delle regole vengono definite dai dati di riferimento. Per altre informazioni sulle regole, vedere Elaborare regole basate su soglie configurabili in Analisi di flusso di Azure.

Aggiungi l'apprendimento automatico alle informazioni dettagliate in tempo reale

Il modello di rilevamento anomalie predefinito di Analisi di flusso di Azure è un modo pratico per introdurre Machine Learning nell'applicazione in tempo reale. Per un'ampia gamma di esigenze di Machine Learning, vedere Analisi di flusso di Azure si integra con il servizio di assegnazione dei punteggi di Azure Machine Learning.

Per gli utenti avanzati che vogliono incorporare il training e l'assegnazione dei punteggi online nella stessa pipeline di Analisi di flusso, vedere questo esempio di come eseguire questa operazione con la regressione lineare.

Data warehousing in tempo reale

Un altro modello comune è il data warehouse in tempo reale, detto anche data warehouse di streaming. Oltre agli eventi in arrivo in Hub eventi e hub IoT dall'applicazione, è possibile usare Analisi di flusso di Azure in esecuzione in IoT Edge per soddisfare le esigenze di pulizia dei dati, riduzione dei dati e archivio dati e inoltro. Analisi di flusso in esecuzione in IoT Edge può gestire correttamente le limitazioni della larghezza di banda e i problemi di connettività nel sistema. Stream Analytics può supportare un rate di throughput fino a 200 MB/sec durante la scrittura in Azure Synapse Analytics.

Archiviazione dei dati in tempo reale per l'analisi

La maggior parte delle attività di data science e analisi avviene ancora offline. È possibile archiviare i dati in Analisi di flusso di Azure tramite i formati di output di Azure Data Lake Store Gen2 e Parquet. Questa funzionalità rimuove l'attrito per inserire i dati direttamente in Azure Data Lake Analytics, Azure Databricks e Azure HDInsight. Analisi di flusso di Azure viene utilizzato come motore ETL (Extract-Transform-Load) in questa soluzione per operazioni quasi in tempo reale. È possibile esplorare i dati archiviati in Data Lake usando vari motori di calcolo.

Usare i dati di riferimento per l'arricchimento

L'arricchimento dei dati è spesso un requisito per i motori ETL. Analisi di flusso di Azure supporta l'arricchimento dei dati con dati di riferimento da SQL Database e archiviazione BLOB di Azure. L'arricchimento dei dati può essere eseguito per i dati in arrivo sia in Azure Data Lake che in Azure Synapse Analytics.

Rendere operativi i dati analitici dai dati archiviati

Se si combina il modello di analisi offline con il modello di applicazione quasi in tempo reale, è possibile creare un ciclo di feedback. Il ciclo di feedback consente all'applicazione di modificare automaticamente i modelli nei dati. Questo ciclo di feedback può essere semplice come modificare il valore soglia per gli avvisi o complesso come ripetere il training dei modelli di Machine Learning. La stessa architettura della soluzione può essere applicata sia ai processi ASA in esecuzione nel cloud che in IoT Edge.

Come monitorare i processi ASA

Per elaborare in tempo reale gli eventi in ingresso in modo continuo, è possibile eseguire un processo di Analisi di flusso di Azure 24 ore su 24, 7 giorni su 7. La garanzia del tempo di attività è fondamentale per la salute generale dell'applicazione complessiva. Anche se Stream Analytics è l'unico servizio di analisi di streaming nel settore che offre una garanzia di disponibilità del 99,9%, si verifica comunque un certo livello di tempo di inattività. Nel corso degli anni, Stream Analytics ha introdotto metriche, log e stati delle attività per riflettere lo stato di salute dei lavori. Tutte le informazioni vengono visualizzate tramite il servizio Monitoraggio di Azure e possono essere ulteriormente esportate in Microsoft Operations Management Suite. Per altre informazioni, vedere Monitorare il processo di Stream Analytics del portale di Azure.

Gli aspetti fondamentali da monitorare sono due, come indicato di seguito.

• Stato del processo non riuscito

  Prima di tutto, è necessario assicurarsi che il processo sia in esecuzione. Se il job non è in esecuzione, non vengono generate nuove metriche o log. I job possono passare a uno stato di errore per vari motivi, tra cui un elevato livello di utilizzo di SU (cioè esaurimento delle risorse).

• Metriche di ritardo del watermark

  Questa metrica riflette quanto è indietro la pipeline di elaborazione rispetto al tempo dell'orologio a muro (in secondi). Parte del ritardo è attribuito alla logica di elaborazione intrinseca. Di conseguenza, il monitoraggio della tendenza crescente è molto più importante rispetto al monitoraggio del valore assoluto. Il ritardo dello stato stazionario dovrebbe essere risolto nella progettazione dell'applicazione, non tramite il monitoraggio o gli avvisi.

In caso di errore, i registri di attività e i log di diagnostica sono i migliori punti di partenza per cercare eventuali errori.

Creare applicazioni resilienti e cruciali

Indipendentemente dalla garanzia del contratto di servizio di Analisi di flusso di Azure e dal modo in cui si esegue attentamente l'applicazione end-to-end, si verificano interruzioni. Se l'applicazione è critica per il funzionamento, dovresti essere preparato per le interruzioni per ripristinare senza problemi.

Per le applicazioni di avviso, l'aspetto più importante consiste nel rilevare l'avviso successivo. È possibile scegliere di riavviare il processo dall'ora corrente durante il ripristino, ignorando gli avvisi precedenti. La semantica dell'avvio del lavoro è basata sulla prima ora di uscita, non sulla prima ora di ingresso. L'input viene riavvolto all'indietro una quantità di tempo appropriata per garantire che il primo output al momento specificato sia completo e corretto. Non si otterranno aggregazioni parziali né si attiveranno avvisi in modo imprevisto di conseguenza.

È anche possibile scegliere di avviare l'output da un momento nel passato. Sia Event Hubs che IoT Hub abbiano criteri di conservazione che contengono una quantità ragionevole di dati per consentire l'elaborazione dei dati passati. Il compromesso è la velocità con cui è possibile allinearsi con il tempo corrente e iniziare a generare nuovi avvisi tempestivi. I dati perdono valore rapidamente nel tempo, quindi è importante avanzare in fretta fino al momento attuale. Esistono due modi per recuperare rapidamente:

• Allocare più risorse (SU) quando si riprende terreno.
• Riavvia dall'ora corrente.

Il riavvio dall'ora attuale è semplice, con il compromesso di lasciare un intervallo durante l'elaborazione. Il riavvio in questo modo potrebbe essere appropriato per gli scenari di avviso, ma può essere problematico per gli scenari di dashboard e non è fattibile per gli scenari di archiviazione e magazzinaggio dei dati.

Il provisioning di più risorse può velocizzare il processo, ma l'effetto di un aumento della velocità di elaborazione è complesso.

• Verifica che il tuo carico di lavoro sia scalabile a un numero maggiore di SU. Non tutte le query sono scalabili. È necessario assicurarsi che la query sia parallelizzata.

• Assicurarsi che siano presenti partizioni sufficienti negli hub eventi upstream o negli hub IoT per aggiungere altre unità di throughput (TUs) per ridimensionare la larghezza di banda in ingresso. Tenere presente che ogni TU di Hub Eventi ha un limite massimo per una velocità di output di 2 MB/s.

• Assicurarsi di aver effettuato il provisioning di risorse sufficienti nei sink di output, ovvero database SQL, Azure Cosmos DB, in modo da non limitare l'aumento dell'output, che a volte può causare il blocco del sistema.

L'aspetto più importante consiste nell'anticipare la modifica della frequenza di elaborazione, testare questi scenari prima di passare all'ambiente di produzione e prepararsi a ridimensionare correttamente l'elaborazione durante il tempo di ripristino degli errori.

Nello scenario estremo in cui gli eventi in ingresso sono tutti ritardati, è possibile che tutti gli eventi posticipati vengano eliminati se è stata applicata una finestra di arrivo tardiva al processo. L'eliminazione degli eventi potrebbe sembrare un comportamento misterioso all'inizio; tuttavia, considerando che Stream Analytics è un motore di elaborazione in tempo reale, si prevede che gli eventi in ingresso siano vicini all'ora di clock del sistema. Deve eliminare gli eventi che violano questi vincoli.

Architetture lambda o processo di riempimento retroattivo

Fortunatamente, il modello di archiviazione dei dati precedente può essere usato per elaborare questi eventi tardivi normalmente. L'idea è che il job di archiviazione elabora gli eventi in ingresso in base all'ora di arrivo e archivia gli eventi nell'intervallo di tempo corretto in Azure Blob o in Azure Data Lake Store con il relativo orario di evento. Non importa quanto un evento arrivi in ritardo, non verrà mai scartato. Farà sempre parte della giusta fascia oraria. Durante il ripristino, è possibile rielaborare gli eventi archiviati e riempire di nuovo i risultati nell'archivio scelto. Questo è simile al modo in cui vengono implementati i modelli lambda.

Il processo di backfill deve essere eseguito con un sistema di elaborazione batch offline, che probabilmente ha un modello di programmazione diverso rispetto ad Analisi di flusso di Azure. Ciò significa che è necessario riapplicare l'intera logica di elaborazione.

Per il backfilling, è comunque importante effettuare almeno temporaneamente il provisioning di più risorse nei sink di output per gestire una velocità effettiva superiore rispetto alle esigenze di elaborazione dello stato stabile.

Scenari	Riavvia solo a partire da ora	Riprendi dall'ora dell'ultima interruzione	Riavviare da ora + riempimento con eventi archiviati
Dashboarding	Crea un divario	OK per un'interruzione breve	Usare durante un'interruzione prolungata
Invio di avvisi	Accettabile	OK per interruzioni brevi	Non necessario
App per l'origine degli eventi	Accettabile	OK per interruzioni brevi	Usare per un'interruzione prolungata del servizio
Data warehousing	Perdita di dati	Accettabile	Non necessario
Analisi offline	Perdita di dati	Accettabile	Non necessario

Combinazione delle funzionalità

Non è difficile immaginare che tutti i modelli di soluzione menzionati in precedenza possano essere combinati in un sistema end-to-end complesso. Il sistema combinato può includere dashboard, avvisi, applicazione di origine eventi, data warehousing e funzionalità di analisi offline.

La chiave consiste nel progettare il sistema in modelli componibili, in modo che ogni sottosistema possa essere compilato, testato, aggiornato e ripristinato in modo indipendente.

Passaggi successivi

Sono stati ora illustrati vari modelli di soluzione usando Analisi di flusso di Azure. Adesso puoi esaminare approfonditamente e creare il tuo primo job di Stream Analytics:

• Creare un processo di Analisi di flusso tramite il portale di Azure.
• Creare un processo di Analisi di flusso tramite Azure PowerShell.
• Creare un processo di Analisi di flusso con Visual Studio.