Flink基础知识--无界数据处理

无界数据：流式传输与大多数基于批处理的无界数据处理方法的临时性质相反，流式系统是针对无界数据构建的。正如我们之前所讨论的，对于许多真实的分布式输入源，您不仅会发现自己处理无界数据，还会处理以下数据：事件时间高度无序，这意味着您需要某种时间 如果要在发生它们的上下文中分析数据，则在管道中进行基于shuffle。
在不同的事件时间偏差中，意味着你不能只假设你总是会在某个恒定的时间ε中看到给定事件时间X的大部分数据。
在处理具有这些特征的数据时，您可以采取一些方法。
我通常将这些方法分为四组：时间不可知，近似，按处理时间加窗，以及按事件时间加窗。
现在让我们花一点时间来研究这些方法。

1.时间不可知
时间不可知处理用于时间基本无关的情况;也就是说，所有相关逻辑都是数据驱动的。因为有关此类用例的所有内容都是由更多数据的到来决定的，所以除了基本数据传输之外，流引擎实际上没有什么特别需要支持的。因此，基本上所有流式传输系统都支持开箱即用的时间不可用的用例（当然，如果你关心正确性，模块系统到系统的一致性保证差异）。通过简单地将无界源切割成有界数据集的任意序列并独立处理这些数据集，批处理系统也非常适合无界数据源的时间不可知处理。我们在本节中看一些具体的例子，但考虑到处理与时间无关的处理的直接性（至少从时间角度来看），除此之外我们不会花太多时间在它上面。
过滤一种非常基本的时间不可知处理形式是过滤，其示例如图1-5所示。

想象一下，您正在处理网络流量日志，并且您希望过滤掉所有不是来自特定域的流量。你会看到每个记录到达时，查看它是否属于感兴趣的域，如果没有则删除它。因为这种事情在任何时候都只依赖于单个元素，所以数据源是无界的，无序的，并且具有不同的事件时间偏差这一事实是无关紧要的。

图1-5。过滤无限数据。从不同类型的数据集合（从左到右流动）被过滤成包含单一类型的同类集合。

内连接
另一个与时间无关的例子是内连接，如图1-6所示。

当连接两个无界数据源时，如果您只关心来自两个源的元素到达时的连接结果，则逻辑中没有时间元素。在看到来自一个源的值后，您可以简单地将其缓冲为持久状态;只有在来自其他源的第二个值到达之后，才需要发出连接记录。 （事实上​​，你可能想要某种垃圾收集策略用于未经许可的部分连接，这可能是基于时间的。但是对于很少或没有未完成连接的用例，这样的事情可能不是问题。）

将语义切换到某种外连接会引入我们所讨论的数据完整性问题：在您看到连接的一侧之后，您如何知道另一方是否会到达？
说实话，你没有，所以你需要引入一些超时的概念，这会引入一个时间元素。时间元素本质上是一种窗口形式，我们将在一瞬间更加密切地关注它。

2.近似算法

第二类主要方法是近似算法，例如近似Top-N，流k-means等。它们采用无限的输入源并提供输出数据，如果你眯着眼睛看，它们或多或少看起来像你希望得到的那样，如图1-7所示。
近似算法的优点在于，通过设计，它们的开销很低，并且设计用于无界数据。缺点是它们存在有限的一组，算法本身往往很复杂（这使得很难想出新的算法），它们的近似性质限制了它们的效用。

图1-7。计算无界数据的近似值。数据通过复杂的算法运行，产生的输出数据或多或少与另一侧的预期结果相似。

值得注意的是，这些算法通常在其设计中确实存在一些时间因素（例如，某种内置衰变）。并且因为它们在到达时处理元素，所以该时间元素通常基于处理时间。这对于在其近似上提供某种可证明的误差界限的算法尤其重要。如果这些误差范围是以按顺序到达的数据为基础的，那么当您向算法提供具有不同事件时间偏差的无序数据时，它们基本上没有任何意义。要记住的事情。
近似算法本身是一个引人入胜的主题，但由于它们本质上是时间不可知处理的另一个例子（以算法本身的时间特征为模），因此我们可以非常直接地使用它们，因此，鉴于我们目前的重点，它们不值得进一步关注。
窗口化无限数据处理的其余两种方法都是窗口的变化。在深入研究它们之间的差异之前，我应该清楚地说明窗口的确切含义，因为我们只是在上一节中简要介绍了它。窗口化只是获取数据源（无界或有界）的概念，并沿着时间边界将其切割成有限的块以进行处理。图1-8显示了三种不同的窗口模式。

图1-8。 窗口策略。 每个示例都显示三个不同的键，突出显示对齐窗口（适用于所有数据）和未对齐窗口（适用于数据子集）之间的差异。

让我们仔细看看每个策略：固定窗口（又名翻滚窗口）我们之前讨论过固定窗口。固定窗口将时间切片为具有固定大小的时间长度的片段。通常（如图1-9所示），固定窗口的分段均匀地应用于整个数据集，这是对齐窗口的示例。在某些情况下，希望对不同数据子集（例如，每个键）的窗口进行相移以随时间更均匀地扩展窗口完成负载，而这是未对齐窗口的示例，因为它们在数据上变化。
滑动窗口（又称跳跃窗口）固定窗口的推广，滑动窗口由固定长度和固定周期定义。如果周期小于长度，则窗口重叠。如果周期等于长度，则您有固定的窗口。如果周期大于长度，则会有一个奇怪的采样窗口，该窗口仅查看数据的子集随时间的变化。
与固定窗口一样，滑动窗口通常是对齐的，但在某些用例中它们可以不对齐作为性能优化。
请注意，图1-8中的滑动窗口是按原样绘制的，以提供滑动感;实际上，所有五个窗口都将应用于整个数据集。
会话动态窗口的一个示例，会话由一系列事件组成，这些事件由不活动的间隙大于某个超时而终止。
会话通常用于通过将一系列时间相关事件（例如，在一次观看中观看的一系列视频）分组在一起来分析用户随时间的行为。会话很有意思，因为它们的长度不能先验地定义;它们取决于所涉及的实际数据。它们也是未对齐窗口的规范示例，因为会话实际上从不相同的不同子集（例如，不同的用户）

我们之前讨论的两个时间域（处理时间和事件时间）基本上是我们关心的两个。窗口化在两个域都有意义，所以让我们详细看看每个窗口，看看它们有何不同。因为处理时间窗口在历史上比较常见，所以我们将从那里开始。
通过处理时间进行窗口化当按处理时间窗口化时，系统实质上将输入数据缓冲到窗口中，直到经过一定量的处理时间。例如，在五分钟固定窗口的情况下，系统会将数据缓冲五分钟的处理时间，之后它会将在这五分钟内观察到的所有数据视为一个窗口并将它们发送到下游进行处理。

图1-9。通过处理时间窗口进入固定窗口。数据根据它们到达管道的顺序收集到窗口中。

处理时间窗口有一些很好的属性：它很简单。实现非常简单，因为您从不担心在一段时间内对数据进行混洗。你只需在它们到达时缓冲它们并在窗口关闭时将它们发送到下游。

判断窗口的完整性很简单。由于系统完全了解是否已经看到窗口的所有输入，因此可以就给定窗口是否完整做出完美的决定。这意味着当按处理时间进行窗口化时，无需以任何方式处理“延迟”数据。

如果您想要在观察时推断出有关源的信息，那么处理时间窗口正是您想要的。
许多监测方案都属于这一类。想象一下，跟踪发送到全球规模Web服务的每秒请求数。
为了检测中断而计算这些请求的速率是处理时间窗口的完美使用。
除了优点之外，处理时间窗口有一个非常大的缺点：如果有问题的数据具有与它们相关联的事件时间，那么如果处理时间窗口要反映实际时间，则这些数据必须按事件时间顺序到达那些事件确实发生了。不幸的是，在许多真实的分布式输入源中，事件时序数据并不常见。
举一个简单的例子，想象一下任何收集使用统计数据以供以后处理的移动应用程序。对于特定移动设备在任何时间内脱机（短暂的连接丢失，飞越全国的飞机模式等）的情况，在此期间记录的数据将不会上传，直到设备再次联机。这意味着数据可能会以分钟，小时，天，周或更长的事件时间偏差到达。当处理时间窗口化时，从这样的数据集中绘制任何类型的有用推论基本上是不可能的。
作为另一个例子，当整个系统健康时，许多分布式输入源似乎可以提供事件时间有序（或非常接近）的数据。不幸的是，健康时事件时间偏差对于输入源来说是低的这一事实并不意味着它总会保持这种状态。考虑一个处理在多个大洲收集的数据的全球服务。如果网络问题跨越带宽受限的跨大陆线（遗憾的是，这种情况非常普遍）会进一步降低带宽和/或增加延迟，突然一部分输入数据可能会以比以前更大的偏差开始到达。如果您通过处理时间来处理这些数据，那么您的窗口将不再代表其中实际发生的数据;相反，当事件到达处理管道时，它们代表时间窗口，这是旧数据和当前数据的任意混合。

我们在这两种情况下真正想要的是以一种对事件到达顺序稳健的方式按事件时间窗口数据。我们真正想要的是事件时间窗口。

按事件时间窗口事件
时间窗口是当您需要观察有限块中反映事件实际发生时间的数据源时使用的窗口。这是开窗的黄金标准。在2016年之前，大多数使用中的数据处理系统缺乏本机支持（尽管任何具有良好一致性模型的系统，如Hadoop或Spark Streaming 1.x，都可以作为构建这种窗口系统的合理基础）。我很高兴地说今天的世界看起来非常不同，有多个系统，从Flink到Spark，Storm到Apex，本身支持某种事件时间窗口。
图1-10显示了将无界源窗口化为一个固定窗口的示例。
在这里插入图片描述
图1-10。按事件时间窗口固定窗口。数据根据它们发生的时间收集到窗口中。黑色箭头表示到达处理时间窗口的示例数据，这些数据与它们所属的事件时间窗口不同。

图1-10中的黑色箭头表示两个特别有趣的数据。每个到达的处理时间窗口与每个数据位所属的事件时间窗口不匹配。因此，如果这些数据已被窗口化为关注事件时间的用例的处理时间窗口，则计算结果将是不正确的。
正如您所料，事件时间的正确性是使用事件时间窗口的一个好处.

关于无界数据源的事件时间窗口的另一个好处是，您可以创建动态大小的窗口，例如会话，而不会在通过固定窗口生成会话时观察到任意分割（正如我们之前在“无界数据”中的会话示例中看到的那样） ：Streaming“），如图1-11所示。

图1-11。按事件时间窗口进入会话窗口。数据被收集到会话窗口中，根据相应事件发生的时间捕获活动突发。黑色箭头再次调出将数据放入正确的事件时间位置所需的时间改组。
当然，强大的语义很少是免费的，事件时间窗口也不例外。事件时间窗口有两个明显的缺点，因为窗口必须经常比窗口本身的实际长度更长（处理时间）：缓冲由于延长窗口寿命，需要更多的数据缓冲。
值得庆幸的是，持久存储通常是大多数数据处理系统所依赖的资源类型中最便宜的（其他类型主要是CPU，网络带宽和RAM）。因此，当使用任何设计良好的数据处理系统具有强一致的持久状态和体面的内存缓存层时，这个问题通常不像您想象的那么令人担忧。而且，许多有用的聚合不要求整个输入集被缓冲（例如，总和或平均），而是可以递增地执行，其中存储在持久状态中的小得多的中间聚合。
完整性鉴于我们通常没有很好的方法知道我们何时看到给定窗口的所有数据，我们如何知道窗口的结果何时可以实现？事实上，我们根本就没有。对于许多类型的输入，系统可以通过诸如MillWheel，Cloud Dataflow和Flink（我们在第3章和第4章中讨论的更多）中的水印之类的东西给出窗口完成的合理准确的启发式估计。但是对于绝对正确性至关重要的情况（再次考虑计费），唯一真正的选择是为管道构建者提供一种方式来表达何时需要实现窗口的结果以及如何随时间推移这些结果。

处理窗口完整性（或缺少窗口完整性）是一个引人入胜的主题，但最好在具体示例的背景下进行探讨，我们将在下面进行讨论。
在本章中，我们已经完成了以下内容：明确的术语，将“流式传输”的定义集中在指代以无限数据为基础构建的系统，同时使用更多描述性术语，如近似/推测结果，通常归类于“流媒体“伞。
此外，我们

1.强调了大规模数据集的两个重要维度：基数（即有界与无界）和编码（即表与流），后者将消耗本书后半部分的大部分内容。
2.评估精心设计的批处理和流媒体系统的相对功能，定位流实际上是批处理的严格超集，并且像流媒体不如批处理的Lambda架构这样的概念注定要在流媒体系统成熟时退休。
3.提出了流式系统所需的两个高级概念，分别是赶上并最终超越批次，分别是正确性和推理时间的工具。
4.确定了事件时间和处理时间之间的重要差异，描述了这些差异在分析数据时的差异所带来的困难，并提出了从完整性概念转向简单适应数据随时间变化的方法。
5.通过批处理和流引擎，查看有界和无界数据的常用主要数据处理方法，大致将无界方法分类为：时间不可知，近似，处理时间窗口和事件时间窗口。

接下来，我们深入研究梁模型的细节，从概念上看看我们如何分解四个相关轴上的数据处理概念：什么，何地，何时以及如何。我们还详细研究了在多个场景中处理一个简单，具体的示例数据集，突出了梁模型启用的多个用例，以及一些具体的API，以实现我们的基础。这些示例将有助于推动本章介绍的事件时间和处理时间的概念，同时另外探索水印等新概念。
为了完整起见，也许值得一提的是，这个定义既包括真正的流媒体实现，也包括微生物实现。对于那些不熟悉微型分析系统的人来说，他们是流式系统，它使用批处理引擎的重复执行来处理无界数据。 Spark Streaming是业界的典范。
熟悉我原来的“Streaming 101”文章的读者可能会记得，在引用数据集时，我更加强调鼓励放弃术语“流”。从未流行过，我最初认为这是由于它的吸引力和普遍的现有用法。然而，回想起来，我认为我完全错了。实际上，区分两种不同类型的数据集结构有很大的价值：表和流。实际上，本书的后半部分大部分都致力于理解这两者之间的关系。

如果你在我说完一次时你不熟悉我的意思，它指的是某些数据处理框架提供的特定类型的一致性保证。一致性保证通常分为三大类：最多一次处理，至少一次处理和完全处理。

请注意，此处使用的名称是指在管道生成的输出中观察到的有效语义，而不是管道可能处理（或尝试处理）任何给定记录的实际次数。出于这个原因，有时使用一次有效一次而不是一次，因为它更能代表事物的潜在本质。 Reuven在第5章中更详细地介绍了这些概念。
自从“Streaming 101”的最初出版以来，许多人向我指出，将处理时间放在x轴上并将事件时间放在y轴上会更直观。我同意交换两个轴最初会感觉更自然，因为事件时间似乎是处理时间的自变量的因变量。
然而，因为两个变量都是单调的并且密切相关，所以它们是有效的相互依赖的变量。所以我认为从技术角度来看你只需选择一个轴并坚持下去。数学令人困惑（特别是在北美之外，它突然变成了复数并且在你身上团结起来）。
这个结果真的不应该是令人惊讶的（但对我而言，因此我指出它为什么），因为我们在测量两种类型的偏斜/滞后时有效地创建了具有理想线的直角三角形。数学很酷。
我们将在第2章详细介绍对齐的固定窗口，在第4章中查看未对齐的固定窗口。
如果你在学术文献或基于SQL的流媒体系统中搜索得足够多，你还会遇到第三个窗口时间域：基于元组的窗口（即，窗口的大小以元素数量计算）。然而，基于元组的窗口本质上是处理时窗口的一种形式，其中元素在到达系统时被分配单调增加的时间戳。因此，我们不会进一步详细讨论基于元组的窗口。