浅谈流处理

流处理是一种大数据处理技术。它使用户能够查询连续数据流，并在从接收数据开始很短的时间内快速检测条件。检测时间从几毫秒到几分钟不等。例如，通过流处理，你可以通过查询来自温度传感器的数据流并检测温度何时达到冻结点来接收警报。

它还有许多名称：实时分析、流分析、复杂事件处理、实时流分析和事件处理。尽管一些术语在历史上存在差异，但现在工具（框架）在术语流处理下已经趋于一致。（有关框架的列表和本文的最后一节以了解历史，请参阅这个Quora问题）

它通过 Apache Storm 作为一种像 Hadoop 一样能够快速给出结果的技术得以普及，之后它被当作一种大数据技术采用。现在有很多竞争者。

为什么需要流处理

从处理数据中得出的见解(insights)是有价值的。这样的见解(insights)并非都是生来平等的。一些见解(insights)在发生后不久就具有很高的价值，并且随着时间的流逝，这种价值会迅速减少。流处理针对这样的场景。流处理的关键优势在于它能够更快地提供见解(insights)，通常在毫秒到秒之间。

下面是使用流处理的一些次要原因。

原因1:有些数据自然地以永无止境的事件流出现。要进行批处理，需要存储它、在某个时间停止数据收集并处理数据。然后你必须执行下一批操作，然后担心跨多个批进行聚合。相比之下，流处理永无止境的数据流更优雅、更自然。你可以检测模式、检查结果、查看多个焦点级别，还可以轻松地同时查看来自多个流的数据。

流处理天然地适合时间序列数据和随时间变化的检测模式。例如，如果你试图检测无限流中的web会话的长度（这是尝试检测序列的示例）。分批处理非常困难，因为某些会话将分为两批。流处理可以很容易地处理这个问题。

如果你退一步考虑，最连续的数据序列是时间序列数据：交通传感器、健康传感器、事务日志、活动日志等。几乎所有IoT数据都是时间序列数据。因此，使用天然适用的编程模型是有意义的。

原因2:批处理允许数据建立并尝试同时处理它们，而流处理立即处理进来的数据，因此处理随时间扩展。因此，流处理可以使用比批处理少得多的硬件。此外，流处理还允许通过系统负载削减进行近似查询处理。因此，流处理天然适合于近似答案足够多的用例。

原因3:有时数据很大，甚至无法存储。流处理允许你处理大型消防马型数据，并且只保留有用的位。

原因4:最后，有许多流数据可用（例如，客户事务、活动、网站访问），并且随着IoT用例（各种传感器）的增长，这些数据将更快。流式是一种更自然的模型，可以考虑和编程这些用例。

然而，流处理也不是所有用例都适用的工具。一个好的经验法则是，如果处理需要多次遍历完整数据或者具有随机访问（想想图数据集），那么流处理就很棘手。流处理中一个大的缺失用例是训练模型的机器学习算法。另一方面，如果处理可以通过一次遍历数据完成，或者具有时间位置（处理倾向于访问最近的数据），那么它非常适合于流式传输。

如何进行流处理

如果你想要构建一个处理流数据并做出实时决策的应用程序，您可以使用 工具 或者自己构建它。答案取决于你计划处理多少复杂性、希望扩展多少、需要多少可靠性和容错性等。

如果希望自己构建应用程序，请将事件放在消息代理主题（例如， ActiveMQ 、 RabbitMQ 或 Kafka ）中，编写代码以从 broker 中的主题接收事件（它们成为你的流），然后将结果发布 broker 。这样的代码称为 actor 。

但是，你可以使用流处理框架来节省时间，而不是从头开始编码上述场景。事件流处理器允许你为每个 actor 编写逻辑，连接 actor ，并将边缘连接到数据源。你可以直接向流处理器发送事件，也可以通过 broker 发送事件。

事件流处理器将通过收集数据、将数据传递给每个 actor 、确保它们以正确的顺序运行、收集结果、如果负载高则进行伸缩以及处理故障来完成艰巨的工作。例如 Storm 、 Flink 和 Samza 。如果你希望以这种方式构建应用程序，请查看相应的用户指南

自2016年以来，出现了名为流式SQL（ Streaming SQL 101 ）的新思想。我们称一种语言为“流式SQL”，它允许用户编写类似查询的 SQL 来查询流式数据。有许多流式SQL语言正在兴起。

WSO2 流处理器和 SQLStreams 等项目支持SQL超过五年了。

• Apache Storm 在2016年增加了对流式SQL的支持
• [自2016年以来，Apache Flink增加了对流式SQL的支持](Apache Flink added support for Streaming SQL since 2016)
• Apache Kafka在2017年增加了对SQL（他们称之为KSQL）的支持
• Apache Samza在2017年增加了对SQL的支持

使用流式SQL语言，开发人员可以快速地将流式查询合并到他们的应用程序中。到2018年，大多数流处理器支持通过流SQL语言处理数据。

让我们了解如何将SQL映射到流。流是移动中的表数据。设想一个永无止境的表，其中随着时间的流逝，新数据出现。流就是这样的一张表。流中的一个记录或一行称为事件。但是，它有一个模式，并且表现得像数据库行。为了理解这些观点， Tyler Akidau在Strata的演讲 是一个很好的资源。

编写SQL查询时，查询存储在数据库中的数据。然而，当你编写流式SQL查询时，你将它们写在现在的数据以及将来将要出现的数据上。因此，流式SQL查询永远不会结束。有问题吗？没有，因为查询的输出是流。一旦事件匹配，并且输出事件立即可用，事件将被放置在输出流中。

流表示可以通过逻辑通道的所有事件，并且永远不会结束。例如，如果我们在锅炉中有一个温度传感器，我们可以将传感器的输出表示为一个流。但是，经典的SQL摄取存储在数据库表中的数据，对其进行处理，并将其写入数据库表。相反，上面的查询将在数据流进入时接收数据流，并生成数据流作为输出。例如，假设锅炉流中每10分钟发生一次事件。当事件与筛选器匹配时，筛选器查询将立即在结果流中生成事件。

因此，你可以按照以下方式构建应用程序。通过直接发送或通过broker向流处理器发送事件。然后你可以使用“流式SQL”编写应用程序的流式部分。最后，将 Stream 处理器配置为对结果进行操作。这通过在流处理器触发时调用服务或通过将事件发布到 broker 主题并监听主题来完成。

有许多流处理框架可用。（参见Quora问题： 什么是最好的流处理解决方案？ ）.

我推荐一个我帮助构建的， WSO2 流处理器（ WSO2SP ）。它可以从 Kafka 、 HTTP 请求、消息 broker 中获取数据，并且可以使用“流式SQL”语言查询数据流。 WSO2SP 是 Apache 许可下的开源。只需要两台普通服务器，就可以提供高可用性，并且可以处理100K+TPS吞吐量。它可以在 Kafka 之上扩展到数百万个 TPS ，并支持多个数据中心的部署。

谁正在使用流式处理

一般来说，流处理对于我们能够检测问题并且我们有合理的响应来改善结果的用例是有用的。此外，在数据驱动的组织中，它还起着关键作用。

以下是一些使用案例

• 算法交易，股市监控
• 智能病人护理
• 监控生产线
• 供应链优化
• 入侵、监视和欺诈检测(例如Uber)
• 大多数智能设备应用：智能汽车，智能家居
• 智能电网-（例如，负载预测和离群值插头检测参见 智能电网，40亿个事件，吞吐在100Ks ）
• 交通监控，地理围栏，车辆和野生动物跟踪，例如TFL伦敦运输管理系统
• 运动分析-用实时分析来增强运动（例如，这是我们在真正的足球比赛中所做的工作（例如， 在足球广播上覆盖实时分析 ）
• 上下文感知促销和广告
• 计算机系统与网络监控
• 预测性维护(例如， 用于预测性维护的机器学习技术 )
• 地理空间数据处理

有关如何使用流处理的更多讨论，请参阅 用于构建流处理和实时应用程序的13种流处理模式

流处理的历史及其框架

流处理从提供对数据库中存储的数据的有条件查询的活动数据库开始已经有很长的历史了。第一个流处理框架之一是 TelegraphCQ ，它构建在 PostgreSQL 之上。

然后它们长成两个分支。

第一个分支称为流处理。这些框架允许用户创建查询图连接用户代码并使用许多机器运行查询图。例如 Aurora 、 PIPES 、 STREAM 、 Borealis 和雅虎 S4 。这些流处理架构关注可伸缩性。

第二个分支称为复杂事件处理。这些框架支持查询语言（比如现在我们使用流式SQL），并且关注针对给定查询进行有效的事件处理，但是通常运行在1-2个节点上。例如 ODE 、 SASE 、 Esper 、 Cayuga 和 Sidhi 。这些架构关注于高效的流算法。

这两个分支的流处理框架仅限于学术研究或股票市场等利基应用。流处理重新成为雅虎S4和Apache Storm关注的焦点。它被介绍为“类似于Hadoop，但是是实时的”。它成为大数据运动的一部分。

在过去的五年里，这两个分支合并了。我在前面的文章中详细讨论了这个问题。

如果您想了解更多关于流处理框架的历史，请阅读 Recent Advancements in Event Processing 和 Processing flows of information: From data stream to complex event Processing

希望这是有用的。如果你喜欢这篇文章，你也许会发现 Stream Processing 101 和 Patterns for Streaming Realtime Analytics .