流式计算系统分析

2011年度的Hadoop China大会刚刚落下帷幕，这次会议的一个热点议题就是数据流计算，在MapReduce计算模型风靡全球之后，Stream Processing将会是下一个研究热点，无论是在工业界还是学术界。本文从深层次对各种典型的数据流计算系统架构及其基于的设计理念进行剖析。
背景与动机
背景
随着当今社会数据量的日益膨胀，普通服务器组成的计算集群用于处理各种数据应用。在工业领域，像网页检索、机器翻译、广告投放等；在科研领域，像生物复杂分析、自然语言处理、气候模拟预测等。MapReduce是一种很好的集群并行编程模型，加之拥有强大的开源实现——Hadoop分布式系统，能够满足大部分应用的需求。

不过MapReduce只是分布式/并行计算的一个方面，虽然它是一个很好的抽象，但不能有效地解决计算领域的任何问题。计算领域是个看起来像个“Tower of Babel”，它由许多相关领域的技术组合而成，而且每个贡献者看它的视角是不一样的，解决不同应用问题所用到的技术也是不尽相同的。例如，对于那些需要重复使用一批数据集的应用，像机器学习中的迭代式算法，R/Excel等交互式数据挖掘工具等，MapReduce并不能提供高效率的处理，因为处理这种应用逻辑需要执行多轮作业。

计算领域的巴贝塔模型

目前业界诞生了许多系统，它们仿照MapReduce约束编程模型的方式，为了获取更好的执行效率，这些系统包括，微软的DAG任务计算模型 Dryad、Google的图批量同步处理系统Pregel和增量式计算框架Percolator，Yahoo!的数据流计算系统S4、NYU的共享内存处理系统Piccolo以及Berkeley的交互式实时处理系统Spark等等。
本文关注的是数据流实时应用，数据流计算来自于一个信念：数据的价值随着时间的流逝而降低，所以事件出现后必须尽快地对它们进行处理，最好数据出现时便立刻对其进行处理，发生一个事件进行一次处理，而不是缓存起来成一批处理。在数据流模型中，需要处理的输入数据（全部或部分）并不存储在可随机访问的磁盘或内存中，它们以一个或多个“连续数据流”的形式到达。数据流不同于传统的存储关系模型，主要有以下几个方面的特点：

• 流中的数据元素在线到达，需要实时处理；
• 系统无法控制将要处理的新到达的数据元素的顺序，无论这些数据元素是在一个数据流中还是跨多个数据流；也即重放的数据流可能和上次数据流的元素顺序不一致；
• 数据流的潜在大小也许是无穷无尽的；
• 一旦数据流中的某个元素经过处理，要么被丢弃，要么被归档存储。因此，除非该数据被直接存储在内存中，否则将不容易被检索；
• 数据流系统涉及的操作分为有状态和无状态两种，无状态的算子包括union、filter等，有状态的算子包括bsort、join、 aggregate等。有状态的算子如果执行失败后，其保持的状态会丢失，重放数据流产生的状态和输出不一定和失效前保持一致，而无状态的算子失败后，重放数据流能够构建与之前一致的输出。

数据流计算可以看成是一个个算子（节点）和一条条数据流（边）组成的数据流图。
需求
典型的商用搜索引擎，像Google、Bing和Yahoo等，通常在用户查询响应中提供结构化的Web结果，同时也插入基于流量的点击付费模式的文本广告。为了在页面上最佳位置展现最相关的广告，通过一些算法来动态估算给定上下文中一个广告被点击的可能性。上下文可能包括用户偏好、地理位置、历史查询、历史点击等信息。一个主搜索引擎可能每秒钟处理成千上万次查询，每个页面都可能会包含多个广告。为了及时处理用户反馈，需要低延迟、可扩展、高可靠的处理引擎。对于社交网站来说，实时统计和分析用户行为数据，精准地推荐朋友，或者是及时地反馈圈子动态，都会极大地提升用户体验，增加用户黏性。另外，对于一些反作弊业务来说，尤其是与计费相关的业务，对时效性、可靠性和准确度的要求都会非常高。
挑战
为了保证实时性，许多实时数据流处理系统都是专用系统，它们不得不面对可靠性、扩展性和伸缩性方面的问题；使用MapReduce的好处在于 Hadoop帮助业务屏蔽了底层处理，上层作业不用关心容错和扩容方面的问题，应用升级也很方便；不过基于MapReduce的业务不得不面对处理延迟的问题。有一种想法是将基于MapReduce的批量处理转为小批量处理，将输入数据切成小的片段，每隔一个周期就启动一次MapReduce作业，这种实现需要减少每个片段的延迟，并且需要考虑系统的复杂度：

• 将输入数据分隔成固定大小的片段，再由MapReduce平台处理，缺点在于处理延迟与数据片段的长度、初始化处理任务的开销成正比。小的分段会降低延迟，增加附加开销，并且分段之间的依赖管理更加复杂（例如一个分段可能会需要前一个分段的信息）；反之，大的分段会增加延迟。最优化的分段大小取决于具体应用。
• 为了支持流式处理，MapReduce需要被改造成Pipeline的模式，而不是reduce直接输出；考虑到效率，中间结果最好只保存在内存中等等。这些改动使得原有的MapReduce框架的复杂度大大增加，不利于系统的维护和扩展。
• 用户被迫使用MapReduce的接口来定义流式作业，这使得用户程序的可伸缩性降低。

MapReduce框架为批处理做了高度优化，系统典型地通过调度批量任务来操作静态数据，任务不是常驻服务，数据也不是实时流入；而数据流计算的典型范式之一是不确定数据速率的事件流流入系统，系统处理能力必须与事件流量匹配。数据流实时处理的模式决定了要和批处理使用非常不同的架构，试图搭建一个既适合流式计算又适合批处理的通用平台，结果可能会是一个高度复杂的系统，并且最终系统可能对两种计算都不理想。因此，当前业界诞生了许多数据流实时计算系统来满足各自需求，当然除了延迟，它们需要解决可靠性、扩展性和伸缩性等方面的挑战。

小批量数据处理和流式数据处理的对比

相关工作
Facebook Data Free-way and Puma
Facebook实时数据流的用例主要来自站点和网页分析。Facebook Insights，该产品允许站长、广告商、应用开发者和网页主根据时间维度来查看展现/点击/动作计数，计数通过人口统计学逻辑像性别和年龄来做区分，另外还可以查看独立访次和热点像最受欢迎的网址。
构建Facebook Insights产品后端服务的主要挑战有两个方面：一是数据流量非常大，包括Facebook和非Facebook的网站流量；一是用户希望尽快看到摘要，以便他们能够立刻知道最受欢迎的文章或最新的游戏。

早期的Facebook通过已有的数据仓库解决方案来处理Insights流量。日志数据流从HTTP服务器产生，通过日志收集传输框架Scribe耗费秒级时间传送到共享存储NFS文件系统，然后通过小时级的Copier/Loader将数据文件上传到Hadoop。数据摘要通过每天例行的流水作业产生，结果定期会更新到前端的Mysql服务器，以便通过OLTP工具产生报表等。Hadoop 集群节点有3000个，扩展性和容错性方面的问题能够很好地解决。Copier/Loader其实就是MapReduce作业，能够屏蔽机器故障等问题。流水作业是由基于Hive的类SQl语言开发。

Facebook Insights网页查询示意图

早期的这套系统扩展性很好，能够达到数据中心的部署上限，不过整体的处理延迟较大，从日志产生起1～2天后才能得到最终的报表。为了减少整个系统的处理延迟，Facebook做了两方面的工作，一是优化数据的传输通道，一是优化数据的处理系统。

Facebook传统日志处理流程

优化后的数据通道称为Data Freeway，能够处理峰值9GB/s的数据并且端到端的延迟在10s以内，支持超过2500种的日志种类。Data Freeway主要包括4个组件，Scribe、Calligraphus、 Continuous Copier和PTail。Scribe用于客户端，负责通过RPC发送数据；Calligraphusshuffle数据并写到 HDFS，它提供了日志种类的管理，利用Zookeeper进行辅助；Continuous Copier将文件从一个HDFS拷贝到另一个 HDFS；PTail并行地tail多个HDFS上的目录，并写文件数据到标准输出。换句话说，Data Freeway提供了文件到消息、消息到消息、消息到文件和文件到文件的四种传输方式，可以根据应用场景灵活部署，提高传输效率。

Facebook Data Freeway数据传输系统

传输通道优化后，Facebook又优化了数据流处理系统Puma。早期的处理系统如下图所示，PTail将数据以流的方式传递给 Puma2，Puma2每秒需要处理百万级的消息，处理多为Aggregation方式的操作，遵循时间序列，涉及的复杂Aggregation操作诸如独立访次、最频繁事件等等。对于每条消息，Puma2发送“increment”操作到HBase。考虑到自动负载均衡、自动容错和写入吞吐等因素，Puma选择HBase而不是Mysql作为其存储引擎。Puma2的服务器都是对等的，也即同时可能有多个Puma2服务器向HBase中修改同一行数据。因此，Facebook为HBase增加了新的功能，支持一条increment操作修改同行数据的多个列。

Puma2系统数据处理通路

Puma2的架构非常简单并且易于维护，其涉及的状态仅仅是PTail的checkpoint ，即上游数据位置，周期性地存储在HBase中。由于是对称结构，集群扩容和机器故障时的处理都非常方便。不过，Puma2的缺点也很突出，首先，HBase的 increment操作是非常昂贵的，因为它涉及到读和写，而HBase的随机读效率是很差的；另外，复杂Aggregation操作也不好支持，需要在HBase上写很多用户代码；再者，Puma2在故障时会产生少量重复数据，因为HBase的increment和PTail的checkpoint并不是一个原子操作。

Puma3系统数据处理通路

由于Puma2的缺点限制了整个数据通路的延迟优化，因此Facebook开发了新的Puma3系统。两代系统最大的区别在于Puma3的 Aggregation是在本地内存执行的，而不是基于HBase，这使得Puma3的处理延迟很低。为了支持内存中的Aggregation，数据在 Puma3中通过Aggregation Key进行分片，这个分桶策略在传输通道的Calligraphus阶段实施的。Puma3的每个分片都是内存中的哈希表，每个表项对应一个Key及用户定义的Aggregation方法，包括count、sum、avg等等。HBase只作为持久化存储，定期 Puma3将内存数据checkpoint到HBase中，只有当Puma3故障时才从HBase中读相关数据进行重放。由于正常处理逻辑绕开了 HBase的读流程，因此整个处理系统的效率大大增加。
Twitter Storm
Twitter首席工程师、Storm的作者Nathan Marz最近有一篇很火的文章叫做“How to beat the CAP theorem”，讲述了他对于数据系统设计的全新理念。
Nathan认为，数据处理可以通过一个简单的公式来表达：Query = Function(All Data)，所谓数据系统就是要回答数据集问题的系统，问题称为Query。由于Query是所有数据上的函数，那么加快函数执行的方法就是预先准备好这些Query，当有新的数据产生时，就重新对所有数据执行函数。这样问题就变得简单，基于批处理计算，除了结果需要滞后一段时间才能获得外，Query总是可以被反复执行。任何超过一段时间的数据已经被计算进入了批处理视图中，所以剩下来要做的就是处理最近时间段的数据。
为了处理最近几个小时的数据，需要一个实时系统和批处理系统同时运行。这个实时系统在最近几个小时数据上预计算查询函数。要计算一个查询函数，需要查询批处理视图和实时视图，并把它们合并起来以得到最终的数据。进行实时计算的系统就是Storm，它在数据流上进行持续计算，并且对这种流式数据处理提供了有力保障。在批处理层仅需要考虑数据和数据上的查询函数，批处理层因此很好掌控。在实时层，需要使用增量算法和复杂的NoSQL数据库。把所有的复杂问题独立到实时层中，这对系统的鲁棒性、可靠性可以做出重大贡献。

Twitter数据系统分层处理架构

Twitter拥有如此分层的数据处理架构，Hadoop和ElephantDB组成批处理系统，Storm和Cassandra组成实时系统，实时系统处理的结果最终会由批处理系统来修正，正是这个观点使得Storm的设计与众不同。
Storm是Twitter近期开源的实时数据流计算系统，它被托管在GitHub上，遵循 Eclipse Public License 1.0。GitHub上的最新版本是Storm 0.5.2，用Clojure函数式语言开发。 Storm为分布式实时计算提供了一组通用原语，可被用于“流处理”之中，实时处理消息并更新数据库，这是管理队列及工作者集群的另一种方式。Storm 借鉴了Hadoop的计算模型，Hadoop运行的是一个Job, 而Storm运行的是一个Topology。Job是有生命周期的，而 Topology是个Service，是个不会停止的Job。
Storm的应用场景主要有以下三类：

• 信息流处理（Stream processing）

Storm可用来实时处理新数据和更新数据库，兼顾容错性和可扩展性。

• 持续计算（Continuous computation）

Storm可进行持续Query并把结果即时反馈给客户端。比如把Twitter上的热门话题发送到浏览器中。

• 分布式远程程序调用（Distributed RPC）

Storm可用来并行处理密集查询。Storm的拓扑结构是一个等待调用信息的分布函数，当它收到一条调用信息后，会对查询进行计算，并返回查询结果。例如Distributed RPC可以做并行搜索或者处理大集合的数据。
Storm的主要特点如下：

• 简单的编程模型

类似于MapReduce降低了并行批处理复杂性，Storm降低了进行实时处理的复杂性。

• 支持各种编程语言

可以在Storm之上使用各种编程语言。默认支持Clojure、Java、Ruby和Python。要增加对其他语言的支持，只需实现一个简单的Storm通信协议即可。

• 支持容错

Storm会管理工作进程和节点的故障。

• 支持水平扩展

计算是在多个线程、进程和服务器之间并行进行的。

• 可靠的消息处理

Storm保证每个消息至少能得到一次完整处理。任务失败时，它会负责从消息源重试消息。Storm使用一种比较巧妙的方式判断tuple是否丢失，即发送方和应答方都需要向系统内部的第三方acker异或一个随机数，如果在超时时间内acker上记录的消息随机数为0则认为消息已被正确处理，否则acker将通知spout进行重放。

• 高效消息处理

系统的设计保证了消息能得到快速的处理，使用ØMQ作为底层消息队列。

Storm数据流处理示意图

Storm 并不提供消息的去重和算子状态的持久化，如果有这方面的需求，需要在应用层面进行处理。这两点也符合Storm的设计初衷，消息重复是其为了容错和保证消息不丢而带来的副作用，但是对大多数实时计算来说，并不会要求达到批处理的那种准确度，所以大多数应用都不会对消息重复比较敏感；如果应用对消息重复很敏感，可以在应用层进行去重，或者将消息处理定义为幂等操作，再或者由批处理层来修正。
Storm系统并提供任务状态的持久化和高可靠，比如任务failover后的内存状态恢复。这些状态的保存和恢复需要任务自身依赖外围系统来保证，比如依赖一个高可靠的key-value存储系统，或者分布式文件系统等等。正因为不考虑持久化方案，Storm的设计和实现得到大大简化，回头看看它面向的应用，大多数并不涉及状态持久化，有需要的应用层面也可以解决，批处理层也会进行最终的Merge校验，这个设计思路也符合Nathan提出的数据系统分层架构。
Yahoo! S4
Yahoo! S4（Simple Scalable Streaming System）是一个通用的、分布式的、可扩展的、分区容错的、可插拔的流式系统。S4的诞生是为了提高广告点击流量的处理效率，基于S4框架，开发者可以容易地开发面向持续流数据处理的应用。S4的最新版本是 alpha version v0.3.0，最近刚成为Apache孵化项目，其设计特点有以下几个方面：

• Actor计算模型

为了能在普通机型构成的集群上进行分布式处理，并且集群内部不使用共享内存，S4架构采用了Actor模式，这种模式提供了封装和地址透明语义，因此在允许应用大规模并发的同时，也提供了简单的编程接口。S4系统通过处理单元（Processing Elements，PEs）进行计算，消息在处理单元间以数据事件的形式传送，PE消费事件，发出一个或多个可能被其他PE处理的事件，或者直接发布结果。每个PE的状态对于其他PE不可见，PE之间唯一的交互模式就是发出事件和消费事件。框架提供了路由事件到合适的PE和创建新PE实例的功能。S4的设计模式符合封装和地址透明的特性。

基于S4的CTR计算流程图

• 对等集群架构

除了遵循Actor模式，S4也参照了MapReduce模式。为了简化部署和运维，从而达到更好地稳定性和扩展性，S4采用了对等架构，集群中的所有处理节点都是等同的，没有中心控制。这种架构将使得集群的扩展性很好，处理节点的总数理论上无上限；同时，S4将没有单点容错的问题。

• 可插拔体系架构

S4系统使用Java语言开发，采用了极富层次的模块化编程，每个通用功能点都尽量抽象出来作为通用模块，而且尽可能地让各模块实现可定制化。

• 支持部分容错

基于Zookeeper服务的集群管理层将会自动路由事件从失效节点到其他节点。除非显式保存到持久性存储，否则节点故障时，节点上处理事件的状态会丢失。

• 支持面向对象

节点间通信采用“plain old Java objects”(POJOs) 模式，应用开发者不需要写schemas 或用哈希表来在节点间发送tuples。
S4的重要应用场景就是CTR预估这类应用。点击通过率(CTR)是广告点击数除以展现数得到的比率，当拥有了足够历史的展现和点击数据后，CTR 是用户点击广告可能性的一个很好的估算，精确的来源点击对于个性化和搜索排名来说都价值无限。展现事件包含展现数据，如展现ID、查询、用户、广告等，点击事件只包含点击信息和所点击的展现ID。在S4系统中计算查询广告级别的CTR，需要使用一个由查询和广告组成的key来路由点击事件和展现事件。如果点击流量不包含查询和广告信息，需要将上次事件路由到的展现ID和查询广告关联作为key。关联之后，事件必须通过过滤器。最终，展现和点击聚集到一起来计算CTR。显示了一个CTR计算的事件流过程。该流程如果基于MapReduce框架，则需要执行多轮作业。
据S4的开发者称，在线流量上的实验显示基于S4系统的新CTR计算框架可以在不影响收入的前提下将CTR值提高3%，这主要是通过快速检测低质量的广告并把它们过滤出去而获得的收益。
S4系统提供的低延迟处理能够使得商务广告部门获益，但是潜在的风险也不能忽视，那就是事件流的速率快到一定程度后，S4可能无法处理，会导致事件的丢失。

S4在流量压力测试下的事件丢失情况

模型与挑战
Puma、Storm和S4都是当前比较典型的数据流计算系统，之前讨论了它们各自的设计、实现和应用，我们再通过各个维度的建模视角来分析这些系统，领悟数据流系统的设计原则。本文从处理模型、交互模型、调度模型和语言模型几个方面来度量这几个系统。
分析系统的整体架构
在分析数据流系统模型之前，我们先看看整个分析系统的整体架构，给出了实时计算系统在整个数据分析大系统中所处的位置。实时计算系统和批处理计算系统同属于计算这个大的范畴，批处理计算可以是MapReduce、MPI等，实时计算可以是S4、Storm等，批处理和实时都可以或不依赖统一的资源调度系统。另外，计算系统的输入、输出，包括中间过程的输入、输出，都与存储系统HDFS或者传输通道Scribe等交互。计算系统的上层是数据仓库，或者计算系统直接和用户交互，交互方式可以是SQL-like，或者是MR-like等。计算系统的输出结果可以导入数据库，由OLAP工具产生报表等，也可以导向前端OLTP系统，及时反馈用户。

数据分析系统整体架构

处理模型

在传统的实时数据流处理系统中，业内早期经常使用Queue+Worker的处理方式。系统维护者静态配置Worker和Queue的对应关系，即哪些Worker从哪些Queue中读数据，往哪些Queue中写，如果流量或业务增加，需要扩容 Queue或worker时，可能需要重新规划两者的对应关系。为了保证可靠性，Queue通常具有高可用的特性，worker发来的消息都会被 Queue持久化保存，而每个queue对每条消息都持久化的开销就会有些高，并且会造成消息处理的延迟增大。阿里、百度和腾讯都有基于这种框架的业务处理系统，甚至Facebook早期也是这么处理的，只不过包括Facebook Puma2、支付宝的海狗等系统使用HBase作为Queue，屏蔽了高可用和扩容方面的问题，但低延迟的问题依然会呈现。

数据流计算系统的三种高可用技术

为了使得数据流处理系统的延迟变低，所有数据计算必须在内存中执行，并且流动数据不能每条都通过Queue进行持久化，这样子数据处理的高可用又变成了亟需解决的问题。大部分数据流处理的高可用技术基于故障恢复，如果服务器故障，一组预先定义的备份机器将接管失败的执行。通常基于故障恢复的高可用方法有三类：

• Passive Standby

在Passive Standby方式下，每个primary定期做checkpoints（即拷贝从上个checkpoint到当前状态的改变）到它的backup。Passive Standby方式广泛试用于局域网集群，它能够经受高负载情况，却降低了恢复速度。一些已有技术将每个服务器上的计算进行拆分，将拆分后的部分备份到多个服务器。基于这种分布式备份，能够实现恢复的并行化，大大减少恢复时间。

• Active Standby

在Active Standby方式下，每个backup也会接收并处理输出数据，和primary并行，在广域网应用环境下，该方法是个好的选择。比较Passive Standby，Active Standby方式保证了更快的恢复速度，低负载情况下所有backup使用和primary相同的资源。通过使用分配给tuples的序列数，Flux技术实现了无损和副本自由的故障恢复语义。Flux允许副本之间松耦合，一个副本能够比其他执行地更快，导致在很多时候执行交迭。Balazinska等人研究active Standby方法的变体，能够处理网络故障和分割。

• Upstream Backup

在Upstream Backup方式下，每个primary记录它的输出数据到日志，这样即使下游primary发生故障，backup也能通过重放日志数据来从头重新构建丢失的状态。Upstream Backup在无故障期间执行效率很高，因为其backup一致保持空闲状态。然而，它可能会花费较长时间来恢复状态较大的计算。例如，恢复一个带有30分钟窗口的Aggregattion 算子，需要重新处理30分钟内的所有tuples。对于那些算子的状态很小，并且资源紧缺，故障发生稀少的情况，Upstream Backup是个好的选择。

调度模型
在调度模型方面，Storm拥有自己的主节点Nimbus，而Puma和S4号称对称架构，没有中心节点，但我有理由详细，这些系统未来也会有自己的主节点。对称结构没有单点，扩展性理论上无限，容错和负载均衡需要依赖分布式协议，例如借助Zookeeper；而主从结构在实现故障恢复和负载均衡上更加容易，缺点是存在单点，可能会造成性能或稳定性方面的问题。仔细分析下，其实数据流系统的主节点不存在单点问题：

• 主节点无状态，可以有多个Standby节点，都向Zookeeper注册，当主节点故障后，自动切换到Standby节点，这点和BigTable类的系统是类似的；
• 主节点并无性能瓶颈，像MapReduce这类批处理系统，由于任务是有生命周期的，因此主节点需要频繁调度任务，规模增大时容易造成主节点的调度压力增大；而数据流系统的任务常驻内存，一旦执行就不退出，即只有启动或故障时才会调度，因此调度并无压力。

Storm将每个任务都注册到Zookeeper，由Zookeeper去检测任务的存活，进而通知主节点；也有一些系统通过任务的本地守护进程感知故障并向主节点汇报，两者并无本质差异。数据流系统有主节点之后，任务的调度和故障的处理就变得方便了许多，将哪些任务调度到哪些机器去执行，这依赖于系统状态和机器的资源使用等因素。

另外，数据流系统需要考虑负载分流方面的问题，即当流量增加时，如果将负载均匀地分流到集群的处理节点。一般有几种做法，根据流量可以动态地对任务进行分裂，分裂后的多个任务再进行调度；也可以先静态地配置任务的粒度，让每个相关任务处理的流量较少，当发现流量增加时进行任务迁移。后者实现简单，但对资源的使用存在一些浪费；前者实现复杂，对无状态的任务拆分可行，但如果用户定义的任务有自身状态，那么拆分用户状态是非常困难的事情。

数据流系统的交互模型

• Interaction Model

一般来说，数据流系统的传输模型都是基于Push的，如图所示，数据源产生数据后推送到数据流处理系统，数据流系统内部的数据基于Push方式进行流动，最终会推送到下游系统。Push方式则是由上游不间断地推送给下游，不考虑下游状况，除非收到异常应答，数据流有可能在下游积累，Push方式的优点在于，数据可以即时发出，更加高效。而Pull方式的优点在于，可以由下游节点根据自身状况控制何时来获取上游数据，积累数据统一在上游管理，在某些情况下两者实现上可以转化。Facebook的Data Freeway系统就实现了Push和Pull两种方式的数据流传输，只不过Push方式是基于 RPC实现，而Pull方式是基于HDFS实现。

• Language Model

一般的数据流处理系统和MapReduce类似，提供给开发者MR-like用户接口，提供一些专用的Operator，支持用户定制任务，支持用户定制策略；另外，支持用户使用XML等方式定义数据流图。Puma计划未来使用SQL-like接口，因为Hive开发SQl接口时已有相关经验。对于一些商用数据流系统像StreamBase等，已经有完备的用户接口，除了支持SQL，甚至支持用户使用图形化界面来定义任务和数据流图，非常方便。

结束语

实时数据流计算是近年来分布式/并行计算领域研究和实践的重点，无论是工业界还是学术界，诞生了多个具有代表性的数据流计算系统，用于解决实际生产问题和进行学术研究。不同的系统满足不同应用的需求，系统并无好坏之分，关键在于服务的对象是谁。对于各个公司的业务需求来说，那个系统就是它们最需要的系统。下图比较了典型的三个数据流计算系统Puma、Storm和S4，它们分别适用于站点统计、社交网络和广告投放等应用。

Puma、Storm和S4三种数据流计算系统对比

上图从开发语言、高可用机制、支持精确恢复、主从架构、资源利用率、恢复时间、支持状态持久化及支持去重等几个方面对这三种系统进行了对比。可以看到，为了高效开发，两个系统使用Java，另一种系统使用函数式编程语言Clojure；高可用方案，有两个系统使用Passive Standby方式，系统恢复时间可控，但系统复杂度增加，资源使用率也较低，因为需要一些机器用来当备机；而Storm选择了更简单可行的上游回放方式，资源使用率高，就是恢复时间可能稍长些；Puma和S4都支持状态持久化，但S4目前不支持数据去重，未来可能会实现；三个系统都做不到精确恢复，即恢复后的执行结果和无故障发生时保持一致，因为即使是Passive Standby方式，也只是定期Checkpoint，并没有跟踪每条消息的执行。商用的 StreamBase支持精确恢复，这主要应用于金融领域。
实时数据流计算在科研领域已有多年的研究，诞生了像Borealis、DSMS等系统。由于网络数据的不断膨胀和用户需求的不断涌现，近年来互联网企业开始广泛研究和使用数据流处理，诞生了Puma、Storm和S4等系统。正是需求推动了技术的进步，技术革新也影响着用户需求，数据流计算领域的发展才刚刚起步，未来一定更加辉煌。