Flink基础知识 ---事件时间与处理时间

事件时间与处理时间要谈论无限数据处理，需要清楚地了解所涉及的时间域。在任何数据处理系统中，通常有两个我们关心的时间域：事件时间这是事件实际发生的时间。
处理时间这是在系统中观察事件的时间。
并非所有的用例都关心事件时间（如果你的事情没有，那么万岁！你的生活会更容易），但很多人都这么做。示例包括表征用户随时间的行为，大多数计费应用程序以及许多类型的异常检测，仅举几例。
在理想的世界中，事件时间和处理时间总是相等的，事件在发生时立即处理。然而，现实并非如此，事件时间和处理时间之间的偏差不仅非零，而且通常是底层输入源，执行引擎和硬件特性的高度可变函数。可能影响偏差水平的事情包括：共享资源限制，如网络拥塞，网络分区或非专用环境中的共享CPU软件原因，如分布式系统逻辑，争用等，数据本身的特征，如密钥分配，吞吐量变化或无序变化（即，在离线使用整个航班后，人们将手机从飞机模式中移出的平面）结果，如果您绘制事件时间和处理的进度时间任何]真实世界的系统，你通常会得到一些看起来有点像图1-1中的红线的东西。

图1-1。 时域映射。 x轴表示系统中的事件时间完整性; 也就是说，在事件时间内的时间X，已经观察到事件时间小于X的所有数据。 y轴表示处理时间的进度; 也就是说，数据处理系统在执行时观察到的正常时钟时间。

在图1-1中，斜率为1的黑色虚线表示理想值，其中处理时间和事件时间完全相等;红线代表现实。在这个例子中，系统在处理时间开始时滞后一点，在中间转向更接近理想，然后再向后滞后一点。乍一看，此图中有两种类型的倾斜，每种都在不同的时域中：处理时间理想线和红线之间的垂直距离是处理时域中的滞后。该距离告诉您在给定时间的事件发生时和处理时间之间观察到的延迟（处理时间）。这可能是两个偏差中更自然和直观的。
事件时间理想红线和红线之间的水平距离是此时管道中事件时间偏差的量。它告诉您当前管道的理想（事件时间）落后多远。
实际上，任何给定时间点的处理时间滞后和事件时间偏差都是相同的;他们只是看待同一件事的两种方式。关于滞后/偏斜的重要思考是这样的：因为事件时间和处理时间之间的整体映射不是静态的（即，滞后/偏斜可以随时间任意变化），这意味着您无法仅在上下文中分析您的数据。如果您关注他们的活动时间（即事件实际发生时），您的管道会观察他们。
不幸的是，这是许多为无界数据设计的系统在历史上运行的方式。为了应对无界数据集的无限性，这些系统通常提供一些窗口化输入数据的概念。我们稍后会深入讨论窗口，但它本质上意味着将数据集沿时间边界切割成有限的片段。如果您关心正确性并且有兴趣在事件时间的上下文中分析您的数据，则无法像许多系统那样使用处理时间（即处理时间窗口）来定义那些时间边界;在处理时间和事件时间之间没有一致的相关性，你的一些事件时间数据将在错误的处理时间窗口中结束（由于分布式系统的固有滞后性，许多类型的输入源的在线/离线性质，等等，从窗口抛出正确性。我们将在后面的部分中的一些示例以及本书的其余部分中更详细地介绍此问题。
不幸的是，当按事件时间窗口化时，图片并不完全乐观。在无界数据的情况下，无序和变量偏斜会导致事件时间窗口的完整性问题：缺少处理时间和事件时间之间的可预测映射，如何确定何时观察到给定事件时间的所有数据X？对于许多真实世界的数据源，你根本做不到。但是，目前使用的绝大多数数据处理系统都依赖于某些完整性概念，这使得它们在应用于无界数据集时处于严重劣势。
我建议不要试图将无限数据整理成最终变得完整的有限批次信息，而应该设计工具，让我们生活在这些复杂数据集所带来的不确定性世界中。新数据将会到来，旧数据可能会被撤回或更新，我们构建的任何系统都应该能够自行处理这些事实，完整性概念是对特定和适当用例的方便优化，而不是跨语义必需他们都是。
在详细介绍这种方法可能是什么样子之前，让我们完成一个更有用的背景：常见的数据处理模式。

数据处理模式此时，我们已经建立了足够的背景知识，我们可以开始研究当今有界和无界数据处理中常见的核心类型的使用模式。 我们看看两种类型的处理，并且在相关的情况下，我们关注的两种主要类型的引擎（批量和流式传输，在这种情况下，我基本上是将流式传输与流式传输混合在一起，因为两者之间存在差异） 在这个层面上并不是非常重要）。