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

flink对于流处理架构的意义十分重要，kafka让消息具有了持久化的能力，而处理数据，甚至穿越时间的能力都要靠flink来完成。

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

flink对于正确性的保证

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

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

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

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

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

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

flink对于时间的处理

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

采用批处理架构处理

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

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

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

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

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

​

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

采用流处理

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

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

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

在流处理中，主要有两个时间概念 ：

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

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

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

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

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

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 处理迟到数据的机制可以解决这个问题。

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

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

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

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