GMTC深圳站本周日开幕,14大专题全部上线,完整日程>> 了解详情
写点什么

Apache Flink 进阶(三):Checkpoint 原理剖析与应用实践

  • 2019 年 9 月 25 日
  • 本文字数:2711 字

    阅读完需:约 9 分钟

Apache Flink进阶(三):Checkpoint原理剖析与应用实践

本文将分享 Flink 中 Checkpoint 的应用实践,包括四个部分,分别是 Checkpoint 与 state 的关系、什么是 state、如何在 Flink 中使用 state 和 Checkpoint 的执行机制。如果你对于 Apache Flink 了解不多,可以先阅读Apache Flink 零基础入门系列文章。


Checkpoint 与 state 的关系

Checkpoint 是从 source 触发到下游所有节点完成的一次全局操作。下图可以有一个对 Checkpoint 的直观感受,红框里面可以看到一共触发了 569K 次 Checkpoint,然后全部都成功完成,没有 fail 的。



state 其实就是 Checkpoint 所做的主要持久化备份的主要数据,看下图的具体数据统计,其 state 也就 9kb 大小 。



什么是 state

我们接下来看什么是 state。先看一个非常经典的 word count 代码,这段代码会去监控本地的 9000 端口的数据并对网络端口输入进行词频统计,我们本地行动 netcat,然后在终端输入 hello world,执行程序会输出什么?



答案很明显,(hello, 1)(word,1)


那么问题来了,如果再次在终端输入 hello world,程序会输入什么?


答案其实也很明显,(hello, 2)(world, 2)。为什么 Flink 知道之前已经处理过一次 hello world,这就是 state 发挥作用了,这里是被称为 keyed state 存储了之前需要统计的数据,所以帮助 Flink 知道 hello 和 world 分别出现过一次。


回顾一下刚才这段 word count 代码。keyby 接口的调用会创建 keyed stream 对 key 进行划分,这是使用 keyed state 的前提。在此之后,sum 方法会调用内置的 StreamGroupedReduce 实现。



什么是 keyed state

对于 keyed state,有两个特点:


  • 只能应用于 KeyedStream 的函数与操作中,例如 Keyed UDF, window state

  • keyed state 是已经分区/划分好的,每一个 key 只能属于某一个 keyed state


对于如何理解已经分区的概念,我们需要看一下 keyby 的语义,大家可以看到下图左边有三个并发,右边也是三个并发,左边的词进来之后,通过 keyby 会进行相应的分发。例如对于 hello word,hello 这个词通过 hash 运算永远只会到右下方并发的 task 上面去。



什么是 operator state

  • 又称为 non-keyed state,每一个 operator state 都仅与一个 operator 的实例绑定。

  • 常见的 operator state 是 source state,例如记录当前 source 的 offset


再看一段使用 operator state 的 word count 代码:



这里的fromElements会调用FromElementsFunction的类,其中就使用了类型为 list state 的 operator state。根据 state 类型做一个分类如下图:



除了从这种分类的角度,还有一种分类的角度是从 Flink 是否直接接管:


  • Managed State:由 Flink 管理的 state,刚才举例的所有 state 均是 managed state

  • Raw State:Flink 仅提供 stream 可以进行存储数据,对 Flink 而言 raw state 只是一些 bytes


在实际生产中,都只推荐使用 managed state,本文将围绕该话题进行讨论。


如何在 Flink 中使用 state

下图就前文 word count 的 sum 所使用的StreamGroupedReduce类为例讲解了如何在代码中使用 keyed state:



下图则对 word count 示例中的FromElementsFunction类进行详解并分享如何在代码中使用 operator state:



Checkpoint 的执行机制

在介绍 Checkpoint 的执行机制前,我们需要了解一下 state 的存储,因为 state 是 Checkpoint 进行持久化备份的主要角色。


Statebackend 的分类

下图阐释了目前 Flink 内置的三类 state backend,其中MemoryStateBackendFsStateBackend在运行时都是存储在 java heap 中的,只有在执行 Checkpoint 时,FsStateBackend才会将数据以文件格式持久化到远程存储上。而RocksDBStateBackend则借用了 RocksDB(内存磁盘混合的 LSM DB)对 state 进行存储。



对于HeapKeyedStateBackend,有两种实现:


  • 支持异步 Checkpoint(默认):存储格式 CopyOnWriteStateMap

  • 仅支持同步 Checkpoint:存储格式 NestedStateMap


特别在 MemoryStateBackend 内使用HeapKeyedStateBackend时,Checkpoint 序列化数据阶段默认有最大 5 MB 数据的限制


对于RocksDBKeyedStateBackend,每个 state 都存储在一个单独的 column family 内,其中 keyGroup,Key 和 Namespace 进行序列化存储在 DB 作为 key。



Checkpoint 执行机制详解

本小节将对 Checkpoint 的执行流程逐步拆解进行讲解,下图左侧是 Checkpoint Coordinator,是整个 Checkpoint 的发起者,中间是由两个 source,一个 sink 组成的 Flink 作业,最右侧的是持久化存储,在大部分用户场景中对应 HDFS。


a. 第一步,Checkpoint Coordinator 向所有 source 节点 trigger Checkpoint;。



b. 第二步,source 节点向下游广播 barrier,这个 barrier 就是实现 Chandy-Lamport 分布式快照算法的核心,下游的 task 只有收到所有 input 的 barrier 才会执行相应的 Checkpoint。



c. 第三步,当 task 完成 state 备份后,会将备份数据的地址(state handle)通知给 Checkpoint coordinator。



d. 第四步,下游的 sink 节点收集齐上游两个 input 的 barrier 之后,会执行本地快照,这里特地展示了 RocksDB incremental Checkpoint 的流程,首先 RocksDB 会全量刷数据到磁盘上(红色大三角表示),然后 Flink 框架会从中选择没有上传的文件进行持久化备份(紫色小三角)。



e. 同样的,sink 节点在完成自己的 Checkpoint 之后,会将 state handle 返回通知 Coordinator。



f. 最后,当 Checkpoint coordinator 收集齐所有 task 的 state handle,就认为这一次的 Checkpoint 全局完成了,向持久化存储中再备份一个 Checkpoint meta 文件。



Checkpoint 的 EXACTLY_ONCE 语义

为了实现 EXACTLY ONCE 语义,Flink 通过一个 input buffer 将在对齐阶段收到的数据缓存起来,等对齐完成之后再进行处理。而对于 AT LEAST ONCE 语义,无需缓存收集到的数据,会对后续直接处理,所以导致 restore 时,数据可能会被多次处理。下图是官网文档里面就 Checkpoint align 的示意图:



需要特别注意的是,Flink 的 Checkpoint 机制只能保证 Flink 的计算过程可以做到 EXACTLY ONCE,端到端的 EXACTLY ONCE 需要 source 和 sink 支持。


Savepoint 与 Checkpoint 的区别

作业恢复时,二者均可以使用,主要区别如下:


SavepointExternalized Checkpoint
用户通过命令触发,由用户管理其创建与删除Checkpoint 完成时,在用户给定的外部持久化存储保存
标准化格式存储,允许作业升级或者配置变更当作业 FAILED(或者CANCELED)时,外部存储的 Checkpoint 会保留下来
用户在恢复时需要提供用于恢复作业状态的 savepoint 路径用户在恢复时需要提供用于恢复的作业状态的 Checkpoint 路径


相关文章:


Apache Flink进阶(二):时间属性深度解析


Apache Flink进阶(一):Runtime 核心机制剖析


Apache Flink 零基础入门系列文章


2019 年 9 月 25 日 09:106875

评论 1 条评论

发布
用户头像
对于小白的我,还是有一丢丢看不懂
2020 年 12 月 16 日 10:05
回复
没有更多了
发现更多内容

万字带你深入阿里开源的Canal工作原理

大数据老哥

大数据 canal

AES128解密只能解一半的问题

李日盛

AES 问题定位

Android面试(二)

我就感觉到快

从烟酒茶说系统化学习

张老蔫

28天写作

第一周作业

Esther

为什么你家的 K8s 应用平台不好用?

孙健波

Kubernetes PaaS KubeVela

阿里开源SpringSecurity:用户+案例+认证+框架

996小迁

Java 程序员 架构 面试 springsecurity

边缘安全 | 正确使用CDN 让你更好规避安全风险

阿里云Edge Plus

安全 CDN

【盘点2020】机房网络性能哪家强?年度冠军揭晓

博睿数据

机房 评测

直播预告丨NLP领域的2020年大事记及2021展望

京东科技开发者

机器学习 AI nlp

数据倾斜?Spark 3.0 AQE专治各种不服

王知无

大数据 spark

胜天半子!阿里内部力荐SpringBoot全栈笔记全网首发,源码实战齐飞

Java架构之路

Java 程序员 架构 面试 编程语言

​Kubernetes资源清单篇:如何创建资源?​

xcbeyond

Kubernetes 28天写作 Kubernetes从入门到精通

客户服务高触达,零代码从短信/邮件跳转小程序客服

环信

Soul网关源码阅读(八)路由匹配初探

Java 源码阅读 网关

【我给面试官画饼】软件测试理论基础、质量保证常见面试题——会被面试官赶出来吗?

程序员阿沐

面试 软件测试 测试工程师 质量保证

百度首届智能小程序高校大赛圆满结束:关注学生心理健康小程序获全国一等奖

DT极客

实现数字经济和实体经济深度融合

Geek_987812

区块链

永续合约APP系统软件开发

系统开发

企业短信服务质量与用户体验如何监控?短信监测技术震撼来袭

博睿数据

短信 数据监测

基于Prometheus+Grafana打造企业级Flink监控系统

王知无

大数据 flink 监控

数字货币应用从C端走向B端 实践中这些难题仍需关注

Geek_987812

数字货币

技术分享 | 漫谈音视频中的拥塞控制

拍乐云Pano

LeetCode题解:105. 从前序与中序遍历序列构造二叉树,递归+哈希表,JavaScript,详细注释

Lee Chen

算法 LeetCode 前端进阶训练营

跨界融合,区块链推动实体经济提档升级

Geek_987812

人工智能 云计算 大数据

观看辽篮比赛,思考团队管理——关于团队的灵魂拷问,你中了几个?

伯薇

团队管理 团队建设 团队 赋能 激励

大数据知识专栏 -MapReduce 自定义排序技术

小马哥

大数据 hadoop mapreduce 七日更

休息一天

IT蜗壳-Tango

七日更

你kin你擦!阿里终于肯把内部高并发编程高阶笔记开源出来了

Java架构之路

Java 程序员 架构 面试 编程语言

关于JDK15的简单理解

Java架构师迁哥

程序员生产环境-软件篇

ITCamel

程序员 效率工具 工作效率

2021星空论坛:破局创新,论道数字化转型

2021星空论坛:破局创新,论道数字化转型

Apache Flink进阶(三):Checkpoint原理剖析与应用实践-InfoQ