大数据-121 - Flink Time Watermark 详解 附带示例详解

2024-09-06 12:12
文章标签 数据 详解 附带 121 示例 flink time watermark

本文主要是介绍大数据-121 - Flink Time Watermark 详解 附带示例详解，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

点一下关注吧！！！非常感谢！！持续更新！！！

目前已经更新到了：

  • Hadoop（已更完）
  • HDFS（已更完）
  • MapReduce（已更完）
  • Hive（已更完）
  • Flume（已更完）
  • Sqoop（已更完）
  • Zookeeper（已更完）
  • HBase（已更完）
  • Redis （已更完）
  • Kafka（已更完）
  • Spark（已更完）
  • Flink（正在更新！）

章节内容

上节我们完成了如下的内容：

  • 滑动窗口：时间驱动、事件驱动
  • 会话窗口：时间驱动、事件驱动

在这里插入图片描述

Time

在Flink的流式处理中，会涉及到时间的不同概念， 如下图所示：
在这里插入图片描述

  • EventTime[事件时间]：事件发生的时间，例如：点击网站上的某个链接的时间，每一条日志都会记录自己的生成时间，如果EventTime为基准来定义时间窗口那将形成EventTimeWindow，要求消息本身就应该携带EventTime
  • IngestionTime[摄入时间]：数据进入Flink时间，如某个Flink节点SourceOperator接收到数据的时间，例如：某个Source消费到Kafka中的数据，如果以IngesingTime为基准来定义时间窗口那将形成IngestingTimeWindow，以Source的SystemTime为准
  • ProcessingTime[处理时间]：某个Flink节点执行某个Operation的时间，例如：TimeWindow处理数据时的系统时间，默认时间的属性就是ProcessingTime。如果以ProcessingTime基准来定义时间窗口将形成ProcessingTimeWindow，以Operator的SystemTime为准

在Flink的流式处理中，绝大部分的业务都会使用EventTime，一般只在EventTime无法使用时，才会被迫使用ProcessingTime或者IngestionTime。
如果使用EventTime，那么需要引入EventTime的事件属性，引入方式如下所示：

# 设置使用事件时间
env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime)

基本概念

在 Apache Flink 中，Time Watermark（时间水印）是处理事件时间（Event Time）流处理的核心概念之一。它用于解决乱序事件的问题，帮助系统正确地按照事件发生的时间顺序进行处理。下面是详细解释：

事件时间（Event Time）和处理时间（Processing Time）

事件时间（Event Time）：事件生成时所关联的时间戳。例如，一条日志记录的生成时间。
处理时间（Processing Time）：事件到达 Flink 处理节点时的时间。这取决于系统的时间。
在实际的流处理中，事件的到达顺序可能会与它们的事件时间不一致，因为网络延迟、分布式系统等原因导致事件乱序。因此，使用事件时间而非处理时间来处理流数据更能准确反映数据的真实生成顺序。

乱序事件

乱序事件指的是数据流中的事件没有按照事件时间的顺序进入流处理系统。例如，事件A的事件时间是 12:00:01，事件B是 12:00:02，但事件B可能会比事件A先到达处理系统。

为了处理这种乱序问题，Flink 引入了 Watermark 机制。

什么是 Watermark

Watermark 是一个特殊的标志，它用于告诉 Flink 数据流中事件的进展情况。简单来说，Watermark 是 Flink 中估计的“当前时间”，表示所有早于该时间戳的事件都已经到达。

Watermark 的定义

Flink 认为当前时间在 Watermark 时间戳之前的所有事件已经接收完毕，不再期待有早于该时间戳的事件。
当 Watermark 时间戳更新时，系统可以触发基于事件时间的窗口操作，比如窗口计算、聚合等。
示例： 假设 Watermark 当前的值是 12:00:00，那么 Flink 认为 12:00:00 之前的事件已经全部到达，不会再有更早的事件来临。这时系统可以处理 12:00:00 之前的事件并触发窗口计算。

Watermark 生成方式

Watermark 可以通过自定义来生成，也可以使用内置策略。在常见情况下，Watermark 生成方式有两种：

a. 固定延迟策略（Fixed Delay）

最简单的 Watermark 生成方式是引入固定的延迟。例如，假设延迟 5 秒生成 Watermark，那么每个事件时间戳减去 5 秒就是当前的 Watermark。

b. 周期性生成 Watermark

Flink 允许 Watermark 定期生成，可以通过定期检查数据流中的最大时间戳来生成新的 Watermark。

数据延迟问题

示例1

现在假设，你正在去往地下停车场的路上，并且打算用手机点一份外卖。
选好了外卖之后，你就用在线支付功能付款了，这个时候是 11点50分。
但是这时，你走进了地下停车库，而这里没有手机信号，因此外卖的在线支付并没有立刻成功，而支付系统一直在Retry这个操作。
当你找到了自己的车并开出停车场的时候，已经是 12点05分了，而支付数据的处理时间是 12点05 分。
一般在实际开发中会以事件时间作为计算标准。

示例2

在这里插入图片描述

  • 一条日志进入Flink的事件为 2024-07-27 10:00:01 摄入时间
  • 到达Window系统的时间是 2024-07-27 10:00:02 处理时间
  • 日志内容为：2024-07-27 09:59:5- INFO Fail Over 事件时间

对于业务来说，要统计1小时内的故障日志的个数，哪个时间最有意义？当然是事件时间。
EventTime，因为我们要根据日志的生成时间进行统计。

示例3

某APP记录用户的所有点击行为，并回传日志，（在网络不好的情况下，先保存本地，延后回传）。
A用户在 11:02 对APP进行操作，B用户在 11:03 操作了APP。
但是A用户的网络太不稳定，回传日志延迟了，导致我们服务端先接受到B的消息，再接收到A的消息，消息乱序了。

示例4

在实际环境中，经常会出现，因为网络原因，数据有可能会延迟一会儿才到达Flink实时处理系统，我们先来设想一下下面的场景：
在这里插入图片描述

  • 使用时间窗口来统计10分钟内的用户流量
  • 有一个时间窗口：开始时间 2024-07-27 10:00:00，结束时间 2024-07-27 10:10:00
  • 有一个数据，因为网络延迟：事件发生的时间为：2024-07-27 10:10:00，但进入到窗口的事件为：2024-07-27 10:10:02 延迟2秒

这种处理方式，根据消息进入到Window时间，来进行计算，在网络有延迟的时候，会引起计算误差。

如何解决

使用水印来解决网络延迟的问题。
通过上面的例子，我们知道，在进行数据处理的时候应该按照事件时间进行处理，也就是窗口应该要考虑到事件时间。
但是窗口不能无限的一直等待延迟数据的到来，需要有一个触发窗口计算的进制，也就是我们接下来要学的Watermark水位线/水印机制。

WaterMark

水印（Watermark）就是一个时间戳，Flink可以给数据流添加水印，可以理解为：

  • 收到一条消息后，额外给这个消息添加一个时间字段，这就是添加水印。
  • 水印并不影响原有EventTime事件时间
  • 当数据流添加水印后，按照水印时间来触发窗口计算：也就是Watermark水印是用来触发窗口计算的
  • 一般会设置水印时间，比事件时间小几秒钟，表示最大允许数据延迟到达多久（即水印时间 = 事件时间 - 允许延迟时间）
  • 当接收到的 水印时间 >= 窗口结束时间，则触发计算，如等到一条数据的水印时间为 10:10:03 >= 10:10:00 才触发计算，也就是要等到事件为 10:10:03的数据到来才触发计算

在这里插入图片描述

解决总结

Watermark是用来解决延迟数据的问题，如窗口：10:00:00 ~ 10:10:00
而数据到达的顺序是：A 10:10:00，B 10:09:58
如果没有Watermark，那么A数据将会触发窗口计算，B数据来了窗口已经关闭，则该数据丢失。
如果有了 Watermark，设置允许数据迟到的阈值为3秒。
那么该窗口的结束条件则为水印：水印时间 >= 窗口结束时间 10:10:00，也就是需要一条数据的水印事件=10:10:00
而水印时间10:10:00 = 事件时间 - 延迟时间 3 秒
也就是需要有一条事件为10:10:03的数据到来，才会触发真正的计算。
而上面的A 10:10:00，B 10:09:58 都不会触发计算，也就是会被窗口包含，直到10:10:03的数据到来才会计算窗口 10:00:00 - 10:10:00 的数据。

Watermark

实现步骤

  • 获取数据源
  • 转化
  • 声明水印（Watermark）
  • 分组聚合，调用Window操作
  • 保存处理结果

注意事项

当使用 EventTimeWindow时，所有的Window在EventTime的时间轴上进行划分，也就是说，在Window启动后，会根据初始的EventTime时间每隔一段时间划分一个窗口，如果Window大小是3秒，那么1分钟内会把Window划分为如下的形式：

[00:00:00,00:00:03)
[00:00:03,00:00:06)
[00:00:03,00:00:09)
[00:00:03,00:00:12)
[00:00:03,00:00:15)
[00:00:03,00:00:18)
[00:00:03,00:00:21)
[00:00:03,00:00:24)
  • 窗口是左闭右开，形式为为：[window_start_time, window_end_time)
  • Window的设定基于第一条消息的事件时间，也就是说，Window会一直按照指定的时间间隔进行划分，不论这个Window中没有数据，EventTime 在这个Window期间的数据会进入这个Window
  • Window会不断产生，属于这个Window范围的数据会不断加入到Window中，所有未被触发的Window都会等待出发，只要Window还没出发，属于这个Window范围的数据就会一直被加入到Window中，直到Window被处罚才会停止数据的追加，而当Window触发之后才接收到属于被触发Window的数据会被丢弃。
  • Window会在以下的条件满足时才会被处罚执行：（1）在[window_start_time, window_end_time)窗口中有数据存在，（2）Watermark时间 >= window_end_time

一般会设置水印时间，比事件时间小几秒钟，表示最大允许数据延迟到达是多久：水印时间=事件时间-允许延迟时间。
当接收到水印时间 >= 窗口结束时间 且 窗口内有数据，则触发计算：事件时间 - 允许延迟时间 >= 窗口结束时间 或 事件时间 >= 窗口结束时间 + 允许延迟时间

这篇关于大数据-121 - Flink Time Watermark 详解 附带示例详解的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/1141974。

相关文章

Spring Security基于数据库验证流程详解

Spring Security基于数据库验证流程详解

Spring Security 校验流程图 相关解释说明（认真看哦） AbstractAuthenticationProcessingFilter 抽象类 /*** 调用 #requiresAuthentication(HttpServletRequest, HttpServletResponse) 决定是否需要进行验证操作。* 如果需要验证，则会调用 #attemptAuthentica
阅读更多...
大模型研发全揭秘：客服工单数据标注的完整攻略

大模型研发全揭秘：客服工单数据标注的完整攻略

在人工智能（AI）领域，数据标注是模型训练过程中至关重要的一步。无论你是新手还是有经验的从业者，掌握数据标注的技术细节和常见问题的解决方案都能为你的AI项目增添不少价值。在电信运营商的客服系统中，工单数据是客户问题和解决方案的重要记录。通过对这些工单数据进行有效标注，不仅能够帮助提升客服自动化系统的智能化水平，还能优化客户服务流程，提高客户满意度。本文将详细介绍如何在电信运营商客服工单的背景下进行
阅读更多...
基于MySQL Binlog的Elasticsearch数据同步实践

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展，我们的业务数据越来越多，单纯使用 MySQL 已经不能满足我们的数据查询需求，例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后，随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步，我们目前的解决方案是建立数据中间表。把需要检索的业务数据，统一放到一张M
阅读更多...
关于数据埋点，你需要了解这些基本知识

关于数据埋点，你需要了解这些基本知识

产品汪每天都在和数据打交道，你知道数据来自哪里吗？ 移动app端内的用户行为数据大多来自埋点，了解一些埋点知识，能和数据分析师、技术侃大山，参与到前期的数据采集，更重要是让最终的埋点数据能为我所用，否则可怜巴巴等上几个月是常有的事。   埋点类型 根据埋点方式，可以区分为： 手动埋点半自动埋点全自动埋点 秉承“任何事物都有两面性”的道理：自动程度高的，能解决通用统计，便于统一化管理，但个性化定
阅读更多...
使用SecondaryNameNode恢复NameNode的数据

使用SecondaryNameNode恢复NameNode的数据

1）需求： NameNode进程挂了并且存储的数据也丢失了，如何恢复NameNode 此种方式恢复的数据可能存在小部分数据的丢失。 2）故障模拟 （1）kill -9 NameNode进程 [lytfly@hadoop102 current]$ kill -9 19886 （2）删除NameNode存储的数据（/opt/module/hadoop-3.1.4/data/tmp/dfs/na
阅读更多...
异构存储（冷热数据分离）

异构存储（冷热数据分离）

异构存储主要解决不同的数据，存储在不同类型的硬盘中，达到最佳性能的问题。 异构存储Shell操作 （1）查看当前有哪些存储策略可以用 [lytfly@hadoop102 hadoop-3.1.4]$ hdfs storagepolicies -listPolicies （2）为指定路径（数据存储目录）设置指定的存储策略 hdfs storagepolicies -setStoragePo
阅读更多...
Hadoop集群数据均衡之磁盘间数据均衡

Hadoop集群数据均衡之磁盘间数据均衡

生产环境，由于硬盘空间不足，往往需要增加一块硬盘。刚加载的硬盘没有数据时，可以执行磁盘数据均衡命令。（Hadoop3.x新特性） plan后面带的节点的名字必须是已经存在的，并且是需要均衡的节点。 如果节点不存在，会报如下错误： 如果节点只有一个硬盘的话，不会创建均衡计划： （1）生成均衡计划 hdfs diskbalancer -plan hadoop102 （2）执行均衡计划 hd
阅读更多...
OpenHarmony鸿蒙开发（ Beta5.0）无感配网详解

OpenHarmony鸿蒙开发（ Beta5.0）无感配网详解

1、简介 无感配网是指在设备联网过程中无需输入热点相关账号信息，即可快速实现设备配网，是一种兼顾高效性、可靠性和安全性的配网方式。 2、配网原理 2.1 通信原理 手机和智能设备之间的信息传递，利用特有的NAN协议实现。利用手机和智能设备之间的WiFi 感知订阅、发布能力，实现了数字管家应用和设备之间的发现。在完成设备间的认证和响应后，即可发送相关配网数据。同时还支持与常规Sof
阅读更多...
【Prometheus】PromQL向量匹配实现不同标签的向量数据进行运算

【Prometheus】PromQL向量匹配实现不同标签的向量数据进行运算

✨✨ 欢迎大家来到景天科技苑✨✨ 🎈🎈 养成好习惯，先赞后看哦~🎈🎈 🏆 作者简介：景天科技苑 🏆《头衔》：大厂架构师，华为云开发者社区专家博主，阿里云开发者社区专家博主，CSDN全栈领域优质创作者，掘金优秀博主，51CTO博客专家等。 🏆《博客》：Python全栈，前后端开发，小程序开发，人工智能，js逆向，App逆向，网络系统安全，数据分析，Django，fastapi
阅读更多...
烟火目标检测数据集 7800张 烟火检测 带标注 voc yolo

烟火目标检测数据集 7800张 烟火检测 带标注 voc yolo

一个包含7800张带标注图像的数据集，专门用于烟火目标检测，是一个非常有价值的资源，尤其对于那些致力于公共安全、事件管理和烟花表演监控等领域的人士而言。下面是对此数据集的一个详细介绍： 数据集名称：烟火目标检测数据集 数据集规模： 图片数量：7800张类别：主要包含烟火类目标，可能还包括其他相关类别，如烟火发射装置、背景等。格式：图像文件通常为JPEG或PNG格式；标注文件可能为X
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2