Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Как и многие другие службы в 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 для дальнейшего анализа и структурирования данных для отчетов, а также множества других вариантов визуализации. Кроме того, вы получаете возможность гибкого использования других решений панели мониторинга, например Tableau.
SQL не является хранилищем данных высокой пропускной способности. Максимальная пропускная способность из Azure Stream Analytics в базу данных SQL в настоящее время составляет приблизительно 24 МБ/с. Если источники событий в вашем решении производят данные с более высокой скоростью, необходимо использовать логику обработки в Stream Analytics, чтобы уменьшить скорость вывода данных в SQL. Вы можете использовать такие методы, как фильтрация, оконные агрегаты, сопоставление шаблонов с темпоральными соединениями и аналитические функции. Вы можете оптимизировать скорость вывода данных в SQL с помощью методов, описанных в выводе Azure Stream Analytics в базу данных Azure SQL.
Внедрение в приложение анализа в реальном времени с использованием сообщений о событиях
Вторым наиболее популярным способом использованием Stream Analytics является создание оповещений в режиме реального времени. В этом шаблоне решения бизнес-логику в Stream Analytics можно использовать для обнаружения временных и пространственных шаблонов или аномалий, а затем создавать сигналы предупреждения. Однако в отличие от решения панели мониторинга, в котором Stream Analytics использует Power BI в качестве предпочтительной конечной точки, можно использовать другие промежуточные приемники данных. Эти приемники включают концентраторы событий, служебную шину и Функции Azure. Вы, как создатель приложений, должны решить, какой приемник данных лучше подходит для вашего сценария.
Для создания оповещений в существующем бизнес-рабочем процессе необходимо реализовать логику потребителя событий нижнего уровня. Так как вы можете реализовать пользовательскую логику в Функциях Azure, то Функции Azure — это самый быстрый способ для выполнения этой интеграции. Для получения инструкции по использованию Azure Functions в качестве выходных данных для задания Stream Analytics, см. статью "Запуск Azure Functions из заданий 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 гарантирует однократную обработку, существует небольшая вероятность того, что повторяющиеся события попадают в промежуточные Event Hubs. Для задачи 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 Data Lake, так и в 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 и того, насколько осторожны вы при использовании своего комплексного приложения, простои случаются. Если приложение является критически важным, необходимо подготовиться к простоям, чтобы обеспечить его корректное восстановление.
Для приложений, генерирующих оповещения, самое важное — обнаружить следующее оповещение. Вы можете перезапустить задание с текущего времени при восстановлении, игнорируя прошлые оповещения. Семантика времени запуска задания определяется временем первого вывода, а не первого ввода данных. Ввод данных перематывается назад на соответствующее время, чтобы гарантировать, что первый вывод, выполненный в указанное время, будет полным и правильным. Вы не получите частичные статистические выражения и в результате не запустите предупреждения непреднамеренно.
Вы также можете начать вывод данных с некоторого момента времени в прошлом. Обе системы — Центры событий и Центр Интернета вещей — имеют политики хранения, которые содержат данные в достаточном объеме, чтобы позволить обработку исторических данных. Обратная сторона состоит в том, насколько быстро можно будет перейти к текущему времени и начать своевременно создавать новые оповещения. С течением времени данные теряют свое значимость, поэтому важно быстро перейти к текущему времени. Существует два способа быстро наверстать упущенное:
- Обеспечивайте дополнительные ресурсы (управляемые единицы) в процессе синхронизации.
- Выполнить перезапуск с текущего момента.
Выполнить перезапуск с текущего момента достаточно просто, но обратная сторона этого действия будет состоять в том, что в процессе обработки данных останется пробел. Перезапуск таким образом может быть нормальным для сценариев генерации оповещений, но он также может быть проблематичным для сценариев панели мониторинга, а также неподходящим для сценариев архивирования и хранения данных.
Предоставление дополнительных ресурсов может ускорить процесс, но эффект от резкого увеличения скорости обработки может вызывать осложнения.
Проверьте, что задание масштабируется на большее количество SU. Не все запросы являются масштабируемыми. Необходимо убедиться, что ваш запрос параллелизован.
Убедитесь, что в вышестоящем Центре событий или Центре Интернета вещей достаточно разделов, чтобы можно было добавить дополнительные единицы пропускной способности (TU) для масштабирования пропускной способности ввода. Помните, что максимальная пропускная способность каждого раздела Event Hubs составляет 2 МБ/с.
Убедитесь, что вы подготовили достаточное количество ресурсов в приемниках выходных данных (т. е. База данных SQL, Azure Cosmos DB), чтобы они не ограничивали всплески выходных данных, что иногда может привести к зависанию системы.
Самым важным будет рассчитать изменение скорости обработки, протестировать эти сценарии перед переносом в рабочую среду и подготовиться к правильному масштабированию обработки во время восстановления после сбоя.
В экстремальном сценарии, когда все входящие события задерживаются, все отложенные события могут быть отброшены, если в вашем задании было применено окно для обработки поздних событий. Пропуск событий может показаться загадочным поведением в начале, но, учитывая, что Stream Analytics является движком обработки в режиме реального времени, он ожидает, что входящие события будут близки к текущему времени. Ей необходимо удалить события, нарушающие эти ограничения.
Лямбда-архитектура или процесс обработки задним числом
К счастью, предыдущий шаблон архивирования данных можно использовать для корректной обработки этих запаздывающих событий. Суть в том, что задание архивации обрабатывает входящие данные по мере их поступления и архивирует события в соответствующий временной сегмент в Azure Blob или Azure Data Lake Store с указанием их времени события. Как бы поздно ни пришло событие, оно никогда не будет отброшено. Он всегда будет помещаться в нужный временной контейнер. Во время восстановления можно выполнить повторную обработку архивных событий и поместить результаты в выбранное хранилище задним числом. Это похоже на реализацию лямбда-шаблонов.
Процесс обработки задним числом должен выполняться в автономной системе пакетной обработки, которая, скорее всего, имеет модель программирования, отличную от Azure Stream Analytics. Это означает, что необходимо повторно выполнить всю логику обработки.
Для дополнительной загрузки по-прежнему важно, по крайней мере временно, выделить дополнительные ресурсы для выходных приемников, чтобы справиться с более высокой пропускной способностью по сравнению с потребностями устоявшегося состояния обработки.
| Сценарии | Перезапустить только с этого момента | Перезапустить с момента последней остановки | Перезапустить с текущего момента и заполнить архивными событиями |
|---|---|---|---|
| Дэшбординг | Создает промежуток | OK для кратковременного сбоя | Используется для продолжительного сбоя |
| Оповещение | Приемлемо | OK для кратковременного сбоя | Необязательно |
| Приложение для событийного моделирования | Приемлемо | Допустимо для кратковременного перебоя | Используется при длительном отключении |
| Хранение данных | Потеря данных | Приемлемо | Необязательно |
| Автономная аналитика | Потеря данных | Приемлемо | Необязательно |
Объединяем все вместе
Трудно представить, что все шаблоны решений, упомянутые ранее, можно объединить в комплексную сквозную систему. Объединенная система может включать панели мониторинга, оповещения, приложение для источников событий, хранилища данных и возможности автономной аналитики.
Важно спроектировать систему, используя составные шаблоны, чтобы каждую подсистему можно было сконструировать, протестировать, обновить и восстановить независимо от других.
Следующие шаги
Теперь вы видели различные шаблоны решений с помощью Azure Stream Analytics. Теперь вы можете вникнуть в детали и создать свое первое задание Stream Analytics: