无处不在的流计算到底是什么？终于有人讲明白了(附导图)

作者：周爽

来源： 大数据DT（ID：hzdashuju）

自从互联网和物联网诞生以来，人与人、人与物、物与物之间的互联和互动愈加紧密和频繁，大量丰富多彩的数据在互联和互动的过程中产生。海量的数据洪流将我们的时间和空间愈占愈满，以至于让我们开始疲于奔命，鲜有时间和能力再去感受和思考那些一瞬间的百万种可能。

武林江湖中留传着一句至理名言：“天下武功，无坚不摧，唯快不破！”。

更快更完整地获取数据，更快更充分地挖掘出数据价值，业已成为大数据时代各行各业的共识。 在线系统监控、移动数据和物联网、金融风控、推荐系统等，虽然行业各不相同，但是它们有个共同点—— “实时流计算”技术在这些领域发挥着越来越重要的作用。

01 “流”好在哪里？

“流”是一种非常好的编程模式。

▲图1：代表流计算模式的有向无环图DAG

首先，“流”与“异步”不谋而合。

“流”的各个节点通过队列传递消息，不同节点的执行正好就是完全异步的。并且由于有队列隔离，不同节点的执行完全不用考虑并发安全的问题。“流”在内部执行时是异步和并行的，能最大限度提高资源使用效率，提高程序执行性能。

可以说，“流”是“异步”的一种重要表现方式，“异步”则是“流”在执行时的内禀性质。

▲图2：“流”和“异步”，傻傻分不清楚！

其次，如果“流”的执行节点间使用的是阻塞队列 ，那么整个流的各个执行环节就天然地带有了反向压力能力，让我们不必担心很多异步系统在高负载而又临时处理能力不足时造成的OOM问题。

再次，“流”能够非常自然地描述业务执行的流程。 不管是大到整个产品线的各个服务模块，还是小到每个服务模块中的具体实现步骤。就像“分形”一样，“流”能够做任意细力度的划分。这是一种非常普遍的描述事情发生过程的模式。

最后，通过类似于Kafka这样消息中间件的隔离，可以非常清晰地定义模块和模块之间的边界 ，从设计模式中高内聚、低耦合的角度来看，是一种非常不错的实践！

02 流计算解决了什么问题？

总的来说，我们使用流计算主要是为了计算以下几类问题。

1. 流数据操作

流数据操作可以说是流计算系统与生俱来的能力，它本身是针对数据流的转化或转移处理，所以实现和使用起来都相对更加直观。

流数据操作的内容主要包括了三类： 对数据进行清洗、规整和结构化 ，对不同来源的数据进行关联及合并，以及在不同系统之间搬运数据。这三类操作通过一些常用的流式API就可以实现。

2. 单点特征计算

一个事件中包含的用户是否在黑名单中？发生事件的设备是否是模拟器？温度传感器传来的温度事件是否已经超出正常温度范围？发送消息设备的IP是否是代理？一次交易的金额是否属于大额交易？手机是否有SIM卡？

诸如此类的问题，要么可以通过黑白名单，要么能够通过特定的规则计算而得到答案，实现起来相对简单，所以 我们将这类特征计算称之为单点特征。

3. 时间维度聚合特征计算

相同设备的1小时内注册事件次数、相同银行卡号的7天交易事件次数、过去30天内同一IP段上交易金额、过去1分钟高温事件的次数、过去5分钟日志告警事件的次数……

诸如此类特征在诸如风控、预警、监控等各种场景都非常广泛的应用。分析不难发现，这类特征都有个共同特点，它们均需要在时间维度对数据进行聚合运算。因此， 我们称这类特征为时间维度聚合特征。

4. 关联图谱特征计算

除了时间维度的聚合分析外，我们还经常进行“空间”维度的聚合分析。不过 这种分析有个更专业的名字，即“关联图谱”分析。

比如在一些风控场景中，我们需要计算用户账户使用IP的个数、同一手机号码发生在不同城市的个数、同一设备上关联用户的数目、同一用户关联设备的数目、同一推荐人推荐的用户数等特征。

以设备关联用户数为例，如果某个设备上注册的用户很多，那么它的风险就比较高，毕竟正常情况下我们都只会用自己的手机注册自己的账号，而不会是帮其他几十、上百人注册账号的。

5. 事件序列分析

数据流中的数据不是单纯在时间上有着先来后到的关系，而是在数据和数据之间也有着联系。

考虑用户在手机上安装新APP的过程，它可能是先点击了某个广告链接，然后下载并安装了APP，最后成功注册了账号。从“点击”到“下载”，再到“安装”和“注册”，这就完成了一次将广告转化为用户的过程。

再比如在网络欺诈识别场景中，如果用户在新建账号后，立马发生大量交易行为。那么这种“新建账号”到“10分钟内5次交易”的行为就是种非常可疑的行为了。

诸如此类从数据流表示的事件流中，检测并筛选出符合特定模式或行为的事件序列的过程，我们称之为 复杂事件处理 （Complex Event Processing，简称为CEP）。 CEP也是流计算经常被用来解决的问题。

6. 模型学习和预测

随着流计算越来越流行和普及，越来越多的原本主要针对离线批式数据的统计和机器学习模型也被用于流数据。

比如在风控系统中，当我们计算好特征后，还需要把这些特征输入评分模型进行风险评分。根据不同的使用场景，使用的评分模型可能是基于规则的模型，也可能是基于机器学习的模型。传统的机器学习模型主要通过离线训练而来，但现在越来越多的模型会直接基于流数据在线训练和更新。

再比如在异常检测应用中，我们会在线统计并估计变量的分布参数，然后根据训练出的分布模型判断变量之后的取值是否属于异常。 这种同时在线更新和预测的做法，在流计算应用中也越来越常见。

03 流数据状态和流信息状态

在流计算系统中，“ 状态 ”是非常重要的方面。甚至从各种开源流计算框架的发展历史来看，我们会发现大家对实时流计算中的“状态”问题也是一点点逐步才弄清楚的。

关联操作中临时保存的窗口数据、实现时间维度聚合特征、关联图谱特征、CEP中有限状态机、统计或机器学习模型的参数估计，实时流计算系统需要的最主要的几个计算目标，无不与“状态”有关。但， 这些状态是有区别的！

我们将流在执行过程中涉及到的状态，分为两类： 流数据状态 和 流信息状态 。

• 流数据状态。 在流数据处理的过程中，可能需要处理事件窗口、时间乱序、多流关联等问题，在解决这些问题的过程中，通常会涉及到对部分流数据的临时缓存，并在处理完后将其清理。我们将临时保存的部分流数据称为“流数据状态”。

• 流信息状态。 在对流数据的分析过程中，会得到一些我们感兴趣的信息，比如时间维度的聚合数据、关联图谱中的一度关联节点数、CEP中的有限状态机等，这些信息可能会在后续的流数据分析过程中被继续使用，从而需要将这些信息保存下来。同时在后续的流数据处理过程中，这些信息还会被不断地访问和更新。我们将这些分析所得并保存下来的数据称为“流信息状态”。

将实时流计算应用中的状态分为了“流数据状态”和“流信息状态”。可以说是从两个不同的维度对“流”进行的管理。前者“流数据状态”是从“时间”角度对流进行管理，而后者“流信息状态”则是从“空间”角度对流的管理。

“流信息状态”弥补了“流数据状态”只是对事件在时间序列上做管理的不足，将流的状态扩展到了任意的空间。

目前，针对“流信息状态”的存储，主要有三种方式：

• 计算节点和状态数据节点分离的分布式内存数据库方案

▲图3：使用Redis集群进行状态存储和管理

• 计算节点和状态数据节点共存的分布式内存格点方案

▲图4：使用Ignite集群进行状态存储和管理

• 基于分布式文件系统同步状态数据的方案

▲图5：基于分布式文件系统的状态存储和管理集群

将“流计算应用本身的执行过程”和“流数据的信息管理机制”解耦，这使得实时流计算系统的整体结构更加清晰。如果我们将前者理解为CPU的执行流水线，那么后者就相当于是内存。实时流计算系统的这种架构就非常像是一个分布式的JVM了！

04 流计算框架

目前的开源流计算框架有许多，比如Apache Storm、Spark Streaming、Apache Samza、Apache Flink、Akka Streaming、Apache Beam等。这些流计算框架各有特色，那我们该如何面对琳琅满目的流计算框架呢？可以从两个角度来看待这个问题。

从横向功能特征的角度来看 ，其实所有流计算框架的核心概念都是相同的。只要我们掌握了流计算中的核心概念，把握流计算框架中各种问题的关键所在，那么面对这些流计算框架，也不会感到眼花缭乱，乱了阵脚。

从纵向发展历史的角度来看 ，以Flink为代表的新一代流计算框架，在理论和实践上都已日趋完善和成熟。当掌握了流计算中的核心概念后，不妨一开始就站在Flink这个巨人的肩膀上，开始在流计算领域的探索和实践。

而作为有希望统一流计算领域的Apache Beam，实际上是构建在各种具体流计算框架上的更高一层统一编程模式，它对流计算中的各种概念和问题做出了总结，是我们追踪流计算领域最新进展的一个好切入点。

最后附上实时流计算系统思维导图（点击图片可放大）：

作者简介：周爽，本硕毕业于华中科技大学，先后在华为2012实验室高斯部门和上海行邑信息科技有限公司工作。开发过实时分析型内存数据库RTANA、华为公有云RDS服务、移动反欺诈MoFA等产品。目前但任公司技术部架构师一职。著有《实时流计算系统设计与实现》一书。