摘要：Apache Flink是一个面向分布式数据流处理和批量数据处理的开源计算平台，它能够基于同一个Flink运行时，提供支持流处理和批处理两种类型应用的功能。目前，Apache Flink 1.9.0版本已经正式发布，该版本有什么样的里程碑意义，又具有哪些重点改动和新功能呢？本文中，阿里巴巴高级技术专家伍翀就为大家带来了对于Apache Flink 1.9.0版本的介绍。
演讲嘉宾介绍：
本次分享主要分为以下三个方面：
Flink 1.9.0的里程碑意义
Flink 1.9.0的重点改动和新功能
总结
一、Flink 1.9.0的里程碑意义
下图展示的是在2019年中阿里技术微信公众号发表的两篇新闻，一篇为“阿里正式向Apache Flink贡献Blink代码”介绍的是在2019年1月Blink开源并且贡献给Apache Flink，另外一篇为“修改代码150万行！Apache Flink 1.9.0做了这些重大修改！”介绍的是2019年8月Bink合并入Flink之后首次发版。之所以将这两篇新闻放在一起，是因为无论是对于Blink还是Flink而言，Flink 1.9.0的发版都是具有里程碑意义的。
在2019年年初，Blink开源贡献给Apache Flink的时候，一个要点就是Blink会以Flink的一个分支来支持开源，Blink会将其主要的优化点都Merge到Flink里面，一起将Flink做的更好。如今，都已经过去了半年的时间，随着Flink1.9.0版本的发布，阿里巴巴的Blink团队可以骄傲地宣布自己已经兑现了之前的承诺。因此，当我们结合这两篇报道来看的时候，能够发现当初Blink的一些新功能如今已经能够在Flink1.9.0版本里面看到了，也能看出Flink社区的效率和执行力都是非常高的。
二、Flink 1.9.0的重点改动和新功能
这部分将为大家介绍Flink 1.9.0的重点改动和新功能。
架构升级
整体而言，如果一个软件系统产生了较大改动，那基本上就是架构升级带来的，对于Flink而言也不例外。想必熟悉Flink的同学对于下图中左侧的架构图一定不会陌生，在Flink的分布式流式执行引擎之上有一整套相对独立的DataStream API和DataSet API，它们分别负责流计算作业和批处理作业。在此基础之上Flink还提供了一个流批统一的Table API和SQL，用户可以使用相同的Table API或者SQL来描述流计算作业和批处理作业，只需要在运行时告诉Flink引擎以流模式运行还是以批模式运行即可，Table层将会把作业优化成为DataStream作业或者DataSet作业。但是Flink 1.8版本的架构在底层存在一些弊端，那就是DataStream和DataSet在底层共享的代码并不多。其次，两者的API也完全不同，因此就会导致上层重复开发的工作量比较大，长期来看就会使得Flink的开发和维护成本越来越大。
基于上述问题，Blink在架构上进行了一些新型的探索，经过和社区密切的讨论之后确定了Flink未来的架构路线。也就是在Flink未来的版本中，DataSet的API会被完全移除掉，SteamTransformation会作为底层的API来描述批作业和流作业，Table API和SQL会将流作业都翻译到SteamTransformation上，所以在Flink 1.9中为了不影响使用之前版本用户的体验，还需要一种能够让新旧架构并存的方案。基于这个目的，Flink的社区开发人员也做了一系列努力，提出了上图中右侧的Flink 1.9架构设计，将API和实现部分做了模块的拆分，并且提出了一个Planner接口，能够支持不同的Planner具体实现。Planner的具体工作就是优化和翻译成物理执行图等，也就是Flink Query Processor所做的工作。Flink将原本的实现全部移动到了Flink Query Processor中，将从Blink Merge过来的功能都放到了Blink Query Processor。这样就能够实现一举两得，不仅能够使得Table模块拆分之后变得更加清晰，更重要的是也不会影响老版本用户的体验，同时能够使得用户享受到Blink的新功能和优化。
Table API & SQL 重构和新功能
在Table API & SQL 重构和新功能部分，Flink在1.9.0版本中也Merge了大量从Blink中增加的SQL功能。这些新功能都是在阿里巴巴内部经过千锤百炼而沉淀出来的，相信能够使得Flink更上一层台阶。这里挑选了一些比较重要的成果为大家介绍，比如对于SQL DDL的支持，重构了类型系统，高效流式的TopN，高效流式去重，社区关注已久的维表关联，对于MinBatch以及多种解热点手段的支持，完整的批处理支持，Python Table API以及Hive的集成。接下来也会简单介绍下这些新功能。
SQL DDL：在以前如果要注册一个Source或者Table Sink，必须要通过Java、Scala等代码或者配置文件进行注册，而在Flink 1.9版本中则支持了SQL DDL的语法直接去注册或者删除表。
重构类型系统：在Flink 1.9版本中实现了一套全新的数据类型系统，这套全新的类型系统与SQL标准进行了完全对齐，能够支持更加丰富的类型。这套全新的类型系统也为未来Flink SQL能够支持更加完备和完善的功能打下了坚实的基础。
TopN：在Flink 1.9版本提供强大的流处理能力以及社区期待已久的TopN来实时计算排行榜，能够实时计算排名靠前的店铺或者进行实时流数据的过滤。
高效流式去重：在现实的生产系统中，很多ETL作业或者任务没有做到端到端的一致性，这就导致明细层可能存在重复数据，这些数据交给汇总层做汇总时就会造成指标偏大，进而多计算了一些值，因此在进入汇总层之前往往都会做一个去重，这里引入了一个流计算中比较高效的去重功能，能够以比较低的代价来过滤重复的数据。
维表关联：能够实时地关联MySQL、HBase、Hive表中数据。
MinBatch&多种解热点手段：在性能优化方面，Flink 1.9版本也提供了一些性能优化的手段，比如提升吞吐的MinBatch的优化以及多种解热点手段。
完整的批处理支持：Flink 1.9版本具有完整的批处理支持，在下一个版本中也会继续投入力量来支持TBDS达到开箱即用的高性能。
Python Table API：在Flink 1.9版本中也引入了Python Table API，这也是Flink在多语言方向的有一个重大进步。能够使得Python用户能够轻松地玩转Flink SQL这样的功能。
Hive集成：Hive是Hadoop生态圈中不可忽视的重要力量，为了更好地去推广Flink批处理的功能，与Hive进行集成也是必不可少的。很高兴，在Flink 1.9版本的贡献者中也有两位Hive的PMC来推动集成工作。而首先需要解决的就是Flink如何读取Hive数据的问题，目前Flink已经完整打通了对于Hive MetaStore的访问，Flink可以直接去访问Hive MetaStore中的数据，同时反过来Flink也可以将其表数据中的元信息直接存储到Hive MetaStore里面供Hive访问，同时我们也增加了Hive的Connector支持CSV等格式，用户只需要配置Hive的MetaStore就能够在Flink直接读取。在此基础之上，Flink 1.9版本还增加了Hive自定义函数的兼容，Hive的自定义函数都能够在Flink SQL里面直接运行。
批处理改进：细粒度批作业恢复（FLIP-1）
Flink 1.9版本在批处理部分也做了较多的改进，首要的就是细粒度批作业的恢复。这个优化点在很早之前就被提出来了，而在1.9版本里终于将未完成的功能实现了收尾。在Flink 1.9版本中，如果批处理的作业有错误发生，Flink会首先计算这个错误影响的范围，这称为Fault Region，因为在批处理作业中有一些节点需要通过Pipeline的数据进行传输，而其他的节点可以通过Blocking的方式先把数据存储下来，下游再去读取存储下来的数据，如果算子的输出已经进行了完整的保存，那就没有必要将这个算子重新拉起来运行了，这样就使得错误恢复被控制在一个相对较小的范围里面。如果再极端一点，在每个数据Shuffle的地方都进行数据落盘，这就和MapReduce的Map行为比较类似了，不过Flink支持更加高级的用法，用户可以自行控制每个Shuffle的地方通过网络进行直连还是通过文件落盘的方式进行传输，这也是Flink的一个核心不同点。
有了文件Shuffle之后，大家也会想是否能够将这个功能插件化，使其能够将文件Shuffle到其他地方，目前社区也在针对于这个方向做相应的努力，比如可以用Yarn做Shuffle的实现或者做一个分布式服务对于文件进行Shuffle。在阿里内部已经实现了这种架构，实现了单作业处理百TB级别的作业。当Flink具备这种插件化机制以后，就能够轻松地对接更加高效和灵活的Shuffle，让Shuffle这个批处理里面老大难的问题得到较好的解决。
流处理改进：State Processor API(FLIP-43)
流处理一直都是Flink的核心，所以在Flink 1.9版本里面也在流处理方面提出了很多改进，增加了一个非常实用的功能叫做Sate Processor API，其能够帮助用户直接访问Flink中存储的State，API能够帮助用户非常方便地读取、修改甚至重建整个State。这个功能的强大之处在于几个方面，第一个就是灵活地读取外部的数据，比如从一个数据库中读取自主地构建Savepoint，解决作业冷启动问题，这样就不用从N天前开始重跑整个数据。
此外，借助State Processor API，用户可以直接分析State中的数据，因为这部分数据在之前一直属于黑盒，这里面存储的数据是对是错，是否存在异常都用都无从得知，当有了State Processor API之后，用户就可以像分析普通数据一样来分析State数据，进而检测异常和分析故障。第三点就是对于脏数据的订正，比如有一条脏数据污染了State，就可以用State Processor API对于状态进行修复和订正。最后一点就是状态迁移，但用户修改了作业逻辑，还想要复用原来作业中大部分的State，或者想要升级这个State的结构就可以用这个API来完成相应的工作。在流处理面很多常见的工作和问题都可以通过Flink 1.9版本里面提供的State Processor API解决，因此也可以看出这个API的应用前景是非常广泛的。
重构的Web UI
除了上述功能的改进之外，Flink 1.9.0还提供了如下图所示的焕然一新的Web UI。这个最新的前端UI由专业Web前端工程师操刀，采用了最新的AngularJS进行重构。可以看出最新的Web UI非常的清新和现代化，也算是Apache开源软件里面自带UI的一股清流。
三、总结
经过紧锣密鼓的开发，Flink 1.9.0不仅迎来了众多的中国开发者，贡献了海量的代码，也带来了很多的用户。从下图可以看出，无论是从解决issue数量还是从代码commit数量上来看，Flink 1.9.0版本超过了之前两个版本的总和。从代码修改行数来看，Flink 1.9.0达到了150万行，是之前版本的代码修改行数的大约6倍，可以说Flink 1.9.0是Flink开源以来开发者最为活跃的一个版本。从Contributor数量上也可以看出，Flink也吸引了越来越多的贡献者，并且其中很多的贡献者都来自于中国。此外，根据Apache官方所发布的开源项目活跃指标来看，Flink的各项指标也都名列前茅。
从这一切都能够看出，Flink 1.9.0是一个开始，在未来无论是Flink的功能还是生态都会变得越来越好。我们也由衷地希望更多的开发者能够加入Flink开发社区，一起将Flink做的越来越好。
Flink Checkpoint 问题排查实用指南
大涛学长
大涛学长
运营专员
在 Flink 中，状态可靠性保证由 Checkpoint 支持，当作业出现 failover 的情况下，Flink 会从最近成功的 Checkpoint 恢复。在实际情况中，我们可能会遇到 Checkpoint 失败，或者 Checkpoint 慢的情况，本文会统一聊一聊 Flink 中 Checkpoint 异常的情况（包括失败和慢），以及可能的原因和排查思路。
- Checkpoint 流程简介
首先我们需要了解 Flink 中 Checkpoint 的整个流程是怎样的，在了解整个流程之后，我们才能在出问题的时候，更好的进行定位分析。
从上图我们可以知道，Flink 的 Checkpoint 包括如下几个部分：
JM trigger checkpoint
Source 收到 trigger checkpoint 的 PRC，自己开始做 snapshot，并往下游发送 barrier
下游接收 barrier（需要 barrier 都到齐才会开始做 checkpoint）
Task 开始同步阶段 snapshot
Task 开始异步阶段 snapshot
Task snapshot 完成，汇报给 JM
上面的任何一个步骤不成功，整个 checkpoint 都会失败。
2 Checkpoint 异常情况排查
2.1 Checkpoint 失败
可以在 Checkpoint 界面看到如下图所示，下图中 Checkpoint 10423 失败了。
点击 Checkpoint 10423 的详情，我们可以看到类系下图所示的表格（下图中将 operator 名字截取掉了）。
上图中我们看到三行，表示三个 operator，其中每一列的含义分别如下：
其中 Acknowledged 一列表示有多少个 subtask 对这个 Checkpoint 进行了 ack，从图中我们可以知道第三个 operator 总共有 5 个 subtask，但是只有 4 个进行了 ack；
第二列 Latest Acknowledgement 表示该 operator 的所有 subtask 最后 ack 的时间；
End to End Duration 表示整个 operator 的所有 subtask 中完成 snapshot 的最长时间；
State Size 表示当前 Checkpoint 的 state 大小 -- 主要这里如果是增量 checkpoint 的话，则表示增量大小；
Buffered During Alignment 表示在 barrier 对齐阶段积攒了多少数据，如果这个数据过大也间接表示对齐比较慢）；
Checkpoint 失败大致分为两种情况：Checkpoint Decline 和 Checkpoint Expire。
2.1.1 Checkpoint Decline
我们能从 jobmanager.log 中看到类似下面的日志
Decline checkpoint 10423 by task 0b60f08bf8984085b59f8d9bc74ce2e1 of job 85d268e6fbc19411185f7e4868a44178. 其中
10423 是 checkpointID，0b60f08bf8984085b59f8d9bc74ce2e1 是 execution id，85d268e6fbc19411185f7e4868a44178 是 job id，我们可以在 jobmanager.log 中查找 execution id，找到被调度到哪个 taskmanager 上，类似如下所示：
2019-09-02 16:26:20,972 INFO [jobmanager-future-thread-61] org.apache.flink.runtime.executiongraph.ExecutionGraph - XXXXXXXXXXX (100/289) (87b751b1fd90e32af55f02bb2f9a9892) switched from SCHEDULED to DEPLOYING.
2019-09-02 16:26:20,972 INFO [jobmanager-future-thread-61] org.apache.flink.runtime.executiongraph.ExecutionGraph - Deploying XXXXXXXXXXX (100/289) (attempt #0) to slot container_e24_1566836790522_8088_04_013155_1 on hostnameABCDE
从上面的日志我们知道该 execution 被调度到 hostnameABCDE 的 container_e24_1566836790522_8088_04_013155_1 slot 上，接下来我们就可以到 container container_e24_1566836790522_8088_04_013155 的 taskmanager.log 中查找 Checkpoint 失败的具体原因了。
另外对于 Checkpoint Decline 的情况，有一种情况我们在这里单独抽取出来进行介绍：Checkpoint Cancel。
当前 Flink 中如果较小的 Checkpoint 还没有对齐的情况下，收到了更大的 Checkpoint，则会把较小的 Checkpoint 给取消掉。我们可以看到类似下面的日志：
$taskNameWithSubTaskAndID: Received checkpoint barrier for checkpoint 20 before completing current checkpoint 19. Skipping current checkpoint.
这个日志表示，当前 Checkpoint 19 还在对齐阶段，我们收到了 Checkpoint 20 的 barrier。然后会逐级通知到下游的 task checkpoint 19 被取消了，同时也会通知 JM 当前 Checkpoint 被 decline 掉了。
在下游 task 收到被 cancelBarrier 的时候，会打印类似如下的日志：
DEBUG
$taskNameWithSubTaskAndID: Checkpoint 19 canceled, aborting alignment.
或者
DEBUG
$taskNameWithSubTaskAndID: Checkpoint 19 canceled, skipping alignment.
或者
WARN
$taskNameWithSubTaskAndID: Received cancellation barrier for checkpoint 20 before completing current checkpoint 19. Skipping current checkpoint.
上面三种日志都表示当前 task 接收到上游发送过来的 barrierCancel 消息，从而取消了对应的 Checkpoint。
2.1.2 Checkpoint Expire
如果 Checkpoint 做的非常慢，超过了 timeout 还没有完成，则整个 Checkpoint 也会失败。当一个 Checkpoint 由于超时而失败是，会在 jobmanager.log 中看到如下的日志：
Checkpoint 1 of job 85d268e6fbc19411185f7e4868a44178 expired before completing.
表示 Chekpoint 1 由于超时而失败，这个时候可以可以看这个日志后面是否有类似下面的日志：
Received late message for now expired checkpoint attempt 1 from 0b60f08bf8984085b59f8d9bc74ce2e1 of job 85d268e6fbc19411185f7e4868a44178.
可以按照 2.1.1 中的方法找到对应的 taskmanager.log 查看具体信息。
下面的日志如果是 DEBUG 的话，我们会在开始处标记 DEBUG
我们按照下面的日志把 TM 端的 snapshot 分为三个阶段，开始做 snapshot 前，同步阶段，异步阶段：
DEBUG
Starting checkpoint (6751) CHECKPOINT on task taskNameWithSubtasks (4/4)
这个日志表示 TM 端 barrier 对齐后，准备开始做 Checkpoint。
DEBUG
2019-08-06 13:43:02,613 DEBUG org.apache.flink.runtime.state.AbstractSnapshotStrategy - DefaultOperatorStateBackend snapshot (FsCheckpointStorageLocation {fileSystem=org.apache.flink.core.fs.SafetyNetWrapperFileSystem@70442baf, checkpointDirectory=xxxxxxxx, sharedStateDirectory=xxxxxxxx, taskOwnedStateDirectory=xxxxxx, metadataFilePath=xxxxxx, reference=(default), fileStateSizeThreshold=1024}, synchronous part) in thread Thread[Async calls on Source: xxxxxx
_source -> Filter (27/70),5,Flink Task Threads] took 0 ms.
上面的日志表示当前这个 backend 的同步阶段完成，共使用了 0 ms。
DEBUG
DefaultOperatorStateBackend snapshot (FsCheckpointStorageLocation {fileSystem=org.apache.flink.core.fs.SafetyNetWrapperFileSystem@7908affe, checkpointDirectory=xxxxxx, sharedStateDirectory=xxxxx, taskOwnedStateDirectory=xxxxx, metadataFilePath=xxxxxx, reference=(default), fileStateSizeThreshold=1024}, asynchronous part) in thread Thread[pool-48-thread-14,5,Flink Task Threads] took 369 ms
上面的日志表示异步阶段完成，异步阶段使用了 369 ms
在现有的日志情况下，我们通过上面三个日志，定位 snapshot 是开始晚，同步阶段做的慢，还是异步阶段做的慢。然后再按照情况继续进一步排查问题。
2.2 Checkpoint 慢
在 2.1 节中，我们介绍了 Checkpoint 失败的排查思路，本节会分情况介绍 Checkpoint 慢的情况。
Checkpoint 慢的情况如下：比如 Checkpoint interval 1 分钟，超时 10 分钟，Checkpoint 经常需要做 9 分钟（我们希望 1 分钟左右就能够做完），而且我们预期 state size 不是非常大。
对于 Checkpoint 慢的情况，我们可以按照下面的顺序逐一检查。
2.2.0 Source Trigger Checkpoint 慢
这个一般发生较少，但是也有可能，因为 source 做 snapshot 并往下游发送 barrier 的时候，需要抢锁（这个现在社区正在进行用 mailBox 的方式替代当前抢锁的方式，详情参考[1])。如果一直抢不到锁的话，则可能导致 Checkpoint 一直得不到机会进行。如果在 Source 所在的 taskmanager.log 中找不到开始做 Checkpoint 的 log，则可以考虑是否属于这种情况，可以通过 jstack 进行进一步确认锁的持有情况。
2.2.1 使用增量 Checkpoint
现在 Flink 中 Checkpoint 有两种模式，全量 Checkpoint 和 增量 Checkpoint，其中全量 Checkpoint 会把当前的 state 全部备份一次到持久化存储，而增量 Checkpoint，则只备份上一次 Checkpoint 中不存在的 state，因此增量 Checkpoint 每次上传的内容会相对更好，在速度上会有更大的优势。
现在 Flink 中仅在 RocksDBStateBackend 中支持增量 Checkpoint，如果你已经使用 RocksDBStateBackend，可以通过开启增量 Checkpoint 来加速，具体的可以参考 [2]。
2.2.2 作业存在反压或者数据倾斜
我们知道 task 仅在接受到所有的 barrier 之后才会进行 snapshot，如果作业存在反压，或者有数据倾斜，则会导致全部的 channel 或者某些 channel 的 barrier 发送慢，从而整体影响 Checkpoint 的时间，这两个可以通过如下的页面进行检查：
上图中我们选择了一个 task，查看所有 subtask 的反压情况，发现都是 high，表示反压情况严重，这种情况下会导致下游接收 barrier 比较晚。
上图中我们选择其中一个 operator，点击所有的 subtask，然后按照 Records Received/Bytes Received/TPS 从大到小进行排序，能看到前面几个 subtask 会比其他的 subtask 要处理的数据多。
如果存在反压或者数据倾斜的情况，我们需要首先解决反压或者数据倾斜问题之后，再查看 Checkpoint 的时间是否符合预期。
2.2.2 Barrier 对齐慢
从前面我们知道 Checkpoint 在 task 端分为 barrier 对齐（收齐所有上游发送过来的 barrier），然后开始同步阶段，再做异步阶段。如果 barrier 一直对不齐的话，就不会开始做 snapshot。
barrier 对齐之后会有如下日志打印：
DEBUG
Starting checkpoint (6751) CHECKPOINT on task taskNameWithSubtasks (4/4)
如果 taskmanager.log 中没有这个日志，则表示 barrier 一直没有对齐，接下来我们需要了解哪些上游的 barrier 没有发送下来，如果你使用 At Least Once 的话，可以观察下面的日志：
DEBUG
Received barrier for checkpoint 96508 from channel 5
表示该 task 收到了 channel 5 来的 barrier，然后看对应 Checkpoint，再查看还剩哪些上游的 barrier 没有接受到，对于 ExactlyOnce 暂时没有类似的日志，可以考虑自己添加，或者 jmap 查看。
2.2.3 主线程太忙，导致没机会做 snapshot
在 task 端，所有的处理都是单线程的，数据处理和 barrier 处理都由主线程处理，如果主线程在处理太慢（比如使用 RocksDBBackend，state 操作慢导致整体处理慢），导致 barrier 处理的慢，也会影响整体 Checkpoint 的进度，在这一步我们需要能够查看某个 PID 对应 hotmethod，这里推荐两个方法：
多次连续 jstack，查看一直处于 RUNNABLE 状态的线程有哪些；
使用工具 AsyncProfile dump 一份火焰图，查看占用 CPU 最多的栈；
如果有其他更方便的方法当然更好，也欢迎推荐。
2.2.4 同步阶段做的慢
同步阶段一般不会太慢，但是如果我们通过日志发现同步阶段比较慢的话，对于非 RocksDBBackend 我们可以考虑查看是否开启了异步 snapshot，如果开启了异步 snapshot 还是慢，需要看整个 JVM 在干嘛，也可以使用前一节中的工具。对于 RocksDBBackend 来说，我们可以用 iostate 查看磁盘的压力如何，另外可以查看 tm 端 RocksDB 的 log 的日志如何，查看其中 SNAPSHOT 的时间总共开销多少。
RocksDB 开始 snapshot 的日志如下：
2019/09/10-14:22:55.734684 7fef66ffd700 [utilities/checkpoint/checkpoint_impl.cc:83] Started the snapshot process -- creating snapshot in directory /tmp/flink-io-87c360ce-0b98-48f4-9629-2cf0528d5d53/XXXXXXXXXXX/chk-92729
snapshot 结束的日志如下：
2019/09/10-14:22:56.001275 7fef66ffd700 [utilities/checkpoint/checkpoint_impl.cc:145] Snapshot DONE. All is good
2.2.6 异步阶段做的慢
对于异步阶段来说，tm 端主要将 state 备份到持久化存储上，对于非 RocksDBBackend 来说，主要瓶颈来自于网络，这个阶段可以考虑观察网络的 metric，或者对应机器上能够观察到网络流量的情况（比如 iftop)。
对于 RocksDB 来说，则需要从本地读取文件，写入到远程的持久化存储上，所以不仅需要考虑网络的瓶颈，还需要考虑本地磁盘的性能。另外对于 RocksDBBackend 来说，如果觉得网络流量不是瓶颈，但是上传比较慢的话，还可以尝试考虑开启多线程上传功能[3]。
3 总结
在第二部分内容中，我们介绍了官方编译的包的情况下排查一些 Checkpoint 异常情况的主要场景，以及相应的排查方法，如果排查了上面所有的情况，还是没有发现瓶颈所在，则可以考虑添加更详细的日志，逐步将范围缩小，然后最终定位原因。
上文提到的一些 DEBUG 日志，如果 flink dist 包是自己编译的话，则建议将 Checkpoint 整个步骤内的一些 DEBUG 改为 INFO，能够通过日志了解整个 Checkpoint 的整体阶段，什么时候完成了什么阶段，也在 Checkpoint 异常的时候，快速知道每个阶段都消耗了多少时间。
本文作者：jark
原文链接：https://yq.aliyun.com/article...
本文为云栖社区原创内容，未经允许不得转载。