Streaming 101: The world beyond batch

本文翻译至：https://www.oreilly.com/ideas...
很经典的文章，英文好的同学直接点击原文查看。

如今，有充分的理由，流数据处理在大数据中已占很大的比重:

• 企业渴望更及时的数据，而应用流计算是实现较低延迟的好方法
• 使用为此类永无止境的数据设计的系统，可以更轻松地驯服在现代业务中越来越普遍的海量的无界数据集。
• 随着数据的到达而进行处理，可以随着时间的推移更均匀地分散工作负载，从而产生更加一致且可预测的资源消耗。

尽管业务的驱动增加了人们对流计算的兴趣，但与批处理相比，现有的大多数流计算系统仍相对不成熟，这导致该领域最近出现了许多令人兴奋的积极发展。

至少可以说，作为过去五年来在Google从事大规模流处理系统工作的人（MillWheel，Cloud Dataflow），我对这种流计算精神感到高兴。我还想确保人们理解流处理系统的所有功能以及如何最好地使用它们，尤其是考虑到大多数现有批处理和流处理系统之间仍然存在语义上的差距。为此O'Reilly的人还邀请我为Strata + Hadoop World London 2015进行“跟批处理说再见”的书面演讲。由于我要讲的内容很多，因此我将其分为两篇文章：

• 流式处理101：第一篇文章将介绍一些基本的背景信息，并阐明一些术语，然后再深入探讨时域的详细信息以及批处理和流式处理的通用数据处理方法的高级概述。
• 数据流模型：第二篇文章将主要介绍Cloud Dataflow所使用的统一批处理+流处理的模型框架，并介绍适用于各种用例场景，然后，我将对现有的批处理和流系统进行简要的比较。

背景

首先，我将介绍一些重要的背景信息，这些信息将有助于构想我要讨论的其余主题。我们将从下面三部分展开：

• 术语：要准确谈论复杂的主题，需要对术语进行精确的定义。对于某些在当前使用中超出理解范畴的术语，我将尽力明确我在讲这些术语时的意思。
• 功能：我将谈谈流计算系统常有的缺点。我还将提出一个思路，且认为数据处理系统构建者需要采用这种思路，才能满足未来数据消费的需求。
• 时域：我将介绍与数据处理相关的两个主要时间域，展示它们之间的关系，并指出这两个域带来的一些困难。

术语：什么是流计算？

在继续之前，我想先解决一件事：什么是计算？如今，“流计算”一词用于表示各种不同的事物（为简单起见，到目前为止，我一直在宽松地使用它），这可能会导致误解真正的流计算或实际的流计算系统。因此，我愿意精确地定义该术语。

问题的症结在于，许多应该由它们描述的事物（例如，无界数据处理，近似结果等）过去都被被通俗地描述了执行引擎。术语缺乏精确性，使真正的流计算意味着什么，并且在某些情况下，流计算系统本身承受的负担是它们的功能仅限于经常被描述为“流计算”的特征，例如近似或推测性结果。鉴于精心设计的流传输系统具有与任何现有批处理引擎一样的能力（在技术上更多），可以产生正确，一致，可重复的结果，因此我更倾向于将流计算这一术语更为非常具体的含义：一种设计时要考虑到无界数据集的数据处理引擎。（为了完整起见，可能值得一提的是，该定义包括真正的流式处理和微批处理的实现）。

关于“流计算”的其他常见含义，以下是我经常听到的一些说辞，每种说法都有更精确的描述性术语，我建议我们作为一个社区应尝试采用：
1.无界数据Unbounded data：一种不断增长的，本质上无界的数据集。这些通常称为“流数据”。 但是，术语“流”或“批”在应用于数据集时会出现问题，因为如上所述，它们暗示了使用。实际上，所讨论的两种类型的数据集之间的差异是它们的局限性，因此最好对它们进行特征化用来捕获这种区别的术语。 因此，我将无限“流”数据集称为无界数据，将有限“批”数据集称为有界数据。
2.无界数据处理Unbounded data processing：正在进行的数据处理模式，应用于上述类型的无界数据。我个人喜欢使用流处理来描述这种类型的数据处理。自从批处理系统被构思出来以来，就已经使用批处理引擎的重复运行来处理无界数据（相反，设计良好的流系统不仅仅具有处理有限数据上的“批量”工作负载的能力）。这样，为了清楚起见，我将简称为无界数据处理。
3.低延迟，近似和/或推测性结果Low-latency, approximate, and/or speculative results:：这些结果最常与流引擎关联。传统上，批处理系统在设计时并未考虑到低延迟或推测性结果，这是历史的产物，仅此而已。当然，如果得到指示，批处理引擎完全有能力产生近似结果。因此，与上述术语相比，将这些结果描述为什么（低延迟，近似和/或推测性）要好于通过历史（通过流引擎）将其表现出来的方式更好。
从现在开始，每当我使用“流处理Streaming”一词时，就可以放心地假设我的意思是为无界数据集设计的执行引擎，仅此而已。当我指上述任何其他术语时，我将明确地说出无界限数据，无界限数据处理或低延迟/近似/推测性结果。这些是我们在Cloud Dataflow中采用的术语，我鼓励其他人也采取类似的立场。

关于流处理的极大限制

接下来，让我们来谈谈流处理系统可以做什么和不能做什么。流处理系统长期以来一直局限于提供低延迟，低准确性/推测性结果的小众市场，通常将其与功能更强大的批处理系统结合使用，以提供最终正确的结果，即Lambda体系结构。
对于尚未熟悉Lambda体系架构的人员，其基本思想是将流系统与批处理系统一起运行，两者都执行基本相同的计算。流式系统为您提供低延迟，近似的结果（由于使用近似算法，或者因为流式系统本身不能提供完成正确性），一段时间后，批处理系统也随之计算并为您提供正确的输出。它最初是由Twitter的Nathan Marz（Storm的创建者）提出的，最终获得了相当大的成功，因为它在当时是一个绝妙的主意。流引擎对准确性要求很高的部门来说有点令人失望，而批处理引擎本来就如您所期望的那样笨拙，因此Lambda也为您提供了一种方法来品尝自己的蛋糕并吃掉它。不幸的是，维护Lambda系统很麻烦：您需要构建，配置和维护、管理两个独立版本，然后以某种方式合并来自两个管道的结果。

作为花了很多年时间在高度一致的流处理引擎上工作的人，我还发现Lambda体系结构的整个原理有点不好。 毫不奇怪，我是杰伊·克雷普斯（Jay Kreps）在《质疑Lambda Architecture》一文问世时的忠实拥护者。 这是针对双模式执行的必要性的第一个引人注目的陈述。Kreps在使用像Kafka这样的可重播系统作为流系统连接时解决了可重复性的问题，并提出了Kappa体系结构，这基本上意味着要使用一个设计合理的系统来运行单个管道来处理手头的工作。我不认为该概念本身需要名称，但原则上我完全支持该想法。

老实说，我会更进一步。我认为精心设计的流系统实际上能提供了批处理功能的严格超集，所以今天应该不需要批处理系统。我对于Flink员工深怀这个想法并建立一个即使在“批处理”模式下也能运行的系统，感到很荣幸。

所有这一切的必然结果是，流处理系统的广泛成熟以及用于无界数据处理的强大框架相结合，将使Lambda体系结构及时降级到其所属的大数据历史的上古时代。 我相信现在已经成为现实，您实际上只需要两件事：

1.正确性-这使您与批处理相等
正确性归结为一致的存储，流处理系统需要一种随时间检查持久状态的方法（Kreps在他的“为什么局部状态是流处理的基本要素”中谈到过），并且必须设计得足够好，以在发生机器故障时保持一致。几年前，当Spark Streaming首次出现在公共大数据场景中时，这是一个在黑暗的流处理世界中保持一致性的灯塔。值得庆幸的是，此后情况有所改善，但值得注意的是，仍有许多流系统在没有强一致性的情况下仍在尝试。我真的不敢相信最多只能进行一次处理，但是确实如此。

重申一下，因为这一点很重要：一次处理必须具有高度的一致性，而正确性则必须具有一致性，这对于任何有机会满足或超过批处理系统功能的系统都是必需的。除非您真的不在乎结果，否则我恳请您避免使用任何无法提供高度一致状态的流系统。批处理系统如果能够产生正确的答案，则不需要您提前进行验证；不要在无法达到相同标准的流处理系统上浪费时间。

如果您想了解更多有关在流系统中获得强大一致性所需的知识，建议您阅读MillWheel和Spark Streaming论文。这两篇论文都花费大量时间讨论一致性。考虑到文献中和其他地方有关此主题的高质量信息，我将不在这些帖子中进一步介绍。

2.时间推理工具-这使您超出了批处理范围
良好的时间推理工具对于处理事件时间偏斜不同的无边界，无序数据至关重要。越来越多的现代数据集表现出这些特征，并且现有的批处理系统（以及大多数流系统）缺乏必要的工具来应对它们带来的困难。我将用完这篇文章的其余部分以及下一篇文章的大部分内容，来解释和关注这一点。

首先，我们将对时域的重要概念有一个基本的了解，之后，我们将更深入地了解变化的事件-时间偏差的无边界，无序数据的含义；然后，我们将在本文的其余部分中讨论使用批处理和流式系统进行有界和无界数据处理的常用方法。

事件时间与处理时间（event time vs. processing time）

无界数据处理，需要对所涉及的时间域有清楚的了解。在任何数据处理系统中，我们通常会关注两个时间域：
事件时间:即事件实际发生的时间。
处理时间:这是在系统中观察到事件的时间。

并非所有的用例都关心事件的发生时间，但很多情况下都如此。示例包括表征一段时间内的用户行为，大多数计费应用程序以及许多类型的异常检测，仅举几例。

在理想情况下，事件时间和处理时间将始终相等，事件在发生时会立即得到处理。但是，实际情况并非如此，事件时间与处理时间之间的偏差不仅不为零，而且还经常是基础输入源，执行引擎和硬件的特征的高度可变的函数，可能影响偏斜程度的因素包括：

• 共享资源限制，例如网络拥塞，网络分区或非专用环境中的共享CPU。
• 软件原因，例如分布式系统逻辑等
• 数据本身的特征，包括密钥分布，吞吐量差异或无序差异（例如，一架飞机中，人们将手机从离线切换到飞机模式中时）。

结果，如果在任何实际系统中绘制事件时间和处理时间的进度图，通常都会得到一些类似于图1中红线的图形。

斜率为1的黑色虚线表示理想情况下，处理时间和事件时间完全相等；红线代表现实。在此示例中，系统在处理时间开始时稍微滞后，在中间偏向理想位置，然后再次向末尾滞后。理想线和红线之间的水平距离是处理时间和事件时间之间的偏斜。这种偏差本质上是处理管道引入的延迟。

由于事件时间与处理时间之间的映射不是静态的，这意味着如果您关心数据的事件时间（即事件实际发生的时间），就不能仅在管道中何时观察到数据的上下文中分析数据。不幸的是，这是大多数为无界数据设计的现有系统的运行方式。为了应对无界数据集的无限性质，这些系统通常提供一些窗口化输入数据的概念。我们将在下面更深入地讨论窗口化，但这本质上意味着将数据集沿时间边界切成有限的片段。如果您关心正确性并有兴趣在事件时间的背景下分析数据，则不能像大多数现有系统那样使用处理时间（即处理时间窗口）来定义那些时间边界。由于处理时间与事件时间之间没有一致的关联，因此某些事件时间数据最终会在错误的处理时间窗口内结束（由于分布式系统固有的滞后性，多种类型的输入源的在线/离线特性等），将正确性扔出窗外。我们将在下面的许多示例以及下一篇文章中更详细地讨论这个问题。

不幸的是，在按活动时间进行窗口浏览时，图片也不完全是玫瑰色。在数据不受限制的情况下，混乱和可变偏斜会引发事件时间窗口的完整性问题：在处理时间和事件时间之间缺乏可预测的映射，如何确定在给定事件时间X内观察到所有数据的时间？对于许多现实世界的数据源，您根本无法做到。当今使用的绝大多数数据处理系统都依赖某种完整性的概念，这在将它们应用于无限制数据集时会处于严重的劣势。我建议，与其尝试将无界数据整理成最终完成的有限信息批次，不如设计能够使我们生活在这些复杂数据集带来的不确定性世界中的工具。新数据将到达，旧数据可能会被收回或更新，我们构建的任何系统都应能够独自应对这些事实，完整性的概念是一种方便的优化方法，而不是语义上的必要性。

在深入研究如何尝试使用Cloud Dataflow中使用的Dataflow模型构建这样的系统之前，让我们结束另一个有用的背景知识：通用数据处理模式。

Data processing patterns

此时，我们已经建立了足够的背景，可以开始研究当今有界和无界数据处理中常见的使用模式的核心类型；我们将在我们关注的两种主要引擎类型（批处理和流处理）的背景下研究这两种类型的处理以及相关的处理，在这种情况下，我基本上将微批处理与流式处理混为一谈，在此级别上，两者之间的差异并不十分重要）。

Bounded data

处理有界数据非常简单，并且每个人都可能熟悉，在下图中，我们从左侧开始，其中混乱的数据集，我们通过诸如MapReduce之类的数据处理引擎（通常为批处理，尽管设计良好的流处理引擎也可以正常运行）运行它，并在右侧最终生成具有更大内在价值的新结构化数据集：

当然，尽管作为此方案的一部分，您实际可以计算的内容也有无限的变化，但总体模型非常简单。更有趣的是处理无界数据集的任务。现在，让我们看一下通常处理无界数据的各种方式，首先是传统批处理引擎所使用的方法，然后是人们可以为无界数据设计的系统所采用的方法，例如大多数流或微批处理引擎。

Unbounded data — batch

批处理引擎虽然没有明确考虑到无界数据的设计，但自从最初想到批处理系统以来，就已经使用它来处理无界数据集，正如人们可能期望的那样，这种方法围绕将无界数据切成适合批处理的有界数据集的集合。

Fixed windows

使用批处理引擎重复运行来处理无界数据集的最常见方法是，将输入数据的窗口设置为固定大小的窗口，然后将这些窗口中的每一个作为独立的有界数据进行处理。特别是对于日志这样的输入源，事件可以写入名称和它们对应的窗口的目录和文件层次结构中，这种事情乍一看似乎很简单，因为您实际上已经执行了基于时间的随机化来获取数据提前进入适当的事件时间窗口。

但是实际上，大多数系统仍然要处理完整性问题：如果由于网络分区而导致某些事件在传送到日志的途中被延迟怎么办？如果您的事件是全球范围内收集的，并且必须在处理之前将其转移到一个公共位置怎么办？如果您的事件来自移动设备怎么办？这意味着可能需要采取某种缓解措施（例如，延迟处理，直到您确定所有事件都已收集完毕，或者在数据延迟到达时重新处理给定窗口的整个批次）。

Sessions

当您尝试使用批处理引擎将无限制的数据处理为更复杂的窗口化策略（例如会话）时，这种方法会进一步崩溃。会话通常被定义为由于不活动间隙而终止的活动时间段（例如，针对特定用户），使用典型的批处理引擎计算会话时，通常会遇到将会话拆分为多个批次的情况，如下图中的红色标记所示，可以通过增加批量大小来减少拆分的数量，但要以增加等待时间为代价，另一个选择是添加其他逻辑以拼接来自先前运行的会话，但以进一步复杂为代价。

无论哪种方式，使用经典的批处理引擎来计算会话都不理想，更好的方法是以流式方式建立会话，稍后我们将介绍。

Unbounded data — streaming

与大多数基于批处理的无界数据处理方法的即席性质相反，流系统是为无界数据构建的，如前所述，对于许多实际的分布式输入源，您不仅发现自己正在处理无界数据，而且还处理以下数据：

事件时间高度无序，这意味着如果要在发生数据的上下文中分析数据，则需要在管道中进行某种基于时间的混洗。
事件时间偏斜的变化程度不同，这意味着您不仅仅可以假设在给定的事件时间X内，始终会在时间Y的恒定ε内看到大部分数据。
处理具有这些特征的数据时，可以采取几种方法，我通常将这些方法分为四类：

• 时间无关
• 近似
• 按处理时间窗口化
• 按事件时间窗口化

现在，我们将花费一些时间来研究每种方法。

Time-agnostic

与时间无关的处理用于时间基本上无关紧要的情况，即所有相关逻辑都是数据驱动的，由于有关此类用例的一切都是由更多数据的到来决定的，因此，除了基本的数据交付外，流处理引擎实际上不需要支持任何特殊功能。结果，基本上所有现有的流系统都开箱即用地支持时间不可知的用例（一致性方面模数系统间的差异，当然对那些关心正确性的人而言），批处理系统也非常适合于无界限数据的时间不可知的处理，只需将无界数据切成任意序列的有界数据集并独立处理这些数据集即可，在本节中，我们将看几个具体示例，但是鉴于处理与时间无关的处理非常简单，因此在此之上将不会花费更多的时间。

Filtering

与时间无关的处理的一种非常基本的形式是过滤。 假设您正在处理Web流量日志，并且想要过滤掉并非来自特定域的所有流量，您将查看到达的每个记录，查看它是否属于限制条件的特定域，如果不属于，则将其删除，由于这种情况在任何时候都仅取决于单个元素，因此，数据源是无界的，无序的以及事件时间偏斜不同的事实是无关紧要的。

Inner-joins

另一个与时间无关的示例是内部联接（或哈希联接），在联接两个无界数据源时，如果您只关心两个源中的元素到达时的联接结果，则逻辑上就没有时间性元素。 看到一个来源的值后，您可以简单地将其缓冲到持久状态； 您只需在来自其他来源的第二个值到达时发出联接的记录。 （实际上，您可能需要某种针对未忽略的部分联接的垃圾回收策略，这可能是基于时间的。但是对于很少或没有未完成联接的用例来说，这样的事情可能不是问题。）

将语义转换为某种外部联接会引入我们讨论过的数据完整性问题：一旦看到联接的一侧，您如何知道另一侧是否会到达？说实话，所以您必须引入一些超时概念，其中引入了时间元素，时间要素本质上是窗口化的一种形式，我们稍后会详细介绍。

Approximation algorithms

方法的第二大类是近似算法，例如近似Top-N，流式K均值等。它们采用无限制的输入源并提供输出数据，如果您斜视它们，它们或多或少看起来像您希望得到。近似算法的优点是，根据设计，它们的开销很低，并且设计用于无界数据。缺点是它们的数量有限，算法本身通常很复杂（这使得很难构想出新算法），并且它们的近似性质限制了它们的实用性。

值得注意的是：这些算法通常在设计中确实需要时间（例如，某种内置的衰减），并且由于它们在到达元素时对其进行处理，因此该时间元素通常基于处理时间。这对于在近似值上提供某种可证明的误差范围的算法尤其重要。如果这些错误范围是根据有序到达的数据确定的，则当您以不同的事件时间偏斜向算法提供无序数据时，它们实际上没有任何意义。要记住的事情。

逼近算法本身是一个引人入胜的主题，但是由于它们本质上是时间不可知处理的另一个示例（以算法本身的时间特征为模），因此使用起来非常简单，因此鉴于我们当前的关注重点，因此不值得进一步关注。

Windowing

其余两种用于无界数据处理的方法都是窗口的变体。 在深入探讨它们之间的差异之前，我应该先弄清楚窗口是什么意思，因为我只是简短地谈了一，窗口化只是简单的概念，即获取一个数据源（无界或有界），并沿时间边界将其切成有限的块进行处理，下图显示了三种不同的窗口模式：

• 固定窗口：固定的窗口将时间分割成具有固定大小的时间长度的片段。通常（如图8所示），将固定窗口的段均匀地应用于整个数据集，这是对齐窗口的一个示例。在某些情况下，最好对数据的不同子集的窗口进行相移（例如，每个键），以使窗口完成负载随着时间的推移更均匀地分布，这是未对齐窗口的一个示例，因为它们在数据中会有所不同。
• 滑动窗口：固定窗口的概括，滑动窗口由固定的长度和固定的时间段定义。如果周期小于长度，则窗口重叠，如果周期等于长度，则您有固定的窗口。而且，如果周期大于长度，那么您将获得一种奇怪的采样窗口，该窗口仅查看一段时间内数据的子集。与固定窗口一样，滑动窗口通常是对齐的，尽管在某些用例中作为性能优化可能未对齐。注意，图8中的滑动窗口是按原样绘制的，以提供滑动处理的感觉。实际上，所有五个窗口将应用于整个数据集。
• 会话：动态窗口的一个示例，会话由事件序列组成，这些事件序列以不活动的间隔大于某个超时终止，会话通常用于通过将一系列与时间相关的事件组合在一起来分析一段时间内的用户行为，会话很有趣，因为它们的长度不能事先定义，它们取决于所涉及的实际数据，它们也是未对齐窗口的典型示例，因为会话实际上在不同的数据子集（例如，不同的用户）之间永远不会完全相同。

讨论的两个时间域-处理时间和事件时间-本质上是我们关心的两个，在这两个领域中，窗口化都是有意义的，因此，我们将详细介绍每个领域，并探讨它们之间的不同，由于处理时间窗口在现有系统中非常普遍，因此我将从这里开始。

Windowing by processing time

当按处理时间开窗时，系统实质上会将传入的数据缓冲到窗口中，直到经过了一定数量的处理时间为止。例如，对于五分钟的固定窗口，系统将缓冲数据五分钟的处理时间，然后将其在那五分钟内观察到的所有数据视为一个窗口，并将其发送到下游进行处理。

处理时间窗口具有一些不错的属性：

• 这很简单。该实现非常简单，因为您不必担心会在一定时间内乱码数据。您只需在事物到达时缓冲它们，然后在窗口关闭时将它们发送到下游。
• 判断窗口的完整性很简单。由于系统具有完全了解窗口的所有输入的知识，因此它可以对给定窗口是否完整做出完美的决策。这意味着在按处理时间进行窗口化处理时，无需以任何方式处理“最新”数据。
• 如果您想推断有关来源的信息，那么处理时间窗正是您想要的，许多监视方案都属于此类，想象一下，跟踪每秒发送到全局Web服务的请求数，为检测中断而计算这些请求的比率是对处理时间窗口的完美利用。

抛开优点，处理时间窗口化有一个很大的缺点：如果所讨论的数据具有关联的事件时间，则这些数据必须按事件时间顺序到达，前提是处理时间窗口要反映出这些事件实际发生的时间的事实，然而，按事件时间排序的数据在许多实际的分布式输入源中并不常见。

作为一个简单的示例，想象一下任何收集使用情况统计信息以供以后处理的移动应用程序。如果给定的移动设备离线任何时间（短暂的连接中断，在全国范围内飞行时的飞行模式等），则在该时间段内记录的数据要等到该设备重新上线后才能上传。这意味着数据可能会以几分钟，几小时，几天，几周或更长时间的事件时间偏差到达。当按处理时间进行窗口化时，从这样的数据集中得出任何有用的推断基本上是不可能的。

作为另一个示例，当整个系统运行状况良好时，许多分布式输入源似乎可以提供事件时间排序（或几乎如此）的数据。不幸的是，健康时输入源的事件时间偏斜较低，但这并不意味着它将始终保持这种状态。考虑一个全球服务，该服务处理在多个大洲收集的数据。如果跨带宽受限的跨大陆线路（不幸的是，这很常见）的网络问题进一步降低了带宽和/或增加了延迟，那么突然会有一部分输入数据开始出现比以前更大的偏斜。如果要按处理时间对数据进行窗口化处理，则窗口将不再代表窗口中实际发生的数据。相反，它们表示事件到达处理管道时的时间窗口，这是旧数据和当前数据的任意混合。

在这两种情况下，我们真正想要的是按照事件的时间对数据进行窗口化，从而对事件的到达顺序具有鲁棒性。 我们真正想要的是事件时间窗口。

Windowing by event time

当需要以有限的块观察数据源以反映那些事件实际发生的时间时，将使用事件时间窗口，这是窗口化的黄金标准，令人遗憾的是，当今使用的大多数数据处理系统都缺乏对它的支持（尽管任何具有像样的一致性模型的系统，例如Hadoop或Spark Streaming，都可以充当构建此类窗口系统的合理基础）。

下图显示了一个示例，该示例将无限制的源窗口化为一小时的固定窗口：

图中的实线表示两个感兴趣的特定数据，这两个数据都到达与它们所属的事件时间窗口不匹配的处理时间窗口，这样，如果针对关注事件时间的用例将这些数据放入处理时间窗口中，则计算结果将是不正确的。 正如人们所期望的那样，事件时间正确性是使用事件时间窗口的一件好事。

关于在无界数据上进行事件时间窗口化的另一件好事是，您可以创建动态大小的窗口，例如会话，而在固定窗口上生成会话时，不会观察到任何分裂（正如我们先前在会话示例中从“无界数据”中看到的那样） —批处理”部分）：

当然，强大的语义很少免费提供，事件时间窗口也不例外。事件时间窗口有两个明显的缺点，这是因为窗口（在处理时间中）必须经常比窗口本身的实际长度更长的寿命：

• 缓冲：由于延长了窗口寿命，因此需要更多的数据缓冲。幸运的是，持久存储通常是大多数数据处理系统所依赖的资源类型中最便宜的（其他主要是CPU，网络带宽和RAM）；因此，与使用任何设计良好，具有持久一致状态并具有良好内存缓存层的数据处理系统相比，此问题通常比人们可能想到的要少得多。而且，许多有用的聚合不需要缓冲整个输入集（例如，求和或平均），而是可以增量地执行，而持久性存储的中间聚合则小得多。
• 完整性：鉴于我们通常不知道何时查看给定窗口的所有数据，因此如何知道何时可以实现窗口结果？实际上，我们根本不这样做。对于许多类型的输入，系统可以通过诸如MillWheel的水印之类的东西（在第2部分中将详细介绍）来给出窗口完成的合理准确的启发式估计。但是，在绝对正确性至高无上的情况下（再次考虑帐单），唯一的真实选择是为管道构建器提供一种表达方式，使他们能够表达何时希望实现窗口的结果以及如何随着时间的推移细化这些结果。处理窗口的完整性（或缺乏窗口完整性）是一个有趣的话题，但是在具体示例的背景下也许是最好的探索方式，我们将在下一次探讨。

总结Conclusion

一下写了这么多，读到这里的朋友们：值得称赞！到这里，我们大概要讲的材料已经过了一半，因此可以退一步，回顾一下我到目前为止所讲的内容：

概括Recap

总而言之，在这篇文章中：

• 澄清术语，特别是将“流处理”的定义缩小到仅适用于执行引擎，同时对通常归入“流处理”范畴的不同概念使用更具描述性的术语，例如无界数据和近似/推测性结果。
• 评估设计良好的批处理和流处理系统的相对功能，认为流处理实际上是批处理的严格超集
• 提出了两个高级概念，它们是流系统赶上并最终超过批处理所必需的，分别是正确性和时间推理工具。
• 建立了事件时间与处理时间之间的重要区别，描述了这些区别在发生数据的上下文中分析数据时所带来的困难，并提出了从完整性的概念转向简单地适应随时间变化的数据的方法。
• 通过批处理和流处理引擎研究了当今常用的有界和无界数据的主要数据处理方法，将无界方法粗略地分类为：时间不可知，近似，按处理时间开窗和按事件时间开窗。

Next time

这篇文章为我将在第2部分中探讨的具体示例提供了必要的上下文。该文章大致包括以下内容：

• 从概念上看我们如何在四个相关轴上分解数据流模型中的数据处理概念：什么，在哪里，何时以及如何。
• 详细介绍了如何处理跨多个场景简单的、具体的示例数据集，重点介绍了数据处理模型启用的多个用例以及所涉及的具体API。这些示例将有助于带动本文中介绍的事件时间和处理时间的概念，同时还探索诸如水印之类的新概念。
• 将现有数据处理系统与两个职位所涵盖的重要特征进行比较，以更好地实现其中的受过教育的选择，并鼓励在缺乏的领域进行改进，我的最终目标是改善总体数据处理系统，以及流系统，尤其是整个大数据社区。

Should be a good time. See you then!