2019大数据产业峰会|星环科技季钱飞：流处理的下一阶段——实时智能决策引擎

现在的社区的流处理引擎发展到现在，进入到了小小的瓶颈期。因为在早些年可以看到每个版本发布的时候都会有很多令人振奋的功能特性出现，并且是能够真的让用户拿到后就可以立马用到业务开发当中去的，但是回顾过去一年多的时间，我们回顾整个社区产品发布，它的功能特点还是会让人眼前一亮，但是据我们了解到的这些客户的反馈，真正能够用到生产上的功能点是比较少的。所以同样我们也面临过这样的问题，努力尝试想找到一个新的发力点，如何帮助用户更方便的解决他们的复杂分析的场景，其中一个发力点就是实时决策引擎的功能。

为什么会讲到这一点？因为很多用户使用了我们的流处理产品，他们的业务系统当中已经大量使用了规则引擎。规则引擎是为了解决软件系统开发的速度不能够跟上外界商务环境变化的速度而提出来的，它通过将业务规则和整个应用系统解耦，达到快速规则更新的效果。

所以我们在想，能不能同时结合流处理的实时性以及规则引擎的灵活性，来帮助用户构造一些实时过程是准实时的智能决策系统呢？答案肯定是肯定的。在开发这个功能之前通常我们会怎么做呢？目前业内或者是客户现场用的比较多的架构就是如图所示的，在一个实时流处理引擎当中嵌入一个规则引擎——通常多是drools，架构包括三个模块，业务人员通过drools工具开发自己的业务规则，打包部署到流处理平台上。

第二层是整个实时计算层可以选用sparkstreaming，也可以选用Flink，通过实时接入数据源经过简单的加工之后和平会算出一些中间指标。我们知道场景通常比较复杂，算出来中间指标通常是需要缓存的，这时候又会引入redis的外部存储系统，将缓存之后的指标经过一些关联/加工之后再回到设计出来的业务规则处理模块，最终结果写入外部系统，这样一个架构可能对有经验的分布式开发人员来说还是比较清晰的。

从我个人的角度上来说，我认为这样的架构还是存在一些缺点，主要包括以下几个方面：

首先我们看到架构当中涉及到的组件数量是非常多的，这里只是列出了三个，意味着我们开发人员可能需要同时掌握这么多组件的编程接口，同时需要把它们进行整合对接才能让整个解决方案给跑起来。

第二点是通过这样一个架构很难做到规则的实时更新，主要有两方面原因，第一是通过drools开发方式，开发周期是比较长的，需要开发测试，打包部署到流处理平台，熟练工也得几小时以上。第二方面原因是现在我们用的比较多的流处理框架并没有为规则提供专门的管理模块，所以并没有办法做到实时的规则更新。

第三个问题是引入redis外部缓存带来的问题，一方面是性能问题，我们做过简单的测试，在通过redis做多指标的关联，再经过规则处理，整个这样一个处理流程的延迟会达到大几十毫秒甚至一百毫秒的延迟，这样的延迟在很多对延迟要求比较高的行业不可接受。第二方面，redis本身高可用的问题，虽然有提供分布式以及持久化的策略，但是经过我们的实验发现，开启这些高可用的策略之后整个性能和稳定性方面还是不能满足生产的要求。第三方面是整个架构当中因为是用来做实时规则处理，所以规则引擎其实还是核心组件，但是像drools是跟大数据规则独立出来的，如果将开发出来的规则和现有大数据系统进行对接的话其实是有比较大的代价。

既然我们发现其中会存在这么多问题，所以我们决定在slipstream当中引入一个专门的规则处理模块，可以看到将整个规则处理流程分为了4个阶段，第一规则的定义、第二规则库管理、第三规则解析执行、第四规则响应处理。通过这样一个细分我们希望能够帮助客户/合作伙伴提供一个一站式智能决策开发平台。

星环科技为何能实现这个目标？目前来说，我们已经实现的功能主要包括，第一是基于SQL的规则开发编程接口，能够跟现在大数据的生态是完美兼容的；第二我们对规则提供了一个多版本的管理机制，可以实现在线规则更新和升级；第三是我们能够自动利用分布式的计算引擎实现类型的规则处理，同时会结合现在在一些客户、一些行业的积累实现了很多台湾判断和响应策略的通过用范式。

接下来可以看一个简单的基于stream rule engine的处理。第一是指标定义，我们现在接入规则都是基于一些指标的判断，指标定义方面引入两层抽象，metricgroup，每个metrc是根据不同的维度、不同的指标计算出来的，slipstream会根据同一个metricgroup中进行自动的优化。第二是规则定义，同样引入了两层，ruleset包含一组相关的规则，同时可以在ruleset上定义一些匹配的策略，希望都满足之后进行处理还是特定规则或者一定比例的规则满足就做一些特别的处理，在那个基础之上抽象出来三个规则管理相关的接口，通过start stop规则处理的任务，如果发生了变化或者更新，通过不停机的在线升级。

刚才提的第三个问题，我们自己开发了一套规则引擎分布式实时缓存系统，系统采用了分层的架构。第一层是基于executor内存过素缓存平台，可以实现整个写入微秒级别的延迟，达到单物理节点百万的吞吐。第二层是基于transwarpshiva的缓存，可以将中间指标进行缓存，同时还实现的高速缓存和外部存储之间的自动刷出和加载策略，将内存写入达到一定之后自动刷缓。当然虽然这个缓存系统最初是为规则引擎内部所使用的，我们发现其实大量的用户为中间计算出来的指标是有些查询需求的，所以我们也对外暴露了一些中间指标的访问接口，目前支持两种访问策略，一个是发布订阅模式一个是批量读的模式。

当然我们现在已经有些客户和合作伙伴基于这样一个规则引擎在开发当中的决策系统，但是毕竟是属于全新的功能模块，所以还是有大量的工作需要完善和探索。

我个人觉得在实质规则处理方面接下来有这几个尝试的方向：

1、首先还要不断的优化整个规则处理的性能，以满足更多行业对规则判断高性能要求的需求，让我们这样一个实时规则模块实现它的创新价值；

（编辑：济源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!