VS
- Apache Storm 只能处理流数据，没有批处理的能力。
- 事实上，Flink的流式处理引擎和Storm很相似，比如 Flink的并行任务和Storm的bolt很相似。他俩都是通过流水线数据的传输来降低数据延时。然而Flink 提供了很多跟高级的api ,Flink的DataStream提供了Map、GroupBy、Window和Join等api来代替storm的bolt在一个或多个readers 和collectors的功能，而Storm在实现这些功能的时候都需要程序员自己实现。另外的不同在于处理语义。
Storm提供了”at-least-once “而Flink提供了”exactly-once”，两个框架给与语义不同的保证在实现上也就相当的不同。
Storm也提供了 exactly-once 以及高级api ，但是被称为Trident ，然而Trident 是在微批处理的基础上实现的，就很像Spark了而不是Flink1
Storm 采用 record-level ack，Flink采用Chandy-Lamport的轻微变种。简言之，在数据源中周期性的注入marker，然后放入数据流中，无论何时只要任务执行器接受到一个marker，执行器检查他的内部状态。当一个marker被所有的数据输出sink给接收到，证明这个marker被提交（在这个marker之前的所有执行的数据，到上一个被提交的marker之后的所以数据）。万一有一个sink没有接受到marker，所有的源操作器将重置他们的处理数据到最近一次确认提交的marker然后继续执行。这种检查标记点的方法比record-level ack更加的轻量级。这个幻灯片（幻灯片2）讨论了flink相应的容错机制、检查点、处理状态。
Flink的“可调延迟性”指的是Flink的记录从一个任务到另外一个任务的时间延迟。我再前面说了，flink使用流水线转移，在数据生成之后快速转发。为了效率，这些记录会被收集起来放在缓冲器中，当缓冲器满了或者是到了一个确定的阈值时间点被网络发送。这个阈值控制着这个记录的延迟。因为他指定了最大时间的延迟，一个记录从生成到发送出去。然而，他不能被用来保证一个数据从进入Flink项目到出Flink项目所花费的时间，因为这取决于任务处理执行时间和网络传输了多少次。
Flink比Storm的改进还有以下几点
背压
Flink流计算当不同操作器在速度不同的时候表现的很好。因为低速流操作器背压高速流操作器很好，虽然网络层管理控制缓存池。
用户定义状态
Flink允许用户在操作器中自定义状态。这个自定义状态可以参与在检查点的容错处理，也提供exactly-once语义支持。参见这个列子（幻灯片3），在一个操作器中用户自定义机器状态，该状态始终与数据流一起参与checkpoint。
流窗口
流窗口和窗口聚合是数据流分析的重要组成部分。Flink配备了一个非常强大的窗口系统，支持多种类型的窗口