Flink面前，SparkStreaming根本不是对手？

计算引擎是整个大数据生态非常重要的一环，根据业务需求不同，大数据计算又分为离线批量计算和在线实时计算。比如基于MapReduce的海量计算属于离线计算范畴；基于ClickHouse的计算属于实时在线计算范畴。Flink就是一款既支持离线批量计算又支持实时在线计算引擎，无疑大数据开发/架构师必须具备的核心技能。

大数据起源于批处理，在批处理上，Spark有很深的积累。为了应对全球大量业务的实时需求，Spark也推出了流计算解决方案——SparkStreaming。但Spark毕竟不是一款纯流式计算引擎，所以在时效性等问题上，始终无法提供极致的流批一体体验。

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

Flink本身带有的优势：

• Flink支持高吞吐、低延迟、高性能的流处理；

• Flink支持高度灵活的窗口（window）操作；

• Flink支持有状态计算的exactly-once语义；

• Flink提供DataStreamAPI和DataSetAPI。

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

• 支持高效容错的状态管理，保证在任何时间都能计算出正确的结果；

• 同时支持高吞吐、低延迟、高性能的分布式流式数据处理框架；

• 支持事件时间（Event Time）概念，事件即使无序到达甚至延迟到达，数据流都能够计算出精确的结果；

• 轻量级分布式快照（Snapshot）实现的容错，能将计算过程分布到单台并行节点上进行处理。

Spark 和 Flink 两个项目的核心 API 基本一致，Spark 在机器学习整合方面投入更多，Flink 在流处理方面更赞（这也是大家在 2016 年开始关注 Flink 的原因），当然二者最大的区别，也还在于对流式计算的支持。这句的潜在含义就是 Spark 存在的道理：尽管 Spark Steaming 现在和 Flink 相比优势不显，但它的生态更为丰富，除了 Streaming 还有 SQL、MLib、Graphx 等，同时目前 Spark 对 Kubernetes 云原生技术的原生支持更加到位。

本文部分素材源自：知乎、DataFunTalk