flinkstate的简单介绍

本篇文章给大家谈谈flinkstate，以及对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、07_Flink之checkpoint和state
• 2、Flink StateFunction 初识
• 3、[Flink State] State究竟保存在哪里？

07_Flink之checkpoint和state

barrier携带者快照的id，快照的id在快照存放在最前面

flink容错-checkpoint流程

第二个问题：停止数据处理，做完快照，广播屏障。

1、快照数据存储，不往下发？只发barrier，应该里面包含着数据才芹洞咐对。

2、一个算子存储做，那么计算是存储之前做，还是存储之后做。？

第三个问题：最下面那个到底对吗

state数据保存在java堆内存中，执行checkpoint的时候，会把state的快照数据保存到jobmanager的内存中 基于内存的state backend在生产环境下不建议使用。【因为怕丢失】

state数据保存在taskmanager的内存中，执行checkpoint的时候，会把state的快照数据保存到配置颤仔的文件系统中，可以使用hdfs等分布式文件系统。

基于RocksDB + FS

RocksDB跟上面的都略有不同，它会在本地文件系统中维护状态，state会直接写入本地rocksdb中。同时RocksDB需要配置一个远端的filesystem。

checkpoint与state之间的关系

checkpoint是一个动词，如果顺利的话，会产生一个名词。

state：流式计算中持久化的状态

state存放在local state backend。

在flink中，state可以分为这两种，一种嫌纯是keyed State，一种是

并行，多个节点一起计算。

并发，一个节点，多个线程计算。

hello1永远只会到并发的task上面去。

不去keyby也能拿到它.

triggercheckpoint，当task收到所有barrier之后，会进行快照，再快照之前，将自己的输出继续传递barrier，并将自己的状态异步写入到持久化存储中。

我已经把快照做好，并且把元数据告诉你。

Flink StateFunction 初识

Flink 的Stateful Function 2.0 也已经出来一段时间了，不清楚它的用途适用场景。本篇会有Stateful Function的一些相关概念，搬运模哪了多位大神文章内容。

看完解释之后，还是不理解这个是什么。继续看其他解释。。。

FaaS概念再回顾下。

在上面动图中Function按照调用次数收费。毫秒级创建并且启动一个Function实例，运行若干秒后销毁。只有在真正运行，用到Function的时候才计费。

到这里，我们信裤对于前面的内容做一下总结：

Stateful Function是为了解决现有的FaaS无法满足有状态计算，而做出的一款有状态的FaaS产品

那么，问题来了？Stateful Function是如何解决有状态这个问题的呢？

官方说实现的方式有点类似Actor。再一次回旦坦码顾下知识点。

1. Serverless/FaaS 的现状和未来

2. 10分钟了解Actor模型

3. Stateful Functions 开源：集成了 Flink 和 FaaS 的流处理优点

[Flink State] State究竟保存在哪里？

从源码解析State的保存过程 ，上一篇从task和operator出发说明了保存state的过程，到最后是由算子调用snapshot方法，进行state的快照操作。那么state究竟保存在哪里？

1 State Backend简介

关于 Raw Bytes Storage and Backends

总结： StateBackend主要是针对raw bytes storage（即checkpoint），keyed state和乎纳operator state来提供功能的，其中checkpoint数据的存储则是通过CheckpointStreamFactory，而state存储，针对keyedState是通过AbstractKeyedStateBackend，针对operatorState是通过OperatorStateBackend。

2

RocksDBStateBackend的构造函数可以传入一个AbstractStateBackend，否则默认采用FsStateBackend。

可以看到，从OperatorState的角度来讲，目前Flink只有一个实现，即DefaultOperatorStateBackend，它将List风格的State保存在内存中。

从KeyedState的角度来讲，目前有两种实现,HeapKeyedStateBackend将state保存在内存中，而RocksDbKeyedStateBackend将State保存在TM本地的RocksDB中。相对而言，前者在内存中，速度会快，效率高，但一方面会限制state的扒顷粗大小，另一方面也会造成JVM自己的内存问题；后者在本地文件中，就会涉及序列化和反序列化，春镇效率不及前者，但可以保存的state的大小会很大。

从checkpoint和savepoint的角度来看，Memory工厂方法都保存在内存中，显然不能在生产环境使用，而Fs工厂方法和RocksDb工厂方法，则统一都放在文件系统中，比如HDFS。

从上图中3,4两行可以看到，具体用来存储state的有三种HeapKeyedStateBackend，RocksDBKeyedStateBackend和DefaultOperatorStateBackend。

DefaultOperatorStateBackend

（1）

operator的ListSate的实现类PartitionableListState， OperatorState都保存在内存中，本质上还是一个ArrayList。

（2）snapshot方法

该snapshotStrategy是AbstractSnapshotStrategyOperatorStateHandle，而AbstractSnapshotStrategy有三种实现类：

DefaultOperatorStateBackendSnapshotStrategy中的snapshot方法：

该snapshot方法中，主要是对 registeredOperatorStates 和 registeredBroadcastStates 的snapshot。

第一步：

针对所有注册的state进行deepCopy，为了防止在checkpoint的时候数据结构又被修改，deepCopy其实是通过序列化和反序列化的过程；

第二步：

异步写入State和MetaInfo，先创建CheckpointStateOutputStream，通过调用factory的createCheckpointStateOutputStream方法，这个factory是哪种类型的呢？这个是由定义的状态后端所决定的。之后会返回相应的OperatorstateHandle用作restore的过程。

第三步：

在StreamTask触发checkpoint的时候会将一个Task中所有的operator触发一次snapshot，触发部分就是上面1，2两个步骤，其中第二步是会返回一个RunnableFuture，在触发之后会提交一个AsyncSnapshotCallable异步任务，会阻塞一直等到checkpoint的Future，其实就是去调用这个方法AbstractAsyncIOCallable, 直到完成之后OperatorState会返回一个OperatorStateHandle,这个地方和后文的keyedState返回的handle不一样。

[img]

关于flinkstate和的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。