TIMESTAMP BY (Azure Stream Analytics)

Artículo
07/12/2023

Todos los eventos de flujo de datos tienen asociada una marca de tiempo. De forma predeterminada, los eventos del centro de eventos y los IoT Hub se marcan de tiempo en función de cuándo el centro de eventos recibió el evento o IoT Hub; los eventos de Blob Storage se marcan por tiempo con la hora de la última modificación del blob. La marca de tiempo de un evento no cambia si vuelve a iniciar o volver a ejecutar el trabajo.

Muchas aplicaciones de streaming requieren usar la marca de tiempo exacta que se produjo un evento, en lugar de la hora de llegada. Por ejemplo, en una aplicación de punto de venta, es posible que necesite marcas de tiempo de evento correspondientes a la hora en que se registró un pago, en lugar del momento en que un evento de pago alcanza el servicio de ingesta de eventos. Además, los sistemas distribuidos geográficamente y las latencias de red pueden contribuir a tiempos de llegada impredecibles, lo que hace que el uso de una aplicación sea más confiable en una aplicación de streaming. En estos casos, la cláusula TIMESTAMP BY permite especificar valores de marca de tiempo personalizados. El valor puede ser cualquier campo de la carga del evento o la expresión de tipo DATETIME. También se admiten valores de cadena conformes a cualquiera de los formatos ISO 8601 .

Tenga en cuenta que el uso de una marca de tiempo personalizada (cláusula TIMESTAMP BY) puede hacer que Azure Stream Analytics ingiera eventos desordenados con respecto a sus marcas de tiempo por dos motivos:

Los productores de eventos individuales pueden tener relojes del sistema diferentes (y sesgados).
Los eventos de los productores de eventos individuales pueden retrasarse en tránsito, por ejemplo, por falta de disponibilidad de red en el sitio del productor.

Aunque el trastorno entre productores de eventos puede ser grande, el trastorno dentro de los eventos de un solo productor es generalmente pequeño o incluso no existente. En caso de que una consulta solo procese datos de cada productor de eventos de forma independiente, controlar eventos de cada productor en su propia escala de tiempo es más eficaz que administrar los sesgos de tiempo entre los productores. Azure Stream Analytics admite substreams especificando over <over spec> sub-clause para habilitar el procesamiento de eventos en escalas de tiempo independientes. Vea la cláusula "OVER interactúa con el orden de eventos" para ver el impacto que tiene el uso de la cláusula OVER en el procesamiento del trabajo.

Sintaxis

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

Observaciones

Recuperación de la marca de tiempo del evento

La marca de tiempo del evento se puede recuperar en la instrucción SELECT en cualquier parte de la consulta mediante la propiedad System.Timestamp().

La cláusula OVER interactúa con el orden de eventos

Cuando se usa la cláusula OVER, se modifican varios aspectos del procesamiento de eventos por Parte de Azure Stream Analytics:

La tolerancia máxima fuera de orden se aplica dentro de una tupla de valor único de <sobre especificaciones>. Es decir, un evento solo se considera desordenados si llega demasiado desordenados con respecto a otros eventos del mismo productor de eventos.

Por ejemplo, se puede usar un valor de '0' si los eventos del mismo productor de eventos siempre están ordenados y darán lugar a un procesamiento inmediato. Por otro lado, el uso de valores grandes aquí introducirá retrasos de procesamiento, mientras espera a que los eventos desordenados se ensamblan.
La tolerancia máxima de llegada tardía se aplica globalmente (como si no se usara OVER). Es decir, se considera que un evento llega tarde si su marca de tiempo elegida (en la cláusula TIMESTAMP BY) está demasiado lejos de su hora de llegada.

Tenga en cuenta que el uso de valores grandes aquí no introducirá retrasos de procesamiento y los eventos se seguirán procesando inmediatamente (o según la tolerancia de desorden máxima). Un valor de varios días no es irrazonable. Sin embargo, el uso de valores excepcionalmente largos puede tener un impacto en la cantidad de memoria necesaria para procesar el trabajo.
Los eventos de salida para cada productor de eventos se generan a medida que se calculan, lo que significa que los eventos de salida pueden tener marcas de tiempo desordenadas; sin embargo, estarán en orden dentro de una tupla de valor único de <over spec>.

Limitaciones y restricciones

La cláusula TIMESTAMP BY OVER tiene las siguientes limitaciones de uso:

La cláusula TIMESTAMP BY OVER debe usarse para todas las entradas de la consulta o no para ninguna de ellas.
La cláusula TIMESTAMP BY OVER solo se admite con trabajos totalmente paralelos o trabajos de partición única.
Si el flujo de entrada tiene más de una partición, la cláusula OVER debe usarse junto con la cláusula PARTITION BY. La columna PartitionId debe especificarse como parte de las columnas TIMESTAMP BY OVER.
Si se usa la cláusula TIMESTAMP BY OVER, los nombres de columna de la cláusula se deben usar como clave de agrupación en instrucciones GROUP BY y en todos los predicados JOIN al combinar entre secuencias.
Las columnas creadas en una instrucción SELECT o en cualquier otra cláusula de consulta no se pueden usar en la cláusula TIMESTAMP BY, se debe usar un campo de la carga de entrada. Por ejemplo, el resultado de cross APPLY no se puede usar como valor de destino de TIMESTAMP BY. Sin embargo, puede usar un trabajo de Azure Stream Analytics que realice CROSS APPLY y usar un segundo trabajo para realizar TIMESTAMP BY.
System.Timestamp() no se puede usar en TIMESTAMP BY, ya que TIMESTAMP BY es lo que establece el valor de System.Timestamp().

Ejemplos

Ejemplo 1: Acceso a un campo de marca de tiempo desde la carga

Uso EntryTime del campo de la carga como marca de tiempo del evento

SELECT  
      EntryTime,  
      LicensePlate,  
      State   
FROM input TIMESTAMP BY EntryTime

Ejemplo 2: uso de la hora unix de la carga como marca de tiempo del evento

Los sistemas UNIX suelen usar la hora POSIX (o Época) definida como el número de milisegundos que han transcurrido desde las 00:00:00:00 Hora universal coordinada (UTC), jueves, 1 de enero de 1970.

En este ejemplo se muestra cómo usar el campo numérico "epochtime" que contiene la hora de época como marca de tiempo de evento.

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

Ejemplo 3: marcas de tiempo heterogéneas

Imagine el procesamiento de flujos heterogéneos de datos que contienen dos tipos de eventos "A" y "B". Los eventos "A" tienen datos de marca de tiempo en el campo "timestampA" y los eventos "B" tienen marca de tiempo en el campo "timestampB".

En este ejemplo se muestra cómo escribir TIMESTAMP BY para poder trabajar con ambos tipos de eventos o marcas de tiempo.

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

Ejemplo 4: Control de varias escalas de tiempo en una consulta con particiones

Procesar datos de diferentes remitentes (estaciones de peaje) sin aplicar directivas de tiempo en diferentes identificadores de estación de peaje. Los datos de entrada se particionan en función de 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 también

System.Timestamp()
Directivas de desfase horario
Descripción del control del tiempo en Azure Stream Analytics
Hora de Unix