欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

可以穿梭时空的实时计算框架——Flink对时间的处理

程序员文章站 2023-11-15 18:41:58
Flink对于流处理架构的意义十分重要,Kafka让消息具有了持久化的能力,而处理数据,甚至穿越时间的能力都要靠Flink来完成。 在 "Streaming 大数据的未来" 一文中我们知道,对于流式处理最重要的两件事,正确性,时间推理工具。而Flink对两者都有非常好的支持。 Flink对于正确性的 ......

可以穿梭时空的实时计算框架——Flink对时间的处理
flink对于流处理架构的意义十分重要,kafka让消息具有了持久化的能力,而处理数据,甚至穿越时间的能力都要靠flink来完成。

streaming-大数据的未来一文中我们知道,对于流式处理最重要的两件事,正确性,时间推理工具。而flink对两者都有非常好的支持。

flink对于正确性的保证

对于连续的事件流数据,由于我们处理时可能有事件暂未到达,可能导致数据的正确性受到影响,现在采取的普遍做法的通过高延迟的离线计算保证正确性,但是也牺牲了低延迟。

flink的正确性体现在计算窗口的定义符合数据产生的自然规律。比如点击流事件,追踪3个用户a,b,c的访问情况。我们看到数据是可能有间隙的,这也就是session窗口。

可以穿梭时空的实时计算框架——Flink对时间的处理

用sparkstreaming的微批处理方式(虚线为计算窗口,实线是会话窗口),很难做到计算窗口与会话窗口的吻合。而使用flink的流处理api,可以灵活的定义计算窗口。比如可以设置一个值,如果超出这个值就认为活动结束。

可以穿梭时空的实时计算框架——Flink对时间的处理

不同于一般的流处理,flink可以采用事件时间,这对于正确性非常有用。

对于发生故障性的正确性保证,必须要跟踪计算状态,现在大部分时候状态性的保证是靠开发人员完成的,但是连续的流处理计算没有终点。flink采用检查点-checkpoint技术解决了这个问题。在每个检查点,系统都会记录中间计算状态,从而在故障发生时准确地重 置。这一方法使系统以低开销的方式拥有了容错能力——当一切正常时, 检查点机制对系统的影响非常小。

flink提供的接口,包括了跟踪计算的任务,并用同一种技术来实现流处理和批处理,简化了运维开发工作,这也是对正确性的一种保证。

flink对于时间的处理

用流处理和批处理最大的区别就是对时间的处理。

采用批处理架构处理

在该架构中,我们可以每隔一段时间存储数据,比如存在hdfs中,由调度程序定时的执行,将结果输出。

可以穿梭时空的实时计算框架——Flink对时间的处理

这种架构可行但是有几个问题:

  • 太多独立的部分。为了计算数据中的事件数,这种架构动用了太多系统。 每一个系统都有学习成本和管理成本,还可能存在 bug。

  • 对时间的处理方法不明确。假设需要改为每 30 分钟计数一次。这个变动涉及工作流调度逻辑(而不是应用程序代码逻辑),从而使 devops 问题 与业务需求混淆。

  • 预警。假设除了每小时计数一次外,还需要尽可能早地收到计数预警( 如在事件数超过10 时预警)。为了做到这一点,可以在定期运行的批处理作业之外,引入 storm 来采集消息流。 storm 实时提供近似的计数,批处理作业每小时提供准确的计数。但是这样一来,就向架构增加了一个系统,以及与之相关的新编程模型。上述架构叫作 lambda 架构。


可以穿梭时空的实时计算框架——Flink对时间的处理

  • 乱序事件流。在现实世界中,大多数事件流都是乱序的,即事件的实际发生顺序和数据中心所记录的顺序不一样。这意味着本属于前一批的事件可能被错误地归入当前一批。批处理架构很难解决这个问题,大部分人则选择忽视它。
  • 批处理作业的界限不清晰。在分割时间点前后的事件既可能被归入前一批,也可能被归入当前一批。

采用流处理

首先将消息集中写入消息传输系统kafka,事件流由消息传输系统提供,并且只被单一的 flink 作业处理。

可以穿梭时空的实时计算框架——Flink对时间的处理

以时间为单位把事件流分割为一批批任务,这种逻辑完全嵌入在 flink 程序的应用逻辑中。预警由同一个程序生成,乱序事件由 flink 自行处理。要从以固定时间分组改为根据产生数据的时间段分组,只需在 flink 程序中修改对窗口的定义即可。此外,如果应用程序的代码有过改动,只需重播 kafka 主题,即可重播应用程序。采用流处理架构,可以大幅减少需要学习、管理和编写代码的系统。flink 应用程序代码示例:

datastream<logevent> stream = env  
// 通过kafka生成数据流  
.addsource(new flinkkafkaconsumer(...))   
// 分组   
.keyby("country")   
// 将时间窗口设为60分钟  
.timewindow(time.minutes(60))   
// 针对每个时间窗口进行操作   
.apply(new countperwindowfunction());

在流处理中,主要有两个时间概念 :

事件时间,即事件实际发生的时间。更准确地说,每一个事件都有一个与它相关的时间戳,并且时间戳是数据记录的一部分。

处理时间,即事件被处理的时间。处理时间其实就是处理事件的机器所测量的时间。

可以穿梭时空的实时计算框架——Flink对时间的处理

以《星球大战》系列电影为例。首先上映的 3 部电影是该系列中的第 4、5、 6 部(这是事件时间),它们的上映年份分别是 1977 年、1980 年和 1983 年 (这是处理时间)。之后按事件时间上映的第 1、2、3、7 部,对应的处理时间分别是 1999 年、2002 年、2005 年和 2015 年。由此可见,事件流的顺序可能是乱的(尽管年份顺序一般不会乱)

通常还有第 3 个时间概念,即摄取时间,也叫作进入时间。它指的是事件进入流处理框架的时间。缺乏真实事件时间的数据会被流处理器附上时间戳,即流处理器第一次看到它的时间(这个操作由 source 函数完成,它是程序的第一个处理点)。

在现实世界中,许多因素(如连接暂时中断,不同原因导致的网络延迟, 分布式系统中的时钟不同步,数据速率陡增,物理原因,或者运气差)使 得事件时间和处理时间存在偏差(即事件时间偏差)。事件时间顺序和处理 时间顺序通常不一致,这意味着事件以乱序到达流处理器。

flink 允许用户根据所需的语义和对准确性的要求选择采用事 件时间、处理时间或摄取时间定义窗口。

窗口

时间窗口是最简单和最有用的一种窗口。它支持滚动和滑动。

比如一分钟滚动窗口收集最近一分钟的数值,并在一分钟结束时输出总和:

可以穿梭时空的实时计算框架——Flink对时间的处理

一分钟滑动窗口计算最近一分钟的数值总和,但每半分钟滑动一次并输出 结果:

可以穿梭时空的实时计算框架——Flink对时间的处理

在 flink 中,一分钟滚动窗口的定义如下。

stream.timewindow(time.minutes(1))

每半分钟(即 30 秒)滑动一次的一分钟滑动窗口如下所示。

stream.timewindow(time.minutes(1), time.seconds(30))

flink 支持的另一种常见窗口叫作计数窗口。采用计数窗口时,分组依据不 再是时间戳,而是元素的数量。

滑动窗口也可以解释为由 4 个元素组成的计数窗口,并且每两个元素滑动一次。滚动和滑动的计数窗 口分别定义如下。

stream.countwindow(4) 
stream.countwindow(4, 2)

虽然计数窗口有用,但是其定义不如时间窗口严谨,因此要谨慎使用。时 间不会停止,而且时间窗口总会“关闭”。但就计数窗口而言,假设其定义 的元素数量为 100,而某个 key 对应的元素永远达不到 100 个,那么窗口就 永远不会关闭,被该窗口占用的内存也就浪费了。

flink 支持的另一种很有用的窗口是会话窗口。会话窗口由超时时间设定,即希望等待多久才认为会话已经结束。
示例如下:

stream.window(sessionwindows.withgap(time.minutes(5))

触发器

除了窗口之外,flink 还提供触发机制。触发器控制生成结果的时间,即何时聚合窗口内容并将结果返回给用户。每一个默认窗口都有一个触发器。 例如,采用事件时间的时间窗口将在收到水印时被触发。对于用户来说, 除了收到水印时生成完整、准确的结果之外,也可以实现自定义的触发器。

时间回溯

流处理架构的一个核心能力是时间的回溯机制。意味着将数据流倒回至过去的某个时间,重新启动处理程序,直到处理至当前时间为止。 kafka支持这种能力。

可以穿梭时空的实时计算框架——Flink对时间的处理

实时流处理总是在处理最近的数据(即图中“当前时间”的数据),历史流处理 则从过去开始,并且可以一直处理至当前时间。流处理器支持事件时间, 这意味着将数据流“倒带”,用同一组数据重新运行同样的程序,会得到相同的结果。

水印

flink 通过水印来推进事件时间。水印是嵌在流中的常规记录,计算程序通 过水印获知某个时间点已到。收到水印的窗口就知道 不会再有早于该时间的记录出现,因为所有时间戳小于或等于该时间的事 件都已经到达。这时,窗口可以安全地计算并给出结果(总和)。水印使事 件时间与处理时间完全无关。迟到的水印(“迟到”是从处理时间的角度而言)并不会影响结果的正确性,而只会影响收到结果的速度。

水印由应用程序开发人员生成,这通常需要对相应的领域有 一定的了解。完美的水印永远不会错:时间戳小于水印标记时间的事件不会再出现。

如果水印迟到得太久,收到结果的速度可能就会很慢,解决办法是在水印 到达之前输出近似结果(flink 可以实现)。如果水印到达得太早,则可能收到错误结果,不过 flink 处理迟到数据的机制可以解决这个问题。

相关文章:
streaming-大数据的未来

实时计算大数据处理的基石-google dataflow

数据架构的未来——浅谈流处理架构

以上为flink对于时间的处理,更多实时计算,flink,kafka等相关技术博文,欢迎关注实时流式计算:

可以穿梭时空的实时计算框架——Flink对时间的处理