### 简单介绍一下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。
参考:http://vlambda.com/wz_wQQkXRy7NU.html