首先我们考察的便是 Spark,Spark 最大的问题是需要我们人为指定计算的时间窗口,计算的数据也是批量的那种而非单条,这和告警的业务需求本身就不匹配。
因为当时我们想设计的告警计算是实时的,而非定时。Spark Streaming 在后面还因为执行模式进一步被我们淘汰。
Strom 各方面其实都蛮符合我们需求的,它也能实现所谓的单条实时计算。但是,它的计算节点不持有计算状态,某些时候的窗口数据,是需要有类似 Redis 一类的外部存储的。
Flink优势:
Spark 有的功能 Flink 基本都有,流式计算比 Spark 支持要好。
- Spark是基于数据片集合(RDD)进行小批量处理,所以Spark在流式处理方面,不可避免增加一些延时。
- 而 Flink 的流式计算跟 Storm 性能差不多,支持毫秒级计算,而 Spark 则只能支持秒级计算。
- Flink 有自动优化迭代的功能,如有增量迭代。它与 Hadoop 兼容性很好,还有 pipeline 模式增加计算性能。
这里,我需要重点说一下 pipeline 模式。
Staged execution 就如它的名字一样,数据处理分为不同的阶段,只有一批数据一个阶段完全处理完了,才会去执行下一个阶段。典型例子就是 Spark Streaming
Pipeline 则是把执行串行在了一起,只有有计算资源空闲,就会去执行下一个的操作。在外部表象是只有一个阶段。
上面的不好理解,我们思考一个更形象的例子:
某生产线生产某钟玩具需要A,B,C三个步骤,分别需要花费10分钟,40分钟,10分钟,请问连续生产n个玩具大概需要多少分钟?
总结:
stage的弊端是不能提前计算,必须等数据都来了才能开始计算(operateor等数据,空耗时间)。pipeline的优势是数据等着下一个operateor有空闲就立马开始计算(数据等operateor ,不让operateor闲着,时间是有重叠的)
综合前面的调研分析,我们有了上面这张表格。对于我们而言,其实在前面的分析中 Flink 就已经被我们考虑了,尤其是它还有能与 Hadoop 体系很好地整合这种加分项。
感谢博主,收获很多,个人觉得整个架构重点在关注数据流式处理和存储,为什么不考虑用类似influxdb等时序数据库引擎实现呢?
雨帆大佬,这篇文章写的是非常好啦。小弟还有些不懂的地方,可以求个认识么?邮箱是QQ也是微信。