世界正在走向实时化，谈谈Twitter对流处理的理解与思考

流计算成为大数据实时计算的事实代名词

实时计算一般都是针对海量数据进行的，一般要求为秒级。实时计算主要分为两块：

• 数据的实时入库

• 数据的实时计算

数据源是实时的不间断的，要求用户的响应时间也是实时的（比如对于大型网站的流式数据：网站的访问 PV/UV、用户访问了什么内容、搜索了什么内容等，实时的数据计算和分析可以动态实时地刷新用户访问数据，展示网站实时流量的变化情况，分析每天各小时的流量和用户分布情况）。

当谈及大数据实时计算方面当前的挑战时，吴惠君表示这个挑战就如同其名字一样：大数据的挑战，实时计算的挑战。其中，大数据的挑战包括很多方面：

• 比如‘数据的获得’上，现在移动端的数据分布广，按照一般的思路是收集手机数据到云上，那么这个收集的系统就是第一个要解决的挑战，一般 Kafka 比较适用，或者类似的 Pulsar 也有很多人尝试。

• 比如‘数据的存储’上，由于这些收集的数据要被实时计算使用，所以这个存储系统要响应快速，并能很好的跟实时计算的系统结合，一般 Druid 可以适用在这个场景，另外它还能跟批处理的历史数据存储结合。除此之外，还有比如’数据的备份’等等。

在大数据挑战基础上的实时计算的挑战，是个非常复杂的问题。传统的硬实时或者软实时系统难以应用在大数据的情况下，然后在现有大数据平台的基础上构建新的实时系统才是普遍采用的方法，其中流计算就处在这样一个位置。

流计算有几个适应的点，它可以方便的建立在大数据的平台或者云上，并且能够通过一些扩容方法来满足各种大小数据量，凭借它的低延迟的特性，它可以满足一定的实时要求它和其他大数据处理的项目和社区共享先进的理念和经验，这些让流计算当仁不让的成为大数据实时计算的事实代名词。

可见，数据的价值随着时间的流逝而降低，所以事件出现后必须尽快地对它们进行处理，而不是积累。对于这点和传统的 MapReduce 有差异，即传统的分布式计算往往是首先拿到一个大的积累后的数据，再进行数据拆分和聚合。而流处理的重点是通过事件机制，类似流管道一样，接收都消息马上就进行处理。

流式大数据的实时处理

大数据行业核心技术面临的挑战仍然存在，并将在可预见的未来持续下去。随着数据呈指数级增长，企业组织和服务于其的技术公司将继续处在一场持续的战斗中，使其变得易于管理。

大数据通常被分为两类：一类是批式大数据，另一类是流式大数据。

如果把数据当成水库的话，水库里面存在的水就是批式大数据，进来的水是流式大数据。

其中，流式数据的实时分析，一定是有规则、模型的东西。复杂的分析计算，加上实时这两个结合起来，如果能做的好，一定能够加速大数据在各个行业的应用。

当前，越来越多的企业选择流处理。流处理打破了传统的数据分析和处理的模式，即数据最终积累和落地后再针对海量数据进行拆分处理，然后进行分析统计，传统的模式很难真正达到实时性和速度要求。

而实时流处理模型的重点正是既有类似 Hadoop 中 MapReduce 和 PIG 一样的数据处理和调度引擎，又解决了直接通过输入适配接到流的入口，流实时达到实时处理，实时进行分组汇聚等增量操作。

由于流数据实时到达，实时处理，有具体的数据处理的流处理引擎，因此具备低延迟，高可靠性和容错能力。

Twitter 是如何实现对实时系统的异常检测？

据吴惠君介绍：Heron 项目就是 Twitter 提供的流处理或者叫做大数据实时计算的典型。

一个稳定可靠的系统离不开监控，我们不仅监控服务是否存活，还要监控系统的运行状况。运行状况主要是对这些组件的核心 metrics 采集、抓取、分析和报警。

吴惠君描述：

在异常检测方面，Heron 采用的 Dahlion 框架，在 Dhalion 框架基础上开发了 Health manager 模块来检测和处理系统异常。其中，Dhalion 框架是由 Microsoft 和 Twitter 联合发明专用于实时流处理系统的异常检测和响应框架，它主要应对三个在流处理系统中的常见场景：

• self tuning

• self stabilizing

• self healing

Dhalion 由一个 policy 调度器和若干个 detector 和 resolver 来合作完成异常检测和响应。

policy 管理 detector 和 resolver：

• detector 检测系统各种指标的异常；

• resolver 根据 detector 的结果进行对应的处理。

另外，还有些辅助的模块来配合这个主过程，比如 metrics provider 喂给 detecor 检测数据；action 等完成 resolver 和 detector 之间的协同。

在 Dhalion 基础上的 Health manager 实现了几个 Heron 常用的 detector 和 resolver。比如检测 slow instance 的 detector。有些时候，某些容器云调度的容器由于各种原因会比较慢，那么根据这个容器的各种指标，比如队列长度，响应时间，反压 backpressure 标志等，判断比较然后得出这个容器结点相比其他容器是不是异常。

其他一些 detector 还包括检测是不是整体上资源不够，是不是可以压缩资源池等等。在 resolver 方面，从最简单的重启容器，到扩容 / 缩容，特殊操作等等都可以用 resolver 的形式实现应用。

Heron 增加了新功能

自去年 Twitter 开源了大数据实时分析系统 Heron 以来，一年多的时间，Heron 社区开发了许多新的功能。据吴惠君介绍：特别是今年 Heron 增加了 elastic runtime scaling，effectively once，functional API，multi-language topology，self-regulating 等。

 elastic runtime scaling

根据 storm 的数据模型，topology 的并行度是 topology 的作者在编程 topology 的时候指定的。很多情况下，topology 需要应付的数据流量在不停的变化。

topology 的编程者很难预估适合的资源配置，所以动态的调整 topology 的资源配置就是运行时的必要功能需求。直观地改变 topology 中结点的并行度就能快速的改变 topology 的资源使用量来应付数据流量的变换。Heorn 通过 update 命令来实现这种动态调整。

 effectively once

Heron 在原有 tuple 传输模式 at most once 和 at least once 以外，新加入了 effectively once。原有的 at most once 和 at least once 都有些不足之处，比如 at most once 会漏掉某些 tuple；而 at least once 会重复某些 tuple。所以 effectively once 的目标是使得计算结果精确可信。

 Functional API

函数式编程是近年来的热点，Heron 适应时代潮流在原有 API 的基础上添加了函 数式 API 。Heron 函数式 API 让 topology 编程者更专注与 topology 的应用逻辑，而不必关心 topology/spout/bolt 的具体细节。Heron 的函数式 API 相比于原有底层 API 是一种更高层级上的 API，它背后的实现仍然是转化为底层 API 来构建 topology。

 multi language topology

以往 topology 编程者通常使用兼容 Apache Storm 的 Java API 来编写 topology。现在 Heron 提供 Python 和 C++ 的 API，让熟悉 Python 和 C++ 的程序员也可以编写 topology。

Python 和 C++ 的 API 设计与 Java API 类似，它们包含底层 API 用来构造 DAG，将来也会提供函数式 API 让 topology 开发者更专注业务逻辑。

 self-regulating

Heron 结合 Dahlion 框架开发了新的 health manager 模块。

• Dhalion 框架是一个读取 metrics 然后对 topology 进行相应修复的框架。

• health manager 由 2 个步骤组成，detector/diagnose 和 resolver。

detector/diagonse 读取 metrics 探测 topology 状态并发现异常，resolver 根据发现的异常解决让 topology 恢复正常。healtmgr 模块的引入，形成了完整的反馈闭环。

倚仗开源社区 大大节约流式处理成本

流式处理是一种成本和效费比都高的计算模式。企业要如何权衡成本与人员支出的呢? 为此，吴惠君提出了自己的看法，借助云平台和开源社区的力量，可以大大节约成本。

据吴惠君介绍，企业中使用流计算的成本分两部分：机器和人员。

• 机器方面，很多企业都是基于容器云平台上搭建流计算系统，对于这种情况机器池大小，部署等都可控。那么，机器的成本基本就是实打实的成本，意思是要处理这么多这么快的数据就是要这么多机器。对于具体的业务，根据实际场景测试能知道真实要多少机器，然后再看业务设计再来决策是不是值得。

• 人员方面，以 Heron 为例，Heron 开源以后形成了一定规模的社区，很多新的功能和日常项目维护很多都交给社区来做。依托社区的力量，企业实际的人员开销并不大。

流数据处理引擎如何选？

我们可以对比一下现在流行的几种流处理项目：Storm，Flink，Spark Streaming，Kafka Streams 和 Heron。

1. 首先看 Storm。它是适用于需要快速响应中等流量的场景。Storm 和 Heron 在 API 上兼容，在功能上基本可以互换；Twitter 从 Storm 迁移到了 Heron，说明如果 Storm，Heron 二选一的话，没有啥意外 情况需要考虑的话，一般都是选 Heron。

2. 然后看 Kafka Streams。它与 Kafka 绑定，如果现有系统是基于 Kafka 构建的，可以考虑使用 Kafka Streams，减少各种开销。

3. 再看 Spark Streaming，一般认为 Spark Streaming 的流量是这些项目中最高的，但是它的响应延迟也是最高的。对于响应速度要求不高，但是对流通量要求高的系统，可以采用 Spark Streaming；如果把这种情况推广到极致就可以直接使用 Spark 系统。

4. 最后，Flink 使用了流处理的内核，同时提供了流处理和批处理的接口。如果项目中需要同时兼顾流处理和批处理的情况，Flink 比较适合。同时因为需要兼顾两边的取舍，在单个方面就不容易进行针对性的优化和处理。

可见，Spark Streaming，Kafka Streams，Flink 都有特定的应用场景，其他一般流处理情况下可以使用 Heron。

写在最后

世界正在走向实时化，越来越多的应用场景需要以很低的延迟来分析实时数据。随着实时数据的流行，流处理会是很重要处理方式。在许多快速扩展的实时用例中大多都应用了 Heron，其中包括异常和欺诈检测、物联网和万物互联应用、嵌入式系统、虚拟现实和增强现实、广告投放、金融、安全和社会媒体等。在实时流处理过程中，如何选择一款适合的流数据处理引擎？如何更快的采集数据并实时的处理数据？都是企业亟须突破的。