本文整理自抖音电商实时数仓研制工程师张健，在 Flink Forward Asia 实时风控专场的共享。本篇内容首要从 Flink CEP 简介、事务场景与应战、处理方案实践和未来展望四个方面打开介绍。
一、Flink CEP 简介
Flink CEP 是依据 Flink Runtime 构建的杂乱事情处理库，擅长处理跨多个事情的杂乱规矩匹配场景。在电商场景下，例如检测用户下单后，是否超越必定时刻仍没有产生付出行为；检测用户进入直播间后，是否有浏览产品随后加入购物车行为等。
与其他技能选型比较，Flink CEP 有以下优势：
- 支撑跨多事情的规矩匹配核算；
- 具有精准一次核算语义、低推迟、高吞吐等特性。
二、事务场景与应战
随着抖音电商事务逐步趋于稳定和成熟，抖音电商实时数仓团队接到的实时数据规矩类事务需求也逐步增多，因此咱们开始尝试使用 Flink CEP 支撑这些事务场景。下面罗列两个典型的事务场景，并介绍 Flink CEP 在这些场景中遇到的应战。
事务布景
- 实时预警场景。这是十分典型的事务诉求，把用户看数据的方法从大屏“盯盘”转化为“依据规矩检测成果，自动推送”，这无疑对一些关键事务问题的发现和洞悉起到至关重要的效果。有如下三个详细事例：直播实时检测场景。当检测到直播间在一段时刻内观看人数持续下跌时，会实时把消息推送给直播达人，便利其及时做出直播战略的调整。比方调整解说产品的话术，发放粉丝礼物等等，进而提高转化。实时风控的场景。当检测到用户有或许存在刷单行为时，咱们会将这个用户实时推送给渠道治理同学，并做出相应的封禁处置，促进渠道的全体生态健康。售后咨询场景。当检测到一个用户发起咨询后，超越 x 分钟都未得到回复，会当即通知相关的客服人员及时回复，提高全体的用户体验。
- 实施营销场景。这是依据实时数据驱动，依据界说的规矩战略发掘方针群体，并依据事务方针做出精准营销投进的营销活动。有如下三个详细事例：促进购买场景。针对一些价格比较高的产品，当检测到用户下单后没有付出，那么该用户或许因价格犹豫是否付出。这个时分能够及时进行一些刺激购买的运营动作，然后提高渠道的转化率。帮助商家及时发现爆款产品场景。当检测到某款产品在必定时刻内成交超越 x 单时，会实时将这个产品的称号、品牌、库存等信息推送给商家，以便商家及时补货、直播间挂链接等行为，提高运营功率。在线发奖赏场景。当检测抵达人在完结电商大学学习后并在必定时刻内进行了电商开播，或发布了电商短视频等行为，就会对这个达人发放一些典礼奖赏，提高全体达人的入驻率，进而给商家提高愈加多元的达人挑选。
事务应战
第一，在规矩装备方面存在灵敏性不足的问题。当时无论是新增还是修正规矩，都需求实时数仓的研制同学通过修正代码的方法来支撑，这就导致研制同学需求频频的对接事务。在一些极端的场景，如双十一大促期间，一个研制同学往往需求一起对接多个运营同学的规矩创立或许修正的诉求。事务需求也因为人力的单点堵塞问题迟迟无法上线。
第二，规矩与核算使命之间存在深度耦合。当每个规矩都需求强制绑定一个核算使命时，就会导致核算使命的数量会随着规矩的创立逐步增多。很多的使命会造成极高的运维本钱和巨大的资源浪费，使整个体系终究变得不可维护。以前面说到的商家自界说规矩检测爆款产品的这个场景为例，考虑到当时抖音电商庞大的商家群体，终究创立规矩的数量或许是巨大的，进而导致整个核算使命的数量也随之爆炸。
第三，当时社区版 Flink CEP 支撑的规矩语义不够丰厚。罗列两个典型的事例：
- 第一个事例，假定需求检测用户多次下单后，没有在某一时刻内完结付出行为。这种场景的特点是用户最后一次下单后，一向没有付出事情来触发规矩然后完结匹配。当时社区版 Flink CEP 不支撑这种场景，但在实在的事务中这又是十分普遍的规矩诉求。
- 第二个事例，假定需求检测用户在过去一段时刻内，是否完结一些固定行为动作。并要求这些行为不分先后顺序。这种场景当时社区版 Flink CEP 也不支撑。
三、处理方案实践
建设思路
全体分为四个阶段处理上述的问题。
第一阶段，对 Flink CEP 规矩的核心信息进行了提炼和抽象，并规划了一套明晰易懂的规矩 DSL。这样就能够让事务同学自主装备事务规矩，然后处理规矩装备灵敏性不足的问题。那么怎么让事务装备的规矩运转起来就成为下一步待处理的问题。
第二阶段，对 Flink CEP 核算使命进行改造，让其支撑动态提交规矩或许更新规矩的才能，然后完结规矩与核算使命之间的彻底解耦。解耦之后，不再强制要求每一个规矩有必要对应一个核算使命来运转。也便是同一个核算使命能够一起接收提交的多条规矩，完结收敛全体核算使命的数量，提高规矩利用率的方针。
前面两个阶段处理了规矩装备的灵敏性以及规矩与其他使命的强绑定问题，可是依然没有处理规矩自身的语义丰厚性问题。因此，第三阶段，首要针对特定事务的场景的规矩诉求、晋级和拓宽规矩的语义。
通过前三阶段的晋级和优化，前面说到的事务痛点现已基本得到了处理，但规矩引擎在易用性和周边才能方面还有所短缺。例如咱们无法直观的检查当时体系运转的规矩内容、注册事情数据；事务提交的规矩与核算使命之间依据什么样的战略来进行分发；用户依然需求订阅规矩引擎的输出数据进行格式转化、写入方针存储等操作。
因此在第四阶段，整合了前面的方案，并不断丰厚周边才能生态，打造了一站式实时规矩渠道。支撑用户在渠道上进行事情注册、预览、规矩装备、规矩调试、规矩发布等全流程的自主操作，进一步提高作业功率。
规矩 DSL 规划
为了完结事务自主装备规矩，规矩的语法有必要明晰易懂。咱们规划规矩 DSL 全体结合了 JSON 和根底 SQL 语法，利用 JSON 的高可读性来描绘规矩的元数据、规矩匹配属性等信息，利用 SQL 的强壮表达力来描绘 CEP 匹配条件以及匹配成果的处理逻辑。
这儿咱们发现了一个新的问题，怎么通过 SQL 来表达事情是否满意匹配条件？SQL 能够查询哪些表？以一个详细的事例来答复这个问题。
假定要检测用户下单后是否产生了付出行为，那么规矩编译生成的 NFA 或许是上图所示的姿态。在规矩运转时，咱们将当时流入的事情以及当时规矩的中心匹配成果，都以数据表的方法注册到上下文。当时流入的事情对应的表称号默许是 Events，规矩中心匹配成果对应的表称号和它的 PatternName 保持一致。
在这个事例中，每个 SQL 可查询到的表便是三张，分别是 Events 表，表明当时流入的事情；Create_order 表，表明当时现已匹配到的下单事情；Pay_order 表，表明现已匹配到的付出事情。
在装备 SQL 时，就能够对现已注册到上下文的恣意数据表进行查询。当 SQL 查询的成果非空时，就表明当时匹配条件判别通过。状况机通过 Take 边流转到下一个状况，并将事情保存到对应的表，不然就会到 Lgnore 边，丢掉掉事情。
再来看一下这个事例对应的规矩装备条件的完整装备。全体是一个数组的方法，数组中每个元素表明一个 pattern，第二个 pattern 与前一个 pattern 之间的连接类型是 FOLLOWED_BY。第一个 pattern 的匹配条件是从流中检测用户下单事情，第二个 pattern 匹配条件是从流入检测用户付出事情。
注意，这个付出事情的订单是上一步咱们缓存下来的下单事情对应的那个订单。通过上面的改造完结了，只要稍微有一些 SQL 根底的事务人员，都能够看懂并装备规矩。
规矩动态更新
前面咱们说到，当时的 Flink CEP 核算使命不支撑动态提交规矩。首要原因是在编译阶段 Flink CEP 规矩核算逻辑就确认了，而且现已通过 NFACompiler 编译完毕。在运转时核算使命只能固定履行之前现已编译好的规矩。那么咱们是怎么改造的呢？
为了完结规矩的动态发现，咱们引进了一个规矩流，用户提交或修正的规矩都能够发到这条流中。为了完结规矩的动态注入，咱们将规矩流规划为 Broadcast Stream。当发现新提交的规矩时，广播分发到一切的 SubTask。
为了完结规矩的在线加载履行，咱们依据前面说到的规矩 DSL，研制了一套依据规矩的解析器。当 SubTask 收到分发的规矩后，能够在线解析生成规矩运转需求的组件。例如 NFA、规矩匹配条件 SQL 对应的履行计划、匹配成果处理函数等。然后保存到 Flink State 中，持续检测和处理后续的事情。
解释一下为什么采用 Broadcast Stream 来完结规矩的动态注入。因为 Flink CEP 是有状况的核算，规矩的更新/删去往往需求随同 Flink States 的操作和处理。例如：当删去规矩时，连带当时规矩相关的事情缓存等状况信息也需求一起删去。对比通过其他方法感知规矩改变，比方启动一个异步线程定时扫描规矩，通过 Broadcast Stream 的方法优势是，当检测到规矩改变，能够更便利安全的操作 Flink State。
上面的方案处理了一个核算使命动态提交规矩的诉求，但当一个核算使命运转多条规矩时，又带来了一个新的问题。
问题一，因为规矩的事情分组逻辑或许不同。(比方规矩 A 需求先对事情流按照”用户的 IP 地址”路由到同一 Task 后再进行 NFA 匹配核算。而规矩 B 则需求对事情流按”用户的设备 ID“进行路由）。那么当这两个规矩运转在同一个核算使命时，怎么兼容呢？
为了处理这个问题，咱们新增了 KeyGenOperator 算子。当检测到新的事情流入时，先依据每一条规矩装备生成一个与之对应分组的 Key，然后按分组 Key 再进行下游的 Task 分发，这样就完结了对多条规矩的不同事情分组逻辑的兼容。
问题二，因为同一个核算使命运转多条规矩，就或许会带来规矩核算冗余的问题。比方，规矩 A 重视用户下单、付出等付出相关事情，而规矩 B 重视用户的产品浏览、评论等流量相关的事情。假如同一个核算使命一起运转这两条规矩，那么这个使命就有必要一起消费这两类事情。也便是说规矩 A 本不重视流量类的事情，但因为整个使命全体订阅了这类事情，就导致规矩 A 也有必要处理这类事情。
为了处理上述问题，咱们在 KeyGenOperator 算子新增了“事情挑选”组件，完结针对同一输入事情不同规矩里的个性化事情挑选。也便是说，针对新流入的事情，仅当规矩重视这个事情的时分，才会生成与之对应的分组 Key，而且进行后续的核算。
值得一提的是：在商家自界说预警的事务场景中，因为事情挑选的效果是比较好的（也便是说，商家自界说的每个规矩仅重视当时商家所属产品的相关事情），那么通过咱们测验，单个使命（在 600Core、800 并发度的状况下）能够支撑的商家简单规矩数量能够超越百万。
规矩语义优化
当产生事情 A 后一段时刻内，没有产生事情 B，其对应的伪代码或许是上面的这种方法。当时的 Flink CEP 不支撑这种语义，因为或许造成没有事情触发这条规矩，终究完结匹配的状况。
针对这个问题，咱们在规矩生成的 NFA 中引进一种 Pending 状况。当流入事情满意创立订单的条件之后，状况会随之迁移到 Pending 状况等候超时。当 Flink CEP 使命的 watermark 向前推进时，会触发 Pending 状况的 NFC 进行核算，判别是否现已超时，假如超时就会触发 NFA，迁移到下一个 Final 状况。假如在这之前体系流入了订单付出事情，就会转移到 Stop 状况。
通过这种方法，咱们完结了对产生事情 A 之后一段时刻内，没有产生事情 B 类的语义的支撑。
全体架构
为了进一步提高规矩引擎的使用性，咱们整合前面的方案，拓宽规矩引擎的周边才能，研制了一站式规矩渠道。用户能够在渠道上自助进行事情的注册、预览、规矩装备、调试、发布等全流程的自助操作。
渠道整个架构共分为四层，分别是：
事情层，例如看播事情、下单事情、物流事情、客服事情等。
核算层，担任动态的接收用户提交的 CEP 规矩，并对规矩进行解析，检测后续流入事情。核算层的核心是规矩核算模块，也便是详细的 Flink CEP 核算使命。一起在核算层还有规矩调度模块和规矩解析模块，规矩调度模块担任将新提交的规矩分发到详细的 Flink CEP 核算使命，调度战略能够挑选同事情源优先或许负载均衡优先。
- 同事情源优先是将重视相同 topic 的事情的规矩，调动到同一个 Flink CEP 核算使命。例如将重视看播事情的规矩调度到一个核算使命中，而将重视物流事情的规矩调度到另一个核算使命中。负载均衡优先则是依据 Flink CEP 核算使命当时的负载状况，尽量将新提交的规矩调度到相对空闲的核算使命履行。
- 规矩解析模块担任当集团使命收到规矩之后，解析并编译规矩，生成规矩运转时的组件。例如前面说到的 NFA、规矩匹配条件对应的 SQL 履行计划等等。
触达层，担任核算层规矩匹配成果的数据使用，首要包含推迟战略管理、维度字段扩大、推送方针管理等。
- 推迟战略管理首要担任当方针完结匹配后，是否当即进入下一个动作。例如，当用户完结既定的行为动作之后，能够挑选当即发放优惠券，或许等候五分钟之后再发放优惠券。
- 维度字段扩大首要担任当方针完结匹配后，为数据补充相关的维度字段。例如，当用户完结浏览、下单、付出行为后，咱们能够依据渠道的装备，拼接补充订单相关的产品信息。例如产品的称号、价格等，供用户终究更好的决议计划。
- 推送方针管理首要担任当方针完结匹配后，详细需求履行的动作。例如当检测到用户有或许存在刷单行为时，给渠道治理同学推送飞书消息。
渠道层，担任与用户交互以及使命运维等作业。
事务成效方面：
- 事务自主装备规矩，提高需求支撑灵敏性。目前共创立各类实时规矩 2.5w+，服务渠道运营同学 100+。
- 规矩与核算使命解耦，无需研制介入即可支撑规矩创立/改变。事务规矩需求支撑平均耗时由 1day 缩减至 1hour。
- 提高 CEP 规矩语义丰厚度。规矩引擎才能完结了抖音电商 70%+ 事务场景的掩盖。
技能成效方面：
- 由 Case By Case 的点状需求支撑模式向面向渠道的例行迭代改变，避免了单点人力堵塞问题，提高全体代码健壮性。
- 全体核算使命数量得到收敛，当时总体使命数量 ≤50，月均核算使命治理运维相关作业量下降 50%+。
- 下降核算使命全体资源浪费，单使命平均资源利用率提高 50%+。
四、未来展望
未来计划在以下三个方面继续对规矩引擎进行建设。
- 继续打磨实时规矩渠道周边生态才能，完结更丰厚、灵敏的事情接入、触达方法。
- 探索规矩核算流批一体，打破离线、实时事情之间的壁垒，拓宽渠道使用范围。
- 打通公司大数据研制环境，完结愈加便捷的核算使命操作，进一步下降人工本钱。
