Latenza in Activator

L'attivatore del Fabric esegue le regole sui dati in tempo reale. I risultati sono quasi istantanei, ma vari fattori possono introdurre latenza. Nella maggior parte dei casi, non si nota questa latenza, ma in alcuni casi può essere fino a 10 minuti. La ricezione di informazioni accurate e tempestive è una considerazione importante quando si creano e ricevono regole. Questo articolo esamina i processi e le impostazioni che determinano l'equilibrio tra l'inclusione di eventi e la struttura delle regole e la velocità con cui Activator invia un'attivazione. Ad esempio, Activator deve consentire l'arrivo e l'inserimento di più dati oppure Activator deve garantire che i destinatari ricevano gli avvisi in un determinato momento? In che modo la struttura delle regole influisce sulla velocità con cui Activator invia un'attivazione ai destinatari?

Tre fattori importanti influisce sulla latenza di attivazione delle regole:

• Tolleranza di arrivo in ritardo.
• Latenza di elaborazione back-end.
• Latenza di aggregazione.

Tolleranza per arrivo in ritardo

Nei dati di streaming, gli eventi non arrivano sempre in ordine o in tempo. L'ora dell'evento di un evento (quando si è verificato) potrebbe rientrare nell'intervallo di tempo di una regola, ma l'ora di arrivo (quando Activator l'ha ricevuta) potrebbe rientrare all'esterno di tale finestra, rendendo l'evento in ritardo. Per impostazione predefinita, Activator elimina gli eventi tardivi dalla valutazione delle regole.

L'impostazione Tempo di attesa per gli eventi in arrivo in ritardo controlla per quanto tempo Activator attende prima di chiudere la finestra di valutazione, dando agli eventi in ritardo la possibilità di arrivare. Questa impostazione si trova nella sezione Impostazioni avanzate della schermata Definizione regola. Per informazioni su come configurarlo, vedere Impostazione di tolleranza per arrivo in ritardo.

Latenza di elaborazione back-end

L'attivatore potrebbe dover elaborare una regola prima dell'attivazione, che può introdurre un ritardo di un massimo di un minuto. Ad esempio, se la regola viene confrontata con un set di eventi precedente, Activator recupera i dati precedenti, esegue il confronto e calcola il risultato. Come altro esempio, se la regola viene eseguita su 10 milioni di righe di dati, anche l'elaborazione di tale volume da parte di Activator introduce latenza.

Latenza di aggregazione

Se viene usata un'aggregazione nella definizione della regola, la regola viene attivata solo quando viene completata l'intervallo di tempo specificato. Si supponga, ad esempio, che una regola venga compilata in base alla media dei dati in quattro ore. Se un evento che soddisfa le condizioni della regola viene inserito alle 12.00, la regola viene attivata alle 14.00. La latenza è il risultato delle impostazioni di aggregazione. Anche quando una regola include un'aggregazione semplice, ad esempio media, Activator non può inviare un'attivazione fino a quando Activator non esegue l'aggregazione tra i dati dell'evento in ingresso.

Concetti di base sul tempo

Per meglio inquadrare la discussione, definiamo alcuni concetti fondamentali sul tempo.

• Ora dell'evento: Ora in cui si è verificato l'evento originale. Fa parte del payload dell'evento. Ad esempio, il momento in cui un sensore rileva un'auto che si avvicina a un casello rappresenta il momento dell'evento.
• Tempo di elaborazione: ora in cui il sistema di elaborazione riceve e osserva l'evento. Ad esempio, dopo che il sensore del casello vede l'auto, il tempo in cui il sistema informatico riceve e elabora le informazioni del sensore è il tempo di elaborazione.
• Ora di arrivo (filigrana o ora di inserimento): un indicatore che mostra quando i dati dell'evento raggiungono Activator. Per la natura dei flussi, i dati dell'evento in ingresso non si arrestano mai, quindi gli orari di arrivo indicano l'avanzamento raggiunto da Activator fino a un certo punto nel flusso. È a questo punto che Activator può produrre risultati completi, corretti e ripetibili che non devono essere ritirati. E, a questo punto, Activator può iniziare a elaborare i dati. L'attivatore elabora i dati in modo prevedibile e ripetibile. Ad esempio, se Activator deve ricontare i dati per la gestione degli errori, può usare i tempi di arrivo come punti di partenza e di fine sicuri. Ad esempio, una volta che il sistema di casello ha ricevuto tutti i rilevamenti di auto fino alle 9:05, l'ora di arrivo avanza alle 9:05. I rilevamenti che arrivano dopo quel punto, anche se l'ora dell'evento era precedente alle 9:05, sono in ritardo.

L'arrivo in ritardo si verifica quando una regola ha un parametro di ora e l'ora dell'evento rientra in tale parametro di ora, ma l'ora di arrivo non rientra. Consideriamo l'esempio del casello: il sensore rileva l'auto e il tempo dell'evento rientra nell'intervallo di tempo della regola. Tuttavia, se il sensore richiede troppo tempo per trasmettere il rilevamento, ad esempio a causa della congestione della rete, l'evento arriva all'attivatore dopo la chiusura della finestra. L'attivatore considera l'evento in ritardo. Se si desidera includere gli arrivi in ritardo, impostare l'ora di attesa per gli eventi in arrivo in ritardo in Impostazioni avanzate.

Per altre informazioni su questo argomento, vedere i post di blog di Tyler Akidau Streaming 101 e Streaming 102.

Impostazione della tolleranza per arrivo in ritardo

È possibile configurare l'impostazione di tolleranza di arrivo in ritardo. Il valore predefinito è di due minuti. Questa impostazione contribuisce alla latenza. Le regole create con un tempo di attesa hanno una latenza minima uguale alla durata configurata. Quando si crea una regola, decidere se usare l'impostazione predefinita o modificarla. L'impostazione garantisce che gli eventi in ritardo e gli eventi non ordinati abbiano la possibilità di essere inclusi nella valutazione delle regole. Se un evento non rientra nella tolleranza di arrivo in ritardo configurata, Activator non lo prende in considerazione. Qualsiasi evento con un orario di arrivo dopo tale soglia non viene preso in considerazione.

Screenshot della schermata della definizione della regola con le impostazioni avanzate aperte, che mostra l'impostazione del tempo di attesa per gli eventi che arrivano in ritardo.

In generale, valutare se è più importante:

• Attendere i punti dati in ritardo o
• Eseguire la regola su dati potenzialmente incompleti in modo che la regola venga attivata prima. 

In questo esempio, i punti dati vengono misurati in incrementi di 15 minuti. I primi tre puntini, che sono blu, ci riescono nell'intervallo di tempo. Il quarto punto, che è arancione, non lo fa. L'ora dell'evento rientra nell'intervallo di 15 minuti, ma l'evento non viene inserito da Activator entro l'intervallo di 15 minuti. L'attivatore valuta solo la regola sui dati con un'ora di arrivo entro la finestra di 15 minuti. A meno che non si aumenti la tolleranza di arrivo in ritardo, i punti dati che arrivano dopo la chiusura della finestra non sono inclusi.

L'attivatore non può tenere conto dei ritardi delle origini dati. Ad esempio, potrebbero essere presenti sensori IoT offline per un'ora. Quando tornano online, Activator può ricevere i dati, ma i dati sono stati posticipati per un'ora dallo stato offline, che si verifica al di fuori di Activator.

Di seguito è riportato un altro esempio.

Si crea una regola che calcola la temperatura media in intervalli di minuti. Il tempo di attesa per gli eventi in ritardo è impostato sul valore predefinito di due minuti. L'attivatore include valori di temperatura 20 e 30 e calcola una media di 25. Tuttavia, Activator non include l'evento arrivato in ritardo di 40 gradi fino alla successiva attivazione della regola.

Regole basate sugli oggetti visivi di Power BI

La latenza predefinita varia in base al servizio. La latenza per i flussi di eventi è diversa dalla latenza per gli oggetti visivi di Power BI. Due fattori influiscono sulla latenza per le regole basate su oggetti visivi di Power BI: la frequenza di esecuzione di interrogazioni sugli oggetti visivi di Power BI costruiti nel sistema e un ritardo che il back-end di Activator potrebbe introdurre.

Le regole di Power BI vengono valutate ogni volta che arrivano nuovi dati in Activator. Per impostazione predefinita, Activator esegue query Power BI una volta all'ora, il che significa che gli eventi che soddisfano la condizione della regola attivano un'attivazione al massimo di un'ora dopo l'evento. È possibile modificare questa frequenza nelle impostazioni dell'origine dati. Per ulteriori informazioni, vedere frequenza delle query per le origini dati di query e impostare avvisi in Power BI e modificarli nel Fabric Activator.