实时数据流处理的8个需求

0.摘要

需要实时处理大量数据流的应用正在推动传统数据处理基础设施的极限。这些基于流的应用包括华尔街的市场资讯处理和电子交易、网络和基础设施监控、欺诈检测以及军事环境中的指挥和控制。此外，随着廉价微型传感器技术所带来的“巨变”逐渐到来，我们预计会看到地球上所有有意义的物质都被“传感器标记”，并实时报告其状态或位置。这种对实际世界的传感器化将引领一片“绿地”，涌现出具有大容量和低延迟处理要求的新型监测和控制应用。

最近，出现了几种技术，包括现成的流处理引擎，专门解决高容量、实时数据处理的挑战，而无需使用自定义代码。同时，一些现有的软件技术，如数据库管理系统和规则引擎，也被营销部门“重新定位”，以解决这些应用的问题。

在本文中，我们概述了一个系统应该满足的八个要求，以在各种实时流处理应用中表现出色。我们的目标是为信息技术人员提供高级别的指导，让他们知道在评估备选流处理解决方案时该关注什么。因此，本文的目的类似于关系型数据库管理系统和在线分析处理的需求文档。在我们的要求框架下，我们还简要回顾了替代软件技术。本文试图保持中立，因此没有提及任何具体的商业产品。

1. 简介

在华尔街和其他全球交易所，电子交易量呈指数级增长。市场数据源可以每秒生成数万条消息。Options Price Reporting Authority（OPRA）汇总所有期权交易所的报价和交易，估计2005年峰值速率为每秒122,000条消息，并以每年翻倍的速度增长。这种庞大的流量增加正在压力或破坏传统的资讯处理系统。此外，在电子交易中，即使延迟一秒钟也是不可接受的，而引擎产生最新结果的交易操作将最大化套利利润。这个事实导致金融服务公司要求非常高容量的资讯处理，同时具有非常低的延迟。

在监控计算机网络的拒绝服务和其他安全攻击方面也存在类似的要求。从金融服务网络到手机网络的实时欺诈检测表现出类似的特征。随着时间的推移，工业设施的过程控制和自动化，从炼油厂到玉米片工厂，也将转移到这样的“消防水龙带”数据量和亚秒级延迟要求。

微传感器技术的进步正在带来一种“巨变”。虽然近来RFID技术获得了最多的关注，但还有各种价格、能力和占地面积不同的其他技术（例如mote和Lojack）。随着时间的推移，这种巨变将导致所有具有物质意义的物体都被传感器标记以实时报告其位置和/或状态。

军队一直是无线传感器网络技术的早期推动者和采用者。例如，美国陆军一直在研究给所有士兵配备生命体征监测器。此外，许多军用车辆已经配备了GPS系统，但尚未连接到闭环系统中。军队希望利用这项技术监测所有车辆的位置，并实时确定它们是否偏离航线。

基于其他传感器的监测应用将逐渐在非军事领域出现。标记将应用于游乐园客户的乘车管理和防止孩子走失。更复杂的“易通行”系统将允许基于拥堵的高速公路收费，同时优化都市地区的汽车路线。来自现有和新兴监测应用的“火水管”实时数据处理提供了一个重要的流处理挑战和机遇。

传统上，使用定制编码来解决高容量、低延迟的流处理问题。尽管“自己动手”的方法因其缺乏灵活性、高开发和维护成本以及对新功能请求的响应时间慢而普遍受到鄙视，但应用程序开发人员不得不采用这种方法，因为他们在传统现成软件方面运气不佳。

最近，一些传统软件技术，如数据库管理系统和规则引擎，已被重新定位并重新包装以适应这个应用领域。此外，一种新的基础设施软件类别——流处理引擎（例如，Aurora 、STREAM 、TelegraphCQ ）已经出现，专门支持高容量、低延迟的流处理应用。

在本文中，我们描述了一个系统必须具备的八个特性，才能在各种实时流处理应用程序中表现出色。我们的目标是为信息技术人员提供高层次的指导，以便他们在评估选项时知道该寻找什么。因此，本文与早期针对关系型DBSMs和在线分析处理的需求的论文具有相似的目标。

我们在下一节中将这些特性作为八条规则的集合呈现。然后我们在第三节中回顾替代技术，并总结它们在实时流处理方面的表现如何。最后，我们在第四节中做出最后的结论。

2.八项实时流处理规则

规则1：保持数据运动

为了实现低延迟，系统必须能够在关键处理路径中执行消息处理，而不需要进行昂贵的存储操作。存储操作会为过程增加大量不必要的延迟（例如，提交数据库记录需要写入日志记录）。对于许多流处理应用程序来说，要求在消息处理之前执行这样一个耗时的操作既不可接受，也不必要。相反，消息应该在流中“即时”处理。请参见下图，了解这种直通式处理范例的架构示意图。

“直通式”消息处理，可选存储。

另一个延迟问题存在于被动系统中，这些系统在进行处理之前等待应用程序告诉它们该做什么。被动系统要求应用程序不断轮询感兴趣的条件。不幸的是，轮询会增加系统和应用程序的额外开销，并增加延迟，因为（平均而言）轮询间隔的一半会加到处理延迟中。主动系统通过集成内置的事件/数据驱动处理能力来避免这种开销。

实时流处理系统的第一个要求是在流中处理消息，无需将其存储以执行任何操作或操作序列。理想情况下，该系统还应使用主动（即非轮询）处理模型。

规则2：使用SQL在流数据上进行查询（StreamSQL）

在流应用程序中，必须使用某种查询机制来查找感兴趣的输出事件或计算实时分析。历史上，在流应用程序中，通常使用C ++或Java等通用语言作为开发和编程工具。不幸的是，依赖低级编程方案会导致长时间的开发周期和高维护成本。

相比之下，使用高级语言（如SQL）处理移动实时数据非常理想。 SQL已经成为数据库语言的持久标准超过三十年了。 SQL之所以能成功地表达复杂的数据转换，是因为它基于一组非常强大的数据处理原语，可以进行过滤、合并、相关和聚合。 SQL明确了这些基元如何相互作用，使得它的含义可以独立于运行时条件而轻松理解。此外，SQL是一个广泛传播的标准，被数十万个数据库程序员所理解，并且由目前所有重要的商业DBMS实现，由于其功能、强大和相对易用性的结合。鉴于全球已经安装和运行了数百万个运行SQL的关系数据库服务器，因此利用熟悉的SQL查询模型和运算符并简单地扩展它们以对连续数据流执行处理是很有意义的。通过使用SQL风格的构造来捕获应用程序逻辑，可以降低编程成本并提高上市时间。

为了满足流处理的独特需求，需要StreamSQL，这是SQL语言的一种变体，专门设计用于处理连续的数据流。StreamSQL应该通过添加丰富的窗口构造和流特定的运算符，扩展标准SQL的语义（假定记录在有限的存储数据集中）。

虽然传统的SQL系统在到达表的末尾时知道它已经完成计算，但是由于流数据永远不会结束，因此流处理引擎必须指示何时完成此类操作并输出答案。窗口构造通过定义多消息运算符（例如聚合或连接）的“范围”来实现此目的。

窗口应该可以根据时间（可能是最常见的用例）、消息数量或消息中其他属性的断点来定义。这样的窗口应该能够从当前窗口滑动可变量（例如，一个窗口可以是五个时刻宽度，下一个窗口可以从当前窗口滑动一个时刻）。因此，根据窗口大小和滑动参数的选择，窗口可以是不相交的或重叠的。下图展示了滑动窗口的示例。

窗口定义了操作的范围。该窗口的大小为5条消息，并且每次执行相关运算符时，该窗口滑动1个。连续的窗口重叠

此外，需要一些在标准SQL中不存在的新的面向流的操作符。一个例子是“合并”（Merge）操作符，它以对数据消息的到达时间和顺序敏感的方式多路复用来自多个流的消息。

最后，操作符集必须是可扩展的，以便开发人员可以轻松地在系统内实现新的处理功能（例如，在流数据上实现专有的分析算法）。

第二个要求是支持具有内置可扩展流定向基元和运算符的高级“StreamSQL”语言。

规则三：处理流的缺陷（延迟、丢失和乱序数据）

在传统数据库中，数据在被查询之前总是存在的，但在实时系统中，由于数据从未存储，基础设施必须提供处理延迟、丢失或乱序数据的功能。

其中一个要求是能够超时单个计算或操作。例如，考虑一个简单的实时业务分析，它计算25个证券的最后一个标记的平均价格。只需要等待每个证券的标记，然后输出平均价格。然而，假设其中一个25个股票的交易量较小，并且该股票的标记不会在接下来的10分钟内收到。这是一个必须阻塞等待输入完成计算的计算示例。这些输入可能会及时到达，也可能不会。实际上，如果证券交易委员会下令停止交易其中的任何一个25个证券之一，则计算将无限期地阻塞。

在实时系统中，让程序无限期等待从来不是一个好主意。因此，任何可能阻塞的操作都必须允许超时，以便应用程序可以继续处理部分数据。任何实时处理系统必须为任何潜在的阻塞操作设置这样的超时。

处理乱序数据引入了类似的挑战。通常情况下，时间窗口（例如 [9:00 - 9:01]）会在收到时间戳大于窗口关闭时间的消息时关闭。但是，这种操作假定数据按照时间戳的顺序到达，这并不一定是实际情况。为了处理乱序数据，必须提供一种机制，允许窗口在额外的时间内保持打开状态。在 Aurora 中指定的一种解决方案是“弹性期”的概念。

第三个需求是具有内置机制来提供对流“缺陷”的韧性，包括缺失和乱序数据，这些通常存在于实际数据流中。

规则4：产生可预测的结果

流处理系统必须以可预测的方式处理时间序列消息，以确保处理结果是确定性的和可重复的。

例如，考虑两个数据流，一个包含具有字段的TICKS数据：

TICKS (stock_symbol, volume, price, time)

另一个是SPLITS数据流，它指示股票何时拆分，格式如下：

SPLITS (symbol, time, split_factor)

一个典型的流处理应用是为一组股票生成实时的拆分调整后的价格。价格必须根据已经发生的分割系数进行调整。只有当消息以升序时间顺序被系统处理时，才能生成正确的答案，而不考虑消息到达系统的时间。如果分割消息被无序地处理，则涉及的股票的拆分调整后的价格将在一个或多个时间段上是错误的。请注意，仅在输入到系统之前对消息进行排序是不足够的——只有在整个处理管道中维护时间顺序和确定性处理，才能保证正确性。

能够产生可预测的结果也从容错和恢复的角度非常重要，因为重播和重新处理相同的输入流应该无论执行时间如何都会产生相同的结果。

第四个要求是流处理引擎必须保证可预测和可重复的结果。

第五条规则：整合存储和流数据

对于许多流处理应用程序，比较“现在”和“过去”是一项常见任务。因此，流处理系统必须也提供对存储状态的仔细管理。例如，在在线数据挖掘应用程序（例如检测信用卡或其他交易欺诈）中，识别活动是否“不寻常”需要在一段时间内收集通常的活动模式，将它们汇总为“签名”，并在实时中与当前活动进行比较。为了实现这个任务，历史数据和实时数据需要在同一个应用程序中集成，以进行比较。

这个要求的一个非常流行的扩展来自于具有电子交易应用程序的公司，他们想编写一个交易算法，然后在历史数据上测试它，以查看它在其他情况下的表现如何。当算法在历史数据上运行良好时，客户想无缝切换到实时数据，即在不修改应用程序代码的情况下。

自动无缝切换的另一个原因是希望从过去某个时间点（例如两小时前）开始计算某种业务分析，赶上实时，并在实时数据上无缝继续进行计算。这需要自动从历史数据切换到实时数据，而不需要人为干预。

对于低延迟的流数据应用程序，通过客户端-服务器数据库连接来高效存储和访问持久状态会增加过多的延迟和开销。因此，状态必须存储在与应用程序相同的操作系统地址空间中，使用嵌入式数据库系统。因此，StreamSQL命令的范围应该是实时流或嵌入式数据库系统中的存储表。

第五个要求是具备有效地存储、访问和修改状态信息的能力，并将其与实时流数据结合使用。为了实现无缝集成，系统在处理这两种类型的数据时应使用统一的语言。

规则6：保证数据安全和可用性

为了保护关键信息的完整性并避免实时处理中的中断，流处理系统必须使用高可用性（HA）解决方案。

高可用性是大多数流处理应用的关键问题。例如，几乎所有金融服务公司都希望他们的应用程序始终保持运行状态，无论发生什么情况。如果发生故障，应用程序需要故障转移至备份硬件并继续运行。重新启动操作系统并从日志中恢复应用程序会产生过多的开销，因此对于实时处理来说是不可接受的。因此，“Tandem-style”热备份和实时故障转移方案 [6]是这些类型应用程序的最佳合理替代方案，其中辅助系统定期将其处理状态与主系统同步，并在主系统失败时接管。该HA模型如图所示。

“Tandem-style” 热备份和故障转移可以确保实时流处理的高可用性。

第六个要求是确保应用程序在任何时候都处于运行状态，数据的完整性得以维护，即使出现故障。

规则7：自动分区和扩展应用程序

随着低成本的通用集群具有有利的性价比特性，分布式操作变得越来越重要。因此，在处理的输入流量或处理的复杂性增加时，应该能够将应用程序分割到多台计算机上实现可伸缩性，而无需开发人员编写底层代码。

流处理系统还应支持多线程操作，以利用现代多处理器（或多核）计算机架构。即使在单处理器机器上，也应支持多线程操作以避免因外部事件而阻塞，从而促进低延迟。

不仅必须轻松地提供可扩展性，而且生成的应用程序应自动透明地在可用计算机上进行负载平衡，以便应用程序不会被单个超负荷计算机拖垮。

第七个要求是具有在多个处理器和机器之间分布处理以实现增量可扩展性的能力。理想情况下，分布应该是自动和透明的。

第八个规则是实时处理和响应

没有上述规则单独存在时都不能让应用程序做出任何差异，除非应用程序可以“跟得上”，即能够在COTS硬件上以微秒到毫秒的延迟范围内处理数万到数十万条流数据。

为了实现如此高的性能，系统应该有一个高度优化的执行路径，使得开销与有用工作的比例最小化。正如前面规则所示，一个关键问题是通过将所有关键功能（如处理和存储）集成到单个系统进程中来最小化“边界穿越”的数量。但这本身并不足够；所有系统组件都需要考虑高性能设计。

为确保系统能够满足这一要求，任何具有高速流应用程序的用户都必须仔细测试他所考虑的任何产品在目标工作负载上的吞吐量和延迟。

第八个要求是流处理系统必须具备高度优化、最小化开销的执行引擎，以满足高容量应用程序的实时响应需求。

3.软件技术与流处理

3.1 基本架构

除了自定义编程外，还有至少三种不同的软件系统技术可以潜在地应用于解决高容量低延迟的流处理问题。它们分别是数据库管理系统（DBMS）、规则引擎和流处理引擎，我们将在下面进行讨论：

• 数据库管理系统（DBMS）由于其可靠存储大型数据集和高效处理人工发起的查询的能力而被广泛使用。如果有足够的主存，主存储器DBMS可以通过避免大多数操作使用磁盘来提供比传统DBMS更高的性能。

  流数据直接或通过加载应用程序输入到DBMS中。一组应用程序可以操纵DBMS数据。客户端可以使用这些预构建的应用程序，通常带有运行时参数，并且还可以使用嵌入式SQL调用将附加应用程序编码为通用语言，如C ++或Java。

• 规则引擎最早出现在20世纪70年代，当时人工智能界最初提出了诸如PLANNER和Conniver之类的系统。稍后的更广泛的规则引擎是Prolog（1980年代），还有几个更近期的例子（例如OPS5 ）。规则引擎通常接受条件/动作对，通常使用“如果-那么”符号表示，监视输入流以获取任何感兴趣的条件，然后在满足条件时采取适当的操作。换句话说，规则引擎执行存储在规则库中的一组规则。

  规则库为规则提供持久存储。当流数据进入系统时，它们立即与现有规则匹配。当规则的条件匹配时，规则被称为“触发”。然后采取相应的操作可能会向外部应用程序产生警报/输出，也可能仅修改内部变量的状态，这可能会导致进一步的规则触发。

• 流处理引擎(SPEs)专门设计用于处理流数据，并最近作为第三种选择受到关注。它们的基本架构如图所示。SPEs可以像SQL处理一样处理传入的消息，而无需必要时存储它们。显然，为了在必要时存储状态，可以在系统中嵌入传统的SQL数据库以提高效率。SPEs使用专用原语和构造（例如时间窗口）来表达面向流的处理逻辑。

(i) 数据库系统，(ii) 规则引擎和 (iii) 流处理引擎的基本架构。

接下来，我们将根据第2节提出的要求对这些系统进行简要评估。

3.2 它们的优缺点如何？

DBMS使用“存储后处理”模型，输入数据首先存储，可能被索引，然后再进行处理。主存储DBMS更快，因为它们可以避免大部分更新操作涉及磁盘，但否则使用相同的基本模型。DBMS是被动的，即它们等待应用程序告诉它们该做什么。一些DBMS具有内置的触发机制，但众所周知，触发器的可扩展性较差。另一方面，规则引擎和SPE都是主动的，并且不需要在处理之前存储任何数据。因此，DBMS不会使数据保持流动，而规则引擎和SPE会。

SQL是设计用于有限大小的存储数据，因此需要扩展才能处理潜在的无界时间序列数据流。SQL/Temporal仍处于起步阶段，DBMS供应商实现的SQL仅支持窗口操作的基本概念。规则语言需要类似的扩展，以便它们可以表达对时间感兴趣的条件。此外，规则语言还需要聚合的概念，在许多流处理应用中都是常见操作。因此，SPE支持对流进行SQL样式处理，而DBMS和规则引擎则不支持。

在规则引擎和SPE中，编写可能阻塞的操作是可能的，但也很容易支持超时。在DBMS解决方案中，应用程序必须明确指定其轮询行为以模拟超时的效果并接收部分数据。同样，DBMS触发系统没有明显的超时方式。对于DBMS来说，无序数据也存在类似的挑战。总体而言，规则引擎和SPE相比于DBMS更容易处理流数据的不完美性。

为了产生可预测的结果，SPE或规则引擎必须具有利用输入消息的时间戳顺序的确定性执行模式。DBMS对这一要求特别困难。ACID事务提供的同步和正确性保证针对传统数据库应用程序的要求，并且单独不能确保流处理的可预测和确定性执行语义。主要原因是DBMS不需要可重复的执行，而是强制实施较弱的可串行化条件。在没有任何内置正确性标准的情况下，独立应用程序的执行顺序必须由某些外部软件控制，这可能会对性能和复杂性产生不利影响。

无缝地集成存储和流数据对DBMS和规则引擎都是问题。存储状态是DBMS自然而然的功能。然而，正如之前所述，DBMS无法很好地处理流数据。即使在流应用程序中仅用于状态存储，客户端-服务器DBMS也将无效，因为它将产生高延迟和开销。因此，只有在DBMS可以嵌入应用程序时，DBMS解决方案才是可接受的。

3.3 表格结果

在表1中，我们总结了本节讨论的结果。表中的每个条目包含以下四个值之一：

• Yes：架构自然支持该功能。
• No：架构不支持该功能。
• Possible：架构可以支持该功能。应检查供应商是否符合要求。
• Difficult：架构可以支持该功能，但由于需要进行巨大的修改，因此难度较大。应检查供应商是否符合要求。

SPEs提供了最好的功能，因为它们是从头开始设计和优化以满足流处理的要求。DBMS和规则引擎最初是为不同类别的应用程序设计的，具有不同的基本假设和要求。因此，这两个系统根本上是将流处理“硬塞”到它们自己的模型中。因此，不足为奇地看到它们在这个领域有根本性的局限性。特别是，两个系统都无法有效且统一地处理流数据和存储数据。

4.结论

存在大量现有和新兴应用程序需要对高容量数据流进行复杂的实时处理。虽然这些应用程序传统上是通过定制编码的“点解决方案”来服务的，但专门针对它们的基础设施软件也最近开始在研究实验室和市场上出现。

基于我们对各种流应用程序的经验，我们提出了八条规则来描述实时流处理的要求。这些规则用于说明任何用于高容量低延迟流处理应用程序的系统所需的必要功能。我们还观察到，传统的系统软件未能满足这些要求，这证明了SPE的必要性和相对优势。

本文由闻数起舞翻译自论文 《The 8 requirements of real-time stream processing》https://dl.acm.org/doi/10.1145/1107499.1107504