TIMESTAMP BY

✅ Analisi di flusso di Azure

A tutti gli eventi del flusso di dati è associato un timestamp. Per impostazione predefinita, gli eventi dell'hub eventi e dell'hub IoT vengono timestampati in base al momento in cui l'evento è stato ricevuto dall'hub eventi o dall'hub IoT; gli eventi dell'archivio BLOB vengono timestampati dall'ora dell'ultima modifica del BLOB. Il timestamp di un evento non cambia se si avvia nuovamente o si esegue di nuovo 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 può essere necessario che i timestamp degli 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 con distribuzione geografica possono contribuire a orari di arrivo imprevedibili, rendendo l'uso di un'applicazione più affidabile in un'applicazione di streaming. Per questi casi, la clausola TIMESTAMP BY consente di specificare valori di timestamp personalizzati. Il valore può essere qualsiasi campo dal payload o dall'espressione dell'evento 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 non in ordine rispetto ai timestamp per due motivi:

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

Mentre 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 producer di eventi in modo indipendente, la gestione degli eventi da ogni producer nella sequenza temporale è più efficiente rispetto alla gestione degli sfasamenti temporali tra i producer. Analisi di flusso di Azure supporta i sottostream specificando OVER <over spec-clause> per abilitare l'elaborazione di eventi in sequenze temporali indipendenti. Per l'impatto dell'uso della clausola OVER sull'elaborazione del processo, vedere 'CLAUSOLA OVER interagisce con l'ordinamento degli eventi'.

Syntax

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

Remarks

Recupero del timestamp dell'evento

Il timestamp dell'evento può essere recuperato nell'istruzione SELECT in qualsiasi parte della query tramite 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 non in ordine viene applicata all'interno di una singola tupla di valori superiore alla <specifica>. Ovvero, un evento viene considerato non in ordine solo se arriva troppo fuori ordine rispetto ad altri eventi dello stesso producer di eventi.

Ad esempio, un valore "0" può essere usato se gli eventi dello stesso producer di eventi vengono sempre ordinati e comportano un'elaborazione immediata. D'altra parte, l'uso di valori di grandi dimensioni in questo caso comporta ritardi di elaborazione, in attesa dell'assemblaggio degli eventi non ordinati.
La tolleranza massima per arrivo in ritardo viene applicata a livello globale (come se NON fosse stato usato OVER). 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 non in ordine). Un valore di diversi giorni non è irragionevole. Tuttavia, l'uso di valori eccezionalmente lunghi può avere un impatto sulla quantità di memoria necessaria per elaborare il processo.
Gli eventi di output per ogni producer di eventi vengono generati durante il calcolo, il che significa che gli eventi di output possono avere timestamp non ordinati; tuttavia, saranno in ordine all'interno di una singola tupla di valori di <sopra specifica>.

Limitazioni e restrizioni

La clausola TIMESTAMP BY OVER presenta le limitazioni di utilizzo seguenti:

La clausola TIMESTAMP BY OVER deve essere usata per tutti gli input della query o non per nessuna di esse.
La clausola TIMESTAMP BY OVER è supportata solo con processi completamente paralleli o processi a 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 utilizzata 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'unione tra flussi.
Le colonne create in un'istruzione SELECT o in qualsiasi altra clausola di query non possono essere utilizzate nella clausola TIMESTAMP BY, è necessario usare un campo del payload di input. Ad esempio, il risultato di un CROSS APPLY non può essere utilizzato 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, perché TIMESTAMP BY è ciò che stabilisce il valore di System.Timestamp().

Examples

Esempio 1: accedere a un campo timestamp dal payload

Usare EntryTime il campo del payload come timestamp dell'evento

SELECT  
      EntryTime,  
      LicensePlate,  
      State   
FROM input TIMESTAMP BY EntryTime

Esempio 2: usare l'ora 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:00 Coordinated Universal Time (UTC), giovedì 1 gennaio 1970.

In questo esempio viene illustrato come usare il campo numerico 'epochtime' contenente Epoch time 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' hanno dati timestamp nel campo 'timestampA' e gli 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 di mittenti diversi (stazioni a pagamento) senza applicare criteri di tempo a diversi ID stazione a pagamento. 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

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2025-07-10