【大数据平台】Flink（复习用）

1.Flink的核心组件栈？

 Flink发展越来越成熟，已经拥有了自己的丰富的核心组件栈。Flink核心组件栈分为三层：物理部署层、Runtime核心层和API&Libraries层。
（1）物理部署层。Flink的底层是物理部署层。Flink可以采用Local模式运行，启动单个JVM，也可以采用Standalone集群模式运行，还可以采用YARN集群模式运行，或者也可以运行在谷歌云服务（GCE）和亚马逊云服务（EC2）上。
（2）Runtime核心层。该层主要负责对上层不同接口提供基础服务，也是Flink分布式计算框架的核心实现层。该层提供了两套核心的API：流处理（DataStream API）和批处理（DataSet API）。
（3）API&Libraries 层。作为分布式数据库处理框架，Flink 提供了支撑流计算和批计算的接口，同时，在此基础上抽象出不同的应用类型的组件库，如CEP（基于流处理的复杂事件处理库）、SQL&Table库（既可以基于流处理，也可以基于批处理）、FlinkML（基于批处理的机器学习库）、Gelly（基于批处理的图计算库）等。

 

2.Flink体系架构？

Flink体系架构主要由两个组件组成，分别为JobManager和TaskManager, Flink 体系架构也遵循 Master/Slave架构设计原则，JobManager为Master节点，TaskManager为Slave节点。

 

在执行Flink程序时，Flink程序需要首先提交给Job Client，然后，Job Client将作业提交给JobManager。JobManager负责协调资源分配和作业执行，它首先要做的是分配所需的资源。资源分配完成后，任务将提交给相应的TaskManager。在接收任务时，TaskManager启动一个线程以开始执行。执行到位时，TaskManager会继续向JobManager报告状态更改。作业可以有各种状态，例如开始执行、正在进行或已完成。作业执行完成后，其结果将发送回客户端（Job Client）。

 

3.Flink的编程模型？

 Flink提供了不同级别的抽象，以开发流或批处理作业。

在 Flink 编程模型中，最低级的抽象接口是状态化的数据流接口。这个接口通过过程函数（Process Function）被集成到DataStream API中。该接口允许用户自由地处理来自一个或多个流中的事件，并使用一致的容错状态。另外，用户也可以通过注册事件时间并处理回调函数的方法来实现复杂的计算。

实际上，大多数应用并不需要上述的底层抽象，而只需针对核心API（Core APIs）进行编程，比如DataStream API（有界或无界流数据）以及DataSet API（有界数据集）。这些API为数据处理提供了大量的通用模块，比如用户定义的各种各样的转换（Transformation）、连接（Join）、聚合（Aggregation）、窗口（Window）等。DataStream API集成了底层的处理函数，使得可以对一些特定的操作提供更低层次的抽象。DataSet API为有界数据集提供了额外的支持，例如循环与迭代。

Table API以表为中心，能够动态地修改表（在表达流数据时）。Table API是一种扩展的关系模型：表有二维数据结构（类似于关系数据库中的表），同时API提供可比较的操作，例如select、project、join、group-by、aggregate等。Table API程序定义的是应该执行什么样的逻辑操作，而不是直接准确地指定程序代码运行的具体步骤。尽管Table API可以通过各种各样的用户自定义函数（User Defined Function,UDF）进行扩展，但是它在表达能力上仍然比不上核心API，不过，它使用起来会更加简洁（代码量更少）。除此之外，Table API程序在执行之前会通过内置优化器进行优化。用户可以在表与 DataStream/DataSet 之间无缝切换，以允许程序将 Table API 与DataStream API/DataSet API混合使用。

Flink提供的最高级接口是SQL。这一层抽象在语法与表达能力上与Table API类似，唯一的区别是通过SQL实现程序。SQL抽象与Table API交互密切，同时SQL查询可以直接在Table API定义的表上执行。

 

4.Flink、Storm与Spark的对比？

流处理架构需要具备低延迟、高吞吐和高性能的特性，而目前从市场上已有的产品来看，只有Flink可以满足要求。Storm虽然可以做到低延迟，但是无法实现高吞吐，也不能在故障发生时准确地处理计算状态。Spark Streaming通过采用微批处理方法实现了高吞吐和容错性，但是牺牲了低延迟和实时处理能力。Flink实现了Google Dataflow流计算模型，是一种兼具高吞吐、低延迟和高性能的实时流计算框架，并且同时支持批处理和流处理。此外，Flink支持高度容错的状态管理，防止状态在计算过程中因为系统异常而出现丢失。因此，Flink成了能够满足流处理架构要求的理想的流计算框架。

 

5.Flink的优势？

Flink实现了Google DataFlow流计算模型，与其他的流计算框架相比，Flink具有突出的特点，它不仅是一个高吞吐、低延迟的计算引擎，还具备其他的高级特性，比如提供有状态的计算，支持状态管理，支持强一致性的语义，以及支持对消息乱序的处理。

总体而言，Flink具有以下优势。

（1）同时支持高吞吐、低延迟、高性能。

对于分布式流计算框架而言，同时支持高吞吐、低延迟和高性能非常重要。但是，目前在开源社区中，能够同时满足这3个方面要求的流计算框架只有Flink。Storm可以做到低延迟，但是无法实现高吞吐。Spark Streaming可以实现高吞吐和容错性，但是不具备低延迟和实时处理能力。

（2）同时支持流处理和批处理。

Flink不仅擅长流处理，也能够很好地支持批处理。对于Flink而言，批量数据是流数据的一个子集，批处理被视作一种特殊的流处理，因此，可以通过一套引擎来处理流数据和批量数据。

（3）高度灵活的流式窗口。

在流计算中，数据流是无限的，无法直接进行计算，因此，Flink提出了窗口的概念。一个窗口是若干元素的集合，流计算以窗口为基本单元进行数据处理。窗口可以是时间驱动的（Time Window，例如每30秒），也可以是数据驱动的（Count Window，例如每100个元素）。窗口可以分为翻滚窗口（Tumbling Window，无重叠）、滚动窗口（Sliding Window，有重叠）和会话窗口（Session Window）。

（4）支持有状态计算。

流计算分为无状态和有状态两种情况。无状态计算观察每个独立的事件，并根据最后一个事件输出结果，Storm 就是无状态的计算框架，每一条消息来了以后，彼此都是独立的，和前后都没有关系。有状态的计算则会基于多个事件输出结果。正确地实现有状态计算，比实现无状态计算难得多。Flink就是可以支持有状态计算的新一代流处理框架。

（5）具有良好的容错性。

当分布式系统引入状态时，就会产生“一致性”问题。一致性实际上是“正确性级别”的另一种说法，也就是说，在成功处理故障并恢复之后得到的结果，与没有发生故障时得到的结果相比，前者有多正确。Storm只能实现“至少一次”（At-least-once）的容错性，Spark Streaming虽然可以支持“精确一次”的容错性，但是，无法做到毫秒级的实时处理。Flink提供了容错机制，可以恢复数据流应用到一致状态。该机制确保在发生故障时，程序的状态最终将只反映数据流中的每个记录一次，也就是实现了“精确一次”的容错性。容错机制不断地创建分布式数据流的快照，对于小状态的流式程序，快照非常轻量，可以高频率创建而对性能影响很小。

（6）具有独立的内存管理。

Java本身提供了垃圾回收机制来实现内存管理，但是，在大数据面前，JVM的内存结构和垃圾回收机制往往会成为掣肘。所以，目前包括Flink在内的越来越多的大数据项目开始自己管理JVM内存，为的就是获得像C一样的性能以及避免内存溢出的发生。Flink通过序列化/反序列化方法，将所有的数据对象转换成二进制在内存中存储，这样做一方面降低了数据存储的空间，另一方面能够更加有效地对内存空间进行利用，降低垃圾回收机制带来的性能下降或任务异常风险。

（7）支持迭代和增量迭代。

对某些迭代而言，并不是单次迭代产生的下一次工作集中的每个元素都需要重新参与下一轮迭代，有时只需要重新计算部分数据同时选择性地更新解集，这种形式的迭代被称为增量迭代。增量迭代能够使一些算法执行得更高效，它可以让算法专注于工作集中的“热点”数据部分，这导致工作集中的绝大部分数据冷却得非常快，因此随后的迭代面对的数据规模将会大幅缩小。Flink的设计思想主要源于Hadoop、MPP数据库和流计算系统等，支持增量迭代计算，具有对迭代进行自动优化的功能。