### 简单介绍一下Flink
Flink 是一个框架和分布式处理引擎，用于对无界和有界数据流进行有状态计算。 并且 Flink 提供了数据分布、容错机制以及资源管理等核心功能。
Flink提供了诸多高抽象层的API以便用户编写分布式任务：
-
DataSet API， 对静态数据进行批处理操作，将静态数据抽象成分布式的数据集，用户可以方便地使用Flink提供的各种操作符对分布式数据集进行处理，支持Java、Scala和Python。
-
DataStream API，对数据流进行流处理操作，将流式的数据抽象成分布式的数据流，用户可以方便地对分布式数据流进行各种操作，支持Java和Scala。
-
Table API，对结构化数据进行查询操作，将结构化数据抽象成关系表，并通过类SQL的DSL对关系表进行各种查询操作，支持Java和Scala。
此外，Flink 还针对特定的应用领域提供了领域库，例如： Flink ML，Flink 的机器学习库，提供了机器学习Pipelines API并实现了多种机器学习算法。 Gelly，Flink 的图计算库，提供了图计算的相关API及多种图计算算法实现。
### Flink 相比传统的 Spark Streaming 有什么区别?
Flink 是标准的实时处理引擎，基于事件驱动。而 Spark Streaming 是微批（Micro-Batch）的模型。
1. 架构模型
Spark Streaming 在运行时的主要角色包括： Master、Worker、Driver、Executor，Flink 在运行时主要包含： Jobmanager、Taskmanager和Slot。
2. 任务调度
Spark Streaming 连续不断的生成微小的数据批次，构建有向无环图DAG，Spark Streaming 会依次创建 DStreamGraph、JobGenerator、JobScheduler。
Flink 根据用户提交的代码生成 StreamGraph，经过优化生成 JobGraph，然后提交给 JobManager进行处理，JobManager 会根据 JobGraph 生成 ExecutionGraph，ExecutionGraph 是 Flink 调度最核心的数据结构，JobManager 根据 ExecutionGraph 对 Job 进行调度。
3. 时间机制
Spark Streaming 支持的时间机制有限，只支持处理时间。 Flink 支持了流处理程序在时间上的三个定义： 处理时间、事件时间、注入时间。 同时也支持 watermark 机制来处理滞后数据。
4. 容错机制
对于 Spark Streaming 任务，我们可以设置 checkpoint，然后假如发生故障并重启，我们可以从上次 checkpoint 之处恢复，但是这个行为只能使得数据不丢失，可能会重复处理，不能做到恰好一次处理语义。
Flink 则使用两阶段提交协议来解决这个问题。
### Flink 的组件栈有哪些？
- DataSource ：表示数据源组件，主要用来接收数据，目前官网提供了readTextFile、socketTextStream、fromCollection以及一些第三方的Source。
- Transformation ：表示算子，主要用来对数据进行处理，比如Map、FlatMap、Filter、Reduce、Aggregation 等。
- DataSink ：表示输出组件，主要用来把计算的结果输出到其他存储介质中，比如writeAsText 以及Kafka、Redis、Elasticsearch等第三方Sink组件。
### Flink 集群都有哪些角色
Flink 程序在运行时主要有 TaskManager，JobManager，Client三种角色。 其中JobManager扮演着集群中的管理者Master的角色，它是整个集群的协调者，负责接收Flink Job，协调检查点，Failover 故障恢复等，同时管理Flink集群中从节点TaskManager。
TaskManager是实际负责执行计算的Worker，在其上执行Flink Job的一组Task，每个TaskManager负责管理其所在节点上的资源信息，如内存、磁盘、网络，在启动的时候将资源的状态向JobManager汇报。
Client是Flink程序提交的客户端，当用户提交一个Flink程序时，会首先创建一个Client，该Client首先会对用户提交的Flink程序进行预处理，并提交到Flink集群中处理，所以Client需要从用户提交的Flink程序配置中获取JobManager的地址，并建立到JobManager的连接，将Flink Job提交给JobManager。
### Flink 资源管理中 Task Slot 的概念
在Flink架构角色中我们提到，TaskManager是实际负责执行计算的Worker，TaskManager 是一个 JVM 进程，并会以独立的线程来执行一个task或多个subtask。 为了控制一个 TaskManager 能接受多少个 task，Flink 提出了 Task Slot 的概念。
简单的说，TaskManager会将自己节点上管理的资源分为不同的Slot： 固定大小的资源子集。 这样就避免了不同Job的Task互相竞争内存资源，但是需要主要的是，Slot只会做内存的隔离。 没有做CPU的隔离。
### Flink 分区策略
GlobalPartitioner 数据会被分发到下游算子的第一个实例中进行处理。
ShufflePartitioner 数据会被随机分发到下游算子的每一个实例中进行处理。
RebalancePartitioner 数据会被循环发送到下游的每一个实例中进行处理。
RescalePartitioner 这种分区器会根据上下游算子的并行度，循环的方式输出到下游算子的每个实例。 这里有点难以理解，假设上游并行度为2，编号为A和B。 下游并行度为4，编号为1，2，3，4。 那么A则把数据循环发送给1和2，B则把数据循环发送给3和4。 假设上游并行度为4，编号为A，B，C，D。 下游并行度为2，编号为1，2。 那么A和B则把数据发送给1，C和D则把数据发送给2。
BroadcastPartitioner 广播分区会将上游数据输出到下游算子的每个实例中。 适合于大数据集和小数据集做Jion的场景。
ForwardPartitioner ForwardPartitioner 用于将记录输出到下游本地的算子实例。 它要求上下游算子并行度一样。 简单的说，ForwardPartitioner用来做数据的控制台打印。
KeyGroupStreamPartitioner Hash分区器。 会将数据按 Key 的 Hash 值输出到下游算子实例中。
CustomPartitionerWrapper 用户自定义分区器。 需要用户自己实现Partitioner接口，来定义自己的分区逻辑。
### Flink的并行度和设置
Flink中的任务被分为多个并行任务来执行，其中每个并行的实例处理一部分数据。 这些并行实例的数量被称为并行度。
我们在实际生产环境中可以从四个不同层面设置并行度：
-
操作算子层面(Operator Level)
-
执行环境层面(Execution Environment Level)
-
客户端层面(Client Level)
-
系统层面(System Level)
需要注意的优先级： 算子层面>环境层面>客户端层面>系统层面。
### Flink的Slot和parallelism有什么区别
slot是指taskmanager的并发执行能力，假设我们将 taskmanager.numberOfTaskSlots 配置为3 那么每一个 taskmanager 中分配3个 TaskSlot, 3个 taskmanager 一共有9个TaskSlot。
parallelism是指taskmanager实际使用的并发能力。 假设我们把 parallelism.default 设置为1，那么9个 TaskSlot 只能用1个，有8个空闲。
### Flink重启策略
-
固定延迟重启策略（Fixed Delay Restart Strategy）
-
故障率重启策略（Failure Rate Restart Strategy）
-
没有重启策略（No Restart Strategy）
-
Fallback重启策略（Fallback Restart Strategy）
### Flink中的分布式缓存
Flink实现的分布式缓存和Hadoop有异曲同工之妙。 目的是在本地读取文件，并把他放在 taskmanager 节点中，防止task重复拉取。
### Flink中的广播变量
把一个dataset 数据集广播出去，然后不同的task在节点上都能够获取到，这个数据在每个节点上只会存在一份。
### Flink中的状态存储
Flink在做计算的过程中经常需要存储中间状态，来避免数据丢失和状态恢复。 选择的状态存储策略不同，会影响状态持久化如何和 checkpoint 交互。
Flink提供了三种状态存储方式： MemoryStateBackend、FsStateBackend、RocksDBStateBackend。
扫一扫
792
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
