Пользовательская временная метка не учитывается в пути BLOB-объектов для потоковой аналитики

Question

Учитывая запрос, который выглядит следующим образом:

SELECT
    EventDate,
    system.Timestamp as test
INTO
    [azuretableoutput]
FROM
    [csvdata] TIMESTAMP BY EventDate

Согласно документации, EventDate теперь должен использоваться как метка времени. Тем не менее, при сохранении данных в хранилище блогов по этому пути:

sadata/Y={datetime:yyyy}/M={datetime:MM}/D={datetime:dd}

Я, похоже, все равно получаю время проглатывания. В моем случае, время приема не значит ничего, и мне нужно использовать EventDate для пути. Это возможно?

При проверке данных в Visual Studio, test и EventDate должны быть равны, однако результаты выглядят так:

EventDate                   ;Test
2020-04-03T11:13:07.3670000Z;2020-04-09T02:16:15.5390000Z
2020-04-03T11:13:07.0460000Z;2020-04-09T02:16:15.5390000Z
2020-04-03T11:13:07.0460000Z;2020-04-09T02:16:15.5390000Z
2020-04-03T11:13:07.3670000Z;2020-04-09T02:16:15.5390000Z
2020-04-03T11:13:08.1470000Z;2020-04-09T02:16:15.5390000Z

Окно прибытия позднего допуска установлено как: 99: 23: 59: 59 Допустимое отклонение от заданного значения устанавливается как: 00: 00: 00: 00 с измененным действием на отклонение.

При выполнении того же запроса в Stream Analytics на Azure я получаю такой результат:

[{"eventdate":"2020-04-03T11:13:20.1060000Z","test":"2020-04-03T11:13:20.1060000Z"},
{"eventdate":"2020-04-03T11:13:20.1060000Z","test":"2020-04-03T11:13:20.1060000Z"},
{"eventdate":"2020-04-03T11:13:20.1060000Z","test":"2020-04-03T11:13:20.1060000Z"}] 

Пока все хорошо. При выполнении запроса с данными на Azure он создает этот путь:

 Y=2020/M=04/D=09

Он должен был создать этот путь: Y = 2020 / M = 04 / D = 03 Интересно, что при проверке данных, которые на самом деле хранится в blobstorage Я нахожу это:

EventDate,test
2020-04-03T11:20:39.3100000Z,2020-04-09T19:33:35.3870000Z,

System.timestamp, кажется, изменяется только при тестировании запроса на выборочных данных, но на самом деле не изменяется, когда запрос работает нормально и получает данные.

Я проверил это с настройкой позднего прибытия, установленной на 0 и 20 дней. На самом деле мне нужно отключить настройку позднего прибытия, поскольку я могу получать события, которым уже несколько лет.

Answer 1

Эта проблема была поднята и закрыта на MicrosoftDocs GitHub

Люди Microsoft говорят:

Максимальное количество дней для опоздания - 20, поэтому если политика установлена ​​на 99: 23: 59: 59 (99 дней). Корректировка может привести к расхождению в System.Timestamp.

По определению окна допуска позднего прибытия, для каждого входящего события, Azure Stream Analytics сравнивает время события с временем прибытия; если время события находится за пределами окна допуска, вы можете настроить систему на удаление события или отрегулировать время события, чтобы оно находилось в пределах допуска.

Учтите, что после создания водяных знаков служба потенциально может получать события с временем события ниже водяного знака. Вы можете настроить службу так, чтобы она отбрасывала эти события или настраивала время события на значение водяного знака.

Как часть корректировки, System.Timestamp события устанавливается в новое значение, но само поле времени события не изменяется. Эта корректировка является единственной ситуацией, когда событие System.Timestamp может отличаться от значения в поле времени события и может вызывать непредвиденные результаты.

Для получения дополнительной информации см. Описание обработки времени в Azure Stream Analytics .

К сожалению, тестирование с образцами данных на портале Azure в настоящее время не учитывает политики.

Потенциально другие полезные ресурсы:

• System.Timestamp ()
• TIMESTAMP BY
• Политики упорядочения событий
• Обработка времени
• Мониторинг заданий