TIMESTAMP BY

✅ Azure Stream Analytics

Todos os eventos de fluxo de dados têm um carimbo de data/hora associado a eles. Por padrão, os eventos do Hub de Eventos e do Hub IoT têm carimbo de data/hora com base em quando o evento foi recebido pelo Hub de Eventos ou Hub IoT; eventos do armazenamento de Blob são marcados com a data e hora da última modificação do blob. O carimbo de data/hora de um evento não é alterado se você reiniciar ou executar novamente seu trabalho.

Muitos aplicativos de streaming exigem o uso do carimbo de data/hora exato em que um evento ocorreu, em vez da hora de chegada. Por exemplo, em um aplicativo de Ponto de Venda, pode-se precisar de carimbos de data/hora de evento correspondentes à hora em que um pagamento foi registrado, em vez da hora em que um evento de pagamento chega ao serviço de ingestão de eventos. Além disso, sistemas geo-distribuídos e latências de rede podem contribuir para tempos de chegada imprevisíveis, tornando o uso de um tempo de aplicativo mais confiável em um aplicativo de streaming. Para esses casos, a cláusula TIMESTAMP BY permite especificar valores de carimbo de data/hora personalizados. O valor pode ser qualquer campo da carga útil do evento ou expressão do tipo DATETIME. Valores de cadeia de caracteres em conformidade com qualquer um dos formatos ISO 8601 também são suportados.

Observe que o uso de um carimbo de data/hora personalizado (cláusula TIMESTAMP BY) pode fazer com que o Azure Stream Analytics ingira eventos fora de ordem em relação aos seus carimbos de data/hora por dois motivos:

Os produtores de eventos individuais podem ter relógios de sistema diferentes (e distorcidos).
Eventos de produtores de eventos individuais podem ser atrasados em trânsito, por exemplo, por indisponibilidade da rede no local do produtor.

Embora a desordem entre os produtores de eventos possa ser grande, a desordem dentro dos eventos de um único produtor é geralmente pequena ou mesmo inexistente. Caso uma consulta processe apenas dados de cada produtor de eventos de forma independente, lidar com eventos de cada produtor em sua própria linha do tempo é mais eficiente do que gerenciar distorções de tempo entre produtores. O Azure Stream Analytics dá suporte a subfluxos especificando a subcláusula OVER <spec> para habilitar o processamento de eventos em cronogramas independentes. Consulte 'A cláusula OVER interage com a ordem de eventos' para saber o impacto que o uso da cláusula OVER tem no processamento do trabalho.

Syntax

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

Remarks

Recuperando carimbo de data/hora do evento

O carimbo de data/hora do evento pode ser recuperado na instrução SELECT em qualquer parte da consulta usando a propriedade System.Timestamp().

A cláusula OVER interage com a ordenação de eventos

Quando a cláusula OVER é usada, vários aspetos do processamento de eventos pelo Azure Stream Analytics são modificados:

A tolerância máxima fora de ordem é aplicada dentro de uma única tupla de valor de <especificação excedente>. Ou seja, um evento só é considerado fora de ordem se chegar muito fora de ordem em relação a outros eventos do mesmo produtor de eventos.

Por exemplo, um valor de '0' pode ser usado se eventos do mesmo produtor de eventos forem sempre ordenados e resultarem em processamento imediato. Por outro lado, o uso de grandes valores aqui introduzirá atrasos de processamento, enquanto aguarda a montagem dos eventos fora de ordem.
A tolerância máxima de chegada tardia é aplicada globalmente (como se OVER não fosse usado). Ou seja, um evento é considerado de chegada tardia se o carimbo de data/hora escolhido (na cláusula TIMESTAMP BY) estiver muito longe da hora de chegada.

Observe que o uso de valores grandes aqui não introduzirá atrasos de processamento e os eventos ainda serão processados imediatamente (ou de acordo com a tolerância máxima fora de ordem). Um valor de vários dias não é despropositado. No entanto, o uso de valores excepcionalmente longos pode ter um impacto na quantidade de memória necessária para processar o trabalho.
Os eventos de saída para cada produtor de eventos são gerados à medida que são calculados, o que significa que os eventos de saída podem ter carimbos de data/hora fora de ordem; no entanto, eles estarão em ordem dentro de uma única tupla de valor de <especificação excedente>.

Limitações e Restrições

A cláusula TIMESTAMP BY OVER tem as seguintes limitações de uso:

A cláusula TIMESTAMP BY OVER deve ser usada para todas as entradas da consulta ou não deve ser usada para nenhuma delas.
A cláusula TIMESTAMP BY OVER só é suportada com trabalhos totalmente paralelos ou trabalhos de partição única.
Se o fluxo de entrada tiver mais de uma partição, a cláusula OVER deve ser usada juntamente com a cláusula PARTITION BY. A coluna PartitionId deve ser especificada como parte das colunas TIMESTAMP BY OVER.
Se a cláusula TIMESTAMP BY OVER for usada, os nomes das colunas da cláusula deverão ser usados como chave de agrupamento nas instruções GROUP BY e em todos os predicados JOIN ao unir entre fluxos.
As colunas criadas em uma instrução SELECT ou em qualquer outra cláusula de consulta não podem ser usadas na cláusula TIMESTAMP BY, um campo da carga útil de entrada deve ser usado. Por exemplo, o resultado de um CROSS APPLY não pode ser usado como o valor de destino do TIMESTAMP BY. No entanto, você pode usar um trabalho do Azure Stream Analytics que executa o CROSS APPLY e usar um segundo trabalho para executar o TIMESTAMP BY.
System.Timestamp() não pode ser usado em TIMESTAMP BY, pois TIMESTAMP BY é o que estabelece o valor de System.Timestamp().

Examples

Exemplo 1 – Aceder a um campo de carimbo de data/hora a partir da carga útil

Usar EntryTime campo da carga como carimbo de data/hora do evento

SELECT  
      EntryTime,  
      LicensePlate,  
      State   
FROM input TIMESTAMP BY EntryTime

Exemplo 2 – Usar a hora UNIX da carga como carimbo de data/hora do evento

Os sistemas UNIX geralmente usam o tempo POSIX (ou Epoch) definido como o número de milissegundos decorridos desde 00:00:00 Tempo Universal Coordenado (UTC), quinta-feira, 1 de janeiro de 1970.

Este exemplo mostra como usar o campo numérico 'epochtime' contendo Epoch time como carimbo de data/hora do evento.

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

Exemplo 3 – Carimbos de data/hora heterogéneos

Imagine o processamento de fluxos heterogéneos de dados contendo dois tipos de eventos «A» e «B». Os eventos 'A' têm dados de carimbo de data/hora no campo 'timestampA' e os eventos 'B' têm carimbo de data/hora no campo 'timestampB'.

Este exemplo mostra como escrever TIMESTAMP BY para poder trabalhar com ambos os tipos de eventos/carimbos de data/hora.

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

Exemplo 4 – Manipulando várias linhas do tempo em uma consulta particionada

Processe dados de diferentes remetentes (estações de pedágio) sem aplicar políticas de tempo em diferentes IDs de estações de pedágio. Os dados de entrada são particionados com base no TollId.

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

Feedback

Esta página foi útil?

Last updated on 2025-07-10