Flink1.10从0到1：（一）为什么要学习Flink

前言：

        本博客用于监督记录本人学习Flink。会从0开始分享一些学习过程，当中不排除可能有些错误，如果有希望指出来，大家友好交流，共同进步。

思考:

        目前实时框架有老牌Strom，也有Strom的升级版Trident，还有应用广泛的Spark Streaming。为什么又出了个Flink？与其他两者相比Flink有什么优势？

解答：

        不多哔哔直接对比！！！

框架	处理机制	API	保证次数	容错	状态管理	延时	吞吐量
Storm	Native(数据进入立即处理)	组合式(基础API)	At least once（至少一次）	Record ACK（ACK机制）	无	低	低
Trident	Micro-Batching（微批处理）	组合式	Exactly once（精准一次）	Record ACK	基于操作（每次操作有一个状态）	中	中
SparkStreaming	Micro-Batching	声明式（提供封装后的高阶函数）	Exactly once	CheckPoint（基于RDD做CheckPoint）	基于DStream	中	高
Flink	Native	声明式	Exactly once	CheckPoint（Flink的一种快照）	基于操作	低	高

处理机制：Storm 和 Flink 是真正的一条一条处理数据；而 Trident（Storm 的封装框架）和 Spark Streaming其实都是小批处理，一次处理一批数据（小批量）。

API：Storm 和 Trident都使用基础 API进行开发，比如实现一个简单的 sum 求和操作；而 Spark Streaming和 Flink 中都提供封装后的高阶函数，可以直接拿来使用，比较方便。

保证次数：在数据处理方面，Storm可以实现至少处理一次，但不能保证仅处理一次，这样就会导致数据重复处理问题，所以针对计数类的需求，可能会产生一些误差；Trident通过事务可以保证对数据实现仅一次的处理，Spark Streaming 和 Flink 也是如此。

容错：Storm和Trident可以通过ACK机制实现数据的容错机制，而Spark Streaming和 Flink 可以通过 CheckPoint机制实现容错机制。

状态管理：Storm 中没有实现状态管理，Spark Streaming 实现了基于 DStream的状态管理，而 Trident和 Flink 实现了基于操作的状态管理。

延时：表示数据处理的延时情况，因此 Storm 和 Flink 接收到一条数据就处理一条数据，其数据处理的延时性是很低的；而 Trident和 Spark Streaming都是小型批处理，它们数据处理的延时性相对会偏高。

吞吐量：Storm的吞吐量其实也不低，只是相对于其他几个框架而言较低；Trident属于中等；而 Spark Streaming和 Flink的吞吐量是比较高的。

 

以上是我通过查阅资料进行的对比，一目了然，Flink必然会被一大票公司选择！！！

最后：

       以上理由都是次要理由，主要理由是公司要用，找工作需要！！！