字节跳动 Flink 状态查询实践与优化

本篇文章介绍了字节跳动在 Flink 状态查询方面所进行的优化，解决了查询 Flink 任务状态时开发成本高及无法查询状态元信息等问题，提出了 State Query on Flink SQL 的解决方案，让用户使用 Flink Batch SQL 就可以快速查询 Flink 任务状态。

背景

众所周知，Flink 中的 State 保存了算子计算过程的中间结果。当任务出现异常时，可以通过查询任务快照中的 State 获取有效线索。

但目前对于 Flink SQL 任务来说，当我们想要查询作业 State 时，通常会因为无法获知 State 的定义方式和具体类型等信息，而导致查询 State 的成本过高。

为了解决这个问题，字节跳动流式计算团队在内部提出了 State Query on Flink SQL 的解决方案——用户通过写 SQL 的方式就可以简单地查询 State。本文将主要介绍字节跳动在 Flink 状态查询这方面所进行的相关工作。

State Processor API 介绍

提到状态查询，我们自然会联想到 Flink 在 1.9 版本提出的特性 -- State Processor API。使用 State Processor API，我们可以将作业产生的 Savepoint 转换成 DataSet，然后使用 DataSet API 完成对 State 的查询、修改和初始化等操作。

下面简单介绍一下 如何使用 State Processor API 来完成 State 的查询：

• 首先创建 ExistingSavepoint 用来表示一个 Savepoint。初始化 ExistingSavepoint 时需要提供 Savepoint 路径和 StateBackend 等信息；

• 然后实现 ReaderFunction 用于重新注册所需要查询的 State 以及定义处理 State 的方式。查询状态的过程中会遍历所有的 Key 并按照我们定义的方式去操作 State；

• 最后，调用 Savepoint.readKeyedState 并传入算子的 uid 和 ReaderFunction，就可以完成 State 的查询。

接下来为大家简述一下 State 查询背后的原理。

在 Savepoint 目录中包含两种文件，一种是状态数据文件，比如上图中的 opA-1-state ，这个文件里面保存着算子 A 在第一个 SubTask 状态的明细数据；还有一种元数据文件，对应上图中的 _metadata，元数据文件中保存了每个算子和状态文件的映射关系。

当我们在进行状态查询的时候。首先在 Client 端会根据 Savepoint 路径去解析 metadata 文件。通过算子 ID，可以获取需要查询的状态