我是负责第10天的Distributed Computing Advent Calendar的sitotkfm。

最初我是在Cyberagent Advent Calendar的第十天写的，但是那边的内容太散乱和无关紧要了，而且有些主题更适合单独写，所以我决定在这里单独进行写作。非常抱歉，这次不是关于Kafka的话题…

資料的時間戳

首先，日志会延迟。
当然，主要是由于传输处理导致的延迟，但是由于负载增加、日志堵塞以及手机应用离线时的日志被缓冲，在重新联机后会经常被发送。
此外，由于传输路由的原因，先发生的事件日志有时候会在后发生的事件之后才到达。
因此，日志的到达被认为是无序的，因为可能会产生延迟。

解析处理可分为流处理（逐个事件的处理）和批处理（对事件集合的处理），当考虑到可以在这两种处理方式下使用的数据处理体系（如Lambda架构）时，如何处理以无序方式发送的事件成为一个问题。

数据流模型

Dataflow模型讨论了在处理流动且无限的数据时的数据管理，可以进行流式处理和批处理。
使用这种数据结构的服务可以通过Google Cloud Dataflow进行使用，并作为开源软件Apache Beam公开发布，拥有相同的数据结构。
在这篇论文中，提出了将无序且持续流动的数据在特定时间确保到达的假设视为困难，并提议将时间分为事件时间和处理时间来处理。

時間的分類

Event time指的是事件发生的时间。Processing time指的是对某一事件进行处理的时间。如果建立了数据流水线，则每个组件的处理时间会有所不同。例如，对服务器日志进行分析的事件，其写入HDFS文件的时间与文件进行MapReduce处理的时间是不同的。更具体地说，Map和Reduce的处理时间也是不同的。

在Apache Flink中，除了这两个时间之外，还引入了Ingestion time。这意味着当事件到达Flink作业流水线的开头时，该事件被标记为Ingestion Time。
在实际运营流处理流水线时，Ingestion Time也是非常有效的。但是，由于这个话题很复杂，所以本次先不涉及。

处理流媒体的时间

因为我对流式传输的日志转发有一些个人的见解，在这次讨论中我们先讨论流式处理的时间管理问题。
当然，对于批处理和窗口处理时的时间管理也是有的，但是那部分可以让大家自行阅读相关论文来了解…

这是一个关于被发送到某个流处理的事件的Event Time和Processing Time分布的示例。（圆圈中的数字现在没有意义，可以忽略）事件的发生顺序在X轴上表示，到达系统的顺序在Y轴上表示。

理想的Watermark（虚线）是指在Event Time和Processing Time没有差异的情况下，即没有任何传输延迟的状态。当然，这是不可能的，所以不存在满足这个Watermark的事件。

实际的Watermark（Actual Watermark，实线）是在Processing Time向前推进时出现的事件所围绕的，并向右上方延伸。这个Watermark中还包括了顺序被颠倒的事件。

请注意，在左上角的事件不包含在Watermark内。

当Processing Time为12:09时，由于Event Time已经到达了12:07，所以这个事件是Watermark之后的事件，所以在流处理中会被忽略。

为了优先考虑数据流模型中的流处理低延迟，选择忽略此事件。Dataflow使用两个时间来确定分析范围。

总结

我想说的是关于时间处理的讨论：根据处理方法，时间处理方式会有所不同。而”Processing Time”和”Event Time”这两种时间处理方法可能会对此提供帮助。

虽然”Event Time”和”Processing Time”在仔细考虑时是很显然的事情，但我认为人们经常会将它们混为一谈。

即使不涉及到Dataflow模型，比如在设置数据库的TTL时，考虑一下是使用”Event Time”还是”Processing Time”也是很重要的。

此外，可能有些人一直追求流处理的准确性，但请意识到这只是与延迟之间的权衡。

大家好，今年剩下的時間不多了，祝大家时光愉快。