Flink总结

Flink总结

1.Filnk的几种部署模式

	1.locol模式:单机测试用 开发不会用
	2.standalone模式 
		以自身的master和slaves搭建集群模式,flink自身进行调度.
	3.yarn模式
		有Hadoop的yarn进行资源调度,有两种模式:session-cluster模式和per-job-cluster模式
			session-cluster模式:首先会在yarn上初始化一个flink集群,根据提交参数,开辟出指定的资源,然后每次提交的任务都由这个flink集群管理,资源是固定的,如果资源不够,只能等上一个任务完成,释放资源才能执行下一个任务
			per-job-cluster模式:每次提交任务都会开辟一个flink集群,相互之间不会有影响.方便管理,任务执行完成之后,会自动释放资源.
	4.k8s模式

2.Flink与Spark的区别

	flink与spark 的主要差别就在于计算的模型不同,spark采用的微批次处理,而flink 是基于操作符的连续流式计算的.
	flink是有事件驱动型计算的,sparksteaming是有时间驱动型计算的.
	在spark的世界观中,一切数据都是由批次组成的,离线是一个很大的批次,实时就是很多很小的批次组成的
	在flink的世界观众,一切数据都是由流组成的,离线是有界流,实时是无界流.
	有界流:有明确开始有明确结束
	无界有:有明确开始没有结束
	流处理具有极低的延迟

3.Flink的组件

	1.jobmanager(作业管理器)
		1.控制一个应用程序,每个应用程序都会对应不同的额jobmanager
		2.jobmanager会接收到要执行的应用程序,包括作业图(相当于spark的任务切分图),逻辑数据图,和打包的所有的jar与其他资源的jar包.
		3.然后jobmanager会根据作业图转换成物理层面的数据流程图,包括所有的并发任务(task)
		4.然后向resourcemanager申请执行所需要的资源,然后将任务图发送给taakmanager中slot执行,会协调各种操作,比如checkpoints
	2.resourcemanager(资源管理器)
		1.负责taskmanger的slot的管理,
		2.flink为不同的环境提供了不同的资源管理器,如yarn,k8s,mesos,standalone
		3.当jobmanager申请资源时,将空闲的taskmanager分配给jobmanager,如果resourcmanager上的资源不足时,还有可以向平台申请资源,负责taskmanager是资源释放
	3.taskmanager(任务管理器)
		1.每个taskmanager会有多个slot,slot的个数,限制了taskmanager的能够执行任务的数量,因为任务都是执行在slot中的.
		2.taskmanager启动后,首先会想resourcemanager注册slot,供给给jobmanager调用
		3.任务执行过程中,一个taskmanager可以和其他运行运行同一job的taskmanager交换数据,
		4.多个个slot决定了最多可以有多少给并行度
	4.Dispatcher(分发器)
		1.跨作业运行,
		2.不是必须的,提交模式不同,就会不同,yarn模式就不会产生dispatcher

4.Flink任务提交流程

	1.首先flink客户端会将所需要的jar和配置信息上传到hadfs中
	2.然后向yarnresourcemanager提交job,yarnresoucemanager就会选择一个NM节点分配资源,启动APPlicationMaster
	3.然后ApplicationMaster会加载flink的jar包与参数配置构建所需要的环境,然后与向Resourcemanager申请资源启动Jobmanager
	4.之后jobmanager会向resourcemanager根据作业图进行申请资源,然后resourcemanager会选择NM中的节点,创建container,加载flink的jar和配置,并且启动taskmanager加载环境,启动之后,taskmanager会向resourcemanager注册,等待jobmanager分发任务.

5.Taskmanager与Slot的关系

	1.task slot表taskmanager拥有固定资源的子集,加入一个taskmanager有3个task slot,那么会将taskmanager管理的内存分成3分给各个slot,可以很好减少任务之间争抢内存,但是不会隔离CPU,仅仅隔离内存的管理,Slot的个数能决定着最大并行度的能力,并行度parallelism是动态概念，即TaskManager运行程序时实际使用的并发能力,根据slot的个数,合理的设置并行度,不能大于资源的slot的个数.
	2.并行度:一个特定算子的子任务（subtask）的个数被称之为其并行度（parallelism）。
	3.任务链:相同并行度的one-to-one算子,并且在一个slot共享组组成一个任务链(默认是在同一个job中).

6.Flink的并行度了解么?Flink 的并行度怎么设置?

	1.flink中任务(task)被分为多个并行任务(subtask)来执行,提高并发率,并行的任务个数称为并行度.我们从四个方面对其进行设置:
	1)算子层面,每个算子都可设置并行度
	2)全局层面(也就是执行环境配置的并行度),
	3)客户端层面 提交任务时指定的并行度
	4)系统层面,系统配置文件中的并行度
	优先级:算子层面>环境层面>客户端层面>系统层面

7.Flink的checkpoint可以保存在哪些地方?

	Flink检查点的核心作用是确保状态正确，即使遇到程序中断，也要正确.
	1.内存中
		将checkpoint存储在JobManager的内存中
	2.文件系统中
		将checkpoint存到远程的持久化文件系统（FileSystem）上
	3.rocksDB
		将所有状态序列化后，存入本地的RocksDB中存储。
	注意：RocksDB的支持并不直接包含在flink中，需要引入依赖

8.Flink的三种时间语义

	1.Event Time 
		数据源中的数据中的时间
	2.Ingestion Time
		进入Flink系统的时间
	3.processing Time
		基于算子对数据进行处理时的时间,默认是处理时间

9.Flink中的窗口

	1.时间窗口
		1.滚动窗口
			每个一点时间就会滚动生成新的窗口,不会重叠数据
		2.滑动窗口
			根据滑动步长,产生新的窗口,会重叠数据
		3.会话窗口
			根据会话时长,一旦隔了一段时间,会开启下一个会话
	2.计数窗口
		1.滚动窗口
		2.滑动窗口

10.Exactly-Once的保证

	如何实现制精准一次呢?
1.sink支持事务:flink就可以通过实现两阶段提交和状态保存,实现端到端的一致性.
	具体步骤:
	1)当第一条数据来的时候,sink就会开启事务,一条一条数据写入sink端.
	2)预提交,将数据数据标记为预提交,预提交的数据还不能被使用或者消费.
	3)当jobmanager触发了checkpoint的的操作,barrier会从source往下游所有的并行的任务中进行传递并且将状态进行ckpoint,当时所有的sink都接收到了barrier并且进行checkpiont,则会通知jobmanager,ckpoint成功了,开启下一阶段事务
	4)然后sink正式提交数据,关闭事务.
	注意:如果checkpoint失败,则事务也会失败,所以checkpoint的超时间隔时间要小于事务的超时时间.
2.sink不支持事务:
	通过幂等写入,需要sink有幂等性,入hbase的rowkey,或是redis.

11.Flink 的状态机制

	flink的计算过程中,需要保存中间状态,避免数据丢失和状态恢复,有三种存储策略:
	1.MemoryStateBackend
		内存级的状态后端，会将键控状态作为内存中的对象进行管理，将它们存储在TaskManager的JVM堆上；而将checkpoint存储在JobManager的内存中
	2.FsStateBackend
		将checkpoint存到远程的持久化文件系统（FileSystem）上。而对于本地状态，跟MemoryStateBackend一样，也会存在TaskManager的JVM堆上。
	3.RocksDBStateBackend
		将所有状态序列化后，存入本地的RocksDB中存储。
	注意：RocksDB的支持并不直接包含在flink中，需要引入依赖

12.Watermark机制

	watermark是一中衡量EventTime进展的机制,是流中的一种特殊的数据,可以设置延迟触发
	watermark处理乱序数据有很好的效果,对于乱序数据,正确的处理方式:watermark机制与Window结合.
	watermark在流中表示EventTime小于watermark的所有数据都已经到,window中的计算执行与关闭执行都是watermark来触发的.

13.Flink分布式快照的原理是什么(chandy-lamport算法)

	flink的容错机制的核心就是数据流与算子状态的一致性快照(核心应用状态的一致性检查点),这些快照就是充当checkpoint,有状态流应用的一致检查点，其实就是所有任务的状态，在某个时间点的一份拷贝（一份快照）；这个时间点，应该是所有任务都恰好处理完一个相同的输入数据的时候,系统发生故障时会发生回滚到上一个状态.
	Flink检查点算法的正式名称是异步分界线快照(asynchronous barrier snapshotting)。该算法大致基于Chandy-Lamport分布式快照算法。
	首先会在source中所有的并行任务中注入一条barrier数据,上游任务会将自己的barrier的发送到所有下游并行的任务中,然后下游所有的操作算子都会将接收到同一时刻对应的所有上游的barrier之前的数据处理完的状态进行ckpoint(barrier需要对齐),如果没有接收到所有的barrier,会将提前来到的数据先缓存到内存中,等barrier都到了,才做下一步计算,处理下一阶段barrier,当所有的sink都接收到了barrier时,意味着数据以及状态都ckpoint了,然后通知jobmananger,实现状态一致性了.
	分布式快照原理核心:
	1.分界线对齐：barrier 向下游传递，sum 任务会等待所有输入分区的 barrier 到达
	2.对于barrier已经到达的分区，继续到达的数据会被缓存
	3.而barrier尚未到达的分区，数据会被正常处理

14.Flink快速FailOver

	Flink 作业都是 long-running 的在线作业，很多对可用性的要求特别高，尤其是跟公司核心业务相关的作业，SLA 要求 4 个 9 甚至更高。
	当作业遇到故障时，如何快速恢复对我们来说是一个巨大的挑战。
	下面分三个方面来展开：

	Flink 当前已有的快速恢复方案；
	基于 container 宕掉的快速恢复；
	基于机器宕掉的快速恢复。
	1）Flink 当前已有的快速恢复方案
    Flink 当前已有的快速恢复方案主要包括以下两种：
		region failover。如果流式作业的 DAG 包含多个子图或者 pipeline，那么 task 失败时只会影响其所属的子图或者 pipeline ，而不用整个 DAG 都重新启动；
		local recovery。在 Flink 将快照同步到共享存储的同时，在本地磁盘也保存一份快照。作业失败恢复时，可以调度到上次部署的位置，并从 local disk 进行快照恢复。
	2）基于 container 宕掉的快速恢复
		实际环境中， container 宕掉再申请有时会长达几十秒，比如因为 hdfs 慢、yarn 慢等原因，严重影响恢复速度。为此，我们做了如下优化：
		冗余资源。维持固定个数的冗余 container，一旦 container 宕掉，冗余 container 立刻候补上来，省去了繁杂的资源申请流程；
	提前申请。一旦发现作业因为 container 宕掉而失败，立刻申请新的 container 。
	以上优化覆盖了很大一部分场景，恢复时间从 30s-60s 降到 20s 以内。
	3）基于机器宕掉的快速恢复
		机器宕掉时，flink on yarn 的恢复时间超过 3 分钟，这对重要作业显然是无法容忍的！为了做到快速恢复，我们需要做到快速感知和恢复：
		冗余资源并打散分配，确保两个冗余资源不在一个 container，redundantContainerNum=max(containerNumOfHost) + 1；
		作业宕机，Hawk 监测系统 5 秒内发现；
		冗余资源快速候补，免去申请资源的流程。
		通过这种方案，我们可以容忍任意一台机器的宕机，并将宕机恢复时间由原先的 3 分钟降低到 30 秒以内。

散分配，确保两个冗余资源不在一个 container，redundantContainerNum=max(containerNumOfHost) + 1；
作业宕机，Hawk 监测系统 5 秒内发现；
冗余资源快速候补，免去申请资源的流程。
通过这种方案，我们可以容忍任意一台机器的宕机，并将宕机恢复时间由原先的 3 分钟降低到 30 秒以内。