【深入浅出flink】第1篇：什么是flink？和Spark Streaming有什么区别？（开篇之作）

【深入浅出flink】第1篇：什么是flink？和Spark Streaming有什么区别？（开篇之作）

大家好，我是雷恩Layne，最近开始写flink系列文章，旨在用最直白的语言讲好flink，让所有看到的人能够一目了然。如果大家喜欢，欢迎点赞、关注，也欢迎留言，共同交流flink的点点滴滴 O(∩_∩)O

文章目录

• • 1. Flink 是什么
  • 2. Spark Streaming VS Flink
  • 3. Flink的设计架构
  • 4. Flink常见部署模式

1. Flink 是什么

官网的解释是：

Apache Flink is a framework and distributed processing engine for stateful computations over unbounded and bounded data streams.

Apache Flink 是一个框架和分布式处理引擎，用于对无界和有界数据流进行有状态的计算。Flink被设计在所有常见的集群环境中运行，以内存执行速度和任意规模来执行计算。

以下对Flink的特性进行解释：

（1）处理无界和有界数据流

在spark的世界观中，一切都是由批次组成的，离线数据是一个大批次，而实时数据是由一个一个无限的小批次组成的。

而在flink的世界观中，一切都是由流组成的，离线数据是有界限的流，实时数据是一个没有界限的流，这就是所谓的有界流和无界流。

• 无界数据流：无界数据流有一个开始但是没有结束，它们不会在生成时终止并提供数据，必须连续处理无界流，也就是说必须在获取后立即处理。对于无界数据流我们无法等待所有数据都到达，因为输入是无界的，并且在任何时间点都不会完成。处理无界数据通常要求以特定顺序（例如事件发生的顺序）获取event，以便能够推断结果完整性。
• 有界数据流：有界数据流有明确定义的开始和结束，可以在执行任何计算之前通过获取所有数据来处理有界流，处理有界流不需要有序获取，因为可以始终对有界数据集进行排序，有界流的处理也称为批处理。

（2）可在所有常见的集群环境中运行

Apache Flink 是一个分布式系统，它需要计算资源来执行应用程序。Flink 集成了所有常见的集群资源管理器，例如 Hadoop YARN、 Apache Mesos 和 Kubernetes，但同时也可以作为独立集群运行（standalone）。

Flink 被设计为能够很好地工作在上述每个资源管理器中。部署Flink 应用程序时，Flink 会根据应用程序配置的并行性自动标识所需的资源，并从资源管理器请求这些资源。在发生故障的情况下，Flink 通过请求新资源来替换发生故障的容器。提交或控制应用程序的所有通信都是通过REST 调用进行的，这可以简化Flink 与各种环境中的集成。

（3） 运行任意规模应用

Flink 旨在任意规模上运行有状态流式应用。因此，应用程序被并行化为可能数千个任务，这些任务分
布在集群中并发执行。所以应用程序能够（在资源充足的前提下）充分利用集群中CPU、内存、磁盘和网络IO。而且Flink 很容易维护非常大的应用程序状态，其异步和增量的检查点算法对处理延迟产生最小的影响。同时提供了一个Exactly-once的一致性语义，保证了数据的正确性，使得Flink可以提供金融级的数据处理能力。

（4）利用内存性能

有状态的Flink 程序针对本地状态访问进行了优化。任务的状态始终保留在内存中，如果状态大小超过
可用内存，则会保存在能高效访问的磁盘数据结构中。任务通过访问本地（通常在内存中）状态来进行计算，从而产生非常低的处理延迟。Flink 通过定期和异步地对本地状态进行持久化存储来保证
故障场景下精确一次的状态一致性。

Periodic, Asynchronous, Incremental snashots ：周期性的，异步的，增量的快照。通过设置一个定期的检查点（快照）去保存本地内存里的状态。假如出现故障的话，从之前存盘的状态去获取就行。原来的状态是放在本地内存里的，而现在的状态是放在远程的持久化磁盘上，就比较稳定了。这就保证了低延时、高吞吐、良好的容错（出现故障时可以恢复）。

2. Spark Streaming VS Flink

（1）流和微批的区别

Spark Micro Batching 模式

Micro-Batching 计算模式认为 “流是批的特例”， 流计算就是将连续不断的批进行持续计算，如果批足够小那么就有足够小的延时，在一定程度上满足了99%的实时计算场景。那么那1%为啥做不到呢? 这就是架构的魅力，在Micro-Batching模式的架构实现上就有一个自然流数据流入系统进行攒批的过程，这在一定程度上就增加了延时。

Flink Native Streaming 模式

Native Streaming 计算模式认为 “批是流的特例”，这个认知更贴切流的概念，比如一些监控类的消息流，数据库 *** 作的binlog，实时的支付交易信息等等自然流数据都是一条，一条的流入。Native Streaming 计算模式每条数据的到来都进行计算，这种计算模式显得更自然，并且延时性能达到更低。

（2）运行时架构的区别

Spark 运行时架构

批计算是把 DAG 划分为不同 stage，DAG 节点之间有血缘关系，在运行期间一个 stage 的 task 任务列表执行完毕，关闭上一个Stage的Task再去执行下一个 stage；Spark Streaming 则是对持续流入的数据划分一个批次，定时去执行批次的数据运算。Structured Streaming 将无限输入流保存在状态存储中，对流数据做微批或实时的计算。

Flink 运行时架构

Flink 有统一的 runtime，在此之上可以是 Batch API、Stream API、ML、Graph、CEP 等，DAG 中的节点上执行上述模块的功能函数，DAG 会一步步转化成 ExecutionGraph，即物理可执行的图，最终交给调度系统。节点中的逻辑在资源池中的 task 上被 apply 执行，task 和 Spark 中的 task 类似，都对应线程池中的一个线程。

在 DAG 的执行上，Spark 和 Flink 有一个比较显著的区别。在 Flink 的流执行模式中，一个事件在一个节点处理完后的输出就可以发到下一个节点立即处理。这样执行引擎并不会引入额外的延迟。与之相应的，所有节点是需要同时运行的。而 Spark 的 micro batch 和一般的 batch 执行一样，处理完上游的 stage 得到输出之后才开始下游的 stage。

在流计算的运行时架构方面，Flink 明显更为统一且优雅一些。

3. Flink的设计架构

Flink是一个分层的架构系统，每一层所包含的组件都提供了特定的抽象，用来服务于上层组件，Flink的分层体现有四层，分别是Deploy层、core层、API层/Libraries层，其中Deploy层主要涉及的是Flink的部署模式及同资源调度组件的交互模式，Core层提供了支持Flink计算的全部核心实现，API层/Libraries层提供了Flink的API接口和基于API接口的特定应用的计算框架；

• Deploy层：该层主要涉及了Flink的部署模式，Flink支持多种部署模式：本地、集群（Standalone/YARN）、云（GCE/EC2），Standalone 部署模式与Spark类似；
• Runtime层：Runtime层提供了支持Flink计算的全部核心实现，比如：支持分布式Stream处理、Job Graph到Execution Graph的映射、调度 等，为上层API层提供基础服务。
• API层：API层主要实现了面向无界Stream的流处理和面向Batch的批处理API，其中面向流处理对应DataStream API，面向批处理对应DataSet API。
• Libraries层：该层也可以称为Flink应用框架层，根据API层的划分，在API层之上构建的满足特定应用的实时计算框架，也分别对应于面向流处理 和面向批处理两类。面向流处理支持：CEP（复杂事件处理）、SQL-like的 *** 作（基于Table的关系 *** 作）；面向批处理支持：FlinkML（机器学习库）、Gelly（图处理）。

4. Flink常见部署模式

（1）Standalone模式

flink作为独立集群运行，不依赖于其它的组件。

（2）Yarn模式

Flink提供了两种在yarn上运行的模式，分别为Session-Cluster和Per-Job-Cluster模式。

Session-cluster 模式

通过命令yarn-session.sh本质上是在yarn集群上启动一个flink集群，由yarn预先给flink集群分配若干个container。flink集群运行期间资源永远保持不变，当一个作业被提交运行后，如果资源满了，下一个作业就无法提交，只能等到yarn中的其中一个作业执行完成后，释放了资源，下个作业才会正常提交。所有作业共享Dispatcher和ResourceManager；共享资源；适合规模小执行时间短的作业。

Per-Job-Cluster 模式

通过命令bin/flink run -m yarn-cluster提交任务，每提交一个作业会根据自身的情况，都会单独向yarn申请资源，在yarn集群上启动flink集群，直到作业执行完成。一个作业的失败与否并不会影响下一个作业的正常提交和运行。独享Dispatcher和ResourceManager，按需接受资源申请；适合规模大长时间运行的作业。

（3）Kubernetes部署

容器化部署时目前业界很流行的一项技术，基于Docker镜像运行能够让用户更加方便地对应用进行管理和运维。容器管理工具中最为流行的就是Kubernetes（k8s），而Flink也在最近的版本中支持了k8s部署模式。

具体部署可参考：集群安装部署的3种方式

参考资料

1. https://mp.weixin.qq.com/s/lt_7x5t7jYwgc_iUiEqHNg
2. https://mp.weixin.qq.com/s/oth_x8y7lJw3Zsnmf1w8DA