TIMESTAMP BY (Analisi di flusso di Azure)

Articolo
08/02/2024

Tutti gli eventi del flusso di dati hanno un timestamp associato. Per impostazione predefinita, gli eventi di Hub eventi e hub IoT vengono timestampati in base al momento in cui l'evento è stato ricevuto dall'hub eventi o hub IoT; gli eventi dell'archiviazione BLOB vengono timestampati dall'ultima volta modificata del BLOB. Il timestamp di un evento non cambia se si avvia di nuovo o si esegue nuovamente il processo.

Molte applicazioni di streaming richiedono l'uso del timestamp esatto che si è verificato un evento anziché l'ora di arrivo. Ad esempio, in un'applicazione Point of Sales, è possibile che siano necessari timestamp eventi corrispondenti al momento in cui è stato registrato un pagamento, anziché il momento in cui un evento di pagamento raggiunge il servizio di inserimento eventi. Inoltre, i sistemi e le latenze di rete distribuite geografica possono contribuire ai tempi di arrivo imprevedibili, rendendo più affidabile un'applicazione in un'applicazione di streaming. Per questi casi, la clausola TIMESTAMP BY consente di specificare valori timestamp personalizzati. Il valore può essere qualsiasi campo dal payload dell'evento o dall'espressione di tipo DATETIME. Sono supportati anche i valori stringa conformi a uno qualsiasi dei formati ISO 8601 .

Si noti che l'uso di un timestamp personalizzato (clausola TIMESTAMP BY) può causare l'inserimento di eventi di Analisi di flusso di Azure al di fuori dell'ordine rispetto ai timestamp per due motivi:

I singoli produttori di eventi possono avere orologi di sistema diversi (e asimmetria).
Gli eventi dei singoli produttori di eventi possono essere ritardati in transito, ad esempio in base alla rete indisponibilità nel sito del produttore.

Anche se il disturbo tra produttori di eventi può essere grande, il disturbo all'interno degli eventi di un singolo produttore è generalmente piccolo o persino inesistente. Nel caso in cui una query elabora solo i dati di ogni produttore di eventi in modo indipendente, la gestione degli eventi da ogni produttore nella propria sequenza temporale è più efficiente rispetto alla gestione degli intervalli di tempo tra i produttori. Analisi di flusso di Azure supporta i sottostream specificando <OVER over spec> sub-clause per abilitare l'elaborazione di eventi in sequenze temporali indipendenti. Per l'impatto sull'uso della clausola OVER per l'elaborazione del processo, vedere "Clausola OVER interagisce con l'ordinamento degli eventi".

Sintassi

TIMESTAMP BY scalar_expression [OVER <over spec> ]  
      
<over spec> ::= 
      { column_name | expression } [,...n ]

Osservazioni

Recupero del timestamp dell'evento

Il timestamp evento può essere recuperato nell'istruzione SELECT in qualsiasi parte della query usando la proprietà System.Timestamp().

La clausola OVER interagisce con l'ordinamento degli eventi

Quando viene usata la clausola OVER, vengono modificati diversi aspetti dell'elaborazione degli eventi da Analisi di flusso di Azure:

La tolleranza massima out-of-order viene applicata all'interno di una singola tupla di valore superiore <alla specifica>. Ovvero, un evento viene considerato fuori ordine solo se arriva troppo fuori ordine rispetto ad altri eventi dello stesso produttore di eventi.

Ad esempio, un valore di '0' può essere usato se gli eventi dello stesso produttore di eventi sono sempre ordinati e comportano un'elaborazione immediata. D'altra parte, l'uso di valori di grandi dimensioni introduce ritardi di elaborazione, in attesa dell'assemblaggio degli eventi non ordinati.
La tolleranza massima di arrivo in ritardo viene applicata a livello globale (come se OVER non è stata usata). Ovvero, un evento viene considerato in ritardo se il timestamp scelto (nella clausola TIMESTAMP BY) è troppo lontano dall'ora di arrivo.

Si noti che l'uso di valori di grandi dimensioni qui non introduce ritardi di elaborazione e gli eventi verranno comunque elaborati immediatamente (o in base alla tolleranza massima out-of-order). Un valore di diversi giorni non è insosonabile. Tuttavia, l'uso di valori estremamente lunghi può avere un impatto sulla quantità di memoria necessaria per elaborare il processo.
Gli eventi di output per ogni produttore di eventi vengono generati man mano che vengono calcolati, il che significa che gli eventi di output possono avere timestamp non ordinati; tuttavia, saranno in ordine all'interno di una singola tupla di valore di <over spec>.

Limitazioni e restrizioni

La clausola TIMESTAMP BY OVER presenta le limitazioni seguenti dell'utilizzo:

La clausola TIMESTAMP BY OVER deve essere usata per tutti gli input della query o non usati per nessuno di essi.
La clausola TIMESTAMP BY OVER è supportata solo con processi completamente paralleli o processi di partizione singola.
Se il flusso di input ha più di una partizione, la clausola OVER deve essere usata insieme alla clausola PARTITION BY. La colonna PartitionId deve essere specificata come parte delle colonne TIMESTAMP BY OVER.
Se viene usata la clausola TIMESTAMP BY OVER, i nomi di colonna della clausola devono essere usati come chiave di raggruppamento nelle istruzioni GROUP BY e in tutti i predicati JOIN durante l'aggiunta tra i flussi.
Le colonne create in un'istruzione SELECT o in altre clausole di query non possono essere usate nella clausola TIMESTAMP BY, è necessario usare un campo dal payload di input. Ad esempio, il risultato di una CROSS APPLY non può essere usato come valore di destinazione di TIMESTAMP BY. È tuttavia possibile usare un processo di Analisi di flusso di Azure che esegue CROSS APPLY e usare un secondo processo per eseguire TIMESTAMP BY.
System.Timestamp() non può essere usato in TIMESTAMP BY, poiché TIMESTAMP BY è il valore di System.Timestamp().

Esempio

Esempio 1: accedere a un campo timestamp dal payload

Usare EntryTime il campo dal payload come timestamp eventi

SELECT  
      EntryTime,  
      LicensePlate,  
      State   
FROM input TIMESTAMP BY EntryTime

Esempio 2: usare il tempo UNIX dal payload come timestamp dell'evento

I sistemi UNIX usano spesso l'ora POSIX (o Epoch) definita come numero di millisecondi trascorsi dalle 00:00:00 Coordinated Universal Time (UTC), giovedì 1 gennaio 1970.

In questo esempio viene illustrato come usare il campo 'epochtime' numerico contenente l'ora dell'epoca come timestamp dell'evento.

SELECT  
      System.Timestamp(),  
      LicensePlate,  
      State  
FROM input TIMESTAMP BY DATEADD(millisecond, epochtime, '1970-01-01T00:00:00Z')

Esempio 3 : timestamp eterogenei

Si supponga di elaborare flussi eterogenei di dati contenenti due tipi di eventi 'A' e 'B'. Gli eventi 'A' dispongono di dati timestamp nel campo 'timestampA' ed eventi 'B' hanno timestamp nel campo 'timestampB'.

In questo esempio viene illustrato come scrivere TIMESTAMP BY per poter usare entrambi i tipi di eventi/timestamp.

SELECT  
      System.Timestamp(),  
      eventType,  
      eventValue,  
FROM input TIMESTAMP BY  
      (CASE eventType   
            WHEN 'A' THEN timestampA  
            WHEN 'B' THEN timestampB  
      ELSE NULL END)

Esempio 4: gestione di più sequenze temporali in una query partizionata

Elaborare i dati da mittenti diversi (stazioni di pedaggio) senza applicare criteri di tempo tra id stazione di pedaggio diversi. I dati di input vengono partizionati in base a TollId.

SELECT
      TollId,
      COUNT(*) AS Count
FROM input
      TIMESTAMP BY EntryTime OVER TollId, PartitionId
      PARTITION BY PartitionId
GROUP BY TUMBLINGWINDOW(minute,3), TollId, PartitionId

Vedere anche

System.Timestamp()
Criteri dello sfasamento dell'ora
Informazioni sulla gestione del tempo in Analisi di flusso di Azure
Ora Unix

Condividi tramite