原作者Srinath Perera 原文链接 水平有限，不足之处，欢迎指正
流处理是一种技术，他允许用户在接收到数据后的很短时间内快速检测到状况。这个检测时间段可能从几毫秒到几分钟不等。
例如，通过流处理，你能查询来自温度传感器的数据流并且在温度达到冰点的时候收到一个警告。
流处理也被称为实时分析，流分析，复杂事件处理(CEP)，实时流分析和事件处理。虽然这些术语由于历史原因有一些不同，但是许多系统已经融入了这些术语。
它是Apache Strom推广的大数据技术之一。并且现在出现了很多竞争者。
大数据确立了从数据处理中获得见解的价值。这种价值不会一直等价，一些见解在发生后不久就有更高的价值，并随着时间的推移迅速下降。流处理针对这种场景，流处理的关键优势在于他能更快的提供洞察力，通常在几毫秒到几秒之间。
流处理被引入并被推广为"像Hadoop这样的技术但可以更快的为你提供结果"。
- 一些数据本身来自于一个永远不会结束的事件流。用批处理的话，你需要存储它，并在某个时刻停止收集数据转而处理数据。之后你需要处理下一批数据然后担心多批次数据的聚合。与之相反，流处理可以优雅自然的处理无穷无尽的数据流。你可以检测状况，检查结果，查看多个层次的关注点，轻松地查看多个数据流的数据。
- 流处理非常适合处理时序数据并随着时间推移检测状况。例如，你正尝试在一个无穷无尽的流里检测一个web session的长度（也有一个例子是检测序列），这种场景使用批处理很难处理，因为一些session将会划分到多个批次，但是使用流处理就很容易。现在回过头来想一下，大部分连续数据序列是时间序列数据。例如，几乎所有的IoT数据是时间序列数据。因此使用这种编程模型是非常适合的（it makes sense to use a programming model that fits naturally）。
- 批处理让数据逐步累积到一起，一次处理他们。而流处理在数据进来的时候就处理，将处理分散到整个时间。因此流处理相对批处理，需要更少的硬件资源，此外流处理还能通过近似查询处理来实现系统减载，所以非常适合近似结果就够用的用例。
- 有的时候数据量非常大，甚至不可能存储他们。流处理能让你处理大流量数据，只保留有用的部分（Stream processing lets you handle large firehose style data and retain only useful bits.）。
- 最后，能获得很多流数据（如顾客交易，活动，网站访问）。流处理是一种更贴切的模型，可以用来思考和编写这些用例。
但是流处理不能满足所有用例，一个好的经验法则是如果处理需要多次遍历整个数据集或者需要随机访问（想一下图形数据集），那么使用流是很棘手的（译者注：流处理是一次便利，顺序访问）。机器学习训练模型也无法使用流处理。另一方面，如果处理能够单次数据传递完成，并且具有时间局部性（处理需要访问最近的数据），那么流处理就非常适合。
如果你想构建一个处理流数据的应用并且实时决策，你可以使用流处理引擎和自己构建这样的引擎。正确的选择取决于你计划处理的复杂程度，需要的扩展规模，以及相应的可靠性和容错能力要求。
如果你想自己构建一个应用，将事件放到一个broker topic中（例如ActiveMQ,RabbitMQ等），写代码从这个topic接收事件，之后再将结果发布到这个broker。这样的代码叫actor。
你可以使用一个流处理引擎来节省时间，而不是从头开始编写上述场景。一个流处理引擎允许你为每个actor编写逻辑，将actor连接起来，并将边连接到数据源。你可以将数据直接发送到流处理引擎，也可以通过broker代理发送。
一个流处理引擎负责收集数据，交付给每个actor,确保他们以正确的顺序运行，收集结果，当负载高的情况下进行扩展以及处理失败。流处理引擎有Storm, Flink, Samza等，如果你想用它们构建应用，请阅读它们各自的手册。
自从2016年，一个新的想法叫流式SQL出现了。他是一种语言，允许用户写类似SQL的查询语句进行流数据查询。有许多流式SQL语言正在兴起：
- 像WSO2 Stream Processor和SQLStreams这样的项目已经支持SQL超过五年。
- Apache Strom在2016年增加了流式SQL的支持
- Apache Flink在2016年增加了流式SQL的支持
- Apache Kafka在2017年增加了SQL的支持（被叫做KSQL）
- Apache Samza在2017年增加了SQL的支持
- Apache Beam在2017年增加了SQL的支持
使用流式SQL语句，开发者能够很快的将流查询融入到它们的应用中。到2018年，大部分流处理引擎都支持使用流式SQL语句处理数据。
让我们理解一下如何将SQL映射到流。想象一个永远不会结束的表，随着时间的推移不断的有数据出现。一个流就是这样数据运动的表。流中的一条记录或者一行被叫做一个事件，但是它有一个schema或者表现得像一个数据库记录行。想理解这些想法，Tyler Akidau在Stata的演讲是一个很好的学习资料
要了解SQL Streams的第一件事就是用流代替表。
当你写SQL查询的时候，你查询的数据是存在数据库中的。而写一个流式SQL查询的时候，你是为当前存在的数据和将要进来的数据编写他们。因此流式SQL查询永远不会结束，但这不会是一个问题？因为他的输出也是一个流。一旦数据匹配并且输出事件立即可用，这个事件将被放置到输出流中。
一个流表示能够通过一个逻辑管道发送的所有事件，并且永远不会结束。例如，我们有一个锅炉的温度传感器，我们可以将传感器的输出表示为流。传统的SQL摄入的数据存储在数据库的表中（处理这些数据，并将它们写到一个数据库表中），相反，上述查询将在数据流进入系统的时候摄取数据并产生数据流作为输出。例如我们假设锅炉流中每十分钟就有事件，当事件与过滤器匹配时，过滤查询将在结果流中生成一个事件。
所以，你能像下面这样构建你的应用。你可以直接或者通过broker发送事件到流处理引擎，然后你可以用流式SQL编写应用的流式部分。最后配置流处理器对结果执行操作。这可以通过由流处理器来触发调用一个服务或者发布事件到一个broker topic并监听这个topic。
当前存在很多流处理引擎（见Quora上的问题：什么是最好的流处理解决方案）。我将推荐我协助构建的一个WSO2流处理引擎。WSO2流处理引擎是Apache许可下的开源软件，只需两台商用服务器，他就可以提供高可用性，并且可以达到100k+ TPS吞吐量。他可以在Kafka上扩展到数百万的TPS。
简而言之，流处理对我们检测问题并具有合理响应来改善结果的用例非常有用。它还在事件驱动组织中发挥着关键作用。
下面是一些用例：
- 算法交易和股市监管
- 智能的病人护理
- 供应链优化
- 入侵，监视和欺诈检测(例如优步)
- 大多数智能设备应用：智能汽车，智能家具等。
- 智能电网-（例如负载预测和异常值插头检测，参见智能电网，400亿事件，百万事件每秒的吞吐量）
- 地理围栏(Geofencing),车辆和野生动物的跟踪-例如 TFL London
- 体育分析-通过实时分析增强运动（例如，这是我们对真正足球比赛所做的工作覆盖足球直播的实时分析）
- 环境感知促销和广告
- 计算机系统和网络监控
- 交通监控
- 预测性维护（例如，查看InfoQ的文章：用于预测性维护的机器学习技术）
- 地理空间数据处理
更多关于流处理的讨论，参见构建流处理和实时应用的13个模式 我希望这篇文章有用，想要了解更多流式SQL，请查看这篇文章流处理101:从SQL到流式SQL。想要尝试流处理，查看WSO2流处理器