Spark Streaming、Storm、Flink对比分析，以及为什么选择Flink作为流处理框架

       随着大数据技术的不断发展和成熟，无论是传统企业还是互联网公司都已经不再满足于离线批处理，实时流处理的需求和重要性日益增长。17年底公司就着力打造实时计算平台，探索实时流计算引擎和 API，例如这几年火爆的 Storm、Spark Streaming、Kafka Streaming、Beam 和 Flink。

        我们当时的目标就是需要一款低延迟、exactly once、流和批统一的，能够支撑足够大体量的复杂计算的引擎。Spark 在当下批、流、机器学习、图计算是比较火的，而且对sql支持也比较好，生态完整。Spark streaming 的本质还是一款基于 microbatch 计算的引擎。这种引擎一个天生的缺点就是每个 microbatch 的调度开销比较大，当我们要求越低的延迟时，额外的开销就越大。这就导致了 spark streaming 实际上不是特别适合于做秒级甚至亚秒级的计算。

      Storm 在最开始的流处理中扮演了很重要的角色，可以亚秒级的响应，阿里开源的JStorm，在很多互联网公司，被广泛应用于流计算处理。Storm是一个没有批处理能力的数据流处理器，除此之外 Storm 只提供了非常底层的 API，用户需要自己实现很多复杂的逻辑。另外，Storm 在状态管理和容错能力上不足。种种原因，Storm 也无法满足我们的需求。

       Kafka streaming 是从一个日志系统做起来的，它的设计目标是足够轻量，足够简洁易用。这一点很难满足我们对大体量的复杂计算的需求。

       Flink几乎满足我们所有的需求：

a) 不同于 Spark，Flink 是一个真正意义上的流计算引擎，和 Storm 类似，Flink 是通过流水线数据传输实现低延迟的流处理；

b) Flink 使用了经典的 Chandy-Lamport 算法，能够在满足低延迟和低 failover 开销的基础之上，完美地解决 exactly once 的目标；

c）如果要用一套引擎来统一流处理和批处理，那就必须以流处理引擎为基础。Flink 还提供了 SQL／tableAPI 这两个 API，为批和流在 query 层的统一又铺平了道路。因此 Flink 是最合适的批和流统一的引擎；

d) 最后，Flink 在设计之初就非常在意性能相关的任务状态 state 和流控等关键技术的设计，这些都使得用 Flink 执行复杂的大规模任务时性能更胜一筹。