Есть ли способ определить «начальную точку» запуска задания? - PullRequest
0 голосов
/ 17 апреля 2019

Я переносу задание потоковой аналитики из Databricks / Spark в Azure Stream Analytics.Входные данные поступают из IoTHub, и запрос должен генерировать события каждый раз, когда значение датчика изменяется между пороговыми диапазонами (например, от «предупреждения» до «предупреждения»).

Существующее решение использует «потоковую передачу с отслеживанием состояния»,т.е. он хранит последнее состояние на устройство в памяти и сравнивает каждое новое сообщение.При запуске задания (или в некоторых дополнительных сценариях) отсутствует «последний статус»;в этом случае создается дополнительное событие, которое корректно обрабатывается нижестоящими компонентами.

Я пытаюсь реализовать эту функцию в ASA:

  1. Сравнение с последней записью может быть легкосделано с помощью
lag(value, 1, null) over (partition by(serialMachine) limit duration(minute, 60))
При тестировании с локальными входными данными результат, описанный выше, является пустым для первой записи, которую можно использовать для создания сообщения. Но при запуске в Azure "лаг" возвращает значение, , даже если исходная запись для него имеет временную метку до настроенного времени начала задания .Я предполагаю, что это рассматривается как «время начала вывода», и все доступные или, по крайней мере, некоторые сообщения загружаются из IoTHub независимо от этой отметки времени.

Я пытался использовать функции ISFIRST и LAST, но все этиобратитесь к временному окну, т.е. производные условия будут выполняться периодически.Но мне это нужно только один раз.

Есть идеи для обхода?

Ответы [ 2 ]

1 голос
/ 17 апреля 2019

Время начала задания фактически определяет время первого вывода. Однако Azure Stream Analytics будет оглядываться назад в потоке событий, в вашем случае 60 минут, поскольку у вас есть LAG с 60 минутами. Недавно мы добавили дополнительную информацию об этом поведении на стартовом задании . В вашем случае вы можете начать работу через 60 минут, чтобы не читать прошлую информацию.

Дайте мне знать, если у вас возникнут дополнительные вопросы, я буду рад помочь.

Спасибо

JS

0 голосов
/ 17 апреля 2019

Если я правильно понял, похоже, что исходная запись была скорректирована. Это означает, что System.Timestamp (т.е. фактически рассматриваемая временная метка) была «перемещена» в будущем, после времени начала. Вы пытались пропустить поздние события? Вы можете настроить свою политику в меню Configure -> Event Ordering.

Ссылка: Настройка политик упорядочения событий для Azure Stream Analytics

...