2019-06-05 10:00

　　各位来宾、各位领导大家上午好，很高兴今天可以跟大家汇报一下星环科技在流处理产品上的进展和一些探索性的工作。

　　在开始演讲之前简单做个自我介绍，我在10年-13年期间在英特尔亚太研究院工作，有幸参与发布了业内首个hadoop的发行版本。13年年终的时候我成为星环信息科技的初创团队成员，我们一起在一年半的时间内发布了首个基于spark的OLAP引擎。从14年到现在我一直负责星环的实时处理产品的研发工作。

　　今天的汇报主要包括以下三个方面：首先跟大家一起回顾一下整个流处理技术的发展历程；然后从星环的视角跟大家一起简单分析一下目前企业级流处理市场现状；最后稍微详细介绍一下我们目前在流处理技术上的探索性的研究和工作。

　　一、流处理技术的发展历程

　　在介绍流处理发展历程之前不妨看一下整个流处理技术所适用的场景，根据盖特纳的研究报告表明，流处理适用于实时数据集成、实时数据分析场景。大家用的比较多的是实时ETL和实时数仓，所有的社区、企业研发的产品基本上是为了解决这两种场景而开发的。我们可以从社区和星环两个层面看一下整个流处理组件发展的重要阶段。在社区产品上我从storm开始接触流处理是从事件驱动模型开发的，有比较低的数据延迟，相对来说在复杂分析上功能支持比较有限。下一个是spark的出现，是基于sparkstreaming的计算引擎实现微批处理模型，可以很方便实现多流之间的关联，流和表之间的统计分析等等，因为是微批模型，延迟最多做到百毫秒的级别。接下来就是Flink，首个提出流批一体的计算引擎，充分利用了事件驱动的处理模型，完善了上面分析的复杂功能。当然到现在为止，包括Flink包括spark在延迟功能上做的已经比较好了。

　　二、星环科技在流处理产品上的发展阶段

　　星环科技是从2014年开始，开辟了流处理产品线sparkstreaming，发布了企业产品，在交通产品上得到了大规模的部署和推广。但是在这个过程当中我们发现，早期的流处理用户很多时候是用来做一些实时ETL和简单的化疗统计，SQL是做的比较好的。我们15年支持首个基于SQL接入的平台，在市场开拓过程当中发现了微批处理的弊端，延迟实在太高了，并且在spark模型上重新改写了后段的引擎，实现首个融合数据驱动的星环产品，在此基础之上包含支持事件处理等等功能。现在我们还在探索一些流处理发展的趋势。

　　星环从2014年开始到现在，流处理产品已经发展经历了5年，服务过的客户数量涉及十多个行业，包括公安、交通、金融、能源、运营商等等，已经部署集群数量大概400多个物理集群，大部分是基于我们的产品构建了实时分析平台和平台上离线的分析应用。400多个集群上节点差不多5000个物理节点，集群规模最大的节点数差不多200多个节点。我们在这么多行业、这么多客户的合作，证明了我们流处理产品的可靠性和功能的完善性，也有幸接收了邀请参与制定《分布式流处理平台技术要求与测试方法》，并且5月份顺利通过分布式流处理平台基础能力测试。

　　通过这几年在企业客户的推广和实施，我们简单总结出来了一个企业对流处理引擎的几个关键指标，包括高性能、易用性、高可用性、安全性、智能化这5个方面。为了实现这5个关键指标，我们对整个slipstream架构从上往下设了三层：

　　存储层用来对接各种输入输出；

　　中间计算层包括分布式流处理引擎的5个模块——数据源管理系、输出管理系、任务管理、分布式执行引擎以及计算过程中的存储管理；

　　第三层是接口层。这里分为两个模块，一个是slipstream的SQL解析层，方便让用户通过ODDC的方式进行流式应用的开发。第二个是流上的挖掘算法解析层，可以在流上跑机器学习的算法。

　　通过这样一个结构，我们早期可以帮助用户实现一些实时的ETL，判断告警、比对告警、窗口比对等等。大家想问，市面上有这么多开源的流数据框架，也有其他发行版的产品，为什么星环会在几年时间内累积如此多的客户。我觉得是由于星环的产品除了在满足基本功能和性能要求之外，还在以下几方面做了比较多的投入。

　　1、易用性方面。星环在易用性上可以说做到了极致，早在2015年底2016年初的时候，我们就已经做到对SQL2003完整的支持，通过SQL的支持可以很方便的帮助用户将他们原先在关于数据库上开发的批处理应用场景迁移到流处理平台上，同时降低后期管理运维成本。

　　2、我们除了SQL之外还支持流上的存储过程，是兼容oracle和DB2两种存储过程与法的，通过这个语法可以实现流上的复杂流程管理。希望通过slipstream帮助用户打通现有公司内的所有数据系统，这样一个工作会覆盖整个实时处理过程中的全链路，包括数据采集接入、中间的指标计算、结果的输出等等。在数据源方面内置支持了大量用户常用的数，包括消息队列、日志系统、用户的其他外部的web service接口，计算过程是接口输入方面通过统一的语言数据管理模块，让用户可以通过统一的SQL接口，以类似于表这样的概念操作常用大数据系统的存储。通过slipstream这样的功能可以很方便的帮助用户构建企业的数据总线。

　　3、在多租户和资源管控方面做的工作。在多租户管理方面，通过静态元数据的管理模块，其中引入两个抽象，需个用户设立的用户在（P）当中，在（P）级别上提供用户访问权限控制，包括创建、启动、察看这些权限。在资源管理方面，引入一个动态资源管理层，这个模块里面提供了基于资源队列的归拢调度算法，方便用户指定它的优先级，以及它所希望运行在的队列，这样可以实现不同应用之间进行资源隔离和管控。

　　4、我们从很早就提供了一站式管理开发平台。通过这样一个管理开发平台希望给用户带来两方面的好处，第一是进一步降低用户开发的成本，用户可以通过图形化拖拽方式设立自己的应用。第二是提供了流任务的监控报警功能。我们知道流任务的监控相比传统的批处理来说会复杂很多，因为它可能不是真的出错了才告警通知，而是在整个运行阶段出现一些性能上的波动，也要及时的报给相关的人员，所以这就要求我们底层引擎搜集到更多的性能指标。对于这些升级的指标制定一些特定的规则和日志告警，我们这样一个一站式管理开发平台就是为了方便用户为不同任务定制不同的报警规则所提供的。

　　三、星环科技在流处理技术发展上的探索

　　刚刚快速的回顾了一下目前企业对流处理这样的产品所提出的一些硬性的指标以及星环在目前流处理产品上所做的一些工作，接下来跟大家一起分享一下我们在流处理技术发展上的探索。

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

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

　　所以我们在想，能不能同时结合流处理的实时性以及规则引擎的灵活性，来帮助用户构造一些实时过程是准实时的智能决策系统呢？答案肯定是肯定的。在开发这个功能之前通常我们会怎么做呢？目前业内或者是客户现场用的比较多的架构就是如图所示的，在一个实时流处理引擎当中嵌入一个规则引擎——通常多是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、首先还要不断的优化整个规则处理的性能，以满足更多行业对规则判断高性能要求的需求，让我们这样一个实时规则模块实现它的创新价值；

　　2、我们希望跟用户形成共生的关系，从用户的需求出发，不断提高用户使用这样一个功能的效率。具体会包含两方面工作，一个是会尽快实现规则处理引擎和中间工作，让用户通过共性化的方式处理规则处理业务规则。第二方面是还在不断丰富内置行业中间的条件判断算子和响应策略，希望能够让用户开发人员尽量少的甚至不用编写代码就能够实现整个业务；

　　3、星环帮助用户业务合作伙伴落地是我们的目标，我们期望通过这样的技术创新不断的跟用户合作挖掘数据产生的价值，最终能够形成一个多赢的局面。

　　以上就是我今天汇报的所有内容，感谢大家。