流处理应用程序通常是有状态的，“记住”已处理事件的信息，并使用它来影响进一步的事件处理。在Flink中，记忆的信息（即状态）被本地存储在配置的状态后端中。为了防止发生故障时丢失数据，状态后端会定期将其内容快照保存到预先配置的持久性存储中。该RocksDB[1]状态后端（即RocksDBStateBackend）是Flink中的三个内置状态后端之一。这篇博客文章将指导您了解使用RocksDB管理应用程序状态的好处，解释何时以及如何使用它，以及清除一些常见的误解。话虽如此，这不是一篇说明RocksDB如何深入工作或如何进行高级故障排除和性能调整的博客文章；如果您需要任何有关这些主题的帮助，可以联系Flink用户邮件列表[2]。
原文：https://www.ververica.com/blog/manage-rocksdb-memory-size-apache-flink 翻译：zhangjun，英语水平不太好，如有问题，请大家不吝赐教
在TiDB中（TiDB是一个分布式SQL数据库，其存储引擎TiKV是一个分布式的key-value存储引擎），TiKV使用了RocksDB作为其底层存储引擎，利用RocksDB提供的键值存储与读写功能，以及LSM-tree架构来实现数据的持久化和高效读写。
Apache Flink 是一个有状态的流处理框架。什么是流处理应用程序的状态呢？你可以理解状态为应用程序算子中的内存。状态在流计算很多复杂场景中非常重要，比如：
作者 | Stefan Ricther & Chris Ward 翻译 | 邱从贤（山智）
Flink 的新版内存管理机制，要追溯到 2020 年初发布的 Flink 1.10 版本。当时 Flink 社区为了实现三大目标：
对于需要保存超大状态（远超于内存容量）的流计算场景来说，目前 RocksDB [1] 是 Flink 平台上官方实现的唯一选择。业界也有使用 Redis 等其他服务作为状态后端的方案，但终究不够成熟，且已被社区否决 [2].
作者：董伟柯，腾讯 CSIG 高级工程师 概要 Flink 的新版内存管理机制，要追溯到 2020 年初发布的 Flink 1.10 版本。当时 Flink 社区为了实现三大目标： 流和批模式下内存管理的统一，即同一套内存配置既可用于流作业也可用于批作业 管控好 RocksDB 等外部组件的内存，避免在容器环境下用量不受控导致被 KILL 消除不同部署模式下配置参数的歧义，消除 cut-off 等参数语义模糊的问题 提出了两个设计提案 FLIP-49: Unified Memory Configuratio
在说背景前，先说一下标题的结论：你配置的 rocksdb 只会影响 flink 任务中 keyed state 存储的方式和地方，flink 任务中的 operator state 不会受到影响。
Apache Flink was purpose-built forstatefulstream processing. Let’s quickly review: what is state in
Flink 1.10 release 文档描述了一些比较重要的点，比如配置、操作、依赖、1.9 版本和 1.10 版本之间的区别，如果你准备将 Flink 升级到 1.10 版本，建议仔细看完下面的内容。
RocksDB 是嵌入式的 Key-Value 数据库，在 Flink 中被用作 RocksDBStateBackend 的底层存储。如下图所示，RocksDB 持久化的 SST文件在本地文件系统上通过多个层级进行组织，不同层级之间会通过异步Compaction 合并重复、过期和已删除的数据。在 RocksDB 的写入过程中，数据经过序列化后写入到WriteBuffer，WriteBuffer 写满后转换为 Immutable Memtable 结构，再通过 RocksDB 的flush 线程从内存 flush 到磁盘上；读取过程中，会先尝试从 WriteBuffer 和 Immutable Memtable 中读取数据，如果没有找到，则会查询 Block Cache，如果内存中都没有的话，则会按层级查找底层的 SST 文件，并将返回的结果所在的 Data Block 加载到 BlockCache，返回给上层应用。
本文主要讨论一个问题：ValueState 中存 Map 与 MapState 有什么区别？
场景描述：当Flink程序的checkpoint被激活时，状态会被持久化到checkpoint，以防止数据丢失和无缝恢复。状态在内部如何组织和它们如何以及在哪持久化，依赖于所选的状态后端。
Checkpoint 的存储的位置取决于配置的 State backend（JobManager 内存，文件系统，数据库...）。
本文主要分享与交流 Flink 状态使用过程中的一些经验与心得，当然标题取了“最佳实践”之名，希望文章内容能给读者带去一些干货。本文内容首先是回顾 state 相关概念，并认识和区别不同的 state backend；之后将分别对 state 使用访问以及 checkpoint 容错相关内容进行详细讲解，分享一些经验和心得。
场景描述：Flink本身为了保证其高可用的特性，以及保证作用的Exactly Once的快速恢复，进而提供了一套强大的Checkpoint机制。这个机制在原理是什么？有哪些需要注意的呢？
为了解决Flink作业使用RocksDB状态后端时的内存超用问题，Flink早在1.10版本就实现了RocksDB的托管内存(managed memory)机制。用户只需启用state.backend.rocksdb.memory.managed参数(默认即为true)，再设定合适的TaskManager托管内存比例taskmanager.memory.managed.fraction，即可满足多数情况的需要。
公司线上一个Flink作业的State Size随时间逐渐增大，运行一段时间后出现报OutOfMemory异常。
其中主要划分为一下 4 大主题，首先是前两个 状态原理、时间窗口 是用于考核候选人对于 Flink 基本原理的理解，编程技巧、实战经验 主要是考核候选人使用 Flink 的经验。
问题导读 1.Flink1.8引入对什么状态的连续清理？ 2.保存点兼容性方面，不在兼容哪个版本？ 3.Maven依赖在Hadoop方便发生了什么变化？ 4.Flink是否发布带有Hadoop的二进制文件？ Flink1.8发布，主要改变如下： 1.将会增量清除旧的State 2.编程方面TableEnvironment弃用 3.Flink1.8将不发布带有Hadoop的二进制安装包 更多详细如下：
在某些场景下 Flink 用户状态一直在无限增长，一些用例需要能够自动清理旧的状态。例如，作业中定义了超长的时间窗口，或者在动态表上应用了无限范围的 GROUP BY 语句。此外，目前开发人员需要自己完成 TTL 的临时实现，例如使用可能不节省存储空间的计时器服务。还有一个比较重要的点是一些法律法规也要求必须在有限时间内访问数据。
Tech 导读 本文综合Apache Flink原理与京东实时计算平台（JRC）的背景，详细讲述了大规模Flink流作业的调优方法。通过阅读本文，读者可了解Flink流作业的通用调优措施，并应用于生产环境。 写在前面 Apache Flink作为Google Dataflow Model的工业级实现，经过多年的发展，如今已经成为流式计算开源领域的事实标准。它具有高吞吐、低时延、原生流批一体、高一致性、高可用性、高伸缩性的特征，同时提供丰富的层级化API、时间窗口、状态化计算等语义，方便用户快速入门实时开发，
最近我们组在大规模上线Flink SQL作业。首先，在进行跑批量初始化完历史数据后，剩下的就是消费Kafka历史数据进行追数了。但是发现某些作业的追数过程十分缓慢，要运行一晚上甚至三四天才能追上最新数据。由于是实时数仓指标计算上线初期，经常验证作业如果有问题就得重蹈覆辙重新追数，效率很低，于是我开始分析Flink SQL的优化。
状态可以存储在Java的堆内或堆外。根据你的状态终端，Flink 也可以管理应用程序的状态，这意味着 Flink 可以处理内存管理（可能会溢出到磁盘，如果有必要），以允许应用程序存储非常大的状态。默认情况下，配置文件 flink-conf.yaml 为所有Flink作业决定其状态终端。
Flink内置了三种Statebackend，MemoryStateBackend和FsStateBackend运行时都是存放在Java Heap中，只有Checkpoint时FsStateBackedn才会将数据以文件格式持久化到远程存储上，RocksDBStateBackend则是使用RocksDB对State进行存储。
Apache Flink 的持久化对许多用户来说都是一个谜。用户最常见反复提问的问题就是不理解 State、StateBackend 以及快照之间的关系。通过学习可以解答我们的一些困惑，但是这个问题如此常见，我们认为 Flink 的用户 API 应该设计的更友好一些。在过去几年中，我们经常会听到如下误解：
这篇文章我们将深入探讨有状态流处理，更确切地说是 Flink 中可用的不同状态后端。在以下部分，我们将介绍 Flink 的3个状态后端，它们的局限性以及根据具体案例需求选择最合适的状态后端。
第一部分讨论如何大规模执行checkpoint。 最后一部分解释了一些关于规划要使用多少资源的最佳实践。
1.Flink1.8.0引入对状态的清理？ 2.保存点兼容性方面，不在兼容哪个版本？ 3.Maven依赖在Hadoop方便发生了什么变化？ 4.Flink是否发布带有Hadoop的二进制文件？
在我们开发Flink应用时，许多有状态流应用程序的一个常见要求是自动清理应用程序状态以有效管理状态大小，或控制应用程序状态的访问时间。 TTL(Time To Live)功能在Flink 1.6.0中开始启动，并在Apache Flink中启用了应用程序状态清理和高效的状态大小管理。
Flink官网的自我介绍：Apache Flink® — Stateful Computations over Data Streams，可以看出状态计算是 Flink 引以为豪的杀手锏。那什么是带状态的计算呢？简单说计算任务的结果不仅仅依赖于输入，还依赖于它的当前状态。
不多说了，本文从盘古开天辟地（状态是啥？）开始说 Flink State。如下为本文目录，诚意满满。
本文将解析 JVM 和 Flink 的内存模型，并总结在工作中遇到和在社区交流中了解到的造成 Flink 内存使用超出容器限制的常见原因。由于 Flink 内存使用与用户代码、部署环境、各种依赖版本等因素都有紧密关系，本文主要讨论 on YARN 部署、Oracle JDK/OpenJDK 8、Flink 1.10+ 的情况。
在 Shopify 中，我们将Apache Flink作为标准的有状态流媒体引擎，为我们的BFCM Live Map等各种用例提供支持。我们的 Flink 应用程序部署在利用Google Kubernetes Engine的 Kubernetes 环境中。我们的集群采用配置使用高可用性模式，配置任务管理为故障点。我们还为我们使用状态保存器作为我们使用的检查点和点写入谷歌云存储（GCS）。
摘要：本文整理自阿里云高级开发工程师 Apache Flink Committer、Flink 1.16 Release Manager 黄兴勃（断尘），在 FFA 2022 核心技术专场的分享。本篇内容主要分为四个部分：
摘要：本文介绍了 Dinky 实时计算平台扩展 iceberg 的实践分享。内容包括：
状态在 Flink 中叫作 State,用来保存中间计算结果或者缓存数据。根据是否需要保存中间结果，分为无状态计算和有状态计算。对于流计算而言，时间持续不断地产生，如果每次计算都是相互独立的，不依赖于上下游的事件，则是无状态计算。如果计算需要依赖于之前或者后续的事件，则是有状态计算。State 是实现有状态计算的下的 Exactly-Once 的基础。
在本节中，您将了解Flink为编写有状态程序提供的api。请参阅有状态流处理以了解有状态流处理背后的概念。
一般指一个具体的Operator的状态(operator的状态表示一些算子在运行的过程中会产生的一些历史结果,如前面的maxBy底层会维护当前的最大值,也就是会维护一个keyedOperator,这个State里面存放就是maxBy这个Operator中的最大值)
有状态的计算是流处理框架要实现的重要功能，因为稍复杂的流处理场景都需要记录状态，然后在新流入数据的基础上不断更新状态。下面的几个场景都需要使用流处理的状态功能：
在本文中，我们将解释什么是 Savepoint，什么会使用它们，并就它们与 Checkpoint 的区别进行对比分析。
Flink社区在FLIP-49提出了新版统一的TaskManager内存模型及配置，这也是Flink 1.10版本最主要的改进与优化点之一。根据社区的说法，该proposal致力于解决1.9版本及之前的TM内存配置的三个缺点：
上图的Flink示例程序对一个数据流做简单处理，整个过程包括了输入（Source）、转换（Transformation）和输出（Sink）。程序由多个DataStream API组成，这些API，又被称为算子 （Operator），共同组成了逻辑视角。在实际执行过程中，逻辑视角会被计算引擎翻译成可并行的物理视角。
在流计算作业中，经常会遇到一些状态数不断累积，导致状态量越来越大的情形。例如，作业中定义了超长的时间窗口，或者在动态表上应用了无限范围的 GROUP BY 语句，以及执行了没有时间窗口限制的双流 JOIN 等等操作。对于这些情况，旧版本的 Flink 并不能很好应对，经常导致堆内存出现 OOM，或者堆外内存（RocksDB）用量持续增长导致超出容器的配额上限，造成作业的频繁崩溃，业务不能正常运行。
Apache Flink 社区迎来了激动人心的两位数位版本号，Flink 1.10.0 正式宣告发布！作为 Flink 社区迄今为止规模最大的一次版本升级，Flink 1.10 容纳了超过 200 位贡献者对超过 1200 个 issue 的开发实现，包含对 Flink 作业的整体性能及稳定性的显著优化、对原生 Kubernetes 的初步集成以及对 Python 支持（PyFlink）的重大优化。
在当前整个行业及公司内部降本增效的大背景下，B站内部也在积极推进实时与在线业务资源的整合，往云原生架构迁移，统一资源池与调度，提升资源利用效率。不过面临的现实问题就是，不同业务场景下，资源的规格诉求不尽相同。在线的业务资源池，由于在线业务的属性，一般只具备很强的计算能力而基本不带存储以及io能力。Flink虽然是一个计算引擎，但是由于其stateful的特性，在很多计算场景下，对存储和io其实有比较强的诉求，因此实时的资源池，同时具备很强的存算能力。两种资源池的整合，必然面临兼容性问题，考虑到大数据整体的存算分离发展趋势，我们尝试对Flink进行存算分离的改造，核心工作就是statebackend的远程化。
作者 | 郭文飞 编辑 | 蔡芳芳 2021 年，字节跳动旗下产品总 MAU 已超过 19 亿。在以抖音、今日头条、西瓜视频等为代表的产品业务背景下，强大的推荐系统显得尤为重要。Flink 提供了非常强大的 SQL 模块和有状态计算模块。目前在字节推荐场景，实时简单计数特征、窗口计数特征、序列特征已经完全迁移到 Flink SQL 方案上。结合 Flink SQL 和 Flink 有状态计算能力，我们正在构建下一代通用的基础特征计算统一架构，期望可以高效支持常用有状态、无状态基础特征的生产。
相信小伙伴们对于Flink一定不会感到陌生，作为连续三年蝉联第一，荣膺全球最活跃的 Apache 开源项目，Flink在中国的热度也一直是居高不下。近几年，在社区的推动下，Flink 技术栈在越来越多的公司开始得到应用，因此在大数据的求职招聘中，对于Flink的着重考察也变得越来越重要。本期文章，菌哥就带大家来总结一下，在面试过程中，Flink常被问到的知识点有哪些？如果本文对你有帮助，记得在看完之后，一键三连(✧◡✧)
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
云直播
对象存储
