Exactly Once 语义在 Flink 中的实现 ｜ 青训营笔记

用户3398530186343
102 阅读5分钟

这是我参与「第四届青训营 」笔记创作活动的第3天

1. 大数据定义

大数据的定义：高速 (Velocity) 涌现的大量 (Volume) 的多样化 (Variety) 数据。这一定义还表明大数据具有 3V 特性。

1.1 大数据的 3V 特性

大量 (Volume)大数据的“大”首先体现在数据量上。在大数据领域，您需要处理海量的低密度的非结构化数据，数据价值可能未知，例如 Twitter 数据流、网页或移动应用点击流，以及设备传感器所捕获的数据等等。在实际应用中，大数据的数据量通常高达数十 TB，甚至数百 PB。
高速 (Velocity)大数据的“高速”指高速接收乃至处理数据— 数据通常直接流入内存而非写入磁盘。在实际应用中，某些联网的智能产品需要实时或近乎实时地运行，要求基于数据实时评估和操作，而大数据只有具备 “高速” 特性才能满足这些要求。
多样化 (Variety)多样化是指可用的数据类型众多。通常来说，传统数据属于结构化数据，能够整齐地纳入关系数据库中。随着大数据的兴起，各种新的非结构化数据类型不断涌现，例如文本、音频和视频等等，它们需要经过额外的预处理操作才能真正提供洞察和支持性元数据。

2. 数据流和动态表

2.1 定义

  • 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: 计算处理逻辑的状态

2.2 传统SQL和流处理

2.2.1 数据流和动态表的转换关系

  1. 数据流和动态表之间的转换；
  2. 在数据流的查询不会终止；
  3. 查询可能会有状态，用来不断更新查询的结果。

image.png

2.2.2 在流上定义表

动态表：与表示批处理数据的静态表不同，动态表是随时间变化的。可以像查询静态批处理表一样查询它们。 数据库表是INSERT、UPDATE和DELETE DML语句的stream的结果，通常称为changelog stream。

3. Flink端到端的Exactly-once语义

3.1 一致性保证语义

  • At-most-once：每条数据消费至多一次，处理延迟低
  • At-least-once：每条数据消费至少一次，一条数据可能存在重复消费
  • Exactly-once：每条数据都被消费且仅被消费一次，仿佛故障从未发生

3.2 端到端Exactly-once语义

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

3.3 两阶段提交协议

image.png 在多个节点参与执行的分布式系统中，为了协调每个节点都能同时执行或者回滚某个事务性的操作，引入了一个中心节点来统一处理所有节点的执行逻辑，这个中心节点叫做协作者，被中心节点调度的其他业务节点叫做参与者

  1. 预提交阶段

    • 协作者向所有参与者发送一个commit消息
    • 每个参与的协作者收到消息后，执行事务，但是不真正提交
    • 若事务成功执行完成，发送一个成功的消息；执行失败，则发送一个失败的消息

  2. 提交阶段

    若协作者成功接收到所有参与者vote yes的消息

    • 协作者向所有参与者发送一个commit消息
    • 每个收到commit消息的参与者释放执行事务所需的资源，并结束这次事务的执行
    • 完成步骤二后，参与者发送一个ack消息给协作者
    • 协作者收到所有参与者的ack消息后，标识事务执行完成

    若协作者由收到参与者vote no的消息（或发生等待超时）

    • 协作者想所有参与者发送一个rollback消息
    • 每个收到rollback消息的参与者回滚事务的执行操作，并释放事务所占资源
    • 完成步骤二后，参与者发送给一个ack消息给协作者
    • 协作者收到所有参与者的ack，标识该事务成功完成回滚

3.4 Flink两阶段提交总结

  1. 事务开始：在sink task向下游写数据之前，均会开启一个事务，后续所有写数据的操作均在这个事务中执行，事务未提交前，事务写入的数据下游不可读
  2. 预提交阶段：JM开始下发Checkpoint Barrier，当各个处理逻辑接收到barrier后停止处理后续数据，对当前状态制作快照，此时sink也不在当前事务下继续处理数据（处理后续的数据需要新打开下一个事务）。状态制作成功则向JM发送成功的消息，失败则发送失败的消息
  3. 提交阶段：若JM收到所有预提交成功的消息，则向所有处理逻辑（包括sink）发送可以提交此次事务的消息，sink接收到此消息后，则完成此次事务的提交，此时下游可以督导这次事务写入的数据；若JM有收到预提交失败的消息，则通知所有处理逻辑回滚这次事务的操作，此时sink则丢弃这次事务提交的数据。

总结

  1. 数据流可以转换成动态表，动态表也能重新转换成数据流;
  2. 处理无限数据流的算子可以是有状态的;
  3. Flink通过Checkpoint机制实现故障前后的状态快照制作和恢复;
  4. 支持两阶段提交协议的下游存储可以结合Flink Checkpoint机制实现严格意义上端到端的Exactly-Once语义实现;

参考

  1. 【大数据专场 学习资料一】第四届字节跳动青训营 - 掘金 (juejin.cn)
  2. 大数据是什么？| Oracle 中国
  3. 概述 |Apache Flink
avatar
文章
阅读
粉丝