关于flink:Flink-CEP-在抖音电商的业务实践

摘要：本文整顿自抖音电商实时数仓研发工程师张健，在 FFA 实时风控专场的分享。本篇内容次要分为四个局部：

1. Flink CEP 简介
2. 业务场景与挑战
3. 解决方案实际
4. 将来瞻望

点击查看直播回放 & 演讲 PPT

一、Flink CEP 简介

Flink CEP 是基于 Flink Runtime 构建的简单事件处理库，它善于解决跨多个事件的简单规定匹配场景。例如检测用户下单后，是否超过半个小时没有产生领取行为；检测用户进入直播间后，是否有浏览商品随后退出购物车行为。

Flink CEP 有以下劣势：

• 反对跨多事件的规定匹配计算；
• 具备精准一次计算语义；
• 低提早、高吞吐等个性。

二、业务场景与挑战

随着抖音电商业务逐步趋于稳定和成熟，抖音电商实时数仓团队接到的实时数据规定类业务需要也逐渐增多，因而咱们开始尝试应用 Flink CEP 来反对这些业务场景。

上面列举两个典型的业务场景，并介绍一下 Flink CEP 在这些场景中遇到的一些挑战。

2.1 业务背景

第一是实时预警场景，它是十分典型的业务诉求，把用户看数据的形式从大屏“盯盘”转换为“依据规定检测后果，被动推送”，这无疑对一些要害业务问题的发现和洞察起到至关重要的作用。有如下三个具体案例：

• 直播实时检测场景。当检测到 10 分钟内观看人数继续上涨的直播间时，实时把音讯推送给直播达人，不便其及时做出直播策略的调整。比方调整解说商品的话术，发放粉丝礼物等等，进而晋升转化。
• 实时风控的场景。当检测到有用户 30 分钟内创立了多笔订单，均未领取的状况，这个用户大概率是一个刷单用户。咱们会将这个用户实时推送给平台治理同学，并做出相应的封禁处理，促成平台的整体生态衰弱。
• 售后征询场景。当检测到一个用户发动征询后，超过 30 分钟都未失去回复，会立刻告诉相干的客服人员及时回复，晋升整体的用户体验。

第二是施行营销场景，它是基于实时数据驱动，依据定义的规定策略开掘目标群体，并依据业务指标做出精准营销投放的营销流动。有如下三个具体案例：

• 实时发券场景。针对一些价格比拟高的商品，当检测到用户下单后超过 30 分钟没有领取，那么该用户很有可能是感觉价格太高，所以始终犹豫要不要领取。这个时候能够及时给这个用户发放一些优惠券刺激购买，从而晋升平台的转化率。
• 帮忙商家及时发现爆款商品场景。当检测到某款商品在五分钟内成交超过 1000 单时，会实时将这个商品的名称、品牌、库存等信息推送给商家，以便商家及时补货、直播间挂链接等行为，晋升经营效率。
• 在线发处分场景。当检测到一个达人在实现电商大学学习后，一天内进行了电商开播或者公布了电商短视频等行为，就会对这个达人发放抖 dou+ 券等典礼处分, 晋升整体达人的入驻率，进而给商家晋升更加多元的达人抉择。

2.2. 业务挑战

第一，在规定配置方面存在灵活性有余的问题。以后无论是新增还是批改规定，都须要实时数仓的研发同学通过批改代码的形式来反对，这就导致研发同学须要频繁的对接业务。在一些极其的场景，比方双十一大促期间，一个研发同学往往须要同时应对接，二十多个经营同学的规定创立或者批改的诉求。业务需要也因为人力的单点阻塞问题迟迟无奈上线。

第二，规定与计算工作之间存在深度耦合。当每个规定都须要强制绑定一个计算工作时，就会导致计算工作的数量会随着规定的创立逐步增多。大量的工作会造成极高的运维老本和微小的资源节约，使整个零碎最终变得不可保护。以后面提到的商家自定义规定检测爆款商品的这个场景为例，思考到以后抖音电商宏大的商家群体，最终创立规定的数量可能是微小的，进而导致整个计算工作的数量也随之爆炸。

第三，以后 Flink CEP 反对的规定语义不够丰盛。列举两个典型的案例：

• 第一个案例，假如咱们须要检测用户屡次下单后，没有在一小时内实现领取行为。这种场景的特点是用户最初一次下单后，始终没有领取事件来触发这个规定实现匹配。以后 Flink CEP 不反对这种场景，但在实在的业务中这又是十分广泛的规定诉求。
• 第二个案例，假如咱们须要检测用户在过来一小时内，是否实现浏览商品、退出购物车、下单行为。留神这里要求的三种行为不分先后顺序，只有在规定的工夫内实现以上三种行为即可。这种场景以后 Flink CEP 也不反对。

三、解决方案实际

整体咱们分为四个阶段来解决上述的问题。

第一阶段，咱们对 Flink CEP 规定的外围信息进行了提炼和形象，并设计了一套清晰易懂的规定 DSL。这样就能够让业务同学自主配置业务规定，从而解决规定配置灵活性有余的问题。那么如何让业务配置的规定运行起来？

第二阶段，咱们对 Flink CEP 计算工作进行革新，让其反对动静提交规定或者更新规定的能力，从而实现规定与计算工作之间的彻底解耦。解耦之后，不再强制要求每一个规定必须对应一个计算工作来运行。也就是同一个计算工作能够同时接管提交的多条规定，实现收敛整体计算工作的数量，晋升规定利用率的指标。

后面两个阶段要解决了规定配置的灵活性以及规定与其余工作的强绑定问题，然而依然没有解决规定自身的语义丰富性问题。因而，第三阶段，咱们次要针对特定业务的场景的规定诉求、降级和拓展规定的语义。

通过前三阶段的降级和优化，后面提到的业务痛点曾经根本失去了解决，但规定引擎在易用性和周边能力方面还有所欠缺。例如咱们无奈直观的查看以后零碎运行的规定内容、注册事件数据；业务提交的规定与计算工作之间依据什么样的策略来进行散发；用户依然须要订阅规定引擎的输入数据进行格局转换、写入指标存储等操作。

因而在第四阶段，咱们整合了后面的计划，并不断丰富周边能力生态，打造了一站式实时规定平台。反对用户在平台上进行事件注册、预览、规定配置、规定调试、规定公布等全流程的自主操作，进一步晋升工作效率。

为了实现业务自主配置规定，规定的语法必须清晰易懂。咱们设计规定 DSL 整体联合了 JSON 和根底 SQL 语法，利用 JSON 的高可读性来形容规定的元数据、规定匹配属性等信息，利用 SQL 的弱小表达力来形容 CEP 匹配条件以及匹配后果的解决逻辑。

这里咱们发现了一个新的问题，如何通过 SQL 来表白事件是否满足匹配条件？SQL 能够查问哪些表？以一个具体的案例来答复这个问题。

假如要检测用户下单后是否产生了领取行为，那么规定编译生成的 NFA 可能是上图所示的样子。在规定运行时，咱们将以后流入的事件以及以后规定的两头匹配后果，都以数据表的模式注册到上下文。以后流入的事件对应的表名称默认是 events，规定两头匹配后果对应的表名称和它的 PatternName 保持一致。

在这个案例中，每个 SQL 可查问到的表就是三张，别离是 events 表，示意以后流入的事件；create_order 表，示意以后曾经匹配到的下单事件；pay_order 表，示意曾经匹配到的领取事件。

在配置 SQL 时，就能够对曾经注册到上下文的任意数据表进行查问。当 SQL 查问的后果非空时，就示意以后匹配条件判断通过。状态机通过 Take 边流转到下一个状态，并将事件保留到对应的表，否则就会到 Ignore 边，抛弃掉事件。

再来看一下这个案例对应的规定配置条件的残缺配置。整体是一个数组的模式，数组中每个元素示意一个 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%+。

四、将来瞻望

将来咱们打算在以下三个方面持续对规定引擎进行建设。

• 第一，持续打磨实时规定平台周边生态能力，实现更丰盛、灵便的事件接入、触达形式。
• 第二，摸索规定计算流批一体，突破离线、实时事件之间的壁垒，拓展平台利用范畴。
• 第三，买通公司大数据研发环境，实现更加便捷的计算工作操作，进一步升高人工成本。

点击查看直播回放 & 演讲 PPT

更多内容

流动举荐

阿里云基于 Apache Flink 构建的企业级产品 - 实时计算 Flink 版现开启流动：
99 元试用 实时计算 Flink 版（包年包月、10CU）即有机会取得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！
理解流动详情：https://www.aliyun.com/produc…