Exactly Once(不丢不重)语义在Flink中的实现

最新推荐文章于 2025-06-02 09:17:13 发布
最新推荐文章于 2025-06-02 09:17:13 发布
阅读量679 收藏
点赞数
CC 4.0 BY-SA版权
文章标签： flink
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/cblock1/article/details/126050993
本文介绍了Apache Flink如何实现Exactly-Once语义，详细阐述了数据流和动态表的概念，状态快照与恢复机制，以及端到端的Exactly-once实现，包括两阶段提交协议在Flink中的应用。此外，还探讨了Flink在账单计算服务中的使用，展示了其在处理数据一致性上的优势。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

一、内容介绍

数据流和动态表

  • Stream: 数据流
  • Dynamic Table: 动态表
  • Continuous Queries: 连续查询
  • Append-only Stream: Append-only 流（只有 INSERT 消息）
  • Retract Stream: Retract 流（同时包含 INSERT 消息和 DELETE 消息）
  • Upsert Stream: Upsert 流（同时包含 UPSERT 消息和 DELETE 消息）
  • Changelog: 包含 INSERT/UPDATE/DELETE 等的数据流
  • State: 计算处理逻辑的状态

Exactly-Once 和 Checkpoint

  • Application Consistency Guarantees: 作业一致性保证
    • At-most-once：每条数据消费至多一次（出现故障啥也不做）
    • At-least-once：每条数据消费至少一次（可能存在重复消费）
    • Exactly-once: 每条数据都被消费且仅被消费一次（仿佛故障从未发生）
  • Checkpoint: Flink 实现各个计算逻辑状态快照算法，也可指一次状态快照
  • Checkpoint barrier: 用于标识状态快照的制作，也将数据划分成不同的消费区间
  • Checkpoint Alignment: 等待多个上游的Checkpoint barrier到达的现象
  • JobManager: 负责协调和管理 Checkpoint

端到端 Exactly-Once 实现

  • Two-phase commit protocol: 两阶段提交协议
  • Transaction: 一系列保证原子性操作的集合，即操作同时执行或者都不执行
  • Kafka: 消息中间件
  • State Backend: 用于管理和保存状态到远端可靠存储

Flink 案例讲解

  • Deduplication：去重，在 state 保留的时间内对重复消息进行去重
  • Aggregation：聚合操作，比如求和、求最大值等

二、数据流和动态表

如何在数据流上执行SQL语句，说明流式处理中状态的概念

    简介：动态表是数据流的SQL表达

2.1数据流和动态表转换

  • Stream: 数据流
  • Dynamic Table: 动态表
  • Continuous Queries: 连续查询
  • State 状态

流到动态表

最低0.47元/天 解锁文章

200万优质内容无限畅学
Popcorn丶30
关注
Flink 实时数据一致性与 Exactly-Once 语义保障实战
晴天彩虹雨的博客
05-10 640
本篇将围绕如何实现端到端的数据一致性、如何正确使用 Checkpoint、状态管理、Sink 的幂等性控制，以及与 Kafka / OLAP 系统的写入一致性设计进行详解
flink实现exactly-once
a3125504x的博客
11-08 856
flink实现exactly-once前言 前言 exactly-once，即实现一次且仅一次。可分为框架内实现和端对端实现。
Flink实现Exactly Once
zwyoozwz的博客
07-29 2951
flink中的exactly once
Flink Exactly-Once 投递实现浅析
公众号[大数据技术与应用实战]，分享大数据实战案例
02-18 2033
  转载自：http://www.whitewood.me/2018/10/16/Flink-Exactly-Once-%E6%8A%95%E9%80%92%E5%AE%9E%E7%8E%B0%E6%B5%85%E6%9E%90/ 随着近来越来越多的业务迁移到 Flink 上，对 Flink 作业的准确性要求也随之进一步提高，其中最为关键的是如何在不同业务场景下保证 exactly-once ...
Flink 实战：深入理解 Exactly Once 语义保障机制
最新发布
gitblog_00457的博客
06-02 244
Flink 实战：深入理解 Exactly Once 语义保障机制 一、Exactly Once 语义的核心价值 在分布式流处理系统中，Exactly Once（精确一次）语义是数据处理的重要保障机制。它确保每条数据在系统中只会被精确处理一次，即使在发生故障的情况下也不会出现数据丢失或重复处理的问题。这对于金融交易、精准营销等对数据准确性要求极高的场景至关重要。 二、Flink 内部 Exactl...
Flink Exactly Once
技术大神之路
06-03 279
Flink Exactly Once Flink Exactly Once 语意是基于Chandy-Lamport这个算法的思想的改进版，引入了barrier，可以在不停止整个流处理系统的前提下，保存和恢复每个subtask的snapshot，让每个节点独立地做状态保存和恢复。 Chandy-Lamport 算法 Initiating a snapshot: 也就是开始创建 snapshot，可以由系统中的任意一个进程发起 Propagating a snapshot: 系统中其他进程开始逐个创建 sna
exactly-once在Flink里的实现
zhaicheng55的博客
09-05 1272
动态表:与表示批处理数据的静态表不同，动态表是随时间变化的。可以像查询静态批处理表一样查询它们。数据库表是INSERT、UPDATE和DELETE DML语句的stream 的结果，通常称为changelog stream.当插入更多的流是，表会不断增长。
Flink端到端的精确一次（Exactly-Once）
大头皮鞋的博客
06-04 3335
Flink端到端的精确一次。
Flink Exactly-Once语义实现原理：大数据精准处理
AI天才研究院
05-04 782
在实时流处理场景中，数据以无限流的形式持续产生，系统需要在分布式、高并发、故障频发的环境下保证数据处理的准确性。Flink的Exactly-Once语义承诺每个输入事件仅会被处理一次并产生唯一确定的结果，这对于金融交易、实时对账、物联网监控等对数据准确性要求极高的场景至关重要。本文将深入解析Flink实现Exactly-Once语义的核心技术，包括分布式快照（Checkpoint）机制水印（Watermark）事件时间处理。
Apache Flink 如何保证 Exactly-Once 语义
06-12 1304
Apache Flink 通过状态一致性检查点和 Two-Phase Commit 协议来确保 Exactly-Once 语义。这些机制确保了数据在分布式系统中的一致性和准确性，从而提高了大数据处理的可靠性和准确性。在实际应用中，我们可以根据具体需求配置 Flink 的检查点策略和外部存储系统的写入策略，以实现更好的性能和可靠性。
Flink的端对端精准一次处理（Exactly-Once）
落幕7的博客
11-27 3725
端对端精准一次处理 Two-Phase Commit(两阶段提交协议)两阶段提交Flink中应用
Flink状态一致性之exactly-once
LSur_king的博客
04-05 1557
幂等写入： 一个操作重复执行很多次，但只导致一次结果的更改，也就是说后面重复执行就不起作用了。eg: pow(e,x)求多阶导还等于自己，HashMap，多次写入key相同的键值对等。 但需要注意的是，也会出现中间状态短暂的不一致，最终结果一致的情景。eg：flink的checkpoint还有流批结合做关联模型转换的ETL，这些不满足强一致性，但可实现最终一致性。 事务写入： 构建的事务对应着checkpoint，等到checkpoint真正完成的时候，才把所有对应的结果写入sink系统...
Flink exactly-once 实战笔记
大JAVA解决方案
04-01 438
Flink-Kafka 众所周知，Flink在很早的时候就通过Checkpointing提供了exactly-once的semantic，不过仅限于自身或者是从KafkaConsumer中消费数据。而在Flink 1.4版本的时候加入了赫赫有名的TwoPhaseCommitSinkFunction，提供了End-to-End的exatcly-once语言，当然是在需要下游支持回滚的情...
Flink Exactly-once 实现原理解析
qianyulin
10-24 1878
通常情况下，流式计算系统都会为用户提供指定数据处理的可靠模式功能，用来表明在实际生产运行中会对数据处理做哪些保障，Flink提供了Exactly-once语义来保障我们的流任务数据处理的精准一致性
Flink详解Exactly-Once机制
长臂人猿的博客
06-29 2993
前言 ​ 通常情况下，流式计算系统都会为用户提供指定数据处理的可靠模式功能，用来表明在实际生产运行中会对数据处理做哪些保障。一般来说，流处理引擎通常为用户的应用程序提供三种数据处理语义：最多一次、至少一次和精确一次。 最多一次（At-most-Once）：用户的数据只会被处理一次，不管成功还是失败，不会重试也不会重发。 至少一次（At-least-Once）：系统会保证数据或事件至少被处理一次。如果中间发生错误或者丢失，那么会从源头重新发送一条然后进入处理系统，所以同一个事件或者消息会被处理多次。
flink 实现端到端的exactly-once语义
weixin_44844089的博客
05-26 806
文章目录1. 三种语义介绍2. Exactly-Once实现的三个地方3. 具体实现过程3.1 source阶段3.2 operator阶段3.3 sink阶段4. 两段式提交的具体实现 1. 三种语义介绍 通常情况下，流式计算系统都会为用户提供数据处理的可靠模式功能，用来表明在实际生产运行中会对数据处理做哪些保障。一般来说，流处理引擎通常为用户的应用程序提供三种数据处理语义：最多一次，至少一次和精确一次。 最多一次（At-most-Once）：这种语义理解起来很简单，用户的数据只会被处理一次，不管成功还
Flink保证数据不丢失不重复、状态一致性
博客
11-05 5924
如图：奇数和偶数分流分别计算 概念 计算结果要保证准确。 一条数据不应该丢失，也不应该重复计算。 遇到故障时可以恢复状态，恢复以后的重新计算结果应该也是完全正确的。 状态一致性分类（级别） AT-MOST-ONCE（最多一次） 当任务故障时，最简单的做法是什么都不干，既不恢复丢失的状态，也不重播丢失的数据。即最多处理一次事件。 AT-LEAST-ONCE（至少一次） （不能保证数据不被重复处理） 在大多数真实应用场景，我们希望不丢事件。但是有些事件还可能被处理多次。 ...
硬核！一文搞懂Flink的checkPoint的exactly-once（好文收藏）
weixin_45857425的博客
06-14 682
Flink的checkPoint原理 1.知识前置 Flink检查点算法：检查点分界线（Checkpoint Barrier） Flink 的检查点算法用到了一种称为分界线（barrier）的特殊数据形式，用来把一条流上数据按照不同的检查点分开。 2.正文开始 *2.1.*JobManager 会向每个 source 任务发送一条带有新检查点 ID 的消息，通过这种方式来启动检查点，检查点分界线由 source 算子注入到常规的数据流中，它的位置是限定好的，不能超过其他数据，也不能被后面的数据超过。 *2
大数据Flink--详细的Exactly Once 语义在 Flink 中的实现
qq_61189986的博客
07-28 649
1.1随处可见的流式数据1.2传统SQL和流处理特征SQL流处理处理数据的有界性处理的表是有界的流是一个无限元组序列处理数据的完整性执行查询可以访问完整的数据执行查询无法访问所有的数据执行时间批处理查询产生固定大小结果后终止查询不断更新结果，永不终止1.3数据流和动态表转换动态表与表示批处理数据的静态表不同，动态表是随时间变化的。可以像查询静态批处理表一样查询它们。(1)数据流和动态表之间的转换；(2)在数据流的查询不会终止；(3)查询可能会有状态，用来不断更新查询的结果。...
解释Exactly-Once语义在 Kafka+Flink 中的实现原理
03-16
<think>嗯，用户想了解Exactly-Once语义在Kafka加Flink中的实现原理。首先，我需要回忆一下Exactly-Once的基本概念，确保自己理解正确。Exactly-Once指的是每个消息被处理且仅被处理一次，即使在系统出现故障的情况下也是如此。这对流处理系统来说非常重要，尤其是在金融或数据分析等关键领域。 接下来，用户可能已经知道Kafka是消息队列，Flink是流处理框架，但需要了解两者如何协同实现Exactly-Once。可能需要分步骤解释，先从整体架构入手，再深入各个组件的作用。 我记得Flink的Checkpoint机制是关键，它基于Chandy-Lamport算法，定期保存状态。但需要详细说明Checkpoint如何与Kafka的offset结合，确保状态和offset的一致性。同时，两阶段提交协议（2PC）在这里的应用，比如Flink的JobManager协调各个Sink端提交事务，确保输出端的一致性。 然后，Kafka本身作为Source和Sink时的不同处理。作为Source时，Flink通过Checkpoint记录offset，故障恢复时从记录的offset重新消费。作为Sink时，可能需要使用Kafka的事务功能，比如开启事务写入数据，在Checkpoint完成时提交事务。 需要注意用户可能混淆Exactly-Once的不同层面，比如处理过程中的Exactly-Once和端到端的Exactly-Once。需要明确Flink内部通过Checkpoint保证状态一致性，而端到端则需要Source和Sink的支持。比如Kafka作为Source时，结合offset提交；作为Sink时，使用事务或幂等写入。 可能存在的误区是认为仅Flink或仅Kafka就能实现端到端Exactly-Once，但实际上需要两者的配合。此外，需要提到Flink的版本，比如从某个版本开始支持两阶段提交，以及Kafka需要0.11以上版本支持事务。 还需要考虑用户可能对技术细节感兴趣，比如分布式快照的具体实现，或者如何处理网络分区、故障恢复的具体步骤。但根据用户的问题，可能不需要过于深入，但需要覆盖关键点。 另外，用户可能想知道实际应用中如何配置，比如Flink的配置参数，Kafka的生产者配置，但问题更关注原理而非实操，所以可能需要简要提及配置方向，但重点放在机制上。 最后，总结实现原理的几个关键点：Checkpoint机制、两阶段提交、Kafka的事务支持，以及它们在端到端流程中的协作。确保逻辑清晰，步骤明确，让用户能够理解各组件如何协同工作来保证Exactly-Once语义。</think>Exactly-Once语义在Kafka+Flink中的实现原理可拆解为三个核心机制协作完成： #### 一、分布式快照（Checkpoint） $$ \text{Checkpoint周期} = \text{状态持久化} + \text{offset标记} $$ 1. **Chandy-Lamport算法**驱动Flink定期生成全局一致的快照 2. 快照包含： - 算子状态（如窗口聚合结果） - Kafka消费偏移量（通过`FlinkKafkaConsumer`记录） 3. 恢复时从最近完整快照重建状态+重新消费对应offset #### 二、两阶段提交协议（2PC） $$ \text{事务提交} = \text{预提交阶段} + \text{最终提交阶段} $$ 1. **JobCoordinator**作为事务协调器 2. 每个Checkpoint周期对应一个事务： - **预提交**：所有算子完成状态保存，Sink暂存数据（如写入Kafka事务） - **提交**：收到所有算子的ACK后，提交外部系统事务 #### 三、Kafka端到端保障 $$ \text{Exactly-Once} = \text{幂等生产} + \text{事务隔离} $$ 1. **生产者端**： - 启用`enable.idempotence=true`（防止重复写入） - 使用事务API（`producer.initTransactions()`） 2. **消费者端**： - 配合`isolation.level=read_committed`（仅读取已提交数据） #### 四、完整工作流程示例 1. Flink启动Checkpoint（Barrier随数据流传播） 2. Sink算子将数据写入Kafka事务（状态为`PRE-COMMIT`） 3. Checkpoint完成时： - 提交Kafka事务（`COMMIT`） - 记录offset到持久化存储 4. 故障恢复时： - 回滚未提交的Kafka事务 - 从最近Checkpoint重建状态+重新消费 #### 五、关键配置项 ```java // Flink配置 env.enableCheckpointing(60000); // 1分钟间隔 env.getCheckpointConfig().setCheckpointingMode(ExactlyOnce); // Kafka生产者 props.put("enable.idempotence", "true"); props.put("transactional.id", "flink-job-01"); ``` > **注意事项**： > 1. Kafka需0.11+版本支持事务 > 2. 事务ID必须唯一且稳定 > 3. 网络超时设置需大于Checkpoint间隔 这种设计通过状态一致性保障（Checkpoint）、分布式事务协调（2PC）和消息系统特性（Kafka事务）的协同，最终实现从数据读取、处理到写入的全链路Exactly-Once语义。
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值