• Flink的Exactly-Once、状态机制、watermark机制


    两段提交保证Exactly-Once

    Flink 可以通过实现两阶段提交和状态保存来实现端到端的一致性 语义。 分为以下几个步骤:
    1)开始事务(beginTransaction)创建一个临时文件夹,来写把数据写入到这个文件夹 里面
    2)预提交(preCommit)将内存中缓存的数据写入文件并关闭
    3)正式提交(commit)将之前写完的临时文件放入目标目录下。这代表着最终的数据 会有一些延迟
    4)丢弃(abort)丢弃临时文件
    5)若失败发生在预提交成功后,正式提交前。可以根据状态来提交预提交的数据,也 可删除预提交的数据。

    Flink 状态机制

    Flink 提 供 了 三 种 状 态 存 储 方 式 : MemoryStateBackend 、 FsStateBackend 、 RocksDBStateBackend。

    MemoryStateBackend:

    1 基于内存的状态管理器,聚合类算子的状态会存储在JobManager的内存中
    2 单次状态大小默认最大被限制为5MB,可以通过构造函数来指定状态初始化内存大小。无论单次状态大小最大被限制为多少,都不可大于akka的frame大小(1.5MB,JobManager和TaskManager之间传输数据的最大消息容量)。状态的总大小不能超过 JobManager 的内存。
    3 是Flink默认的后端状态管理器,默认是异步的
    4 主机内存中的数据可能会丢失,任务可能无法恢复
    5 将工作state保存在TaskManager的内存中,并将checkpoint数据存储在JobManager的内存中

    适用:

    本地开发和调试
    状态比较少的作业
    
    • 1
    • 2

    FsStateBackend:

    1 基于文件系统的状态管理器
    2 如果使用,默认是异步
    3 比较稳定,3个副本,比较安全。不会出现任务无法恢复等问题
    4 状态大小受磁盘容量限制
    5 将工作state保存在TaskManager的内存中,并将checkpoint数据存储在文件系统中

    适用:

    状态比较大,窗口比较长,大的KV状态
    
    • 1

    RocksDBStateBackend:

    1 状态数据先写入RocksDB,然后异步的将状态数据写入文件系统。
    2 正在进行计算的热数据存储在RocksDB,长时间才更新的数据写入磁盘中(文件系统)存储,体量比较小的元数据状态写入JobManager内存中(将工作state保存在RocksDB中,并且默认将checkpoint数据存在文件系统中)
    3 支持的单 key 和单 value 的大小最大为每个 2^31 字节(2GB)
    4 RocksDBStateBackend是目前唯一支持incremental的checkpoints的策略
    5 如果使用,默认是异步

    适用:

    非常大的状态,长窗口,大的KV状态
    增量checkpoint
    
    • 1
    • 2

    Watermark 机制

    Watermark 是一种衡量 Event Time 进展的机制,可以设定延迟触发
    Watermark 是用于处理乱序事件的,而正确的处理乱序事件,通常用 Watermark 机制 结合 window 来实现;
    数据流中的 Watermark 用于表示 timestamp 小于 Watermark 的数据,都已经到达了, 因此,window 的执行也是由 Watermark 触发的。

    分布式快照的原理

    Flink 的容错机制的核心部分是制作分布式数据流和操作算子状态的一致性快照。 这些 快照充当一致性 checkpoint,系统可以在发生故障时回滚。 Flink 用于制作这些快照的机制 在“分布式数据流的轻量级异步快照”中进行了描述。 它受到分布式快照的标准 Chandy-Lamport 算法的启发,专门针对 Flink 的执行模型而定制。
    在这里插入图片描述

    barriers 在数据流源处被注入并行数据流中。快照 n 的 barriers 被插入的位置(我们称之 为 Sn)是快照所包含的数据在数据源中最大位置。
    例如,在 Apache Kafka 中,此位置将是分区中最后一条记录的偏移量。 将该位置 Sn 报告给 checkpoint 协调器(Flink 的 JobManager)。
    然后 barriers 向下游流动。当一个中间操作算子从其所有输入流中收到快照 n 的 barriers 时,它会为快照 n 发出 barriers 进入其所有输出流中。
    一旦 sink 操作算子(流式 DAG 的末端)从其所有输入流接收到 barriers n,它就向 checkpoint 协调器确认快照 n 完成。
    在所有 sink 确认快照后,意味快照着已完成。一旦完成快照 n,job 将永远不再向数据 源请求 Sn 之前的记录,因为此时这些记录(及其后续记录)将已经通过整个数据流拓扑, 也即是已经被处理结束

  • 相关阅读:
    linux驱动工作原理
    生鲜赛道溃败中存活的本来生活,纠结生存
    C++ Tutorials: C++ Language: Classes: Friendship and inheritance
    斯坦福机器学习 Lecture2 (假设函数、参数、样本等等术语,还有批量梯度下降法、随机梯度下降法 SGD 以及它们的相关推导,还有正态方程)
    电气工程中matlab程序拉格朗日松弛算法
    来自北大算法课的Leetcode题解:189. 轮转数组
    10、Python函数命名空间、作用域(LEGB)及Global
    Netty 学习(五):服务端启动核心流程源码说明
    大数据实训项目(小麦种子)-02、实训项目整体功能介绍与演示
    快手本地生活服务商系统怎么操作?
  • 原文地址:https://blog.csdn.net/u011095039/article/details/126080954