什么是织物激活器? 将数据流转换为自动化操作

Fabric 激活器是一个无代码且低延迟的事件检测引擎,可在数据源中检测到特定模式或条件时自动触发作。 关键功能包括:

它持续监视这些数据源的次秒级延迟,并在达到阈值或检测到特定模式时启动作。 这些作可能包括发送电子邮件或 Teams 通知、启动 Power Automate 流或与第三方系统集成。

核心体系结构

激活器是 Fabric Real-Time 智能堆栈的核心的事件检测和规则引擎。 从体系结构上看,它充当智能观察者 -- 使用高速数据流,以近乎实时的方式评估规则条件,并根据事件状态的变化启动自动化下游作。

它适合一种反应式事件驱动的体系结构,其中数据流持续流动,并根据近乎实时的事件数据的有状态评估做出决策。

显示 Fabric 激活器的体系结构的关系图。

  • 事件源

    激活器直接连接到事件流,这些流从各种生成者(Azure 事件中心、IoT 设备、自定义终结点等)引入数据。 这些流充当事件源,激活器可以订阅一个或多个事件流来观察数据更改。 其他事件源可以是 Fabric 或 Azure 事件,也可以是侦听 Power BI 报表或 Real-Time 仪表板的激活器。

  • 事件和对象

    事件是通过事件流接收的单个记录(例如遥测信号或文件删除)。 这些事件根据共享标识符(例如,bikepoint_iddevice_id)分组到对象中。 然后对每个对象评估规则,从而实现检测精细化(例如,可针对每个传感器或每个资产进行探测)。

  • 规则和条件

    每个激活器都包含一个或多个持续评估的规则。 这些规则可以是简单的比较(value < threshold)或有状态表达式,例如 BECOMESDECREASESINCREASESEXIT RANGE或数据缺失(心跳)。 活动器确保每个对象进行状态跟踪,从而支持复杂模式的时间检测。

  • 行动

    满足规则条件后,激活器可以触发:

    • Fabric 中的管道、笔记本、函数或 Spark 作业定义。

    • 通过 Power Automate 执行外部动作。

    • 将 Teams 消息发送到个人、群组或频道

    • 发送电子邮件

  • 警报管理和规则测试

    激活器在激活规则之前提供预览和影响估计,显示规则对历史数据触发的频率。 这些功能有助于防止警报垃圾邮件和过度触发。 在内部,状态转换可以抑制干扰(例如,值必须超过阈值,而不仅仅是保持在阈值之下)。

  • 监视和成本控制

    只有在激活器处于主动运行状态时才会产生费用。 激活器实例的范围限于 Fabric 容量,并可以通过工作区进行监视。 运行时日志和遥测通过事件流和管道输出提供。

部署模型

激活器实例按工作区部署,并绑定到特定数据源。 多个激活器可以监视同一流,从而为不同的业务功能启用并行规则评估。 由于激活器是容量绑定的,因此仅当规则处于主动运行状态时,即用即付定价才适用,从而为间歇性检测方案提供成本效益。

Real-Time 智能中的集成点

组件 与激活器交互
Eventstream 通过低延迟流引入向激活器提供联合数据。
激活器 可以生成触发另一个激活器的事件(例如扩充实体或推断标签)。
管道 激活器的规则触发器的目标,它自动执行下游处理
Power BI 使用触发的管道或笔记本的结果进行实时可视化
Power Automate 允许通过模板化或自定义操作来执行事件驱动的操作。
Fabric 事件 提供 Fabric 中发生的事件,例如刷新语义模型或管道失败
Notebooks 笔记本执行可由激活器触发
Spark 作业定义 Spark 作业执行可由激活器触发
用户数据函数 函数执行可由激活器触发

激活器作为协调程序

在企业级实时体系结构中有效使用激活器需要有意协调 Microsoft Fabric 组件,并对事件量、对象基数和规则复杂性进行性能调优。 本部分介绍如何与其他服务协调激活器,以及如何优化检测逻辑和运行时行为,以支持大规模低延迟、经济高效的自动化。

激活器通过在到达点评估数据并触发下游作,在事件驱动管道中扮演核心角色。 典型的 编排模式 包括:

图案 流说明
引入→检测→转换 事件从 Eventstream 流流入激活器,这会触发管道来扩充或移动数据。
引入→检测→通知 激活器触发 Power Automate 将警报或推送状态发送到 Teams、Outlook 或 ServiceNow。
引入→检测→模型评分 激活器触发 Notebook 对 ML 模型评分或基于实时异常执行高级分析。
具有激活器的反馈循环(计划) 激活器生成的见解(例如敏感度标签)会馈送到激活器规则中,从而实现语义上扩充的自动化。

核心概念

Microsoft Fabric 激活器作为高性能状态感知规则引擎运行,旨在对流式处理事件进行低延迟评估。 在核心上,激活器处理通过事件流发出的实时事件,评估每个逻辑对象的规则条件,并启动下游作以响应状态转换。 有关 Fabric 激活器的概述,请参阅 Fabric 激活器简介

以下概念用于在 Fabric 激活器中生成和触发自动作和响应。

事件源和事件

Fabric 激活器将所有数据源视为事件流。 事件表示对象状态的观察值,通常包括所监视字段的标识符、时间戳和值。

引入到激活器的事件源自:

  • Eventstream 支持多个上游源(例如 Azure 事件中心、IoT 中心、Blob 存储触发器)。 Eventstream 是 Microsoft Fabric 中的特定项类型,可用于引入、转换和路由实时事件,而无需编写任何代码。 Fabric 激活器监视事件流,并在检测到定义的模式或阈值时自动执行操作。 激活器还可以订阅两个或多个事件流来观察数据更改。 事件流因频率而异。 例如,IoT 传感器每秒发出多次事件,物流系统会偶尔生成事件,例如在发货位置扫描包裹时。
  • Fabric 事件。 例如,Fabric 工作区项目事件是对 Fabric 工作区进行更改时发生的离散 Fabric 事件。 这些更改包括创建、更新或删除 Fabric 项。
  • Azure 事件。 例如,客户端创建、替换、删除 Blob 等时,会触发 Azure Blob 存储事件。
  • Power BI 报表。 在这种情况下,事件是基于 Power BI 语义模型的刷新计划(以前称为数据集)的定期观察。 这些观察可能每天或每周发生,形成缓慢移动的事件流。
  • Fabric Real-Time 仪表板。

每个事件都包含:

  • 时间戳
  • 有效负载(结构化或半结构化数据)
  • 用于对象标识的一个或多个属性(例如,device_id、bikepoint_id)

对象

在 Fabric 激活器中,监视的实体称为业务对象,可以是物理对象或概念对象。 示例包括冰柜、车辆、包裹和用户等物理对象,以及广告活动、客户帐户、用户会话等概念对象。

若要在激活器中为业务对象建模,请连接一个或多个事件流,选择要用作对象 ID 的列,并指定要视为对象的属性的字段。

术语 对象实例 是指业务对象的特定示例,例如特定的冰柜、车辆或用户会话。 相比之下,对象通常指常规定义或类(例如,冰柜作为类型)。 术语“总体”用于指正在监视的完整对象实例集。

对象创建是隐式的:激活器使用指定的对象键对事件进行分组。 规则的范围限定为对象,这意味着所有评估逻辑都是对象感知的,并且跨实例独立。 例如,规则监视 bikepoint_id 为每个唯一自行车站创建独立的逻辑评估。

规则

规则定义要在对象上检测的条件,以及满足这些条件时要采取的措施。 例如,冰柜对象上的规则可能会检测到温度何时高于安全阈值,并自动向分配的技术人员发送电子邮件警报。

激活器中的规则可以是无状态或有状态的:

  • 无状态规则 以隔离方式评估每个事件(例如值 < 50)。
  • 有状态规则 会在每个对象的相关事件之间保持记忆(例如数值减少、变为、退出范围)

有状态评估依赖于:

  • Delta 检测:跟踪先前和当前事件值之间的更改。
  • 时间序列:评估基于时间的条件,如事件的缺失(心跳检测)
  • 状态转换:仅在进入新状态时触发规则,防止在未改变的情况下重复触发

每个规则条件会被编译成一个执行图,该图在内存中持续且近乎即时地进行评估。 系统针对事件到达后的次秒决策延迟进行优化。

行动

当规则的条件得到满足并启动行动时,该规则就被激活。 动作支持的目标包括:

  • 构造管道(用于数据移动、扩充)
  • Fabric笔记本(用于机器学习评分、诊断)
  • Fabric Spark 任务(用于批处理/流式处理任务)
  • 构造函数(适用于具有代码的自定义业务逻辑)
  • Power Automate 流(用于业务流程集成)
  • Teams 通知(使用基于模板的消息传送)
  • 电子邮件通知

激活器发出包含当前对象状态和规则元数据的触发消息,且操作是非阻塞的,也就是说,激活器不会等待操作完成,以便启用可扩展的异步流程。

属性

属性是想要监视的业务对象的特定字段或属性。 这些可以是物理特征或概念特征,例如:

  • 封装的温度
  • 发货状态
  • 客户帐户余额
  • 用户会话的参与评分

它们派生自事件流,它们是来自 IoT 传感器、Power BI 报表或其他系统等源的连续数据流。

在激活器中定义业务对象时,可以连接一个或多个事件流,选择要用作对象 ID 的列,然后选择要视为该对象的属性的其他列。 可以针对这些属性创建规则来跟踪一段时间内的更改、检测属性何时超过阈值或超出范围,或者触发警报、工作流或通知等作。

如果要跨多个规则重用逻辑,属性也很有用。 例如,在冰柜对象上,可以定义一个属性,该属性计算一小时内的温度平均值。 定义后,可以在多个规则(例如检测过热、温度波动或维护阈值)中引用此属性,而无需复制逻辑。 通过在属性中集中逻辑,可以更轻松地管理规则、更一致且更易于随时间推移更新。

回溯期

回溯期是指激活器分析以评估规则的历史数据的持续时间。 它可确保有足够的过去数据来准确检测模式或计算聚合(如平均值),即使数据延迟或异常。

回溯期由:

  • 例如,规则的定义方式是需要分析趋势、检测异常还是随时间推移比较值。
  • 传入数据的量,例如事件流中的每秒事件数。

考虑冷链中运送药品包装的药品物流操作。 目标是在包裹过热时收到警报。

假设规则的定义是:

  • 在三小时内评估每个包的平均温度
  • 如果平均温度超过 8°C,则触发警报

若要准确计算此规则,Fabric 激活器需要分析更广泛的历史数据窗口,特别是 6 小时的回溯期。 它确保有足够的数据可用于计算任何时间点的三小时平均值,即使数据到达时有一些延迟或不规则。

回溯期对于及时准确地检测条件至关重要,尤其是在数据模式随时间变化的情况下。

不同、活动对象 ID

基于属性构建的规则用于监视对象的特定属性随时间变化的方式。 在药品物流示例中,每个药品包都由唯一的对象 ID 表示,系统接收每个包的定期温度读数。

为了有效评估这些规则,Fabric 激活器跟踪活动对象 ID,即事件在定义的回溯期内到达的对象。 此行为可确保在应用规则时仅考虑相关的当前活动对象。

例如,收费站可能会在车辆通过时跟踪车辆(对象 ID)。 每个车辆生成事件(例如,进入和退出扫描),并且只有具有最近活动的对象被视为活动,并由系统评估。

还有一些限制,具体取决于在回溯窗口中跟踪的不同对象 ID(包数)。

常见用例

下面是一些实际应用场景,你可以使用 Fabric 激活器:

  • 当同店销售下降时,自动启动广告活动,以帮助提升表现不佳门店的业绩。
  • 通知杂货店经理在破坏发生之前将食品从故障的冰柜中搬迁。
  • 当客户跨应用、网站或其他接触点的旅程表示负面体验时,触发个性化的外展工作流。
  • 在定义的时间范围内未更新发货状态时,主动启动调查工作流,帮助更快地找到丢失的包裹。
  • 当客户陷入欠款时,提醒账户团队根据每个客户的自定义时间或未结余额阈值进行处理。
  • 监视管道的运行状况,当检测到异常或故障时,自动重新运行失败的作业或向团队发出警报。

后续步骤

请参阅 教程:创建和激活 Fabric 激活器规则