Flink/Blink 原理漫谈（一）时间，watermark详解

最新推荐文章于 2025-10-30 15:05:34 发布
原创 最新推荐文章于 2025-10-30 15:05:34 发布 · 1.5k 阅读 · 7 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#blink #flink #大数据 #实时大数据 #sql

本文深入探讨Flink/Blink中的时间概念，包括Event Time、Ingestion Time和Processing Time。重点讲解Watermark机制，用于处理数据乱序问题，保证Event Time的一致性。通过实例解释Watermark如何触发窗口关闭，以及在多流处理中的单调递增策略。

系列文章目录

Flink/Blink 原理漫谈（零）运行时的组件

Flink/Blink 原理漫谈（一）时间，watermark详解

Flink/Blink 原理漫谈（二）流表对偶性和distinct详解

Flink/Blink 原理漫谈（三）state 有状态计算机制 详解

Flink/Blink 原理漫谈（四）window机制详解

Flink/Blink 原理漫谈（五）流式计算的持续查询实现 详解

Flink/Blink 原理漫谈（六）容错机制（fault tolerance）详解

文章目录

一、 时间

一共有三种时间：event time，ingestion time，processing time

Event time：事件发生的时间
Ingestion time：数据进入flink的时间
Processing time：执行操作算子的本地系统时间
在这里插入图片描述
Watermark就是基于Event Time产生的，Blink系统正是利用Event Time和Watermark机制处理数据乱序问题的。Processing Time并不能提供确定性，因为它容易受到Event到达系统的速度（例如来自消息队列）以及记录在Blink系统内部的处理先后顺序的影响。Ingestion Time在概念上位于Event Time和Processing Time之间。

目前Blink SQL 层面向用户开发的时间类型是 Event Time和Processing Time.

二、 watermark

概念

通常来说，数据都是按照event time进入operator中的，但是由于分布式，网络延迟等等原因，先发生的事情反而会在后面传入。
在这里插入图片描述
这就出问题了啊，如果我们只是根据event time来决定是否关闭当前窗口，就可能永远也无法知道什么时候应该关闭当前窗口，因为我们总是无法明确什么时候，当前窗口的所有数据都到位了。这时候就要引入watermarks的概念。

很多网上的文章描述的wa

最低0.47元/天 解锁文章
Flink的Blink计划：深度解析
AI天才研究院
02-18 490
1. 背景介绍 1.1 Apache Flink简介 Apache Flink是一个开源的流处理框架，用于实时数据流处理和批处理应用程序。Flink具有高吞吐量、低延迟和强大的状态管理功能，使其成为大数据处理的理想选择。Flink的核心是一个分布式流数据处理引擎，它可以在各种环境中运行，
Flink分支——Blink的第一次使用
qq_39193541的博客
06-19 4014
Flink分支——Blink的第一次使用 Blink今年年初的时候开源了~ 作为一个跟风小菜鸟，也想跟紧各大佬的步伐，研究下Blink呢。以下是自己在安装编译测试时的步骤和小小心得，与大家共勉。 Blink其实就是Flink的一个分支。他是由阿里巴巴集团基于Flink自主研发的。Flink后期可能会（也许ing）将Blink合并到master上。Flink其实主要就是处理两种数据类型：流（Data...
Flink SQL 实时分析：创建动态表与 Watermark 配置（延迟数据处理方案）
最新发布
2501_93893986的博客
10-30 378
/ 自定义 Watermark 策略（Java 示例）优势支持动态延迟调整可结合数据特征（如分区延迟差异）
使用flink(blink)进行用户行为分析
xiaofeixia__9999的专栏
08-02 954
##Blink Blink是阿里云在Apache Flink基础上深度改进的实时计算平台，同Flink一致Blink旨在将流处理和批处理统一，但Blink相对于社区版Flink，在稳定性上有很多优化，在某些场景特别是在大规模场景会比Flink更加稳定。Blink的另一个重大改进是实现了全新的 Flink SQL 技术栈，在功能上，Blink支持现在标准 SQL 几乎所有的语法和语义，在性能上，Bl...
终于等到你！阿里正式向 Apache Flink 贡献 Blink 源码
阿里技术
01-28 1191
阿里妹导读：如同我们去年12月在 Flink Forward China 峰会所约，阿里巴巴内部 Flink 版本 Blink 将于 2019 年 1 月底正式开源。今天...
官宣！阿里Blink和Flink合并计划出炉
weixin_34418883的博客
02-15 403
apache已公开合并计划，点击可阅读原文《Batch as a Special Case of Streaming and Alibaba's contribution of Blink》，由AI前线进行了翻译。 **春节前一周，经过社区内部讨论，阿里巴巴大数据引擎 Blink 作为 Flink 的分支 正式开源。今天，Apache ...
Flink/Blink 原理漫谈（四）window机制详解
Foools的博客
02-02 1233
系列文章目录 文章目录系列文章目录window机制Group by windowTumbling window 滑动窗口Hop window 滑动窗口Session window 会话窗口OVER WINDOWROWS OVER WindowRange over window window机制 Blink-1.x版本的window内容 有一些比较基本的group by概念我觉得不需要陈述了，主要需要介绍的是两个类型：group by window和over window。 Group by windo
Flink/Blink 原理漫谈（三）state 有状态计算机制 详解
Foools的博客
02-02 1275
系列文章目录 文章目录系列文章目录StateState存储实现State的分类状态一致性端到端的一致性总结 State 首先，blink是有状态计算的，State是流计算特有的，流计算在 大多数场景 下是增量计算，数据逐条处理（大多数场景)，每次计算是在上一次计算结果之上进行处理的，这样的机制势必要将上一次的计算结果进行存储（生产模式要持久化），另外由于 机器，网络，脏数据等原因导致的程序错误，在重启job时候需要从成功的检查点(checkpoint，后面篇章会专门介绍)进行state的恢复。增量计算
Flink/Blink 原理漫谈（五）流式计算的持续查询实现 详解
Foools的博客
02-02 1450
系列文章目录 文章目录系列文章目录持续查询静态查询和动态查询的关系持续查询的实现增量计算：APPEND ONLY场景UPDATE 场景无PK的Append Only 场景有PK的Update 场景Blink store双流join中遇到的append only的问题Blink Sink 持续查询 静态查询和动态查询的关系 传统数据库表我们这里叫Static table，是指在查询的那一刻数据库表的内容不再变化了，查询进行一次计算完成之后表的变化也与本次查询无关了，我们将在Static Table 上面
Flink Watermark详解
王小工小工历程
06-04 2030
Watermark 是用于处理流数据中事件时间（event time）乱序情况的重要机制。在流处理中，数据往往不是按照它们实际发生的时间顺序到达的，这可能是由于网络延迟、系统处理延迟或其他因素导致的。为了能够在这种乱序环境中正确地执行基于时间的操作（如时间窗口聚合），Flink 引入了 Watermark 的概念。Watermark 是一个特殊的标记，它表示“在此时间戳之前的数据应该都已经到达了”。
Blink 漫谈系列 - HelloWorld
weixin_34247299的博客
07-13 320
眼见为实 目前我们概要了解了Blink的强大与宏伟目标(世界一流),但我们相信任何事物的发展都要符合自然规律，一颗小树要长成参天大树要上百年，我们的马老师今天能为亿万人民创造工作，经历近20年，Blink也一样其宏伟目标的实现，需要时间的沉淀，智慧的积累。 用户在给予Blink成长时间的同时也应该体会到Blink亲民的点滴，本篇以HelloWorl...
新一代实时计算领域Flink独树一帜，你知道Blink的关系吗
weixin_61711369的博客
01-22 370
知识分享
Flink系列之Time和WaterMark
kkkkk0826的专栏
01-11 513
　　当数据进入Flink的时候，数据需要带入相应的时间，根据相应的时间进行处理。 　　让咱们想象一个场景，有一个队列，分别带着指定的时间，那么处理的时候，需要根据相应的时间进行处理，比如：统计最近五分钟的访问量，那么就需要知道数据到来的时间。五分钟以内的数据将会被计入，超过五分钟的将会计入下一个计算窗口。 　　那么Flink的Time分为三种： 　　ProcessingTime ： 处理时间...
漫谈加持Blink的Flink和Spark
allwefantasy的专栏
01-28 519
前言 今天朋友圈有篇【阿里技术】发的文章，说Blink的性能如何强悍，功能现在也已经比较完善。譬如： Blink 在 TPC-DS 上和 Spark 相比有着非常明显的性能优势，而且这种性能优势随着数据量的增加而变得越来越大。在实际的场景这种优势已经超过 Spark 三倍，在流计算性能上我们也取得了类似的提升。我们线上的很多典型作业，性能是原来的 3 到...
Flink/Blink 原理漫谈（零）运行时的组件
Foools的博客
02-02 6050
系列文章目录 文章目录系列文章目录前言 谈谈blink和flinkBlink原理漫谈零、 Flink运行时的组件JobManagerTaskManagerResourceManagerDispatcher任务提交流程 前言 谈谈blink和flink 在实习时候接触到了flink，这玩意实现了大促期间的实时大数据更新，这对我们这种只写过python，c++啥玩意的来说闻所未闻，所以了解了一下flink的原理，并且尝试使用了公司的blink，在学习时间之余，整理了所有的学习笔记，目的也是分享学习。 A
Flink之乱序处理,时间语义,WaterMark,允许迟到数据,侧输出流
jason_bone_的博客
02-19 3345
一.理解Flink的乱序问题 理解Flink的乱序问题,的先理解Flink的时间语义. Flink有3中时间语义: Event Time：事件创建的时间 Ingestion Time：数据进入Flink的时间,后续版本好像这个时间语义.也就不讨论了. Processing Time：执行操作算子的本地系统时间，与机器相关.(Event Time的使用,必须配合WaterMark) Flink的时间语义的使用,需要搭配window机制.没有window开窗也就不存在乱序问题.
Flink之Watermark实践
sxiaobei的博客
07-21 6463
我们知道实时计算中，数据时间比较敏感，有eventTime和processTime区分，一般来说eventTime是从原始的消息中提取过来的，processTime是Flink自己提供的，Flink中一个亮点就是可以基于eventTime计算，这个功能很有用，因为实时数据可能会经过比较长的链路，多少会有延时，并且有很大的不确定性，对于一些需要精确体现事件变化趋势的场景中，单纯使用processTi...
Blink和Flink社区近况
Baron_ND的博客
09-14 976
聊聊Blink开源和Flink社区近况 前几天 Blink 开源的消息刷了朋友圈，因为笔者一直关注着社区的发展。所以今天想从我个人的角度来聊聊 Blink 开源，社区 merge Blink 的计划，以及最近发生的一些很有意义的事情。 Blink 开源 这次 Blink 开源的主要目的是让社区的开发者们能尽早地尝试一些他们感兴趣的功能与改进。我觉得最核心的贡献包括： Stream SQL 的新功能和性能优化：如维表Join、TopN、支持迟到数据和提早输出的Window、有效解决Agg数据倾斜问题等
Hadoop、spark、Flink、Blink、storm介绍
影子
03-08 1825
1、什么是hadoop（搭建集群） Hadoop是由java语言编写的，在分布式服务器集群上存储海量数据并运行分布式分析应用的开源框架，其核心部件是HDFS与MapReduce。 HDFS是一个分布式文件系统：引入存放文件元数据信息的服务器Namenode和实际存放数据的服务器Datanode，对数据进行分布式储存和读取。 MapReduce是一个计算框架：MapReduce的核心思想是把计算任务分配给集群内的服务器里执行。通过对计算任务的拆分（Map计算/Reduce计算）再根据任务调度器（JobT
NuttX中如何通过`flink/blink`实现优先级继承机制？
08-27
<think>我们正在讨论NuttX中TCB的flink和blink指针如何用于实现优先级继承机制。优先级继承是一种解决优先级反转问题的技术，当高优先级任务因低优先级任务持有共享资源而阻塞时，临时提升低优先级任务的优先级至与高优先级任务相同，使其尽快执行并释放资源。 在NuttX中，优先级继承机制（Priority Inheritance）主要通过互斥锁（mutex）实现。当任务尝试获取已被持有的互斥锁时，如果持有者优先级低于当前任务，系统会提升持有者优先级以避免优先级反转。而flink和blink指针作为双向链表的连接件，在就绪任务队列中用于快速调整任务的位置（因为就绪队列是按优先级排序的）。 具体实现步骤： 1. **检测优先级反转**：当高优先级任务（H）尝试获取低优先级任务（L）持有的互斥锁时，内核发现L的优先级低于H。 2. **提升持有者优先级**：系统临时将L的优先级提升到与H相同（或略低，具体取决于策略）。 3. **调整就绪队列**：由于L的优先级提升，需要将其在就绪队列中的位置前移（因为就绪队列是按优先级从高到低排序的双向链表）。这里就用到`flink`和`blink`指针： - 将L从当前链表中移除（通过修改相邻节点的`flink`和`blink`指针） - 根据新优先级将L插入到就绪队列的合适位置（同样通过调整链表指针） 4. **任务调度**：调度器下一次调度时，由于L的优先级已提升，会优先执行L，使其尽快释放互斥锁。 5. **恢复原优先级**：当L释放互斥锁后，系统将其优先级恢复为原值，并调整其在就绪队列中的位置。 关键代码逻辑（以互斥锁获取为例）： ```c // 当任务H尝试获取已被L持有的互斥锁时 if (H->priority > L->priority) { // 提升L的优先级至H的优先级 nxsched_set_priority(L, H->priority); // 调整L在就绪队列中的位置（使用flink/blink指针） sched_remove_readytorun(L); // 从原位置移除 sched_add_readytorun(L); // 按新优先级插入 } ``` 在调整链表位置时，`sched_remove_readytorun`和`sched_add_readytorun`函数内部会操作`flink`和`blink`指针，实现$O(1)$复杂度的链表节点删除和插入。例如： ```c void sched_remove_readytorun(FAR struct tcb_s *tcb) { // 获取前驱和后继 FAR struct tcb_s *prev = tcb->blink; FAR struct tcb_s *next = tcb->flink; // 更新前驱的后继指针 if (prev != NULL) { prev->flink = next; } // 更新后继的前驱指针 if (next != NULL) { next->blink = prev; } } ``` **总结**：`flink`和`blink`指针在优先级继承中的作用是**动态调整任务在就绪队列中的位置**，确保因优先级提升而需要提前执行的任务能被快速调度。这种机制有效缓解了优先级反转问题，提高了系统的实时性。</think>### NuttX中如何利用`flink/blink`实现优先级继承机制 在NuttX中，`flink`和`blink`指针通过**动态调整任务在就绪队列中的位置**来实现优先级继承机制。该机制主要用于解决优先级反转问题，具体实现过程如下： #### 1. **优先级继承触发条件** 当高优先级任务（$T_{high}$）因等待低优先级任务（$T_{low}$）持有的资源（如互斥锁）而阻塞时，系统触发优先级继承： ```c /* 互斥锁获取函数片段 */ if (mutex->holder && mutex->holder->sched_priority < current->sched_priority) { nxsched_priority_inherit(mutex->holder, current->sched_priority); // 触发继承[^1] } ``` #### 2. **优先级提升的核心操作** 通过`flink/blink`动态调整任务在就绪队列中的位置： ```mermaid graph LR A[检测优先级反转] --> B{提升持有者优先级} B --> C[从就绪队列移除T_low] C --> D[按新优先级插入队列] D --> E[更新调度指针] ``` 具体实现步骤： 1. **移除原优先级位置** 通过`flink/blink`将$T_{low}$从当前队列位置移除： ```c void sched_remove_readytorun(FAR struct tcb_s *tcb) { // 更新前驱节点的flink if (tcb->blink) tcb->blink->flink = tcb->flink; // 更新后继节点的blink if (tcb->flink) tcb->flink->blink = tcb->blink; } ``` 2. **插入新优先级位置** 使用优先级排序算法重新插入： ```c void sched_add_readytorun(FAR struct tcb_s *tcb) { // 遍历就绪队列(g_readytorun) FAR struct tcb_s *prev = NULL; FAR struct tcb_s *next = g_readytorun.head; // 按优先级查找插入点 while (next && next->sched_priority > tcb->sched_priority) { prev = next; next = next->flink; // 通过flink遍历 } // 更新flink/blink指针 tcb->flink = next; tcb->blink = prev; if (next) next->blink = tcb; if (prev) prev->flink = tcb; } ``` #### 3. **调度器行为变化** 优先级提升后： 1. 就绪队列头部`g_readytorun.head`指向$T_{low}$（因其临时拥有最高优先级） 2. 调度器通过`flink`遍历时优先执行$T_{low}$： ```c FAR struct tcb_s *next = g_readytorun.head; // 获取最高优先级任务 while (next->flink && !ready_to_run(next)) { // 通过flink遍历 next = next->flink; } up_switchcontext(current, next); // 切换到继承优先级的任务 ``` #### 4. **优先级恢复机制** 当$T_{low}$释放资源后： 1. 通过`flink/blink`将其移出当前队列位置 2. 按原始优先级重新插入队列 3. 恢复$T_{high}$到就绪队列头部 #### 设计优势 1. **$O(1)$时间复杂度**：指针操作确保优先级调整高效完成 2. **无锁设计**：单核环境下通过开关中断保证原子性 3. **动态响应**：实时调整`g_readytorun.head`指向当前最高优先级任务 4. **资源优化**：复用TCB现有指针，无需额外存储 > 示例：当I²C驱动（HPWORK）持有资源时，其优先级可临时提升至与等待任务相同，确保实时性要求[^1]。 #### 总结 NuttX通过`flink/blink`实现： 1. **动态队列重组**：快速调整任务在双向链表中的位置 2. **优先级提升**：使资源持有者获得请求者的优先级 3. **实时调度**：确保高优先级任务最小化等待时间 4. **自动恢复**：资源释放后优先级自动回退 这种机制有效解决了嵌入式系统中的优先级反转问题，同时保持调度器的高效性（平均$O(1)$操作复杂度）。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值