为何流处理最近很火,而同根的复杂事件处理一直不温不火

读博士的时候曾经做个CEP,参与过一个叫做Cayuga的复杂事件处理系统:
Cornell Database Group - CayugaCornell Database Group - Cayuga
当时的框架还是和最早的DSMS一样,比如最早Stanford的STREAM,就是上层有个查询语句比如CQL,编译到下层的runtime作为一个automaton执行;几年过去了,情况大变化。现在工作里面也看见过一些在数据流上做复杂事物处理或者查询的工具,比如你提到的Flink CEP,还有这个:
fhussonnois/kafkastreams-cep: Complex Event Processing on top of Kafka Streams
我个人的一个感觉是,现在更多的CEP系统都基于一个下层的流处理平台,比如说现在的Kafka Streams,Flink,Storm;当下层的流处理平台丰富完善之后,CEP变成一个简单的把查询语句编译到流处理平台的 thin layer。
另一方面,不可能让所有人都能够熟练地写Java或者C++甚至Python程序来做复杂的业务流程处理,不现实;现实是需要有SQL for Stream Processing,DSL for Stream Processing,CEP等等等等。所以我觉得CEP或者StreamQL将来还是会变热的,也许就是17年,我也说不准。

■网友
曾经写过简单的类CEP的引擎,也啃过esper几百页的文档,写过一些CEP的应用
结论是:绝大多数的互联网业务,适合CEP的场景,都没有复杂到需要CEP的程度

■网友
因为目前的工作就是做流计算,对流式计算略微有点了解。当前公司的很多业务对实时的要求越来越多,比如双11大屏,实时展示目前的网站pv、uv,购买量等,这就需要实时计算相关技术派上用场了,也就是问题所提到的storm、flink 、kafka等技术,流式计算可以做到每来一条数据就会就行计算,立刻看到统计结果,与T+1 的离线计算相比,在某些场景下,我们是没法容忍后者离线的计算方式。至于后者的CEP, 在Flink 中有接触到 flink cep, 但是这块没怎么研究。
【为何流处理最近很火,而同根的复杂事件处理一直不温不火】 个人觉得未来,微服务和流式计算的架构将会是一个主流。


    推荐阅读