为什么flink那么受欢迎？-Toy模板网

这篇具有很好参考价值的文章主要介绍了为什么flink那么受欢迎？。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

我们知道，Storm已经不流行了，目前几乎没有公司用。

对于大数据开发，主流的就是Hadoop Spark和Flink，一般学习顺序也都是Hadoop——spark——Flink。

现在也有很多人说Spark已经不行了，更倾向于学习和使用Flink。那是因为一些大厂例如阿里主要是使用Flink，双十一这种大型的实时计算量都是用flink来做的

大数据起源于批处理，在批处理上，Spark有很深的积累。为了应对全球大量业务的实时需求，Spark也推出了流计算解决方案——SparkStreaming。

但Spark毕竟不是一款纯流式计算引擎，所以在时效性等问题上，始终无法提供极致的流批一体体验。

而后起新秀Flink的基本数据模型则是数据流，以及事件(Event)的序列。数据流作为数据的基本模型，可以是无边界的无限“流”，即一般意义上的流处理；也可以是有边界的有限“流”，也就同时兼顾了批处理。

Flink相比于Spark而言还有诸多明显优势：

阿里早在几年前就开始探索Flink的实战应用，随着双11阿里基于Flink实时计算场景的屡战屡胜，毋庸置疑，Flink将会加速成为大厂主流的数据处理框架，最终化身下一代大数据处理标准。

Flink通过实现Google Dataflow流式计算模型实现了高吞吐、低延迟、高性能兼具实时流式计算框架，同时支持高度容错的状态管理，防止状态在计算过程中因系统异常丢失，Flink周期性的通过分布式快照技术Checkpoint实现状态的持久化维护，即使在系统异常情况下也能计算出正确的结果。

Storm虽然可以做到低延迟，但是无法实现高吞吐，也不能在故障发生时准确地处理计算状态。
Spark Streaming通过采用微批处理方法实现了高吞吐和容错性，但是牺牲了低延迟和实时处理能力。
Spark的另一个流计算组件Structured Streaming，包括微批处理和持续处理两种处理模型。采用微批处理时，最快响应时间需要 100毫秒，无法支持毫秒级别响应。采用持续处理模型时，可以支持毫秒级别响应，但是只能做到“至少一次”的一致性，无法做到“精确一次”的一致性。

同时支持高吞吐、低延迟、高性能
支持事件时间（EventTime）概念：大多数框架都只支持系统时间，事件传输到计算框架处理时的当前系统时间，Flink支持事件事件进行窗口计算，即使事件乱序到达，流系统也能计算出精确的结果，保持事件产生时的时序性，尽可能避免网络传输、硬件系统的影响。
支持状态计算：流计算过程中会将算子的中间状态保存在内存或文件系统，下一个事件进入算子后可以从之前的状态获取中间结果，避免每次基于全部原始数据来计算统计结果。对于数据量大运算逻辑复杂的流计算场景，有状态计算发挥了非常重要的作用。
支持高度灵活的窗口（Window）操作
基于轻量级分布式快照（Snapshot）实现的容错
基于JVM实现独立的内存管理
Save Point（保存点）：在版本升级运维时，通过Save Point将任务执行的快照保存在存储介质上，任务重启时可以直接从事先保存的Save Point中恢复原有的计算状态。