TIMESTAMP BY (Azure Stream Analytics)

Artigo
08/02/2024

Todos os eventos de fluxo de dados têm um carimbo de data/hora associado aos mesmos. Por predefinição, os eventos do Hub de Eventos e Hub IoT são carimbos de data/hora com base no momento em que o evento foi recebido pelo Hub de Eventos ou Hub IoT; os eventos do Armazenamento de blobs são marcados pela hora da última modificação do blob. O carimbo de data/hora de um evento não será alterado se voltar a iniciar ou executar novamente a sua tarefa.

Muitas aplicações de transmissão em fluxo necessitam de utilizar o carimbo de data/hora exato em que ocorreu um evento, em vez da hora de chegada. Por exemplo, numa aplicação Ponto de Vendas, pode precisar de carimbos de data/hora de evento correspondentes à hora em que um pagamento foi registado, em vez da hora em que um evento de pagamento atinge o serviço de ingestão de eventos. Além disso, os sistemas geográficos distribuídos e as latências de rede podem contribuir para tempos de chegada imprevisíveis, tornando a utilização de um tempo de aplicação mais fiável numa aplicação de transmissão em fluxo. Para estes casos, a cláusula TIMESTAMP BY permite especificar valores de carimbo de data/hora personalizados. O valor pode ser qualquer campo do payload do evento ou expressão do tipo DATETIME. Os valores de cadeias em conformidade com qualquer um dos formatos ISO 8601 também são suportados.

Tenha em atenção que a utilização de um carimbo de data/hora personalizado (cláusula TIMESTAMP BY) pode fazer com que o Azure Stream Analytics ingira eventos fora de ordem relativamente aos respetivos carimbos de data/hora por dois motivos:

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

Embora a desordem entre os produtores de eventos possa ser grande, a desordem nos acontecimentos 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 na sua própria linha cronológica é mais eficiente do que gerir distorções de tempo entre produtores. O Azure Stream Analytics suporta substreams ao especificar a sub-cláusula OVER <over spec> para permitir o processamento de eventos em linhas cronológicas independentes. Veja "A cláusula OVER interage com a ordenação de eventos" para obter o impacto que a utilização da cláusula OVER tem no processamento da tarefa.

Syntax

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

Observações

A obter o carimbo de data/hora do evento

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

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

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

A tolerância máxima fora de ordem é aplicada numa única cadeia de valores de <especificações superiores>. Ou seja, um evento só é considerado fora de ordem se chegar demasiado fora de ordem em relação a outros eventos do mesmo produtor de eventos.

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

Tenha em atenção que a utilização de valores grandes aqui não irá introduzir atrasos no processamento e os eventos continuarão a ser processados imediatamente (ou de acordo com a tolerância máxima fora de ordem). Um valor de vários dias não é irracional. No entanto, a utilização de valores excecionalmente longos pode ter um impacto na quantidade de memória necessária para processar a tarefa.
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, estarão por ordem dentro de uma única cadeia de valor de mais especificações<>.

Limitações e Restrições

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

A cláusula TIMESTAMP BY OVER tem de ser utilizada para todas as entradas da consulta ou não é utilizada para nenhuma delas.
A cláusula TIMESTAMP BY OVER só é suportada com tarefas totalmente paralelas ou tarefas de partição única.
Se o fluxo de entrada tiver mais do que uma partição, a cláusula OVER tem de ser utilizada juntamente com a cláusula PARTITION BY. A coluna PartitionId tem de ser especificada como parte das colunas TIMESTAMP BY OVER.
Se for utilizada a cláusula TIMESTAMP BY OVER, os nomes das colunas da cláusula têm de ser utilizados como chave de agrupamento em instruções GROUP BY e em todos os predicados JOIN ao associar entre fluxos.
As colunas criadas numa instrução SELECT ou em quaisquer outras cláusulas de consulta não podem ser utilizadas na cláusula TIMESTAMP BY, tem de ser utilizado um campo do payload de entrada. Por exemplo, o resultado de uma Aplicação CRUZADA não pode ser utilizado como o valor de destino de TIMESTAMP BY. No entanto, pode utilizar uma tarefa do Azure Stream Analytics que executa a função CROSS APPLY e utilizar uma segunda tarefa para executar o TIMESTAMP BY.
System.Timestamp() não pode ser utilizado em TIMESTAMP BY, uma vez que TIMESTAMP BY é o que estabelece o valor de System.Timestamp().

Exemplos

Exemplo 1 – Aceder a um campo de carimbo de data/hora a partir do payload

Utilizar EntryTime o campo do payload como carimbo de data/hora do evento

SELECT  
      EntryTime,  
      LicensePlate,  
      State   
FROM input TIMESTAMP BY EntryTime

Exemplo 2 – utilizar o tempo UNIX do payload como carimbo de data/hora do evento

Os sistemas UNIX utilizam frequentemente o tempo POSIX (ou Época) definido como o número de milissegundos decorridos desde 00:00:00 Hora Universal Coordenada (UTC), quinta-feira, 1 de janeiro de 1970.

Este exemplo mostra como utilizar o campo "epochtime" numérico que contém a hora da época 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 que contêm 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 "carimbo de data/horaB".

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 – Processar várias linhas cronológicas numa consulta particionada

Processe dados de diferentes remetentes (estações de portagem) sem aplicar políticas de tempo em diferentes IDs de portagens. 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

Consulte também

System.Timestamp()
Políticas de Distorção de Tempo
Compreender o processamento de tempo no Azure Stream Analytics
Hora Unix

Partilhar via