在Flink状态管理详解这篇文章中，我们介绍了Flink的状态都是基于本地的，而Flink又是一个部署在多节点的分布式引擎，分布式系统经常出现进程被杀、节点宕机或网络中断等问题，那么本地的状态在遇到故障时如何保证不丢呢？Flink定期保存状态数据到存储上，故障发生后从之前的备份中恢复，整个被称为Checkpoint机制，它为Flink提供了Exactly-Once的投递保障。本文将介绍Flink的Checkpoint机制的原理。本文会使用多个概念：快照（Snapshot）、分布式快照（Distributed Snapshot）、检查点（Checkpoint）等，这些概念均指的是Flink的Checkpoint机制，读者可以将这些概念等同看待。
最近一次项目当中需要将大量数据保存再Flink程序当中用作缓存数据一共后续数据使用，隧对最近使用到的状态、检查点、保存点等原理和使用进行一个总结
Flink官网的自我介绍：Apache Flink® — Stateful Computations over Data Streams，可以看出状态计算是 Flink 引以为豪的杀手锏。那什么是带状态的计算呢？简单说计算任务的结果不仅仅依赖于输入，还依赖于它的当前状态。
虽然数据流中的许多操作一次只查看一个单独的事件（例如事件解析器），但某些操作会记住多个事件的信息（例如窗口算子）。 这些操作称为有状态的(stateful)。
在我们开发Flink应用时，许多有状态流应用程序的一个常见要求是自动清理应用程序状态以有效管理状态大小，或控制应用程序状态的访问时间。 TTL(Time To Live)功能在Flink 1.6.0中开始启动，并在Apache Flink中启用了应用程序状态清理和高效的状态大小管理。
Flink是一个有状态的流式计算引擎，所以会将中间计算结果(状态)进行保存，默认保存到TaskManager的堆内存中，但是当task挂掉，那么这个task所对应的状态都会被清空，造成了数据丢失，无法保证结果的正确性，哪怕想要得到正确结果，所有数据都要重新计算一遍，效率很低。想要保证 At -least-once 和 Exactly-once，需要把数据状态持久化到更安全的存储介质中，Flink提供了堆内内存、堆外内存、HDFS、RocksDB等存储介质。
批处理在大数据世界有着悠久的历史。早期的大数据处理基本上是批处理的天下。批处理主要操作大容量的静态数据集，并在计算过程完成之后返回结果。所以批处理面对的数据集通常具有以下特征：
之前有想过系统地来一番flink源码分析系列，谁曾想工作中需要完成的需求有些多，完整的flink源码分析系列只能一再往后拖了。之前公众号后台有想学习flink的朋友留言想看更多学习flink的资料，现在先发一些之前收藏的关于flink相关的文章，其中大多翻译自flink社区，希望能给大家带来一些帮助。本文[1]主要围绕flink任务的生命周期展开。
在 Flink 的框架中，进行有状态的计算是 Flink 最重要的特性之一。所谓的状态，其实指的是 Flink 程序的中间计算结果。Flink 支持了不同类型的状态，并且针对状态的持久化还提供了专门的机制和状态管理器。
公司线上一个Flink作业的State Size随时间逐渐增大，运行一段时间后出现报OutOfMemory异常。
导语 | 大数据计算分为离线计算和实时计算，其中离线计算就是我们通常说的批计算，代表技术是Hadoop MapReduce、Hive等；实时计算也被称作流计算，代表技术是Storm、Spark Streaming、Flink等。本文系统地介绍了流式计算的相关知识，并着重介绍了Flink的实现原理细节，便于大家快速地理解和掌握流式计算，并基于Flink完成业务开发。 一、流式计算和批处理 批处理在大数据世界有着悠久的历史。早期的大数据处理基本上是批处理的天下。批处理主要操作大容量的静态数据集，并在计算过
很多有状态流应用程序的常见需求是能够控制应用程序状态的访问时长以及何时删除它。这篇文章介绍了在 1.6.0 版本添加到 Flink 的状态生命周期时间（TTL）功能。
前段时间详细地阅读了 《Apache Flink的流处理》 这本书，作者是 Fabian Hueske&Vasiliki Kalavri，国内崔星灿翻译的，这本书非常详细、全面得介绍了Flink流处理，并且以气象数据的例子讲解其中的使用，我把其中一些比较重要的句子做了比较，并且分享给大家。有一些我不是很理解，需要以后慢慢去消化，我就不做详细的展开。
上图的Flink示例程序对一个数据流做简单处理，整个过程包括了输入（Source）、转换（Transformation）和输出（Sink）。程序由多个DataStream API组成，这些API，又被称为算子 （Operator），共同组成了逻辑视角。在实际执行过程中，逻辑视角会被计算引擎翻译成可并行的物理视角。
在本节中，您将了解Flink为编写有状态程序提供的api。请参阅有状态流处理以了解有状态流处理背后的概念。
Via：https://flink.apache.org/2019/06/26/broadcast-state.html 自版本 Flink 1.5.0 以来，Apache Flink 提供了一种新的状态类型，称为广播状态（Broadcast State）。在本文中，将解释什么是广播状态，并通过示例演示如何将广播状态应用在评估基于事件流的动态模式的应用程序，并指导大家学习广播状态的处理步骤和相关源码，以便在今后的实践中能实现此类的应用。
之前所介绍的流处理API，无论是基本的转换、聚合，还是更为复杂的窗口操作，其实都是基于DataStream进行转换的；所以可以统称为DataStream API，这也是Flink编程的核心。而我们知道，为了让代码有更强大的表现力和易用性，Flink本身提供了多层API，DataStream API只是中间的一环，如图所示：
我们前面写的word count的例子，没有包含状态管理。如果一个task在处理过程中挂掉了，那么它在内存中的状态都会丢失，所有的数据都需要重新计算。从容错和消息处理的语义上(at least once, exactly once)，Flink引入了state和checkpoint。
Checkpoint 机制
虽然数据流中的许多操作一次只查看一个单独的事件（例如事件解析器），但有些操作会记住跨多个事件的信息（例如窗口操作符）。 这些操作称为有状态的。
Flink有两种基本的状态：Keyed State和Operator State。
从版本1.5.0开始，Apache Flink具有一种称为广播状态的新型状态。 在这篇文章中，我们解释了广播状态是什么，并展示了如何将其应用于评估事件流上的动态模式的应用程序的示例。 我们将引导您完成开发步骤和代码，以实现此应用程序。
Flink四大基石分别是：Time （时间）、Window（窗口）、State （状态）、Checkpoint（检查点）。
在上篇文章中，我们过了下基本的理论，也介绍了主流的流处理框架：Storm，Trident，Spark Streaming，Samza和Flink。今天咱们来点有深度的主题，比如，容错，状态管理或者性能。除此之外，我们也将讨论开发分布式流处理应用的指南，并给出推荐的流处理框架。
为了模拟生产环境中实时产生的订单数据，这里我们自己定义一个数据源来源源不断的产生模拟订单数据
场景描述：Flink本身为了保证其高可用的特性，以及保证作用的Exactly Once的快速恢复，进而提供了一套强大的Checkpoint机制。这个机制在原理是什么？有哪些需要注意的呢？
在某些场景下 Flink 用户状态一直在无限增长，一些用例需要能够自动清理旧的状态。例如，作业中定义了超长的时间窗口，或者在动态表上应用了无限范围的 GROUP BY 语句。此外，目前开发人员需要自己完成 TTL 的临时实现，例如使用可能不节省存储空间的计时器服务。还有一个比较重要的点是一些法律法规也要求必须在有限时间内访问数据。
不多说了，本文从盘古开天辟地（状态是啥？）开始说 Flink State。如下为本文目录，诚意满满。
将代码打包，上传至hadoop10 /opt/app/flink,jar; 执行命令运行jar包： [root@hadoop10 app]# flink run -c day160616.CheckPointTest /opt/app/flink.jar Job has been submitted with JobID ee5811b41a5e8c5d7dd052ed78db14b4;
来自Flink Forward Berlin 2017的最受欢迎的会议是Robert Metzger的“坚持下去：如何可靠，高效地操作Apache Flink”。 Robert所涉及的主题之一是如何粗略地确定Apache Flink集群的大小。 Flink Forward的与会者提到他的群集大小调整指南对他们有帮助，因此我们将他的谈话部分转换为博客文章。 请享用！
Flink 故障恢复机制的核心，就是应用状态的一致性检查点，有状态流应用的一致检查点，其实就是所有任务的状态，在某个时间点的一份拷贝（一份快照）；这个时间点，应该是所有任务都恰好处理完一个相同的输入数据的时刻。在执行流应用程序期间，Flink 会定期保存状态的一致检查点，如果发生故障， Flink 将会使用最近的检查点来一致恢复应用程序的状态，并。重新启动处理流程。
Flink是一个有状态的流式计算引擎，所以会将中间计算结果（状态）进行保存，默认保存到TaskManager的堆内存中。
反压（backpressure）是实时计算应用开发中，特别是流式计算中，十分常见的问题。反压意味着数据管道中某个节点成为 瓶颈，处理速率跟不上上游发送数据的速率，而需要对上游进行限速。由于实时计算应用通常使用消息队列来进行生产端和 消费端的解耦，消费端数据源是 pull-based 的，所以反压通常是从某个节点传导至数据源并降低数据源（比如 Kafka consumer）的摄入速率。
要想熟练掌握一个大数据框架，仅仅是学习一些网络上的样例程序是远远不够的，我们必须系统地了解它背后的设计和运行原理。
一、Flink简介 二、Flink 部署及启动 三、Flink 运行架构 四、Flink 算子大全 五、流处理中的 Time 与 Window 六、Flink 状态管理 七、Flink 容错 八、Flink SQL 九、Flink CEP 十、Flink CDC 十一、基于 Flink 构建全场景实时数仓 十二、Flink 大厂面试题
兄弟们，在 18w 字《Flink SQL 成神之路》之后，我的另一篇《Flink 对线面试官》申请出战！
在 Flink 1.4 版本之前，精准一次处理只限于 Flink 应用内，也就是所有的 Operator 完全由 Flink 状态保存并管理的才能实现精确一次处理。但 Flink 处理完数据后大多需要将结果发送到外部系统，比如 Sink 到 Kafka 中，这个过程中 Flink 并不保证精准一次处理。
状态在 Flink 中叫作 State,用来保存中间计算结果或者缓存数据。根据是否需要保存中间结果，分为无状态计算和有状态计算。对于流计算而言，时间持续不断地产生，如果每次计算都是相互独立的，不依赖于上下游的事件，则是无状态计算。如果计算需要依赖于之前或者后续的事件，则是有状态计算。State 是实现有状态计算的下的 Exactly-Once 的基础。
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，返回给上层应用。
Apache Flink 是一个分布式流计算引擎，用于在无边界和有边界数据流上进行有状态的计算。
知道大数据的同学也应该知道 Flink 吧，最近在中国的热度比较高，在社区的推动下，Flink 技术栈在越来越多的公司开始得到应用。
有状态的计算是流处理框架要实现的重要功能，因为稍复杂的流处理场景都需要记录状态，然后在新流入数据的基础上不断更新状态。下面的几个场景都需要使用流处理的状态功能：
ack 数据源是否需要kafka得到确认。all表示需要收到所有ISR节点的确认信息，1表示只需要收到kafka leader的确认信息，0表示不需要任何确认信息。该配置项需要对数据精准性和延迟吞吐量做出权衡。
转载自:https://dwz.cn/xrMCqbk5 摘要： 实际问题 在流计算场景中，数据会源源不断的流入Apache Flink系统，每条数据进入Ap
本文主要分享与交流 Flink 状态使用过程中的一些经验与心得，当然标题取了“最佳实践”之名，希望文章内容能给读者带去一些干货。本文内容首先是回顾 state 相关概念，并认识和区别不同的 state backend；之后将分别对 state 使用访问以及 checkpoint 容错相关内容进行详细讲解，分享一些经验和心得。
第一部分讨论如何大规模执行checkpoint。 最后一部分解释了一些关于规划要使用多少资源的最佳实践。
摘要：实际问题 在流计算场景中，数据会源源不断的流入Apache Flink系统，每条数据进入Apache Flink系统都会触发计算。如果我们想进行一个Count聚合计算，那么每次触发计算是将历史上所有流入的数据重新新计算一次，还是每次计算都是在上一次计算结果之上进行增量计算呢？答案是肯定的，Apache Flink是基于上一次的计算结果进行增量计算的。
在当前整个行业及公司内部降本增效的大背景下，B站内部也在积极推进实时与在线业务资源的整合，往云原生架构迁移，统一资源池与调度，提升资源利用效率。不过面临的现实问题就是，不同业务场景下，资源的规格诉求不尽相同。在线的业务资源池，由于在线业务的属性，一般只具备很强的计算能力而基本不带存储以及io能力。Flink虽然是一个计算引擎，但是由于其stateful的特性，在很多计算场景下，对存储和io其实有比较强的诉求，因此实时的资源池，同时具备很强的存算能力。两种资源池的整合，必然面临兼容性问题，考虑到大数据整体的存算分离发展趋势，我们尝试对Flink进行存算分离的改造，核心工作就是statebackend的远程化。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
