数据时间

首先，日志是延迟的。
当然，大部分的延迟是由传输过程造成的，但也有很多情况下，日志上线后会被缓冲和发送。
另外，根据转发的路由，第一个事件日志可能在下一个事件之后到达。
因此，原本的到达被认为是失序的，因为可能会有延迟。

分析处理可以分为流处理（对单个事件的顺序处理）和批处理（对一组事件的处理），但当考虑一个数据处理系统（如lambda架构）可以用于这两种类型的处理时，如何处理发送出的事件成为一个问题。

数据流模型

数据流模型讨论了在对随机顺序或无限流动的数据进行流或批处理时的数据管理。
使用这种数据结构的服务有Google Cloud Dataflow，Apache Beam也有同样的数据结构，可以作为OSS使用。
本文提出将时间分为事件时间和处理时间，因为很难假设无序无止境地流动的数据一定是在某一时间到达的。

时间的分类

事件时间顾名思义，就是事件发生的时间。
处理时间是指事件处理的时间。 这将为数据管道中的每个组件而改变。 例如，如果事件是在解析服务器日志，那么文件写入HDFS的时间和MapReduce作业开始处理文件的时间就会不同。 细说一下，Map和Reduce的处理时间也是不同的。

除了这两个时间，Apache Flink还引入了一个Ingestion时间。 看来，"摄取时间 "是指一个事件到达Flink中作业流水线的开始时间。
这个Ingestion Time在实际操作流媒体处理管道时也是非常有效的，但我现在就不说了，因为这里说的太多了。

处理流媒体过程中的时间

既然是流媒体日志传输的延续，我想谈谈流媒体过程中的时间管理。
还有一些关于批处理和窗口化的话题，不过我的论文里会让你看。

如果把日志看成是水，水印就是数据流向数据管道的每个组成部分的程度。

这是向流式进程发送事件的事件时间和处理时间分布的一个例子。(圆圈中的数字暂时没有意义，请忽略。)事件的顺序用X轴表示，到达系统的顺序用Y轴表示。
理想水印（细虚线）是指Event时间和Processing Time之间没有差异的情况，也就是说，传输过程中完全没有滞后。 当然，这是不可能的，所以没有满足这个水印的事件。
实际水印（Actual Watermark，深色虚线）延伸到右上方，围绕着随着处理时间向上发展而出现的事件。 这个水印还包括不同顺序的事件。
需要注意的是，左上角的事件目前不包含在水印中。
当处理时间为12:09时，事件时间达到了12:07，所以在流媒体处理过程中忽略了这个事件，因为它是水印之后的事件。

流式数据流模型优先考虑低延迟处理，所以它选择忽略这个事件。

我想说的是，时间的处理根据流程的不同而改变，而处理时间和事件时间这两个时间可以帮助解决这个问题。
事件时间和处理时间如果你仔细想一想，是很自然的事情，但是我觉得有很多时候我们把它们当成是一样的。
即使你不走Dataflow模式，比如你给DB设置TTL的时候，我觉得也要考虑一下是事件时间还是处理时间。
另外，可能有人一直在追求流媒体处理的准确性，但我想你应该知道，这是与延迟的权衡。