背景

流数据处理，同时提供与批处理对应物相比的诸如新鲜度和更顺畅的资源消耗的益处，历史上与不可靠且具有近似结果的缺点相关。然而，这些缺点不是流媒体数据处理本身的固有特征，而是如何实现它们先前已经实现的文物。如Google Cloud DataFlow和Apache Beam近年来所示，流处理可以与批处理一样稳健。在本博客文章中，我们将讨论如何使流媒体数据处理强大。这里有很多想法都是基于磨机，据说谷歌云数据流建立。

问题分析

人们对流媒体数据处理的鲁棒性的主要担忧似乎围绕分布式系统中的公共部分失败情景居中，例如机器故障和网络中断。对于批处理，我们可以在部分故障时始终重新运行整个操作，最终重试后批处理将成功。但在流化处理中，重试看起来像什么？它会丢弃数据或创建重复数据吗？它会伤害流化处理的可扩展性和性能吗？

要回答这些问题，我们可以放大单个计算步骤。流数据处理可以被认为是由许多步骤组成的管道。如果我们可以保证单个计算步骤的稳健性，我们可以概括为整个管道。请注意，我们还需要一个跟踪所有计算并监视整个流水线的逻辑上集中控制服务。但我们不会有时间进入细节。

单个计算步骤

让我们看一下抽象级别的单个计算步骤，以便我们的讨论的结论可以应用于流媒体数据处理中的任何类型的工作。禁止，计算从上游输入，计算结果，并在下游发送结果，如图1所示。

> Figure-3

一旦低水印通过了商店数据点ID的时间戳，就可以清理那些数据点ID。这里的含义是我们还需要将时间戳存储为每个数据点ID。请注意，无需额外的写入清除存储。一旦计算对存储的数据点ID和结果有更新，它可以将其滚动到下一轮执行检查点。

缩放单个计算

即使对于单个计算步骤，我们也需要扩展到多台机器。在我们可以将上述单个计算扩展到在多台机器上并行运行之前，存在一些实际的考虑因素。

首先，我们需要一种方法来确定/发送数据点到当前计算步骤的实例。否则，前面步骤中的重传可以使数据点在不同的当前步骤实例中多次处理数据点，从而导致结果。这可以通过拍摄数据点ID的一致哈希来完成。显然，前面的计算步骤的每个实例需要知道能够适当地路由数据点的当前步骤的所有实例的地址。

当前步骤的每个实例都在一致哈希空间中的一系列值负责。如果特定范围的值变得过于流行，则相应的实例将在重负载下。让我们来看看拆分炎热实例的程序。有关插图，请参见图-4。

> Figure-4

• 控制服务首先讲述与此热门实例通信的前一步实例以暂停将结果发送到热门实例。
• 然后，它告诉热门实例暂停处理。
• 接下来，控制服务创建热门的副本实例。副本实例将读取HOT实例的存储内容，以便它们具有相同的恢复点。但是从现在开始，这两个实例都将写入后续检查点的新行。
• 之后，控制服务告诉两个实例恢复。对于以前突出的结果，下游将从两个实例接收它们。但正如我们之前所讨论的那样，下游很容易专作。
• 最后，控制服务告诉前面的步骤实例基于更新的一致哈希范围分配向两个实例发送到两个实例。

如果上述任何过程未能完成，则控制服务重试直至成功。它应该简单看出，可以以几乎相同的方式完成添加更多实例或减少实例。

最后的话

希望流媒体数据处理现在较少。而且你现在至少打开了可以使流数据处理可以稳健的想法。有关更多系统设计理念，请查看此列表[链接]。