什么是流处理？

流处理是一种大数据技术。它用于查询连续的数据流，并在接收到数据后的一小段时间内快速检测条件。检测时间从几毫秒到几分钟不等。例如，通过流处理，可以在温度达到冰点时接收警报，查询来自温度传感器的数据流。

它也被称为许多名称：实时分析、流分析、复杂事件处理、实时流分析和事件处理。尽管有些术语在历史上有差异，但现在工具（框架）已经在术语流处理下聚合。（有关框架的列表，请参阅此Quora问题，有关历史，请参阅本文的最后一节）。

ApacheStorm将其推广为“像Hadoop这样的技术，但可以更快地提供结果”，之后它被作为一种大数据技术采用。现在有很多竞争者。

为什么需要流处理？

大数据确立了从数据处理中获得的洞察力的价值。这些见解并非都是平等的。有些见解在它发生后不久就更有价值了，价值随着时间的推移而迅速减少。流处理支持这样的场景，提供更快的洞察力，通常在距触发器几毫秒到几秒的时间内。

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

原因1：有些数据自然会以无休止的事件流的形式出现。

要进行批处理，需要存储它，在某个时间停止数据收集并处理数据。然后您必须执行下一批，然后担心在多个批之间聚合。相比之下，流媒体处理从不间断的数据流优雅而自然。您可以检测模式、检查结果、查看多个级别的焦点，还可以轻松地同时查看来自多个流的数据。

流处理自然地适合于时间序列数据和随时间变化的检测模式。例如，如果您尝试检测永无止境流中的web会话的长度（这是尝试检测序列的示例）。这是很难做的批，因为有些会议将分为两批。流处理可以轻松处理这个问题。

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

原因2：批处理让数据积累起来，并试图在数据流处理过程中立即处理它们，因此随着时间的推移，处理过程会分散。

因此，流处理可以使用比批处理少得多的硬件。此外，流处理还通过系统减载实现近似查询处理。因此流处理自然地适合于近似答案足够的用例。

原因3：有时数据量很大，甚至无法存储。

流处理允许您处理大型fire horse样式的数据，并且只保留有用的位。

原因4：最后，有很多流数据可用（例如，客户交易、活动、网站访问），而且随着物联网用例（所有类型的传感器）的出现，它们将增长得更快。

流是一个更自然的模型来考虑和编程那些用例。

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

如何进行流处理？

如果你想建立一个应用程序，处理流数据和采取实时决策，你可以使用一个工具或建立自己。答案取决于你计划处理多少复杂性，你想扩展多少，你需要多少可靠性和容错性等等。

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

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

事件流处理器将通过收集数据、将数据传递给每个参与者、确保它们以正确的顺序运行、收集结果、在负载较高时进行缩放以及处理故障来完成这项艰巨的工作。例如，斯托姆、弗林克和萨姆扎。如果您喜欢这样构建应用程序，请查看相应的用户指南。

自2016年以来，出现了一个名为Streaming SQL的新想法（有关详细信息，请参阅Streaming SQL 101一文）。我们调用一种语言，使用户能够编写类似SQL的查询，以作为“streaming SQL”语言来查询流数据。有许多流式SQL语言正在兴起。

• WSO2流处理器和SQLStreams等项目支持SQL超过5年
• Apache Storm在2016年增加了对流式SQL的支持
• 自2016年以来，Apache Flink增加了对流式SQL的支持
• Apache Kafka在2017年增加了对SQL（他们称之为KSQL）的支持，
• Apache Samza在2017年增加了对SQL的支持

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

让我们了解SQL如何映射到流。流是移动中的表数据。想象一个永无止境的表，随着时间的推移，新的数据会出现。小溪就是这样一张桌子。流中的一条记录或一行称为事件。但是，它有一个模式，其行为就像一个数据库行。为了理解这些想法，泰勒·秋田章男在斯特拉塔的演讲是一个很好的资源。

关于SQL流，首先要了解的是它用流替换表。

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

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

所以你可以按如下方式构建你的应用程序。通过直接发送或通过代理将事件发送到流处理器。然后你可以使用“streaming SQL”编写应用程序的流部分。最后，配置流处理器以对结果执行操作。这是通过在流处理器触发时调用服务，或通过将事件发布到代理主题并侦听该主题来完成的。

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

我推荐我帮助构建的WSO2流处理器（WSO2 SP）。它可以接收来自Kafka、HTTP请求、消息代理的数据，您可以使用“Streaming SQL”语言查询数据流。WSO2 SP是Apache许可下的开源软件。只需两台商用服务器，它就可以提供高可用性，并能处理10万多TPS的吞吐量。它可以在Kafka的基础上扩展到数百万TPS，并支持多数据中心部署。

谁在使用流处理？

一般来说，流处理在用例中是有用的，在用例中我们可以发现问题，并且我们有合理的响应来改进结果。而且，它在数据驱动的组织中扮演着关键角色。

下面是一些用例。

• 算法交易，股市监控，
• 聪明的病人护理
• 监控生产线
• 供应链优化
• 入侵、监视和欺诈检测（例如Uber）
• 大多数智能设备应用：智能汽车、智能家居。
• 智能电网（例如，负荷预测和异常值插头检测——见智能电网，40亿事件，范围为100K）
• 交通监控、地理围栏、车辆和野生动物跟踪-例如伦敦交通局交通管理系统
• 体育分析-通过实时分析来增强体育（例如，这是我们在真实足球比赛中所做的工作（例如，在足球广播上叠加实时分析）
• 上下文感知的促销和广告
• 计算机系统与网络监控
• 预测性维护（例如，用于预测性维护的机器学习技术）
• 地理空间数据处理

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

流处理的历史及其框架

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

然后它们在两条树枝上生长。

第一个分支称为流处理。

这些框架允许用户创建一个连接用户代码的查询图，并使用许多机器运行查询图。例如Aurora, PIPES, STREAM, Borealis, and Yahoo S4。这些流处理架构侧重于可伸缩性。

第二个分支称为复杂事件处理。

这些框架支持查询语言（比如我们现在使用的流式SQL），关注于对给定查询进行有效的事件匹配，但通常运行在1-2个节点上。其中的例子有ODE, SASE, Esper, Cayuga, and Siddhi。这些架构侧重于高效的流算法。

这两个分支的流处理框架仅限于学术研究或利基应用，如股票市场。流处理在Yahoo S4和Apache Storm中再次成为焦点。它被介绍为“like Hadoop, but real time”。它成为大数据运动的一部分。

在过去的五年里，这两个分部合并了。我在之前的一篇文章中已经详细讨论过这个问题。

如果您想了解流处理框架的历史，请阅读事件处理和信息处理流的最新进展：从数据流到复杂事件处理。

原文：https://medium.com/stream-processing/what-is-stream-processing-1eadfca11b97

本文：http://jiagoushi.pro/node/989

讨论：请加入知识星球或者微信圈子【首席架构师圈】