首先我们考察的便是 Spark，Spark 最大的问题是需要我们人为指定计算的时间窗口，计算的数据也是批量的那种而非单条，这和告警的业务需求本身就不匹配。

因为当时我们想设计的告警计算是实时的，而非定时。Spark Streaming 在后面还因为执行模式进一步被我们淘汰。

Strom 各方面其实都蛮符合我们需求的，它也能实现所谓的单条实时计算。但是，它的计算节点不持有计算状态，某些时候的窗口数据，是需要有类似 Redis 一类的外部存储的。

Flink优势：

Spark 有的功能 Flink 基本都有，流式计算比 Spark 支持要好。

  1. Spark是基于数据片集合（RDD）进行小批量处理，所以Spark在流式处理方面，不可避免增加一些延时。
  2. 而 Flink 的流式计算跟 Storm 性能差不多，支持毫秒级计算，而 Spark 则只能支持秒级计算。
  3. Flink 有自动优化迭代的功能，如有增量迭代。它与 Hadoop 兼容性很好，还有 pipeline 模式增加计算性能。

这里，我需要重点说一下 pipeline 模式。

Staged execution 就如它的名字一样，数据处理分为不同的阶段，只有一批数据一个阶段完全处理完了，才会去执行下一个阶段。典型例子就是 Spark Streaming

Pipeline 则是把执行串行在了一起，只有有计算资源空闲，就会去执行下一个的操作。在外部表象是只有一个阶段。

上面的不好理解，我们思考一个更形象的例子：

某生产线生产某钟玩具需要A,B,C三个步骤，分别需要花费10分钟，40分钟，10分钟，请问连续生产n个玩具大概需要多少分钟？

总结：

stage的弊端是不能提前计算，必须等数据都来了才能开始计算(operateor等数据，空耗时间)。pipeline的优势是数据等着下一个operateor有空闲就立马开始计算(数据等operateor ，不让operateor闲着，时间是有重叠的)

综合前面的调研分析，我们有了上面这张表格。对于我们而言，其实在前面的分析中 Flink 就已经被我们考虑了，尤其是它还有能与 Hadoop 体系很好地整合这种加分项。