Шаблоны решений Azure Stream Analytics
Как и многие другие службы в Azure, Stream Analytics лучше использовать с другими службами для создания крупномасштабного комплексного решения. В этой статье обсуждаются простые решения Azure Stream Analytics и различные архитектурные шаблоны. На основе этих шаблонов можно создавать более сложные решения. Шаблоны, описанные в этой статье, можно использовать в самых разнообразных сценариях. Примеры шаблонов для конкретных сценариев приведены в обзоре видов архитектуры решений Azure.
Создание задания Stream Analytics для работы с панелями мониторинга в режиме реального времени
С помощью Azure Stream Analytics можно быстро создавать панели мониторинга и оповещения в режиме реального времени. Простое решение принимает события из Центров событий или Центра Интернета вещей и осуществляет потоковую передачу наборов данных в панель мониторинга Power BI. Дополнительные сведения см. в подробном руководстве Анализ данных телефонных звонков, осуществляемых в мошеннических целях, с помощью Stream Analytics и визуализация результатов на панели мониторинга Power BI.
Это решение можно создать всего через несколько минут с помощью портал Azure. Вам не нужно кодировать подробно. Вместо этого можно использовать язык SQL для выражения бизнес-логики.
Этот шаблон решения обеспечивает наименьшую задержку при передаче данных от источника события на панель мониторинга Power BI в браузере. Azure Stream Analytics — единственная служба Azure в которую встроена эта возможность.
Использование SQL для панели мониторинга
Панель мониторинга Power BI обеспечивает низкую задержку, но ее нельзя использовать для создания полных отчетов Power BI. Согласно общему шаблону отчетов сначала ваши данные выводятся в базу данных SQL. Затем соединитель SQL для Power BI используется, чтобы запросить последние данные в SQL.
При использовании База данных SQL она обеспечивает большую гибкость, но за счет немного более высокой задержки. Это решение является оптимальным для заданий, которым требуется задержка более одной секунды. При использовании этого метода можно максимизировать возможности Power BI для дальнейшего среза и dice данных для отчетов, а также гораздо больше возможностей визуализации. Кроме того, вы получаете возможность гибкого использования других решений панели мониторинга, например Tableau.
SQL не является хранилищем данных высокой пропускной способности. Максимальная пропускная способность из Azure Stream Analytics в базу данных SQL в настоящее время составляет приблизительно 24 МБ/с. Если источники событий в решении производит данные с более высокой скоростью, необходимо использовать логику обработки в Stream Analytics, чтобы уменьшить скорость вывода данных в SQL. Вы можете использовать такие методы, как фильтрация, оконные агрегаты, сопоставление шаблонов с темпоральными соединениями и аналитические функции. Вы можете оптимизировать скорость вывода в SQL с помощью методов, описанных в выходных данных Azure Stream Analytics, для База данных SQL Azure.
Внедрение в приложение анализа в реальном времени с использованием сообщений о событиях
Вторым наиболее популярным способом использованием Stream Analytics является создание оповещений в режиме реального времени. В этом шаблоне решения бизнес-логику в Stream Analytics можно использовать для обнаружения временных и пространственных шаблонов или аномалий, а затем создавать сигналы предупреждения. Однако в отличие от решения панели мониторинга, в котором Stream Analytics использует Power BI в качестве предпочтительной конечной точки, можно использовать другие промежуточные приемники данных. Эти приемники включают концентраторы событий, служебную шину и Функции Azure. Вы, как создатель приложений, должны решить, какой приемник данных лучше подходит для вашего сценария.
Для создания оповещений в существующем бизнес-рабочем процессе необходимо реализовать нижестоящий логику потребителя событий. Так как вы можете реализовать пользовательскую логику в Функциях Azure, то Функции Azure — это самый быстрый способ для выполнения этой интеграции. Руководство по использованию функции Azure в качестве выходных данных для задания Stream Analytics см. в статье "Запуск Функции Azure из заданий Azure Stream Analytics". Функции Azure также поддерживают различные типы уведомлений, включая текстовые уведомления и электронные письма. Вы также можете использовать Logic Apps для такой интеграции с Центрами событий между Stream Analytics и Logic Apps.
Центры событий Azure служба, с другой стороны, предлагает самую гибкую точку интеграции. Многие другие службы, такие как Azure Data Explorer и Аналитика временных рядов, могут использовать события из концентраторов событий. Службы могут быть подключены непосредственно к приемнику Центров событий из Azure Stream Analytics для завершения решения. Концентраторы событий — это также брокер обмена сообщениями самой большой пропускной способностью, доступный в Azure для таких сценариев интеграции.
Динамические приложения и веб-сайты
Вы можете создавать пользовательские визуализации в режиме реального времени, например панель мониторинга или визуализацию сопоставлений, с помощью Azure Stream Analytics и службы Azure SignalR. При использовании SignalR веб-клиенты могут обновляться и отображать динамическое содержимое в режиме реального времени.
Внедрение анализа в реальном времени в приложение с использованием хранилище данных
Сегодня большинство веб-служб и веб-приложений для обслуживания уровня представления используют шаблон "запрос — ответ". Шаблон запроса и ответа прост в сборке и можно легко масштабировать с низким временем отклика с помощью внешнего интерфейса без отслеживания состояния и масштабируемых хранилищ, таких как Azure Cosmos DB.
Большой объем данных часто создает узкие места, влияющие на производительность в системе на базе CRUD. Шаблон решения источников событий используется для устранения узких мест, влияющих на производительность. Кроме того, темпоральные шаблоны и аналитические сведения сложно и неэффективно извлекаются из традиционного хранилища данных. Современные приложения, управляемые большими объемами данных, часто используют архитектуру, основанную на потоках. Azure Stream Analytics как подсистема вычислений для передаваемых данных является краеугольным камнем в этой архитектуре.
В этом шаблоне решения события обрабатываются и агрегируются в хранилищах данных Azure Stream Analytics. Уровень приложения взаимодействует с хранилищами данных, используя традиционный шаблон "запрос — ответ". Из-за способности Stream Analytics обрабатывать большое количество событий в режиме реального времени приложение обладает высокой степенью масштабируемости без необходимости наращивать уровень хранилища данных. Уровень хранилища данных по сути является материализованным представлением в системе. Выходные данные Azure Stream Analytics в Azure Cosmos DB описывают, как Azure Cosmos DB используется в качестве выходных данных Stream Analytics.
В реальных приложениях, где логика обработки сложна и требуется обновить определенные части логики независимо, можно создать несколько заданий Stream Analytics вместе с Центрами событий в качестве посредника событий брокера событий.
Этот шаблон повышает устойчивость и управляемость системы. Однако, несмотря на то, что Stream Analytics гарантирует точно один раз обработки, существует небольшая вероятность того, что повторяющиеся события приземлились в промежуточных центрах событий. Для подчиненного задания Stream Analytics важно дедуплицировать события с помощью логических ключей в окне ретроспективного обзора. Дополнительные сведения о доставке событий см. в справочнике Гарантии доставки событий.
Использование эталонных данных для настройки приложения
Функция эталонных данных Azure Stream Analytics предназначена специально для настройки конечных пользователей, таких как порог предупреждений, правила обработки и геозоны. Уровень приложения может принимать изменения параметров и сохранять их в базе данных SQL. Задание Stream Analytics периодически запрашивает изменения из базы данных и делает параметры настройки доступными путем присоединения эталонных данных. Дополнительные сведения об использовании эталонных данных для настройки приложений см. в статьях Эталонные данные SQL и Присоединение эталонных данных.
Этот шаблон также можно использовать для внедрения обработчика правил, в котором пороговые значения правил определяются на основе эталонных данных. Дополнительные сведения о правилах см. статье Обработка правил на основе настраиваемых порогов в Azure Stream Analytics.
Добавление машинного обучения к аналитическим сведениям в режиме реального времени
Встроенная модель обнаружения аномалий Azure Stream Analytics обеспечивает удобный способ внедрения машинного обучения в приложение, работающее в режиме реального времени. При более широком спектре потребностей машинного обучения см. раздел Интеграция Azure Stream Analytics со службой оценки Машинного обучения Azure.
Опытные пользователи, желающие включить интерактивное обучение и оценку в один и тот же конвейер Stream Analytics, могут ознакомиться с примером того, как сделать это с помощью линейной регрессии.
Хранение данных в режиме реального времени
Другим распространенным шаблоном является хранение данных в режиме реального времени, также называемое потоковым хранилищем данных. Помимо событий, поступающих в Центры событий и Центр Интернета вещей из приложения, службу Azure Stream Analytics, выполняющаяся на IOT Edge, можно использовать для очистки данных, уменьшения объема данных, а также для хранения и пересылки данных. Служба Stream Analytics, выполняющаяся на IoT Edge, может корректно справляться с ограничением пропускной способности и проблемами подключения в системе. Stream Analytics может поддерживать скорость пропускной способности до 200 МБ/с при записи в Azure Synapse Analytics.
Архивация данных в режиме реального времени для аналитики
Большинство действий обработки и анализа данных и аналитики по-прежнему выполняются в автономном режиме. Вы можете архивировать данные в Azure Stream Analytics с помощью выходных данных Azure Data Lake Store 2-го поколения и форматов выходных данных Parquet. Эта возможность устраняет препятствия для передачи данных непосредственно в Azure Data Lake Analytics, Azure Databricks и Azure HDInsight. Azure Stream Analytics используется в качестве обработчика извлечения и загрузки преобразования (ETL) в реальном времени в этом решении. Архивные данные можно изучить в озере данных с помощью различных подсистем вычислений.
Использование эталонных данных для обогащения
Для подсистем ETL часто требуется обогащение данных. Azure Stream Analytics поддерживает обогащение данных с помощью эталонных данных из базы данных SQL и хранилища BLOB-объектов Azure. Обогащение данных можно выполнить для размещения данных как в озере данных Azure, так и в Azure Synapse Analytics.
Применение аналитических сведений из архивных данных
При объединении шаблона автономной аналитики с шаблоном приложения, работающего почти в реальном времени, можно создать цикл обратной связи. Цикл обратной связи позволяет приложению автоматически адаптироваться к изменениям закономерностей в данных. Этот цикл обратной связи может быть простым, как при изменении порогового значения для предупреждений, или сложным, как при переобучении моделей машинного обучения. Одну и ту же архитектуру решения можно применить как к заданиям ASA, выполняемым в облаке, так и к IoT Edge.
Отслеживание заданий ASA
Задание Azure Stream Analytics может выполняться круглосуточно для непрерывной обработки входящих событий в режиме реального времени. Его бесперебойная работа важна для работоспособности всего приложения. Хотя Stream Analytics является единственной службой потоковой аналитики в отрасли, которая предлагает гарантию доступности на 99,9%, вы по-прежнему влечете за собой некоторое время простоя. В течение нескольких лет в Stream Analytics были добавлены метрики, журналы и состояния заданий для отражения работоспособности заданий. Все они отображаются с помощью службы Azure Monitor и могут быть экспортированы в OMS. Дополнительные сведения см. в статье Мониторинг заданий Stream Analytics с помощью портала Azure.
Отслеживанию подлежат две ключевые вещи:
-
В первую очередь необходимо убедиться, что задание выполняется. Без задания в состоянии выполняется новые метрики или журналы не создаются. Задания могут измениться на состояние сбоя по различным причинам, в том числе с высоким уровнем использования SU (то есть сбоем ресурсов).
Метрики задержки водяного знака
Эта метрика отражает, насколько велико отставания вашего конвейера обработки от текущего времени (в секундах). Некоторые задержки обусловлены заложенной логикой обработки. В результате наблюдение за растущей тенденцией гораздо важнее, чем мониторинг абсолютной величины. Задержка устойчивого состояния должна урегулироваться за счет архитектуры приложения, а не с помощью мониторинга или оповещений.
При сбое журналы действий и журналы диагностики лучше всего подходят для начала поиска ошибок.
Создание отказоустойчивых и критически важных приложений
Независимо от гарантий соглашения об уровне обслуживания Azure Stream Analytics и того, насколько осторожны вы при использовании своего комплексного приложения, простои случаются. Если приложение является критически важным, необходимо подготовиться к простоям, чтобы обеспечить его корректное восстановление.
Для приложений, генерирующих оповещения, самое важное — обнаружить следующее оповещение. Вы можете перезапустить задание с текущего времени при восстановлении, игнорируя прошлые оповещения. Семантика времени запуска задания определяется временем первого вывода, а не первого ввода данных. Ввод данных перематывается назад на соответствующее время, чтобы гарантировать, что первый вывод, выполненный в указанное время, будет полным и правильным. Вы не получите частичные статистические выражения и в результате не запустите предупреждения непреднамеренно.
Вы также можете начать выходные данные с некоторого количества времени в прошлом. Центры событий и политики хранения Центра Интернета вещей содержат данные в разумном объеме, позволяющем выполнять обработку за прошедший период. Обратная сторона состоит в том, насколько быстро можно будет перейти к текущему времени и начать своевременно создавать новые оповещения. С течением времени данные теряют свое значимость, поэтому важно быстро перейти к текущему времени. Существует два способа быстро перейти к текущему времени:
- Предоставить дополнительные ресурсы (единицы хранения) при наверстывании.
- Выполнить перезапуск с текущего момента.
Выполнить перезапуск с текущего момента достаточно просто, но обратная сторона этого действия будет состоять в том, что в процессе обработки данных останется пробел. Перезапуск таким образом может быть нормальным для сценариев генерации оповещений, но он также может быть проблематичным для сценариев панели мониторинга, а также неподходящим для сценариев архивирования и хранения данных.
Предоставление дополнительных ресурсов может ускорить процесс, но эффект от резкого увеличения скорости обработки может вызывать осложнения.
Проверьте, что задание масштабируется для использования большего количества единиц хранения. Не все запросы являются масштабируемыми. Необходимо убедиться, что запрос может выполняться параллельно.
Убедитесь, что в вышестоящем Центре событий или Центре Интернета вещей достаточно разделов, чтобы можно было добавить дополнительные единицы пропускной способности (TU) для масштабирования пропускной способности ввода. Помните, что максимальная скорость вывода каждой TU Центра событий составляет 2 МБ/с.
Убедитесь, что вы подготовили достаточно ресурсов в приемниках выходных данных (т. е. База данных SQL, Azure Cosmos DB), чтобы они не тронули всплеск выходных данных, что иногда может привести к блокировке системы.
Самым важным будет рассчитать изменение скорости обработки, протестировать эти сценарии перед переносом в рабочую среду и подготовиться к правильному масштабированию обработки во время восстановления после сбоя.
В экстремальном сценарии, когда все входящие события задерживаются, можно удалить все отложенные события, если в задании было предусмотрено окно для поступления с задержкой. Удаление событий может показаться таинственным поведением в начале; Однако, учитывая, что Stream Analytics является обработчиком обработки в режиме реального времени, он ожидает, что входящие события будут близки к времени настенные часы. Ей необходимо удалить события, нарушающие эти ограничения.
Лямбда-архитектура или процесс обработки задним числом
К счастью, предыдущий шаблон архивирования данных можно использовать для корректной обработки этих запаздывающих событий. Суть в том, что задание архивации обрабатывает входящие события во время поступления и архивирует их в нужный временной контейнер в BLOB-объекте Azure или Azure Data Lake Store с их временем события. Насколько бы поздно не поступило событие, оно не будет удалено. Он всегда будет помещаться в нужный временной контейнер. Во время восстановления можно выполнить повторную обработку архивных событий и поместить результаты в выбранное хранилище задним числом. Это похоже на реализацию лямбда-шаблонов.
Процесс обработки задним числом должен выполняться в автономной системе пакетной обработки, которая, скорее всего, имеет модель программирования, отличную от Azure Stream Analytics. Это означает, что необходимо повторно выполнить всю логику обработки.
Для обработки задним числом по-прежнему важно по крайней мере временно предоставить ресурсы для приемников выходных данных, чтобы справиться с более высокой пропускной способность по сравнению с требуемой для обработки устойчивого состояния.
| Сценарии | Перезапустить только с этого момента | Перезапустить с момента последней остановки | Перезапустить только с этого момента + обработка архивных событий задним числом |
|---|---|---|---|
| Отображение данных на панелях мониторинга | Создает промежуток | OK для кратковременного сбоя | Используется для продолжительного сбоя |
| Оповещение | Приемлемо | OK для кратковременного сбоя | Необязательно |
| Приложение для источников событий | Приемлемо | OK для кратковременного сбоя | Используется для продолжительного сбоя |
| Хранение данных | Потеря данных | Приемлемо | Необязательно |
| Автономная аналитика | Потеря данных | Приемлемо | Необязательно |
Сборка
Трудно представить, что все шаблоны решений, упоминание ранее, можно объединить вместе в комплексной комплексной системе. Объединенная система может включать панели мониторинга, оповещения, приложение для источников событий, хранилища данных и возможности автономной аналитики.
Важно спроектировать систему, используя составные шаблоны, чтобы каждую подсистему можно было сконструировать, протестировать, обновить и восстановить независимо от других.
Следующие шаги
Теперь вы видели различные шаблоны решений с помощью Azure Stream Analytics. Теперь вы можете вникнуть в детали и создать свое первое задание Stream Analytics: