从滴滴的Flink CEP引擎说起

从滴滴的Flink CEP引擎说起

本文转载自 https://www.cnblogs.com/cx2016/p/11647110.html。

CEP业务场景

复杂事件处理（Complex Event Process，简称CEP）用来检测无尽数据流中的复杂模 式，拥有从不同的数据行中辨识查找模式的能力。模式匹配是复杂事件处理的一个强 大援助。 例子包括受一系列事件驱动的各种业务流程，例如在安全应用中侦测异常行为；在金 融应用中查找价格、交易量和其他行为的模式。其他常见的用途如欺诈检测应用和传 感器数据的分析等。

说了这么多可能还是觉得比较抽象，那么我们可以看看这次滴滴分享的FlinkCEP在滴滴中的业务场景。

 

吐槽时刻：

虽然，业务场景ppt写的很好，但是最近几次顺风车事故，给大家留下了糟糕的印象。大数据没用起来，cep其实应该也可以用在顺风车安全检测上吧。

Flink CEP

Flink的CEP是基于Flink Runtime构建的实时数据规则引擎，擅长解决跨事件的匹配问题。
可以看看，滴滴的屁屁踢上给出的两个demo

Flink CEP的特点

 

动态规则

其实，对于实时领域的规则引擎，我们不想每次修改都要打包编码，只希望简单修改一下规则就让它能执行。

当然，最好规则是sql 的形式，运营人员直接参与规则编写而不是频繁提需求，很麻烦。。。。此处，省略万字。。

要知道flink CEP官网给出的API也还是很丰富的，虽然滴滴这比也给出了他们完善的内容。

 

flink官方的CEP文章，浪尖及浪尖组织的flink小团队，已经翻译过了。链接如下：

https://github.com/crestofwave1/oneFlink/blob/master/doc/CEP/FlinkCEPOfficeWeb.md

那么，为了实现动态规则编写，滴滴的架构如下：

具体的规则实现如下：

可以看到，其规则还是要编码成java代码，然后再用groovy动态编译解析，不知道效率如何。。。

对于规则引擎，当然很多人想到的是drools，这个跟flink结合也很简单，但是效率不怎么苟同。

Flink CEP的SQL实现

熟悉flink的小伙伴肯定都知道Flink的SQL引擎是基于Calcite来实现的。那么细心的小伙伴，在calcite官网可以发现，calcite有个关键字MATCH_RECOGNIZE。可以在这个网页搜索，找到MATCH_RECOGNIZE关键字使用。

http://calcite.apache.org/docs/reference.html

那么这时候可能会兴冲冲写个demo。

final String sql = "select frequency,word,timestamp1 "
    + "  from wc match_recognize "
    + "  ("
    + "       order by  timestamp1 "
    + "       measures A.timestamp1 as timestamp1  ,"
    + "       A.word as  word ,"
    + "       A.frequency as  frequency "
    + "       ONE ROW PER MATCH "
    + "    pattern (A B) "
    + "    within interval '5' second "
    + "    define "
    + "      A AS A.word = 'bob' , "
    + "      B AS B.word = 'kaka' "
    + "  ) mr";

很扫兴的它报错了：

 

那么问题来了，calcite支持而flink不支持，为啥？

赶紧发了个issue，然后迅速得到官方回复：

 

 

 

但是，翻翻阿里的blink使用手册和华为的flink使用手册发现两者都支持。

好吧。其实，很不服气，周末，除了健身就是加班。

波折一番，解决了，需要修改flink-table相关的内容，执行计划，coden等。

最终，实现了。

 

---

 

滴滴是如何从零构建集中式实时计算平台的？

 

• 梁李印

阅读数：35242019 年 2 月 7 日 09:00

 

滴滴出行作为一家出行领域的互联网公司，其核心业务是一个实时在线服务。因此具有丰富的实时数据和实时计算场景。本文将介绍滴滴实时计算发展之路以及平台架构实践。

01 实时计算演进

随着滴滴业务的发展，滴滴的实时计算架构也在快速演变。到目前为止大概经历了三个阶段，第一阶段是业务方自建小集群；第二阶段是集中式大集群、平台化；第三阶段是 SQL 化。图 1 标识了其中重要的里程碑，下面给出详细阐述。

在 2017 年以前滴滴并有没有统一的实时计算平台，而是各个业务方自建小集群。其中用到的引擎有 Storm、JStorm、Spark Streaming、Samza 等。业务方自建小集群模式存在如下弊端：

（1）需要预先采购大量机器，由于单个业务独占，资源利用率通常比较低；

（2）缺乏有效的监控报警体系；

（3）维护难度大，需要牵涉业务方大量精力来保障集群的稳定性；

（4）缺乏有效技术支持，且各自沉淀的东西难以共享。

为了有效解决以上问题，滴滴从 2017 年年初开始构建统一的实时计算集群及平台。技术选型上，我们基于滴滴现状选择了内部用以大规模数据清洗的 Spark Streaming 引擎，同时引入 On-YARN 模式。利用 YARN 的多租户体系构建了认证、鉴权、资源隔离、计费等机制。相对于离线计算，实时计算任务对于稳定性有着更高的要求，为此我们构建了两层资源隔离体系。

第一层是基于 CGroup 做进程（Container）级别的 CPU 及内存隔离。第二层是物理机器级别的隔离。我们通过改造 YARN 的 FairScheduler 使其支持 Node Label。达到的效果如图 2 所示：普通业务的任务混跑在同一个 Label 机器上，而特殊业务的任务跑在专用 Label 的机器上。

通过集中式大集群和平台化建设，基本消除了业务方自建小集群带来的弊端，实时计算也进入了第二阶段。伴随着业务的发展，我们发现 Spark Streaming 的 Micro Batch 模式在一些低延时的报警业务及在线业务上显得捉襟见肘。于是我们引入了基于 Native Streaming 模式的 Flink 作为新一代实时计算引擎。Flink 不仅延时可以做到毫秒级，而且提供了基于 Process Time/Event Time 丰富的窗口函数。基于 Flink 我们联合业务方构架了滴滴流量最大的业务网关监控系统，并快速支持了诸如乘客位置变化通知、轨迹异常检测等多个线上业务。

02 实时计算平台架构

为了最大程度方便业务方开发和管理流计算任务，我们构建了如图 3 所示的实时计算平台。在流计算引擎基础上提供了 StreamSQL IDE、监控报警、诊断体系、血缘关系、任务管控等能力。以下分别介绍各自的作用：

（1）StreamSQL IDE。下文会介绍，是一个 Web 化的 SQL IDE；

（2）监控报警。提供任务级的存活、延时、流量等监控以及基于监控的报警能力；

（3）诊断体系。包括流量曲线、Checkpoint、GC、资源使用等曲线视图，以及实时日志检索能力。

（4）血缘关系。我们在流计算引擎中内置了血缘上报能力，进而在平台上呈现流任务与上下游的血缘关系；

（5）任务管控。实现了多租户体系下任务提交、启停、资产管理等能力。通过 Web 化任务提交消除了传统客户机模式，使得平台入口完全可控，内置参数及版本优化得以快速上线。

03 实时规则匹配服务建设

在滴滴内部有大量的实时运营场景，比如“某城市乘客冒泡后 10 秒没有下单”。针对这类检测事件之间依赖关系的场景，用 Fink 的 CEP 是非常合适的。但是社区版本的 CEP 不支持描述语言，每个规则需要开发一个应用，同时不支持动态更新规则。为了解决这些问题，滴滴做了大量功能扩展及优化工作。功能扩展方面主要改动有：

（1）支持 wait 算子。对于刚才例子中的运营规则，社区版本是表达不了的。滴滴通过增加 wait 算子，实现了这类需求；

（2）支持 DSL 语言。基于 Groovy 和 Aviator 解析引擎，我们实现了如图 4 所示的 DSL 描述规则能力。

（3）单任务多规则及规则动态更新。由于实时运营规则由一线运营同学来配置，所以规则数量，规则内容及规则生命周期会经常发生变化。这种情况每个规则一个应用是不太现实的。为此我们开发了多规则模式且支持了动态更新。

除了功能拓展之外，为了应对大规模运营规则的挑战，滴滴在 CEP 性能上也做了大量优化，主要有：

（1）SharedBuffer 重构。基于 Flink MapState 重构 SharedBuffer，减少每次数据处理过程中的状态交互。同时剥离规则和用户数据极大降低每次匹配的时候从状态中反序列化的数据量；

（2）增加访问缓存（已贡献社区）。缓存 SharedBuffer 数据中每次处理所需要更新的引用计数，延缓更新；

（3）简化 event time 语义处理。避免 key 在很分散情况下每次 watermark 更新时要遍历所有 key 的数据；

（4）复用 conditionContext（已贡献社区）。减少条件查询时对 partialMatch 元素的反复查询。

以上优化将 CEP 性能提升了多个数量级。配合功能扩展，我们在滴滴内部提供了如图 5 所示的服务模式。业务方只需要清洗数据并提供规则列表 API 即可具备负责规则的实时匹配能力。

目前滴滴 CEP 已经在快车个性化运营、实时异常工单检测等业务上落地，取得了良好的效果。

04 StreamSQL 建设

正如离线计算中 Hive 之于 MapReduce 一样，流式 SQL 也是必然的发展趋势。通过 SQL 化可以大幅度降低业务方开发流计算的难度，业务方不再需要学习 Java/Scala，也不需要理解引擎执行细节及各类参数调优。为此我们在 2018 年启动了 StreamSQL 建设项目。我们在社区 Flink SQL 基础上拓展了以下能力：

（1）扩展 DDL 语法。如图 6 所示，打通了滴滴内部主流的消息队列以及实时存储系统。通过内置常见消息格式（如 json、binlog、标准日志）的解析能力，使得用户可以轻松写出 DDL 语法，并避免重复写格式解析语句。

（2）拓展 UDF。针对滴滴内部常见处理逻辑，内置了大量 UDF，包括字符串处理、日期处理、Map 对象处理、空间位置处理等。

（3）支持分流语法。单个输入源多个输出流在滴滴内部非常常见，为此我们改造了 Calcite 使其支持分流语义。

（4）支持基于 TTL 的 join 语义。传统的 Window Join 因为存在 window 边界数据突变情况，不能满足滴滴内部的需求。为此我们引入了 TTL State，并基于此开发了基于 TTL Join 的双流 join 以及维表 join。

（5）StreamSQL IDE。前文提到平台化之后我们没有提供客户机，而是通过 Web 提交和管控任务。因此我们也相应开发了 StreamSQL IDE，实现 Web 上开发 StreamSQL，同时提供了语法检测、DEBUG、诊断等能力。

目前 StreamSQL 在滴滴已经成功落地，流计算开发成本得到大幅度降低。预期未来将承担 80% 的流计算业务量。

05 总结

作为一家出行领域的互联网公司，滴滴对实时计算有天然的需求。过去的一年多时间里，我们从零构建了集中式实时计算平台，改变了业务方自建小集群的局面。为满足低延时业务的需求，成功落地了 Flink Streaming，并基于 Flink 构建了实时规则匹配（CEP）服务以及 StreamSQL，使得流计算开发能力大幅度降低。未来将进一步拓展 StreamSQL，并在批流统一、IoT、实时机器学习等领域探索和建设。