能够穿梭时空的实时计算框架——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 部电影是该系列中的第 四、五、 6 部（这是事件时间），它们的上映年份分别是 1977 年、1980 年和 1983 年 （这是处理时间）。以后按事件时间上映的第 一、二、三、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等相关技术博文，欢迎关注实时流式计算：