Flink 状态管理

最新推荐文章于 2024-12-22 22:45:11 发布

原创

最新推荐文章于 2024-12-22 22:45:11 发布 · 1.4k 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#flink #kafka #big data

本文深入解析了状态在实时计算中的关键作用，讨论了为何离线任务不提状态、状态管理的必要性，以及Flink状态分类、使用、后端选择、TTL策略和Checkpoint机制。还特别强调了状态管理在任务容错和性能优化中的重要性，以及常见状态误用案例的警示。

Flink State本文目录：

状态是什么东西？有了状态能做什么？
为什么离线计算中不提状态，实时计算老是提到状态这个概念？状态到底在实时计算中解决了什么问题？
有了状态、为什么又出现了状态管理的概念？
怎么学习 Flink 中的状态、状态管理相关的概念呢？
Flink 中状态的分类？
Flink 中状态的使用方式？
Flink 状态后端的分类及使用建议？
Flink 中状态的能力扩展 - TTL？
Flink 中状态 TTL 的原理机制？
Flink Checkpoint 的运行机制？
Flink Checkpoint 的配置？
Flink Checkpoint 在 HDFS 的存储格式？
Flink Checkpoint 的恢复机制？
Flink SQL 的 State 存储？
Flink 状态的误用之痛？

1. 状态是什么东西？

需要明白：状态不仅仅只限于 Flink 的状态。状态其实是一个普遍存在的东西。

2.为什么离线计算中不提状态，状态到底在实时计算中解决了什么问题？

其实在实时计算中的状态的功能主要体现在任务可以做到失败重启后没有数据质量、时效问题。
实时任务失败重启：实时任务一般都是 7x24 小时 long run 的，挂了之后，就会有以下两个问题。首先给一个实际场景：一个消费上游 Kafka，使用 Set去重计算 DAU 的实时任务。

数据质量问题：当这个实时任务挂了之后恢复，Set空了，这时候任务再继续从上次失败的 Offset 消费 Kafka 产出数据，则产出的数据就是错误数据了。这时候小伙伴可能会提出疑问，计算 DAU 场景的话，这个任务挂了我重新从今天 0 点开始消费 Kafka 不就得了？这个观点没有错，其实这就是博主即将说的第二个问题。
数据时效问题：你要记得，你一定要记得，你是一个实时任务，产出的指标是有时效性（主要是时延）要求的。你可以从今天 0 点开始重新消费，但是你回溯数据也是需要时间的。举例：中午 12 点挂了，实时任务重新回溯 12 个小时的数据能在 1 分钟之内完成嘛？大多数场景下是不能的！一般都要回溯几个小时，这就是实时场景中的数据时效问题。

那当我们把状态给 “管理” 起来时，上面的两个问题就可以迎刃而解。还是相同的计算任务、相同的业务场景：

当我们把 Set这个数据结构定期（每隔 1min）的给存储到 HDFS 上面时，任务挂了、恢复之后。我们的任务还可以从 HDFS 上面把这个数据给读回来，接着从最新的一个 Kafka Offset 继续计算就可以，这样即没有数据质量问题，也没有数据时效性问题。

所以这就是为什么实时任务中老是提到状态、状态管理这些个概念的原因！

那么！离线任务真的是没有状态、状态管理这些个概念这个概念嘛？
离线中其实也有，举个例子 Remote Shuffle Service，比如 Spark Remote Shuffle Service。
一个常见的离线任务运行时，通常都由几个 Stage 组成，比如有 1，2，3，4，5 个 Stage 顺序执行，当第 4 个 Stage 运行挂了之后，离线任务就要从第 1 个 Stage 重新开始执行，这样的话，执行效率是非常低的。
那么这个场景下有没有办法做到第 4 个 Stage 挂了，我们只重新运行第 4 个 Stage 呢？
当然有解法，我们可以将每一个 Stage 的结果保存下来，比如第 3 个 Stage 运行完成之后，将结果保存到远程的服务，当第 4 个 Stage 任务挂了之后，只需要从远程服务将第 3 个 Stage 结果拿来重新执行就行。
而 Remote Shuffle Service 的功能就是将每一个 Stage 的运行结果存储到一个独立的 Service 上面，当第 4 个 Stage fail 之后重新恢复时，可以直接从第 4 个 Stage 开始执行。
那么这里其实也涉及到了状态的概念。对于整个任务来说，这里面的每个 Stage 的结果就是状态，Remote Shuffle Service 就起到了 “管理” 状态的作用。
那么！实时任务真的只能依赖状态、状态管理嘛？
也不一定，举个例子，一个消费 Kafka，计算一个分钟级别的同时在线用户数（TUMBLE 1 min）的实时任务，在任务挂了之后，其实可以完全不依赖状态，直接从前几分钟的 Kafka Offset 去回溯一下数据也可以，能满足时效性的同时，也可以满足数据质量。