От концентратора IOT до нескольких таблиц в базе данных SQL Azure

Question

У меня есть концентратор IOT с устройствами, которые передают данные своих датчиков на него, чтобы сохранить их в базе данных SQL. Это, кажется, довольно легко сделать с помощью задания Stream Analytics.

Однако сложная часть выглядит следующим образом. Данные, которые я отправляю, не нормализованы, и, поскольку я использую базу данных SQL, я хотел бы структурировать их по нескольким таблицам. Это не кажется легкой задачей для Stream Analytics.

Это пример полезной нагрузки, которую я помещаю в концентратор IOT:

{
    "timestamp" : "2019-01-10 12:00",
    "section" : 1,
    "measurements" : 
    {
        "temperature" : 28.7,
        "height" : 280,
        "ec" : 6.8
    },
    "pictures" : {
        "101_a.jpg",
        "102_b.jpg",
        "103_c.jpg"
    }
}

В моей базе данных есть таблица Измерение , MeasurementItem и Изображение . Я хотел бы сохранить отметку времени и раздел в записи Измерение , температуру, высоту и т.д. в записи MeasurementItem и изображения в таблице Изображение . Заполнить одну таблицу легко, но для заполнения второй таблицы мне нужен сгенерированный идентификатор автоинкремента предыдущей записи, чтобы сохранить связь нетронутой.

Возможно ли это с помощью Stream Analytics, и если нет, то как мне это сделать?

Answer 1

У меня появилась функция Azure с триггером-концентратором IoT. Функция использует EF Core для хранения сообщений JSON в базе данных SQL, распределенной по нескольким таблицам. Я немного неохотно подходил к этому подходу, поскольку он вводит дополнительную логику, и я ожидал доплатить за это.

Противоположное оказалось правдой. Для функций Azure первые 400 000 ГБ / с выполнения и 1 000 000 выполнений бесплатны. Более того, это решение обеспечивает дополнительную гибкость и контроль, поскольку ограничение единой таблицы больше не применяется.

Answer 2

Вы не должны пробовать это с Stream Analytics (SA) по нескольким причинам. Он не предназначен для таких рабочих нагрузок, потому что в противном случае SA не сможет выполнять свою работу таким образом. Это просто отправка данных в один или несколько приемников в зависимости от входных данных.

Я бы предложил передать данные компоненту, который способен выполнять логику на стороне вывода. Есть несколько вариантов для этого. 2 примера могут быть:

• Azure Function (через триггер сервисной шины, указывающий на встроенную конечную точку концентратора IoT, как описано здесь )
• Триггер на основе таблицы событий в хранилище, в которое вы записываете данные IoT (так что вы снова могли бы использовать функцию Azure, но позволить ей запускаться событием из учетной записи хранилища)

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

Если у вас есть огромные объемы данных для обработки, вы можете рассмотреть архитектуру, использующую Учетная запись хранилища озера данных в сочетании с Data Lake Analytics . Последние могут собирать, объединять и распространять ваши входящие данные также в различные хранилища данных.