zoukankan      html  css  js  c++  java
  • Flink 应用的一致性保障

    应用一致性保障

    在Flink中,会自动做检查点,用于故障时恢复一个应用。在恢复时,application的state信息可以根据最近完成的检查点进行重建,并继续运行。不过,仅将一个application的state进行重置并不足以满足exactly-once的保证。

    为了给一个应用提供exactly-once保证,在应用根据检查点重置state时,它的每个source connector都应该有能力将它的read position重置到做检查点时的read position。在做一个检查点时,source operator将它的read position也持久化,并在恢复时根据此位置进行重置。对于这类可以重置read position的source connector,比较有代表性的有:

    1. 基于文件的源:可以存储读文件字节流时的偏移量
    2. Kakfa:可以存储读入topic partition的偏移量

    如果一个application从一个无法重置read position的source connector读数据,则在故障发生并恢复时,只能提供at-most-once 的保证。

    Flink的检查点与恢复机制、结合可重置reading position的source connector,可以确保一个应用不会丢失任何数据。但是,此应用仍可能输出同一数据两次。因为若是应用故障发生在两次检查点之间,则必定会导致已经成功输出的数据再次输出一次。所以仅通过Flink与source connector的行为,并不足以提供端到端的exactly-once保证,即使application的state具有exactly-once的保证。

    一个application若是需要提供端到端exactly-once 的保证,则需要特殊的sink connectors。对于sink connectors来说,有两种技术可以应用于不同的场景,用于达到exactly-once的保证,分别为:idempotent writes、以transactional writes。

    Idempotent Writes

    一个idempotent 操作可被执行多次,但是仅会产生一个变化。例如向一个hashmap中插入同样的key-value pair,这即为一个idempotent操作。因为仅有第一次操作会在hashmap中增加此条目,而之后的插入不会改变hashmap中的内容。一个非 idempotent 操作的例子如追加操作,即使是同样的数据,每次追加都会增加一条数据。在流应用中,idempotent write是一个很有特点的操作,它们可以多次执行,但并不改变最终的结果。所以在Flink根据检查点机制进行恢复时,可以在一定程度上缓解replay对结果造成的影响(或是没有影响)。

    需要注意的是,若是一个应用依赖于idempotent sinks,以达到exactly-once 的结果,则必须保证的是:在replay时覆盖之前写的结果。一般来说,只要流应用在replay时正常执行并输出,在新的输出覆盖掉之前写的结果后,即可以正常到达一致状态。

    Transactional Writes

    第二种实现端到端exactly-once 一致性的方法是基于transactional writes。这个方法基于的想法是:仅在最近一个检查点成功完成后,才将所有结果写入到一个外部的sink系统。这个行为可以实现端到端exactly-once的原因是因为:在故障发生时,应用会被重置到最近的检查点,并且在此检查点之后,没有任何结果被写入到外部sink系统。但是此方法会增加延时,因为结果仅能在一个检查点完成后才能看到。

    Flink提供了两种方式分别实现transactional sink connectors – 一个通用的 write-ahead-log(WAL
    以及一个two-phase-commit(2PC)sink。WAL sink将所有result records写入应用的state,并在它收到了一个“检查点完成”的通知后,将结果输出到sink 系统。因为WAL sink会将result records缓存到state backend,所以它可以用于任何sink 系统中。然而,使用此方法实现的exactly-once仍会有些代价:增加了应用的state大小,并且sink 系统需要处理突增写入的模式。

    与WAL不同的是,2PC sink需要sink system提供事务支持,或者提供模拟事务的支持。对于每个检查点,sink首先启动一个事务,将所有接收到的记录添加到事务中,并将它们写入sink系统,但是不提交(commit)。当它收到一个“检查点完成”的通知后,它提交事务,并将结果落盘。

    2PC协议集成在Flink的检查点机制中。Checkpoint barriers便是启动一个新事务的通知,所有operators中对于它“自身检查点完成”的通知,即是它们的commit 投票。JobManager的对于“整个检查点完成”的消息,即为提交事务的指示。

    相对于WAL sinks,2PC sinks是基于sink 系统以及sink的实现方式,达到exactly-once的输出保障。而 相对于WAL sink的突增写入模式,2PC sink为持续向sink 系统写入记录。

    下表展示的是对于不同类型的source与sink connectors,在最优的情况下是否可以达到端到端exactly-once保障的对比(根据sink的实现不同,真正的一致性可能会更差):

     

    References

    Vasiliki Kalavri, Fabian Hueske. Stream Processing With Apache Flink. 2019

  • 相关阅读:
    火狐插件火狐黑客插件将Firefox变成黑客工具的七个插件
    memcache安装环境:WINDOWS 7
    PHP正则表达式
    968. 监控二叉树 力扣(困难) dfs 官方说DP
    375. 猜数字大小 II 力扣(中等) 区间动态规划、记忆化搜索
    629. K个逆序对数组 力扣(困难) 区间动态规划
    剑指 Offer 51. 数组中的逆序对 力扣(困难) 巧用归并排序算法
    488. 祖玛游戏 力扣(困难) dfs
    16. 最接近的三数之和 力扣(中等) 双指针
    319. 灯泡开关 力扣(中等) 数论
  • 原文地址:https://www.cnblogs.com/zackstang/p/11824221.html
Copyright © 2011-2022 走看看