ToB企服应用市场:ToB评测及商务社交产业平台

标题: Flink core知识点总结 [打印本页]

---

作者: 慢吞云雾缓吐愁    时间: 2024-7-24 02:20
标题: Flink core知识点总结
写在前面

五月份，重新整理了flink的相干概念，这次终于从根本逻辑入手，对整个flink job的整体运行过程有了熟悉，不得不说，flink真的很强；
剩下对于窗口这部分概念后续看环境增补吧，感觉应该标题不大
6月份，夺取运用上flink，对于根本标题可以大概debug办理，干！！！
1. Flink并行度相干概念

参考毗连：Flink 架构
1.1 Task、subTask

用户代码：界说了Flink应用程序的举动
Task（任务）：任务是Flink程序执行的最小单元。将用户代码中的算子进行切分，组成一个个Task，一种最常见的划分方式是根据是否shuffle。
subTask：子任务是并行执行的单元，它们可以在不同的线程大概不同的盘算节点上执行。是一个Task的实例，和Task关系可以类别类与对象。现实上，一个subTask默认环境下是一个线程执行的，但是现实上用户可以进行更改
1.2、subTask、Slot

参考链接：细粒度资源管理

TaskManager：是 Flink 中的一个组件，负责执行 Task，它是一个独立的 JVM 进程，运行在集群中的每个节点上。TaskManager 负责管理和执行一个或多个 slot。
Slot： TaskManager 中的资源分配单元，代表了肯定的盘算资源，比如 CPU 和内存。相比spark，可以把slot明白为更细粒度的资源管理，flink是以槽位为最小调治单元

• 同一个 task的不同运行实例（subTask），必须放在不同的 task slot上运行；否则原本可以并行的变成顺序执行，即并行度大于槽位
  
• 同一个 task slot，可以运行多个不同 task的各一个并行实例；如slot3
  

1.3、Task、算子链

上下游算子，能否 chain在一起，放在一个 Task中，取决于如下 3个条件：

• 上下游算子实例间是 oneToOne数据传输（forward）；不消shuffle
  
• 上下游算子并行度雷同；否则无法判定使用哪个算子的并行度
  
• 上下游算子属于雷同的 slotSharingGroup（槽位共享组）；提供用户自动分配资源的功能，比如两个算子都需要CPU，可以人为强行分组，避免一个slot上资源不足
  3个条件都满足，才能归并为一个 task；否则不能归并成一个 task；
  增补：也可以用户详细通过API端开算子链，disableChaining/startNewChain
  

2. Flink分布式部署

参考毗连：Deployment

• flink on Yarn
  flink on yarn（k8s），本质上就是去 yarn 集群上申请容器，来运行 flink 的 jobmanager+taskmanager 集群；
  flink 的 job，是 flink 集群内部的概念，它对 yarn 是不可见的
  
• 三种部署模式：
  
  
  
  • Application Mode【生产中建议使用的模式】：每个 job 独享一个集群，job 退出集群则退出，用户类的 main 方法在集群上运行（ExecuteGraph的构成是在JobManager上完成）；
    
  • Per-Job Mode：每个 job 独享一个集群，job 退出集群则退出，用户类的 main 方法在 client 端运行；（大 job，运行时长很长，比力合适；因为每起一个 job，都要去向 yarn 申请容器启动 jm,tm，比力耗时）
    
  • Session Mode：多个 job 共享同一个集群<jobmanager/taskmanager>、job 退出集群也不会退出，用户类的 main 方法在client 端运行；（需要频仍提交大量小 job 的场景比力适用；因为每次提交一个新 job 的时间，不需要去向 yarn 注册应用）
    
  
  

3. flink的核武器：状态

参考链接：有状态流处置惩罚
参考毗连：Working with State

• 什么是状态？（what）
  Stateful Computations over Data Streams，盘算的时间，用户想要通过某种方式（如：对象）记载信息，因此产生了状态这个说法；
  对于用户本身界说、管理的状态叫作raw state，
  flink 提供了内置的状态数据管理机制（简称状态机制），叫作托管状态；
  

注：其余的很多概念都是由于状态的产生而产生，状态如何记载==>Checkpoint机制；状态存储到那里==>状态后端；什么时间使用状态==>状态恢复策略；状态什么事扫除，扫除策略…==>状态的TTL

• 状态如何使用？（how）
  通过一张图很好的说明flink中的算子状态（包括广播状态）和键控状态的区别；这两个状态实现的API接口不完全雷同，算子状态需要实现CheckpointFunction接口，其余整体上类似，使用的时间根据具体需要来查找相应文档即可；
  
  
  
  标题：上下游的改变会对状态产生什么影响吗？
  以并行度改变为例；
  算子状态并行度会在新的subTask之间均匀分配；
  键控状态将会重新进行hash，然后分配到新的subTask，分配粒度为Task级别；
  标题：状态的TTL，time to live，存活时长；
  这种存活时长类似redis的逾期时间；用户可以设置TTL，但是TTL的时间是可以通过定时异步删除的，符合通用做法；
  留意：状态清理策略包括cleanupIncrementally（针对本地状态空间，且只用于HashMapStateBackend）、cleanupSnapshot（针对快照生效）、cleanupInRocksdbCompactFilter（针对本地状态空间，且只用于EmbeddedRocksDBStateBackend）
  以cleanupIncrementally说明状态的清理过程：
  
  
  
  对应的表示图：
  
  
  
  标题：statebackend是什么？
  参考毗连：状态后端
  状态后端，就是对状态管理功能的具体实现（体会一下什么是后端…），是可插拔的，可以明白为用户使用状态的一个接口；
  HashMapStateBackend 在内存中是使用 CopyOnWriteStateMap (单向链表)布局来存储用户的状态数据；数据优先以java对象的形式放入内存，满了溢出到磁盘；
  RocksDbStateBackend ，状态数据是交给 rocksdb 来管理，写入写出都需要进行序列化，内存中有缓存，也有放到磁盘部分；
  注：上述两种状态后端在生成Checkpoint快照文件的时间，生成的格式完全一致，因此重启后可以更改状态后端；
  
• 为什么要使用状态，大概说状态的应用（why）
  用户画像读取、Task的故障恢复、redis的setBy
  

4. flink的Checkpoint

4.1 checkpoint的基本思想

参考毗连：Checkpoints
假定我们不使用Chandy-Lamport 算法（分布式快照算法）恢复状态，会导致如下标题；

标题：产生上述错误的根本原因是什么？办理方式的关键是？
做快照的时间，在某一瞬间，把所有算子的快照都存下来，这个无法实现，因为不同算子此时处置惩罚的数据不完全雷同，状态在各个算子之间是不同一的，使得快照不靠谱；因此关键需要保证的事存储的快照如何保证是颠末同一批数据的影响；
办理方式：如何拍照可以大概使得拍出逐一致性的状态？
方式一：将发生标题的算子，盘算的状态开始往后传，…好像也是一种办理方式，但是设计框架需要思量到通用性
方法二：到场拍照标记barrier，类似watermark，是一种stringrecord
通过barrier，加持“事务”特性，各人要么都处置惩罚完，要么都没处置惩罚完
注：从下图中，我们可以看到flink的Checkpoint在保证EOS的位置，固然，EOS思量的因素更多，后期会详细先容；
参考毗连：Flink Exactly-once 实现原明白析

4.2 Checkpoint的整体流程

参考毗连：Snapshotting Operator State
注：Checkpoint的整体流程（也是一个2PC协议过程），通过对Checkpoint的基本原理了解后，发现Checkpoint的整个流程真的顺其天然...

• JobManager的CheckpointCoordinator定期向Source task发送start Checkpoint（Trigger Checkpoint）
  
• 当Source task收到Trigger Checkpoint指令后，产生barrier并通过广播的方式发送到下游。Source task及所有其他task，收到barrier-i，会执行本地Checkpoint-i，当Checkpoint-i完成后，向JobManager发送ack；
  
• 当流图的所有节点都完成Checkpoint-n，JobManager会收到所有的ack，那么就表示完成Checkpoint-i（这个时间各个算子只知道本身完成了，不知道其他算子是否完成Checkpoint-i），随即向所有task广播一条Checkpoint-i全部完成的通知消息（收到通事后，sink可能需要提交事务）；
  
  
  
  

其他：

• 本地快照，算子本身管控；全局快照，JobManager负责管理；具体可以参考Fault-tolerance in Flink学习条记
  
• 背压：数据积压来不及处置惩罚，会一级一级向上传递，最终导致数据源的数据积压；
  
• 对齐和非对齐Checkpoint的区别在于，多流输入的时间，两个流是否针对同一个barrier对齐进行Checkpoint；对齐的好处，可以大概保证EOS，缺点及无法保证数据处置惩罚效率的及时性；非对齐的只能保证at least once，一个状态可能被一个数据影响多次（现在不成熟）；参考毗连：Unaligned Checkpointing
  
• Checkpoint相干的参数这里不做讲解，需要用的时间关注一下这些参数可以影响什么；cancel job默认会删除Checkpoint，可以设置参数不删除Checkpoint，下次可以人工指定恢复，默认不会自动接续恢复
  

5. flink的EOS语义（容错机制）

核心：绝对的EOS不存在，任何方式都只能无限逼近
客观天下中，无法把时间顺序上错开的多个操作，真正绑定在一个原子操作中；
参考毗连：Flink Exactly-once 实现原明白析
参考毗连：【Flink】Exactly-Once的保证
5.1 EOS的核心点

EOS的核心要义来自于对checkpoint的明白；

• source端保证：数据可以大概重读（如：读偏移量、重放数据）；重放的数据/偏移量可以和下游的其他算作一起，由checkpoint机制实现“状态数据的”快照同一，
  留意：这里的快照同一就是，颠末同一批数据的影响，状态内里记载了出了标题，下次该从哪个位置读；
  
• 算子状态的EOS保证：分布式快照算法（chandy-lamport），既：一次checkpoint后所持久化的各个算子的状态，确保是颠末了雷同数据的影响，最终效果：一条数据只会影响状态一次；
  
• sink端的保证：由于Source和内部State的容错机制卡，sink端的重复写入可能破坏EOS，办理方式包括：幂等写入、两阶段提交（2PC）（事务机制大概预写日志模拟事务）
  

5.2 sink端的容错机制

从本节可以看出，flink和kafka的使用精密相连，很多标题都是针对两者一起使用时进行辨析

• 幂等写入
  要求：目的存储体系支持幂等写入，且数据中有合适的key（主键）
  极度刁钻的弊端：能实现最终状态的一致性，过程中可能存在不一致，如：输入数据包括时间戳，task重启后，时间戳发送变化；
  

**标题：kafka的幂等性和kafka不支持幂等写入的区别是？
数据重试位置1：kafka中发送消息的时间，通过标记每个消息的序列号new_sn = old_sn+1，broker接受到新的序列号才保存消息；是kafka内部从producer到broker的过程，producer.send(a)失败，重新发送，
数据重试位置2：相当于调用了两次producer.send(a)，两次均成功发送，kafka认为这两条消息都是正常发送的；
注：kafka支持伪事务，开启事务，每次发送消息会标记消息为controllMessage，事务开始；下游消耗则者设置脏读级别，可以决定是否只读已经提交的事务的数据；

**标题2：mysql支持幂等写入，也支持事务写入（mysql会删除未提交的事务），两种使用上效果会有什么区别？
幂等写入，可以及时拿到结果；
事务写入，需要等一批处置惩罚完，再拿到结果；

• 2PC提交（支持事务写入）
  
  
  
  

第一阶段：预提交阶段

• 开启事务
  
• 正常输出数据，保证数据可以正常的以流的方式处置惩罚
  
• Barrier到达
  
• 做local Checkpoint
  
• 预提交事务（存储本质对外事务号ID，以及事务状态，pending）
  
• 向JobManager上报
  
• 等待notify通知
  

第二阶段：事务提交阶段

• notify到达
  
• 提交事务（向外部体系commit，如果成功，则修改事务状态：finished）
  

标题1：预提交事务的信息存储在那里？
预提交事务时间，【事务号ID，以及事务状态】可以通过flink管理大概第三方存储体系管理；
网上给出的资料一般都认为【预提交阶段在Checkpoint成功完成之后结束】，这种说法很明显在commit提交失败后，会丢失数据，通过存储状态ID、状态事务可以进行改进，现实代码中也是这样改进的；
标题2：两阶段提交过程是否还可能存在标题？
1、外部体系，可能不支持：重新毗连之后，根据一个txid来恢复（commit大概rollback）
2、超时，外部体系对前次事务的相干上下文信息已经销毁（包括事务号，以及事务中未提交的数据）
上述两种环境下可能丢数据；
标题3：两阶段提交过程是否可能造成数据重复？
boolean success = conn.commit()后，体系挂了；重启后，发现本次事务提交的状态为pending，再次conn.commit()；
注：如果事务提交不遵循幂等性，则可能造成数据重复
3. 2PC（预写日志）
本质也是事务写入，
任何目的体系，都可通过这种方式实现EOS，核心过程和事务写入类似，只是数据是否先写入到外部体系，下面只给出表示图；

6. flink的重启策略

task级别的故障重启，是体系自动进行的，默认不进行重启，配置过程中思量重启次数、重启隔断、惩罚力度、…
参考链接：Task Failure Recovery
标题：当一个task故障，自动重启时，是否会将整个job的所有task重启？
与failover-strategy策略有关：
all：只要job发生一个task故障，就会导致整个job所有task重启；
region：job中发生一个task故障，只会重启一个故障所影响的task最小集（一般最小集是一个pipeline流水线）

cluster级别的失败重启（故障导致，人为），不会自动从之前的快照数据中恢复状态；如果需要从某个快照状态来恢复数据，则需要手动指定Savepoints；
标题：Checkpoint和Savepoint的区别？
在job运行过程中，除了固定周期自动的Checkpoint之外，还可以由人工下令来触发Checkpoint（这个场景中产生的快照数据就叫作Savepoint）
注：Checkpoint注意task级别的使用，Savepoint针对job级别的重启
参考毗连：Checkpoints 与 Savepoints
扩展资料

Flink - State 之 Kafka 写入 HBase

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

---

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)

Powered by Discuz! X3.4