Azure Запрос Stream Analytics с переключающимся окном с использованием BY TIMESTAMP отлично работает в тесте, но отключен при выполнении результатов задания

Question

Я работаю над проектом IoT. У меня есть Raspberry pi, который отправляет данные интеллектуального счетчика в концентратор событий IoT на Azure. Я читаю данные, используя Azure Stream Analytics Job. Показания счетчика отправляются каждые 10 секунд.

Один из созданных мной запросов вычисляет потребление электроэнергии за час с использованием переворачивающегося окна. Он рассчитывает максимальную читаемость метра из этого окна минус максимальная читаемость метра предыдущего окна, используя лаг. Я использую метку времени с устройства IOT вместо времени прибытия по умолчанию.

WITH onehourwindow AS
(
SELECT
    max(total_low) * 1000 as max_low,
    max(total_high) * 1000 as max_high,
    max(gas) * 1000 as max_gas,
    round(avg(current_consumption), 1) as avg_consumption,
    max(timestamp) as max_timestamp
FROM
    eventhuninputsmartmeter TIMESTAMP BY timestamp
GROUP BY TUMBLINGWINDOW(hour, 1)
)

SELECT 
    (max_low - LAG(max_low) OVER (LIMIT DURATION(hour, 1))) / 1000 as total_consumption_low,
    (max_high - LAG(max_high) OVER (LIMIT DURATION(hour, 1))) / 1000 as total_consumption_high,    
    (max_gas - LAG(max_gas) OVER (LIMIT DURATION(hour, 1))) / 1000 as total_consumption_gas,
    avg_consumption,
    max_timestamp
INTO 
    MeterReadingSQLDB
FROM
    onehourwindow

Запрос возвращает ожидаемые результаты в тесте. Вот пример отметки времени и потребления в результатах теста. Как и ожидалось, последняя отметка времени (max) - это последнее показание метра часа за 59 минут и около 50 секунд.

|----------------------------|---------------------------|
|      max_timestamp         |    total_consumption_high |
|----------------------------|---------------------------|
|2020-02-28T22:59:52.1794730 |         1.171             |
|2020-02-28T21:59:51.6680430 |         0.500             |
|----------------------------|---------------------------|

Когда я запускаю задание запроса, я получаю следующие результаты, записанные в мой SQL БД. Теперь последняя временная метка (max) не является последним показанием счетчика часов (часов), а вместо этого составляет 54 минуты. Если я делаю расчет потребления вручную, я вижу, что используемое окно составляет один час, оно просто начинается не с 00, а с 55 минут каждый час.

|----------------------------|---------------------------|
|      max_timestamp         |    total_consumption_high |
|----------------------------|---------------------------|
|2020-02-28T22:54:52.1300000 |         1.353             |
|2020-02-28T21:54:51.6830000 |         0.510             |
|----------------------------|---------------------------|

Как это решить? Я много чего перепробовал, но никак не могу это исправить. Ответ на пост, приведенный ниже, выглядел многообещающе, но мои события не приходят поздно, определенно не с опозданием на 6 минут. Таким образом, по-прежнему используются политики упорядочения событий по умолчанию.

Azure Потоковая аналитика «TimeStamp By» в запросе не работает на задании, но отлично работает на тесте

Любой мысли о том, чтобы исправить это так, чтобы я получил максимальную метку времени окна в 59 минут и 50 секунд или около того?

Спасибо!

Томас

Answer 1

Поскольку вы обрабатываете данные на основе метки времени в полезной нагрузке события, вполне вероятно, что политики порядка событий, которые вы используете для своей работы, отфильтровывают некоторые входные данные, которые могут вызывать эту проблему. Вы можете посмотреть на 2 метрики , чтобы понять, так ли это:

1. Поздние входные события
2. События вне очереди

Если на самом деле есть входные события, которые являются запоздалыми или не в порядке, убедитесь, что ваши политики упорядочения событий настроены соответствующим образом для включения или удаления таких событий. Вам также следует попытаться просмотреть образцы входных данных, чтобы увидеть, что метки времени соответствуют ожидаемым.

Answer 2

Согласно вашему подробному описанию: ваша тестовая работа хороша и выдает результаты, как вы хотите, я думаю, что sql работает, как и ожидалось, вероятно. Вы можете рассмотреть причины стороны потокового источника данных и настройки задания ASA.

Я использую метку времени с устройства IOT вместо времени прибытия по умолчанию.

На основе операторов из документа ASA TIMESTAMP BY, настраиваемый временная метка может вызвать задержку в результате сетевых или других факторов.

Я бы предложил вам установить offsize параметр в Windows Функция чтобы сбалансировать этот разрыв.