Что такое активатор Fabric? Преобразование потоков данных в автоматизированные действия

Активатор Fabric — это движок обнаружения событий без кода и с низкой задержкой, который автоматически запускает действия при обнаружении определенных шаблонов или условий в источниках данных. Основные возможности:

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

Базовая архитектура

Активатор — это подсистема обнаружения событий и правил в центре стека аналитики Real-Time Fabric. В архитектуре он выступает в качестве интеллектуального наблюдателя — потребляя потоки данных высокой скорости, оценивая условия правила в почти реальном времени, и инициируя автоматические подчиненные действия на основе изменений в состояниях событий.

Он вписывается в реактивную архитектуру, основанную на событиях, где данные текут непрерывно, и принимаются решения на основе оценки событийных данных с учетом состояния почти в реальном времени.

• источники событий

  Активатор подключается непосредственно к потокам событий, которые используют данные от различных производителей (Центры событий Azure, устройства Интернета вещей, настраиваемую конечную точку и т. д.). Эти потоки служат источником событий, и активатор может подписаться на один или несколько потоков событий для наблюдения за изменениями данных. Другими источниками событий могут быть события Fabric или Azure, или активатор, реагирующий на отчеты Power BI или панели мониторинга Real-Time.

• События и объекты

  События — это отдельные записи (например, сигнал телеметрии или удаление файла), полученные через поток событий. Эти события группируются в объекты на основе общего идентификатора (например, bikepoint_id, device_id). Затем правила оцениваются для каждого объекта, что позволяет обеспечить детальное выявление (например, по датчику или активу).

• Правила и условия

  Каждый активатор включает в себя одно или несколько правил, которые оцениваются непрерывно. Эти правила могут быть простыми сравнениями (value < threshold) или выражениями с отслеживанием состояния, такими как BECOMES, DECREASES, INCREASES, EXIT RANGE, или отсутствием данных (поток). Активатор обеспечивает отслеживание состояния для каждого объекта, что обеспечивает комплексное обнаружение шаблонов с течением времени.

• Действия

  Если условие правила удовлетворено, активатор может активировать:

  • Конвейеры данных или записные книжки в Fabric.
  • Внешние действия с помощью Power Automate.
  • Отправка сообщения Teams отдельным, группам или каналу
  • Отправка электронной почты

• Управление оповещениями и тестирование правил

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

• Мониторинг и управление затратами

  Плата взимается только при активной работе активаторов. Экземпляры активатора привязываются к емкостям Fabric и могут отслеживаться через пространство работы. Журналы среды выполнения и данные телеметрии доступны через потоки событий и выходные данные конвейера.

Модель развертывания

Экземпляры активатора развертываются для каждой рабочей области и привязаны к определенным источникам данных. Несколько активаторов могут отслеживать один поток, что позволяет выполнять параллельные оценки правил для отдельных бизнес-функций. Поскольку активатор ограничен возможностями, цены за использование по мере потребления применяются только при активном выполнении правил, что экономически выгодно для временных сценариев обнаружения.

Точки интеграции в аналитике Real-Time

Активатор в качестве оркестратора

Эффективное использование Активатора в корпоративной архитектуре в режиме реального времени требует преднамеренной оркестрации между компонентами Microsoft Fabric и оптимизации производительности в зависимости от объема событий, кардинальности объектов и сложности правил. В этом разделе рассматривается, как оркестрировать Activator с другими службами и как оптимизировать логику обнаружения и поведение среды выполнения для поддержки автоматизации с минимальной задержкой и экономичностью в крупном масштабе.

Активатор играет центральную роль в конвейерах, управляемых событиями, путем оценки данных в точке прибытия и активации действий внизу. Типичные шаблоны оркестрации включают:

Основные понятия

Активатор Microsoft Fabric работает в качестве высокопроизводительного обработчика правил с поддержкой состояния, предназначенного для оценки событий потоковой передачи с низкой задержкой. В основном активатор обрабатывает события в режиме реального времени, создаваемые через поток событий, оценивает условия правила для каждого логического объекта и инициирует подчиненные действия в ответ на переходы состояний. Общие сведения об активаторе Fabric см. в разделе "Общие сведения о активаторе Fabric".

Следующие понятия используются для создания и активации автоматических действий и ответов в Активаторе Fabric.

Источники событий и события

Активатор Fabric обрабатывает все источники данных как потоки событий. Событие представляет наблюдение о состоянии объекта и обычно содержит идентификатор объекта, метку времени и значения отслеживаемых полей.

События, ингерстируемые в систему Activator, происходят из:

• Eventstream, который поддерживает несколько входящих источников (например, Azure Event Hubs, Центр Интернета вещей, триггеры хранилища BLOB-объектов). Eventstream — это определенный тип элемента в Microsoft Fabric, который позволяет выполнять прием, преобразование и маршрутизацию событий в режиме реального времени без написания кода. Активатор Структуры отслеживает поток событий и автоматически принимает меры при обнаружении определенных шаблонов или пороговых значений. Активатор также может подписаться на два или более потоков событий для наблюдения за изменениями данных. Потоки событий зависят от частоты. Например, датчики Интернета вещей генерируют события несколько раз в секунду, а системы логистики создают события периодически, например при сканировании пакетов в местах доставки.
• События Fabric Например, события элементов рабочей области Fabric представляют собой дискретные события Fabric, которые происходят при внесении изменений в рабочую область Fabric. Эти изменения включают создание, обновление или удаление элемента Fabric.
• События Azure. Например, события хранилища BLOB-объектов Azure активируются, когда клиент создает, заменяет или удаляет большой двоичный объект и т. д.
• Отчет Power BI. В этом случае события являются периодическими наблюдениями на основе расписания обновления семантической модели Power BI (прежнее название — набор данных). Эти наблюдения могут происходить ежедневно или еженедельно, формируя поток событий с медленным течением.
• Панель мониторинга Fabric Real-Time.

Каждое событие содержит следующее:

• метка времени;
• Полезная нагрузка (структурированные или частично структурированные данные)
• Один или несколько атрибутов, используемых для идентификации объектов (например, device_id, bikepoint_id)

Объект

В Активаторе Fabric отслеживаемые сущности называются бизнес-объектами, которые могут быть физическими или концептуальными. Примерами являются физические объекты, такие как заморозки, транспортные средства, пакеты и пользователи, а также концептуальные объекты, такие как рекламные кампании, учетные записи клиентов, сеансы пользователей.

Чтобы моделировать бизнес-объект в Активаторе, подключите один или несколько событий, выберите столбец, который будет служить идентификатором объекта, и укажите поля, которые необходимо рассматривать как свойства объекта.

Термин экземпляр объекта относится к конкретному примеру бизнес-объекта, например, определенного морозильника, транспортного средства или сеанса пользователя. В отличие от этого, объект обычно относится к общему определению или классу (например, морозильной камере в качестве типа). Термин "совокупность" используется для полного набора всех экземпляров объектов, которые отслеживаются.

Создание объекта происходит неявно: активатор группирует события по назначенному ключу объекта. Правила относятся к объектам, что означает, что вся логика оценки объектно-ориентирована и независима между экземплярами. Например, мониторинг bikepoint_id правил создает отдельные логические оценки для каждой уникальной велосипедной станции.

Правила

Правила определяют условия, которые необходимо обнаружить в объектах, и действия, которые необходимо предпринять при выполнении этих условий. Например, правило в объекте морозильной камеры может определить, когда температура поднимается выше безопасного порогового значения и автоматически отправляет оповещение электронной почты назначенному специалисту.

Правила в активаторе могут быть без отслеживания состояния или состояния:

• Правила без отслеживания состояния оценивают каждое событие в изоляции (например, значение < 50).
• Правила с отслеживанием состояния поддерживают память между событиями для каждого объекта (например, значение УМЕНЬШАЕТСЯ, СТАНОВИТСЯ, ВЫХОДИТ ЗА ПРЕДЕЛЫ ДИАПАЗОНА)

Оценка состояния зависит от:

• Обнаружение разностных данных: отслеживает изменения между предыдущими и текущими значениями событий.
• Темпоральная последовательность: оценивает условия на основе времени, такие как отсутствие событий (обнаружение пульса)
• Переходы состояния: правила запускаются только при входе в новое состояние, предотвращая повторное срабатывание в неизменившихся условиях

Каждое условие правила компилируется в граф выполнения, который вычисляется непрерывно, в памяти и почти мгновенно. Система оптимизирована для задержки принятия решений на уровне менее одной секунды после прибытия события.

Действия

Когда условия правила выполняются и инициируются действия, то правило, как утверждается, будет активировано. Поддерживаемые целевые объекты для действий включают:

• Конвейеры данных Fabric (для перемещения данных, обогащения)
• Записные книжки Fabric (для оценки машинного обучения, диагностики)
• Потоки Power Automate (для интеграции бизнес-процессов)
• Уведомления Teams (с помощью шаблонных сообщений)

Активатор излучает сообщение триггера с текущим состоянием объекта и метаданными правила, при этом действия не блокируются, т. е. активатор не ожидает завершения действий для обеспечения масштабируемых асинхронных потоков.

Свойства

Свойства — это определенные поля или атрибуты бизнес-объекта, которые необходимо отслеживать. Это могут быть физические или концептуальные характеристики, например:

• Температура пакета
• Состояние отгрузки
• Баланс учетной записи клиента
• Оценка взаимодействия сеанса пользователя

Они являются производными от потоков событий, которые являются непрерывными потоками данных из источников, таких как датчики Интернета вещей, отчеты Power BI или другие системы.

При определении бизнес-объекта в Активаторе необходимо подключить один или несколько потоков событий, выбрать столбец, который будет служить идентификатором объекта, и выбрать другие столбцы, которые будут рассматриваться как свойства этого объекта. Вы можете создавать правила для отслеживания изменений с течением времени, обнаруживать, когда свойство превышает пороговое значение или выходит за пределы диапазона, или активировать такие действия, как оповещения, рабочие процессы или уведомления.

Свойства также полезны при повторном использовании логики в нескольких правилах. Например, в объекте фризера можно определить свойство, которое вычисляет среднее значение температуры за один час. После определения это свойство можно использовать в нескольких правилах, таких как те, которые обнаруживают перегрев, колебания температуры или пороговые значения обслуживания, без дублирования логики. Централизация логики в свойствах упрощает управление, делает ваши правила более согласованными и облегает их обновление с течением времени.

период ретроспективного обзора.

Период ретроспективного анализа относится к длительности исторических данных, которые Activator анализирует для оценки правила. Это гарантирует, что достаточно прошлых данных доступно для точного обнаружения шаблонов или вычислительных агрегатов, таких как средние значения, даже если данные поступают поздно или нерегулярно.

Период обратного просмотра определяется следующим образом:

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

Рассмотрим фармацевтическую логистическую операцию, транспортируя пакеты лекарств в холодной цепи. Цель — получить оповещение, когда пакет становится слишком теплым.

Предположим, что правило определено следующим образом:

• Оценка средней температуры каждого пакета в течение трехчасового окна
• Активировать оповещение, если средняя температура превышает 8°C

Чтобы вычислить это правило точно, Активатор Структуры должен проанализировать более широкое окно исторических данных, в частности, шестичасовой период обратного просмотра. Это гарантирует, что достаточно данных для вычисления трехчасового среднего в любой момент времени, даже если данные поступают с некоторой задержкой или нерегулярностью.

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

Идентификаторы отдельных, активных объектов

Правила, созданные на основе атрибутов, используются для отслеживания того, как определенные атрибуты объекта изменяются с течением времени. В примере фармацевтической логистики каждый пакет медицины представлен уникальным идентификатором объекта, а система получает периодические показания температуры для каждого пакета.

Чтобы эффективно оценить эти правила, Активатор Fabric отслеживает идентификаторы активных объектов, то есть объекты, для которых события приходят в течение заданного ретроспективного периода. Это поведение гарантирует, что при применении правил учитываются только соответствующие активные объекты.

Например, платные станции могут отслеживать транспортные средства (идентификаторы объектов) по мере прохождения. Каждый автомобиль создает события (например, проверки входа и выхода), а только те объекты с недавними действиями считаются активными и оцениваются системой.

Существуют также ограничения на основе количества идентификаторов отдельных объектов (количество пакетов), отслеживаемых в окне обратного просмотра.

Распространенные варианты использования

Ниже приведены несколько реальных сценариев, в которых можно использовать активатор Fabric:

• Автоматически запускайте рекламные кампании при снижении продаж в одном магазине, что помогает повысить производительность в непроизводительных расположениях.
• Уведомите менеджеров продуктовых магазинов перенести продукты из неисправных морозильных камер до того, как они испортятся.
• Активируйте персонализированные рабочие процессы распространения, когда взаимодействие клиента между приложениями, веб-сайтами или другими точками касания указывает на негативный опыт.
• Заранее инициируйте рабочие процессы исследования, когда состояние отгрузки не было обновлено в течение определенного периода времени, помогая быстрее находить потерянные пакеты.
• Оповещать команды по работе с клиентами, когда клиенты оказываются в задержках платежей, используя настраиваемые пороговые значения для времени или невыплаченными балансами для каждого клиента.
• Отслеживайте работоспособность конвейера данных и автоматически перезапускайте неудавшиеся задачи или оповещайте команды при обнаружении аномалий или сбоев.

Следующий шаг

Смотрите руководство: Создание и активация правила в программе Fabric Activator.