Потоковая аналитика в концентратор событий - неожиданно объединяющие события

У меня есть задание потоковой аналитики, которое использует Event Hub из авро-сообщений (назовем это RawEvents), преобразует / выравнивает сообщения и запускает их в отдельный Event Hub (назовем это FormattedEvents).

Каждый экземпляр EventData в RawEvents состоит из одного объекта json верхнего уровня, который имеет массив более подробных событий. Это надуманный пример:

[{"Events": [{"dataOne": 123.0, "dataTwo": 234.0, "subEventCode": 3, "dateTimeLocal": 1482170771, "dateTimeUTC": 1482192371}, {"dataOne": 456.0, "dataTwo": 789.0, "subEventCode": 20, "dateTimeLocal": 1482170771, "dateTimeUTC": 1482192371}], "messageType": "myDeviceType-Events", "deviceID": "myDevice",}]

Задание Stream Analytics выравнивает результаты и распаковывает subEventCode, который является битовой маской. Результаты выглядят примерно так:

{ "MessageType": "myDeviceType-событие", "DeviceID": "MyDevice", EventID: 1, "Dataone":123,"datatwo":234,"subeventcode":6,"flag1":0,"flag2":1,"flag3":1,"flag4":0,"flag5":0,"flag6":0,"flag7":0,"flag8":0,"flag9":0,"flag10":0,"flag11":0,"flag12":0,"flag13":0,"flag14":0,"flag15":0,"flag16":0,"eventepochlocal":"2016-12-06T17:33:11.0000000Z","eventepochutc":"2016-12-06T23:33:11.0000000Z"} {"messagetype":"myDeviceType-Event","deviceid":"myDevice",eventid:2,"dataone":456,"datatwo":789,"subeventcode":8,"flag1":0,"flag2":0,"flag3":0,"flag4":1,"flag5":0,"flag6":0,"flag7":0,"flag8":0,"flag9":0,"flag10":0,"flag11":0,"flag12":0,"flag13":0,"flag14":0,"flag15":0,"flag16":0,"eventepochlocal":"2016-12-06T17:33:11.0000000Z","eventepochutc":"2016-12-06T23:33:11.0000000Z"}

Я ожидаю увидеть два экземпляра EventData при извлечении сообщений из концентратора событий FormattedEvents. То, что я получаю, это один EventData с обоими "сплющенными" событиями в одном и том же сообщении. Это ожидаемое поведение при нацеливании на хранилище больших двоичных объектов или озеро данных, но удивительно при нацеливании на концентратор событий. Я ожидал, что поведение будет похоже на служебную шину.

Это ожидаемое поведение? Есть ли опция конфигурации, чтобы заставить поведение, если так?

2 ответа

Решение

Да, это ожидаемое поведение в настоящее время. Цель состояла в том, чтобы улучшить пропускную способность, пытаясь отправить как можно больше событий в сообщении EventHub (EventData).

К сожалению, на сегодняшний день нет никакой опции конфигурации, чтобы переопределить это поведение. Один из возможных способов, который стоит попробовать, - это использовать концепцию ключа раздела вывода для чего-то сверх уникального (т.е. добавить этот столбец к вашему запросу - GetMetadataPropertyValue(ehInput, "EventId") в качестве outputpk) . Теперь укажите этот "outputpk" как PartitionKey в настройках ASA вашего выходного EventHub.

Дайте мне знать, если это поможет.

ура Четан

Я столкнулся с той же проблемой. Спасибо за ответы по ручному форматированию входного сообщения. Я решил это с моим коллегой с помощью нескольких строк кода, которые убрали перевод строки и возврат каретки. Затем я заменил "}{" на "},{" и сделал его массивом, добавив "[" и "]" к обоим концам.

string modifiedMessage = myEventHubMessage.Replace("\n","").Replace("\r","");    
modifiedMessage = "[" + modifiedMessage.Replace("}{","},{") + "]";

И затем сделать ввод в виде списка объектов в соответствии с его структурой данных:

List<TelemetryDataPoint> newDataPoints = new List<TelemetryDataPoint>();
try
{
    newDataPoints = Newtonsoft.Json.JsonConvert.DeserializeObject<List<TelemetryDataPoint>>(modifiedMessage);

........

Другие вопросы по тегам