有状态流式处理引擎的基石

微信扫一扫,分享到朋友圈

有状态流式处理引擎的基石

「有状态的流式处理」概念解析

流式处理

流式处理简单地说就是一个无穷尽的数据源在持续的收数据,以代码作为数据处理的基础逻辑,然后输出,这就是流式处理的基本原理。

分布式流式处理

Stream需要做分区,设置相同的Key,并让同样的Key流到一个computition instance做相同的运算。

有状态分布式流式处理

代码中定义了变量X,X在数据处理过程会进行读写操作,变量X会影响最后的结果输出。比如计算每个使用者出现的次数,次数即所谓的状态。

Apache Flink 的优势

状态容错

作为有状态分布式流式处理引擎,我们会考虑到容灾问题,而且希望是精确一次的状态容错保证,因为如果修改超过了一次就意味着数据引擎产生的结果是不可靠的。于是我们开始思考以下几点问题:

  • 怎么确保状态拥有精确一次(Exactly-once guarantee)的容错保证?
  • 在分布式场景下怎么为拥有多个本地状态的operator产生grobal consistent snapshot?
  • 最重要的是,怎么在不中断的前提下持续不断地产生快照呢?

简单场景的精确一次容错方法

我们可以考虑最简单的使用场景,比如是在单一的Flink Process中进行运算,我们想到可以用“笨方法”,每处理完一笔计算就累计一次状态,进行一次快照,就能确保精确一次。

分布式状态容错

假设在分布式场景下,进行多个本地状态的运算。现在我们引入一个Checkpoint的概念,将每个Opeartor的状态保存在Checkpoint中,并且将Checkpoint传入共享的DFS中。如果任何一个Process挂掉,就可以从三个完整的Checkpoint将所有运算值得状态恢复。Checkpoint的存在使整个Process能够实现在分布式环境中的Exactly-once。

分散式快照(Distributed Snapshots)方法

关于 Flink 如何在不中断运算的状况下持续产生 Global consistent snapshot?引入Checkpoint barrier N的概念, Flink首先会在job manager触发Checkpoint,Checkpoint触发后会在 Datastream 中会安插 Checkpoint barrier N, 当数据源收到Checkpoint barrier N后会将自已的状态保存好,Checkpoint barrier N跟着数据流动到Opeartor1之后,Opeartor1也将属于Checkpoint barrier N的数据记录在状态中,同样Checkpoint barrier N流到Opeartor2,Opeartor2也会将数据反映到状态上。以上可以看到Checkpoint barrier N完成了一个完整的表格,这个表格叫做Distributed Snapshots,即分布式快照。Flink job manager 可以触发其他的Checkpoint,比如Checkpoint N + 1,Checkpoint N + 2,等也可以同步进行。真是利用这种机制,可以在不阻挡运算的状况下持续的产生Checkpoint。

状态维护

JVM Heap 状态后端:适合数量较小的状态,JVM Heap状态后端每一次运算时都要读取状态,用Java object read/writes进行读写,不会产生较大代价,但当Checkpoint需要将运算值的状态放入Distributed Snapshots时就需要进行序列化了。

RocksDB 状态后端:这是一种 out of core 的状态后端,使用者去读取状态的时候会经过磁盘,相当于将状态维护在磁盘里,与之对应的代价可能就是每次读取状态时,都需要经过序列化和反序列化的过程。

Event Time

我们要思考一个很重要的问题,Event Time怎么才能确定已经收到完整运算所需要的数据,并输出运算结果?这个时间点就是Event Time处理问题的精髓。

Flink 实际上是用 watermarks 来实现 Event Time 的功能。Watermarks其精髓在于,当某个运算值收到带有时间戳“ T ”的 watermarks时,就意味着它不会接收到新的数据了。使用 watermarks 的好处在于可以准确预估收到数据的截止时间。

状态保存与迁移

流式处理应用无时无刻不在运行,所以在运维上有几个考量:变更底层代码逻辑、修 bug 或是升级 Flink 版本,重新定义应用、计算的平行化程度等,我们该怎么保存状态进行数据迁移。

Checkpoint 完美符合以上需求,不过 Flink 中还有另外一个名词叫做Savepoint。Savepoint 跟 Checkpoint 的差别在于,检查点是 Flink 在运行中利用分布式快照持续周期性的产生 Checkpoint,而 Savepoint 则是手动产生的 Checkpoint。即当手动产生一个 Checkpoint 的时候,就叫做一个 Savepoint。

Savepoint 产生的原理是在 Checkpoint barrier 流动到所有的 Pipeline 中手动插入从而产生分布式快照,这些分布式快照点即 Savepoint。

当完成变更时,可以直接从 Savepoint 恢复、执行。当执行恢复时需要注意:在变更应用的过程中流仍在持续运行,如 Kafka 在持续收集资料,所以当从 Savepoint 恢复时,Savepoint 保存着 Checkpoint 产生的时间以及 Kafka 当时所对应的位置。所以它需要恢复到最新的数据,但无论是任何运算,Event Time 都可以确保产生的结果完全一致。

云安全日报200927:IBM企业私有云方案发现重要漏洞,需要尽快升级

上一篇

中移“校企行”专项行动 | 星辰创新营首度精彩亮相

下一篇

你也可能喜欢

有状态流式处理引擎的基石

长按储存图像,分享给朋友