Concetti relativi al server StreamInsight

In questo argomento verrà descritto il modo in cui i dati vengono rappresentati, utilizzati, inseriti in e trasferiti dal server StreamInsight. Scopo dell'argomento è fornire la familiarità necessaria con i concetti di base associati all'elaborazione di eventi complessi in Microsoft StreamInsight. L'argomento inizia con la descrizione delle strutture di dati e prosegue quindi con la descrizione dei componenti del server StreamInsight che operano sui dati o li elaborano.

Flussi

Tutti i dati in StreamInsight sono organizzati in flussi. Ogni flusso descrive una raccolta potenzialmente interminabile di dati che cambiano nel tempo. Un flusso di ticker per le azioni, ad esempio, fornisce il prezzo di azioni diverse su un mercato man mano che queste cambiano nel tempo, mentre un flusso di sensori di temperatura fornisce i valori di temperatura segnalati dal sensore nel tempo.

Si consideri uno scenario di monitoraggio dell'alimentazione in cui l'obiettivo sia esaminare una raccolta di misuratori di alimentazione per misurare il consumo di energia di vari dispositivi. Periodicamente, questi misuratori di alimentazione trasmettono i dati che descrivono il consumo di energia in decimi di watt e il timestamp associato della lettura. Nella tabella seguente vengono mostrate le letture del misuratore di alimentazione da 3 misuratori, presupponendo che ogni misuratore di alimentazione generi una lettura di energia ogni secondo.

Poiché è possibile rappresentare queste informazioni come valori che cambiano nel tempo, i dati possono essere rappresentati in un flusso. Dai dati inclusi nel flusso, una query su tale flusso potrebbe restituire il misuratore con i valori di consumo maggiori e minori in un determinato periodo di tempo oppure l'elenco dei primi 10 misuratori con il consumo di energia più elevato nel tempo.

Eventi

I dati sottostanti rappresentati nel flusso vengono compressi in eventi. Un evento è l'unità di base dei dati elaborati dal server StreamInsight. Ciascun evento include le parti seguenti:

• Intestazione. Un'intestazione di evento contiene i metadati che definiscono il tipo di evento e uno o più timestamp che definiscono l'intervallo di tempo per l'evento. I timestamp sono basati sull'applicazione e vengono forniti dall'origine dati anziché da un'ora di sistema specificata dal server StreamInsight. Si noti che i timestamp utilizzano il tipo di dati DateTimeOffset, che fornisce informazioni sul fuso orario ed è basato su un orologio di 24 ore. Il server StreamInsight normalizza tutte le ore in base alle ore e alle date UTC e verifica nell'input che il flag UTC sia impostato sui campi timestamp.

• Payload. Struttura di dati .NET contenente i dati associati all'evento. I campi presenti nel payload sono definiti dall'utente. I tipi sono basati sul sistema dei tipi .NET.

Gli eventi nel flusso i cui timestamp applicazione corrispondono all'ordine di arrivo nella query vengono denominati 'in ordine'. In caso contrario, gli eventi vengono denominati 'non in ordine'. Il server StreamInsight garantisce che se gli eventi non arrivano in ordine, l'output della query equivale a quello degli eventi arrivati in ordine, a meno che l'autore della query non specifichi altro in modo esplicito. All'interno di un flusso, i modelli tipici di arrivo dell'evento sono:

• Una frequenza regolare, quali record da file o tabelle.

• Una frequenza intermittente e casuale, ad esempio i dati da uno scanner di codici a barre al dettaglio.

• Una frequenza intermittente con burst improvvisi, quali le selezioni nel Web o la telemetria del tempo.

Intestazione dell'evento

L'intestazione di un evento definisce il tipo di evento e le proprietà temporali dell'evento.

Tipo di evento

Il tipo di evento indica se si tratta di un nuovo evento nel flusso o se sta indicando la completezza degli eventi presenti nel flusso. StreamInsight supporta due tipi di evento: INSERT e CTI (Current Time Increment).

Il tipo di evento INSERT aggiunge un evento con il payload nel flusso di eventi. Oltre al payload, l'intestazione dell'evento INSERT identifica l'ora di inizio e di fine per l'evento. Nel diagramma seguente viene mostrato il layout di un tipo di evento INSERT.

Il tipo di evento CTI è un evento di punteggiatura speciale tramite cui viene indicata la completezza degli eventi presenti nel flusso. La struttura degli eventi CTI è costituita da un unico campo che fornisce un timestamp corrente. Un evento CTI risponde a due scopi:

1. Consente innanzitutto a una query di accettare ed elaborare eventi i cui timestamp applicazione non corrispondono al rispettivo ordine di arrivo nella query. Quando viene eseguito un evento CTI, viene indicato al server StreamInsight che nessun evento INSERT in entrata esaminerà la cronologia di eventi prima del timestamp CTI. Di conseguenza, dopo l'esecuzione di un evento CTI, nessun evento INSERT può essere associato a un'ora di inizio precedente al timestamp dell'evento CTI. Questa indicazione di "completezza" di un flusso di eventi consente al server StreamInsight di rilasciare i risultati del windowing o di altri operatori di aggregazione con stato cumulativo, garantendo in tal modo un efficiente flusso degli eventi nel sistema.

2. Il secondo scopo degli eventi CTI è la possibilità di gestire la bassa latenza della query. CTI frequenti restituiranno risultati della query con frequenza maggiore.

Importante
Senza la presenza di eventi CTI nel flusso di input, dalla query non viene generato alcun output.

Per ulteriori informazioni, vedere Avanzamento del tempo applicazione.

Nel diagramma seguente viene illustrato il layout di un tipo di evento CTI.

Modelli di eventi

Il modello di eventi definisce la forma dell'evento in base alle caratteristiche temporali. StreamInsight supporta tre modelli di eventi: intervallo, punto e limite. Gli eventi intervallo possono essere considerati come il tipo più generico, di cui bordo e punto sono casi speciali.

Intervallo

Il modello di eventi intervallo rappresenta un evento il cui payload è valido per un periodo di tempo specificato. Il modello di eventi intervallo richiede che venga fornita l'ora di inizio e di fine dell'evento nei metadati dell'evento. Gli eventi di intervallo sono validi solo per questo specifico intervallo tempo. È importante notare che le ore di inizio sono inclusive, mentre le ore di fine sono esclusive relativamente alla validità del payload dell'evento.

Nel diagramma seguente viene mostrato il layout di un modello di eventi intervallo.

Negli esempi di eventi intervallo sono incluse la larghezza di un impulso elettronico, la durata (validità) di una vendita all'asta o un'attività del ticker per le azioni in cui il prezzo di offerta per l'azione è valido per un periodo di tempo specifico. Nell'esempio di monitoraggio dell'energia descritto in precedenza, è possibile che il flusso di eventi del misuratore di alimentazione venga rappresentato con i seguenti eventi intervallo.

Punto

Un modello di eventi punto rappresenta l'occorrenza di un evento come singolo punto nel tempo. Il modello degli eventi punto richiede solo l'ora di inizio dell'evento. Il server StreamInsight deriva l'ora di fine valida aggiungendo un tick (l'unità di tempo più piccola nel tipo di dati TIME sottostante) all'ora di inizio per impostare l'intervallo di tempo valido per l'evento. Considerando che tali ore di fine dell'evento sono esclusive, gli eventi punto sono validi solo per l'istante dell'ora di inizio.

Nel diagramma seguente viene mostrato il layout di un modello di eventi punto.

Negli esempi di eventi punto sono inclusi la lettura di un misuratore, l'arrivo di un messaggio di posta elettronica, le selezioni effettuate da un utente nel Web, un tick per le azioni o una voce del registro eventi di Windows. Nell'esempio di monitoraggio dell'energia descritto in precedenza, è possibile che il flusso di eventi del misuratore di alimentazione venga rappresentato con i seguenti eventi punto. Si noti che l'ora di fine viene calcolata come ora di inizio più 1 tick (t).

Bordo

Un modello di eventi Edge rappresenta un'occorrenza dell'evento il cui payload è valido per un determinato intervallo di tempo. Tuttavia, poiché solo l'ora di inizio è nota all'arrivo al server StreamInsight, l'ora di fine viene impostata sull'ora massima in futuro. L'ora di fine dell'evento viene conosciuta in un secondo momento e viene aggiornata. Nel modello di eventi Edge sono contenute due proprietà, ovvero una relativa all'ora dell'occorrenza e l'altra al tipo di evento Edge. Insieme, queste proprietà definiscono il punto di inizio o di fine dell'evento Edge.

Nel diagramma seguente viene mostrato il layout di un modello di eventi Edge.

Negli esempi di eventi Edge sono inclusi i processi Windows, gli eventi di traccia di Event Tracing for Windows (ETW), una sessione utente sul Web o la quantizzazione di un segnale analogico. L'intervallo di tempo valido per il payload di un evento Edge è la differenza tra il timestamp dell'evento di inizio e il timestamp dell'evento di fine. Nel diagramma seguente si noti che per l'evento con valore di payload "c" non è nota una data di fine in questo punto del tempo.

Nella figura seguente viene illustrata la quantizzazione di un segnale analogico utilizzando eventi Edge basati sulle ore di inizio e di fine definite nella tabella precedente. Un segnale continuo di questo tipo implica che per ogni nuovo valore è necessario inviare sia un Edge END sia un Edge START. Gli Edge descritti nella figura fanno riferimento all'evento dall'ora t1 all'ora t3.

Considerazioni sulle prestazioni correlate alla scelta del modello di eventi

È importante scegliere il modello di eventi appropriato per il problema. Nel caso di eventi che durano per un periodo di tempo e se l'applicazione è in grado di determinare le ore di inizio e di fine dell'evento, è preferibile utilizzare eventi intervallo per la modellazione a tale scopo. Nel caso di uno scenario in cui non è nota l'ora di fine di un evento all'arrivo dell'evento, è possibile scegliere di eseguire la modellazione dell'evento come evento punto, modificarne la durata perché si estenda per un periodo di tempo e quindi utilizzare l'operazione di ritaglio per modificare la durata quando viene riconosciuta la fine dell'evento. L'altra alternativa consiste nella modellazione di questi eventi come eventi Edge.

Benché gli eventi Edge siano un modello di eventi molto efficace, è necessario tenere presenti alcune implicazioni sulle prestazioni. L'elaborazione di eventi Edge funziona in modo ottimale quando questi eventi arrivano completamente ordinati, ovvero tutti gli Edge iniziali sono ordinati in base all'ora di inizio e tutti gli Edge finali sono ordinati in base all'ora di fine e la sequenza combinata di eventi è anch'essa ordinata correttamente rispetto al tempo. In presenza, ad esempio, di una sequenza di eventi Edge simile alla seguente:

Questa sequenza è non ordinata in base ai timestamp (1, 10, 3, 6, 5, 20). Se, invece, gli eventi Edge fossero completamente ordinati, come nella sequenza (1, 3, 5, 6, 10, 20), vi sarebbe un impatto minore in termini di prestazioni sull'elaborazione delle query. È possibile abilitare questo ordinamento e quindi eseguire l'elaborazione in modo semplice. Suddividere il problema in due query. La prima query può essere una query vuota che riceve eventi Edge come input, li ordina completamente e restituisce gli eventi Edge ordinati. La seconda query può utilizzare questo input ed eseguire la logica principale. Si noti che è necessario definire tali query in due query distinte e quindi riunirle utilizzando la composizione dinamica di query. Per ulteriori informazioni, vedere Creazione di query in fase di esecuzione.

Payload di eventi

Il payload di un evento è una struttura di dati .NET contenente i dati associati all'evento. I campi nel payload sono definiti dall'utente e i relativi tipi sono basati sul sistema di tipi .NET. Per i campi di payload è supportata la maggior parte dei tipi scalari ed elementari CLR. I tipi annidati non sono supportati.

Adattatori

Gli adattatori traducono e recapitano i flussi di eventi in entrata e in uscita da e verso il server StreamInsight. StreamInsight fornisce un SDK per adattatori estremamente flessibile che consente di compilare adattatori per le origini evento e i dispositivi di output (sink) specifici del dominio. Gli adattatori vengono implementati nel linguaggio di programmazione C# e archiviati come assembly. Le classi degli adattatori vengono create come modelli durante la fase di progettazione e registrate nel server StreamInsight. Vengono quindi create le istanze di tali classi come istanze degli adattatori nel server durante la fase di esecuzione.

Adattatori di input

L'istanza di un adattatore di input accetta flussi di eventi in entrata da origini esterne quali database, file, feed di ticker, porte di rete, sensori e così via. L'adattatore di input legge gli eventi in entrata nel formato in cui vengono forniti e traduce tali dati nel formato di evento supportato dal server StreamInsight.

È necessario creare un adattatore di input per gestire le origini evento specifiche per l'origine dati. Se l'origine evento produce un solo tipo di evento, l'adattatore può essere tipizzato. Ovvero, è possibile implementare l'adattatore per generare eventi di un determinato tipo. Con un adattatore tipizzato, tutte le istanze dell'adattatore producono lo stesso formato di payload fisso in cui il numero di campi e i relativi tipi è noto in anticipo. Esempi di tali eventi sono dati di feed di ticker o dati del sensore generati da un dispositivo specifico. Se l'origine evento genera tipi diversi in circostanze diverse, ovvero se gli eventi possono contenere formati di payload diversi o se il formato di payload non è noto in anticipo, implementare un adattatore non tipizzato. Con un adattatore non tipizzato (generico), il formato di payload di eventi viene fornito dall'adattatore come parte di una specifica di configurazione in fase di associazione query. Esempi di origini di questo tipo includono file CSV contenenti un numero di campi variabile, in cui il tipo di dati archiviato nel file non è noto fino alla fase di creazione dell'istanza della query oppure un adattatore per tabelle di SQL Server in cui gli eventi generati dipendono dallo schema della tabella. È importante notare che, in fase di esecuzione, una sola istanza dell'adattatore, tipizzato o non tipizzato, genera sempre eventi di un tipo specifico. Gli adattatori non tipizzati forniscono un'implementazione flessibile per accettare la specifica del tipo di evento in fase di associazione query anziché definire il tipo di evento al momento dell'implementazione dell'adattatore.

Adattatori di output

È necessario creare un adattatore di output per ricevere gli eventi elaborati dal server StreamInsight, tradurre gli eventi in un formato previsto dal dispositivo di output (sink) e generare i dati in tale dispositivo. La progettazione e la creazione di un adattatore di output sono simili alla progettazione e alla creazione di un adattatore di input. Gli adattatori di output tipizzati sono progettati in base a un payload di eventi specifico, mentre per quelli non tipizzati il tipo di evento viene fornito solo in fase di esecuzione durante la creazione dell'istanza della query.

Per ulteriori informazioni, vedere Creazione di adattatori di input e di output. L'API dell'adattatore di base fornisce la flessibilità massima per l'implementazione rispetto a qualsiasi di origine evento o sink di evento. Inoltre, StreamInsight supporta origini evento e sink a un livello superiore di astrazione che implementano le interfacce IObservable o IEnumerable. Per ulteriori informazioni, vedere Utilizzo di origini evento e sink di evento Observable ed enumerabili (StreamInsight).

Elaborazione e analisi di eventi

Con StreamInsight, l'elaborazione dell'evento è organizzata in query basate sulla logica che viene definita. Queste query utilizzano un feed potenzialmente infinito di dati di input che variano in base al tempo (registrati o in tempo reale), eseguono calcoli sui dati e restituiscono il risultato in un modo appropriato.

Modelli di query

Un modello di query è l'unità fondamentale della composizione della query. Si tratta della struttura che definisce la logica di business necessaria per analizzare ed elaborare continuamente gli eventi inviati al server StreamInsight dall'adattatore di input e generare un flusso di eventi utilizzato dall'adattatore di output. Ad esempio, per valutare gli eventi del consumo di energia in ingresso nell'arco di un periodo di tempo specificato in relazione ai valori massimi o minim che superano determinate soglie prestabilite.

È possibile scrivere modelli di query per eseguire unità specifiche di lavoro e quindi comporli in modelli di query più complessi. I modelli di query sono scritti in LINQ combinato con il linguaggio C#. LINQ è una piattaforma di linguaggio che consente di esprimere un calcolo dichiarativo sui set in un modo completamente integrato nel linguaggio host. Di conseguenza, è possibile combinare l'elaborazione dichiarativa degli eventi con la flessibilità della programmazione procedurale nella stessa piattaforma di sviluppo, senza preoccuparsi della mancata corrispondenza di impedenza tra questi due paradigmi di programmazione.

Il server StreamInsight fornisce le funzionalità seguenti per scrivere query e analisi espressive:

• Calcoli per introdurre le proprietà dell'evento aggiuntive

  I casi di utilizzo quali le conversioni di unità richiedono l'esecuzione di calcoli sugli eventi ricevuti. Utilizzando l'operazione di proiezione nel server StreamInsight, è possibile aggiungere altri campi al payload ed eseguire calcoli sui campi nell'evento di input. Per ulteriori informazioni, vedere Proiezione.

• Filtro di eventi

  Nei casi di utilizzo come le notifiche di avviso potrebbe essere necessario controllare se un determinato campo payload supera le soglie operative per l'attrezzatura da monitorare. In generale, solo un subset di eventi che soddisfano caratteristiche determinate è rilevante per questi casi di utilizzo. Gli eventi che non dispongono di queste caratteristiche non devono essere elaborati e possono essere rimossi. L'operazione di filtro consente di esprimere predicati Boolean sul payload dell'evento ed eliminare gli eventi che non soddisfano i predicati. Per ulteriori informazioni, vedere Filtro.

• Raggruppamento di eventi

  Si consideri un flusso di eventi che fornisce le letture delle temperature da tutti i sensori di temperatura. Se tutti gli eventi vengono forniti tramite un singolo flusso di eventi, è possibile suddividere gli eventi in entrata in base al percorso del sensore o all'ID sensore. Il server StreamInsight fornisce un'operazione di raggruppamento che consente di suddividere il flusso in entrata in base alle proprietà degli eventi, quale il percorso o l'ID, e quindi applicare altre operazioni o completare i frammenti di query per ciascun gruppo separatamente. Per ulteriori informazioni, vedere Raggruppamento e applicazione.

• Finestre nel tempo

  Il raggruppamento di eventi nel tempo è un concetto efficace che abilita molti scenari. Ad esempio, si potrebbe voler controllare il numero di errori che si verificano durante un periodo di tempo prestabilito e generare un avviso se una soglia viene superata. Le finestre di salto e le finestre temporali scorrevoli consentono di definire le finestre nei flussi di eventi per eseguire questo tipo di analisi. Per ulteriori informazioni, vedere Utilizzo delle finestre di eventi.

• Aggregazione

  Quando i singoli eventi non sono importanti, potrebbe essere utile considerare i valori di aggregazione quali medie, somme o conteggi. Il server StreamInsight fornisce aggregazioni predefinite per sum, count, min, max e average, che operano in genere su intervalli di tempo. Per ulteriori informazioni, vedere Aggregazioni.

• Identificazione dei candidati TOP N

  Un tipo speciale di operazione di aggregazione è necessario nei casi di utilizzo in cui si desidera identificare gli eventi candidati con rango più alto in base a una metrica specifica in un flusso di eventi. Le operazioni TopK consentono di verificare tali condizioni in base a un ordine stabilito per i campi evento nel flusso. Per ulteriori informazioni, vedere TopK.

• Corrispondenza di eventi da flussi diversi

  Un caso di utilizzo comune consiste nel considerare gli eventi ricevuti da più flussi. Ad esempio, dal momento che le origini evento forniscono timestamp nei dati dell'evento, è necessario assicurarsi di eseguire solo la corrispondenza degli eventi in un flusso con un evento nel secondo flusso, se strettamente correlati nel tempo. È inoltre possibile che vi siano vincoli aggiuntivi sugli eventi di cui eseguire la corrispondenza e sui relativi tempi. Il server StreamInsight fornisce un'efficace operazione di join che esegue entrambe le attività: per prima cosa esegue la corrispondenza degli eventi dalle due origini se i tempi si sovrappongono e quindi esegue il predicato di join specificato nei campi payload. Il risultato di tale corrispondenza contiene i payload del primo e del secondo evento. Per ulteriori informazioni, vedere Join.

• Combinazione di eventi da flussi diversi in un flusso

  Più origini dati possono fornire eventi dello stesso tipo, che è possibile inserire nella stessa query. L'operazione di unione fornita dal server StreamInsight consente di moltiplicare diversi flussi di input in un singolo flusso di output. Per ulteriori informazioni, vedere Unioni.

• Estensioni definite dall'utente

  In alcuni casi, le funzionalità di query predefinite del server StreamInsight potrebbero non essere sufficienti. Per consentire estensioni specifiche del dominio, le query nel server StreamInsight possono richiamare funzionalità definite dall'utente fornite tramite assembly .NET. Oltre alle funzioni definite dall'utente, è possibile definire e implementare aggregazioni o operatori di query personalizzati. Per ulteriori informazioni, vedere Funzioni definite dall'utente (StreamInsight) e Funzioni di aggregazione e operatori definiti dall'utente.

Per ulteriori informazioni, vedere Scrittura di modelli di query in LINQ. Per istruzioni dettagliate sulla scrittura di query LINQ per StreamInsight, vedere la pagina Web contenente la guida alle query di StreamInsight.

Istanze di query

L'associazione di un modello di query a specifici adattatori di input e output consente di registrare un'istanza di query nel server StreamInsight. È possibile avviare, arrestare e gestire query associate nel server StreamInsight. Dopo aver inserito i dati nel server StreamInsight tramite gli adattatori di input, è possibile eseguire calcoli continui sui dati. In altri termini, quando singoli eventi arrivano nel server, questi vengono elaborati dalle query in esecuzione, che generano eventi di output in risposta all'arrivo di eventi di input. Nella figura seguente vengono illustrate le query e gli adattatori di StreamInsight in fase di esecuzione. Il server StreamInsight utilizza ed elabora l'evento quando l'istanza dell'adattatore di input viene associata a un'istanza di una query. I dati elaborati vengono indirizzati quindi all'istanza dell'adattatore di output che viene associato alla stessa istanza di query.

Vedere anche

Concetti

Architettura del server StreamInsight

Esempio end-to-end di StreamInsight