现今实时流计算模型
1.引言
近年来，一种新的数据密集型应用已经得到了广泛的认同，这类应用的特征是：数据不宜用持久稳定关系建模，而适宜用瞬态数据流建模。这些应用的实例包括金融服务、网络监控、电信数据管理、Web应用、生产制造、传感检测等等。在这种数据流模型中，单独的数据单元可能是相关的元组（tuples），例如网络测量、呼叫记录、网页访问等产生的数据。但是，这些数据以大量、快速、时变（可能是不可预知）的数据流持续到达，由此产生了一些基础性的新的研究问题。
数据流计算来自于一个信念：数据的价值随着时间的流逝而降低，所以事件出现后必须尽快地对它们进行处理，最好数据出现时便立刻对其进行处理，发生一个事件进行一次处理，而不是缓存起来成一批处理。例如商用搜索引擎，像Google、Bing和Yahoo !等，通常在用户查询响应中提供结构化的Web结果，同时也插入基于流量的点击付费模式的文本广告。为了在页面上最佳位置展现最相关的广告，通过一些算法来动态估算给定上下文中一个广告被点击的可能性。上下文可能包括用户偏好、地理位置、历史查询、历史点击等信息。一个主搜索引擎可能每秒钟处理成千上万次查询，每个页面都可能会包含多个广告。为了及时处理用户反馈，需要一个低延迟、可扩展、高可靠的处理引擎。
对于这些实时性要求很高的应用，若把持续到达的数据简单地放到传统数据库管理系统（DBMS）中，并在其中进行操作，是不太切实的。传统的DBMS并不是为快速连续的存放单独的数据单元而设计的，而且也并不支持“持续处理”，而“持续处理”是数据流应用的典型特征。另外，现在人们都认识到，“近似性”和“自适应性”是对数据流进行快速查询和其他处理（如数据分析和数据采集）的关键要素，而传统DBMS的主要目标恰恰与之相反：通过稳定的查询设计，得到精确的答案。
另外一些方案是采用MapReduce来进行实时数据流处理。但是，尽管MapReduce做了实时性改进，仍然很难稳定地满足应用需求。这是因为MapReduce（Hadoop）框架为批处理做了高度优化，系统典型地通过调度批量任务来操作静态数据，任务不是常驻服务，数据也不是实时流入；而数据流计算的典型范式之一是不确定数据速率的事件流流入系统，系统处理能力必须与事件流量匹配。
最近Facebook在SIGMOD’ 2011上发表了利用Hbase/Hadoop进行实时处理数据的论文，通过一些实时性改造，让批处理计算平台也具备实时计算的能力。这类基于MapReduce流式处理的缺点有三：
1）将输入数据分隔成固定大小的片段，再由MapReduce平台处理，缺点在于处理延迟与数据片段的长度、初始化处理任务的开销成正比。小的分段会降低延迟，增加附加开销，并且分段之间的依赖管理更加复杂（例如一个分段可能会需要前一个分段的信息）；反之，大的分段会增加延迟。最优化的分段大小取决于具体应用。
2）为了支持流式处理，MapReduce需要被改造成Pipeline的模式，而不是reduce直接输出；考虑到效率，中间结果最好只保存在内存中等等。这些改动使得原有的MapReduce框架的复杂度大大增加，不利于系统的维护和扩展。
3）用户被迫使用MapReduce的接口来定义流式作业，这使得用户程序的可伸缩性降低。
综上所述，流式处理的模式决定了要和批处理使用非常不同的架构，试图搭建一个既适合流式计算又适合批处理的通用平台，结果可能会是一个高度复杂的系统，并且最终系统可能对两种计算都不理想。
2. 数据流模型
在数据流模型中，需要处理的输入数据（全部或部分）并不存储在可随机访问的磁盘或内存中，但它们却以一个或多个“连续数据流”的形式到达。数据流不同于传统的存储关系模型，主要区别有如下几个方面：
流中的数据元素在线到达；
系统无法控制将要处理的新到达的数据元素的顺序，无论这些数据元素是在一个数据流中还是跨多个数据流；也即重放的数据流可能和上次数据流的元素顺序不一致；
数据流的潜在大小也许是无穷无尽的；
一旦数据流中的某个元素经过处理，要么被丢弃，要么被归档存储。因此，除非该数据被直接存储在内存中，否则将不容易被检索。相对于数据流的大小，这是一种典型的极小相关。
数据流模型中的操作并不排除传统关系型数据的存在。通常，数据流操作将建立数据流和关系型数据的联系。在数据流处理过程中，更新存储关系的同时可能会产生传输处理问题。
3. 百度现有数据流系统
百度内部有很多独立的数据流计算系统，用来满足各产品线的业务需求。以下列举几个典型系统稍作分析。
广告点击计费反作弊系统
对于商务搜索部门来说，广告点击计费和网页检索反作弊是非常重要的两个方面。点击计费业务对时效性、高可靠和准确度的要求都非常高，目前由独立的数据流处理系统支撑业务。系统的每来一个元组就处理一次；为了保证业务处理的及时性，在关键处理环节上进行拆分，尽量并行处理；系统本身有容错支持，但非全局容错，只支持某些功能模块的双机互为热备，异常情况下仍然存在丢失少量数据的风险；另外，现有系统仅仅通过目前点击流量进行反作弊计费，而点击依赖的网页检索流量并没有流入系统，反作弊准确性方面还有提升空间。
广告检索反作弊系统
出于实时性和开发效率的权衡，许多实时系统都借助Hadoop来解决问题。相对而言，检索反作弊的时效性要求要低于点击，现有系统也是基于MapReduce框架实现的。MapReduce提供了容错机制，提供了Order By等机制，并保证了最多30分钟的执行时间，这些特性都支撑该系统的运行。不过，检索反作弊系统的设计初衷也是希望做到尽量实时，目前该系统的时效性受限于上游日志文件的生成时限，以及Hadoop平台执行时任务启动开销和执行时间的不稳定。
统一日志统计平台
LOG日志统计平台上运行着一些实时性作业，例如Columbus等，时效性是它们关注的重点。5分钟的统计作业目前在Hadoop实时集群执行，期望保证时效性。不过类似于检索反作弊系统，MapReduce作业的启动开销不可避免；另外，如果Hadoop集群某些机器出现问题，至少需要重新执行多个任务，也会影响作业的时效性；再者，如果统计作业发现数据出现问题，想从某个时间点重新计算，则可能会重复执行以前的大量计算。
统一服务监控平台
对诺亚监控系统而言，时效性和准确度也是其关心的问题，不过由于不涉及钱的问题，它相对要求低一些。诺亚的集群是人工配置的，存在宕机风险；如果流量增大，也需要人工修改配置；诺亚的大部分算子是Aggregator，涉及中间状态的保存，目前没有冗余备份机制，如果发生故障会导致结果不准。
站点统计平台
对福尔摩斯站点统计系统来说，已经基本做到了实时统计，但其现有架构仍然存在很多问题。例如不支持自动容错，不支持自动扩展，不能很好的保证线上服务的可用性和稳定性，系统扩容时往往会影响线上服务，运维人力成本高等；再者，福尔摩斯是个专用系统，许多业务逻辑和系统逻辑混合在一起，每每需要进行业务变更时，改动量很大，也不适合一些规则和业务的快速上线。
综上所述，实现百度公司通用的数据流计算平台是非常必要、非常迫切的一件事情，有助于提升公司业务水平，节省维护成本和开发成本。
4. 百度下一代数据流系统
在百度基础架构部的下一代规划中，实时计算是重要的组成部分。图1从整个分析系统的架构角度，给出了实时计算子系统所处的位置。实时计算系统和批处理计算系统同属于计算这个大的范畴，批处理计算可以是MapReduce、MPI等，实时计算可以是DStream等，批处理和实时都可以或不依赖统一的资源调度系统。另外，计算系统的输入、输出，包括中间过程的输入、输出，都与存储系统或者传输通道（Bigpipe）交互。计算系统的上层是 数据仓库，或者计算系统直接和用户交互，交互方式可以是SQL-like，或者是MR-like等。
(图 1 数据分析系统整体组成示意图)
实时计算方向重要的一个模块就是实时数据流计算。如图2所示，百度下一代通用数据流计算系统DStream提供分布式的、高可靠的、高可用的、可伸缩的、可扩展的、易开发的流式计算服务，一般故障恢复时间在10s以内，极端故障恢复在5分钟内。DStream的Release 1.0版本将在2012年上半年发布。
如图2所示，DStream包括Client、Processing Master（PM）、Processing Node（PN）三大组件，PN上有多个Processing Element（PE）实例执行。DStream依赖几个第三方系统，Bigpipe、Zookeeper和HDFS，分别用于数据流输入输出和操作日志的存储、分布式异常监控、用户文件存储和计算状态存储。
(图 2 数据流计算系统DStream结构示意图)
5. 业界数据流项目
近年来，业界出现了不少实时数据流计算系统，虽然没有一个类似于Hadoop的集大成者，但是也都各具特色，值得我们学习和研究。下面简单介绍几种业界典型的流式计算系统，包括Yahoo! S4、Twitter Storm、IBM StreamBase 及学术界开源的Borealis。
S4
Yahoo! S4（Simple Scalable Streaming System）是一个通用的、分布式的、可扩展的、分区容错的、可插拔的流式系统。基于S4框架，开发者可以容易地开发面向持续流数据处理的应用。S4的最新版本是alpha version v0.3.0，最近刚成为Apache孵化项目，其设计特点有以下几个方面：
1）Actor计算模型
为了能在普通机型构成的集群上进行分布式处理，并且集群内部不使用共享内存，S4架构采用了Actor模式，这种模式提供了封装和地址透明语义，因此在允许应用大规模并发的同时，也提供了简单的编程接口。S4系统通过处理单元（Processing Elements，PEs）进行计算，消息在处理单元间以数据事件的形式传送，PE消费事件，发出一个或多个可能被其他PE处理的事件，或者直接发布结果。每个PE的状态对于其他PE不可见，PE之间唯一的交互模式就是发出事件和消费事件。框架提供了路由事件到合适的PE和创建新PE实例的功能。S4的设计模式符合封装和地址透明的特性。
2）对等集群架构
除了遵循Actor模式，S4也参照了MapReduce模式。为了简化部署和运维，从而达到更好地稳定性和扩展性，S4采用了对等架构，集群中的所有处理节点都是等同的，没有中心控制。这种架构将使得集群的扩展性很好，处理节点的总数理论上无上限；同时，S4将没有单点容错的问题。
3）可插拔体系架构
S4系统使用Java语言开发，采用了极富层次的模块化编程，每个通用功能点都尽量抽象出来作为通用模块，而且尽可能地让各模块实现可定制化。
4）支持部分容错
基于Zookeeper服务的集群管理层将会自动路由事件从失效节点到其他节点。除非显式保存到持久性存储，否则节点故障时，节点上处理事件的状态会丢失。
5）支持面向对象
节点间通信采用“plain old Java objects”(POJOs) 模式，应用开发者不需要写schemas 或用哈希表来在节点间发送tuples。
Storm
Storm是Twitter近期开源的实时数据流计算系统，它被托管在GitHub上，遵循 Eclipse Public License 1.0。GitHub上的最新版本是Storm 0.5.2，用Clojure函数式语言开发。Storm为分布式实时计算提供了一组通用原语，可被用于“流处理”之中，实时处理消息并更新数据库，这是管理队列及工作者集群的另一种方式。Storm的主要特点如下：
1）简单的编程模型
类似于MapReduce降低了并行批处理复杂性，Storm降低了进行实时处理的复杂性。
2）支持各种编程语言
可以在Storm之上使用各种编程语言。默认支持Clojure、Java、Ruby和Python。要增加对其他语言的支持，只需实现一个简单的Storm通信协议即可。
3）支持容错
Storm会管理工作进程和节点的故障。
4）支持水平扩展
计算是在多个线程、进程和服务器之间并行进行的。
5）可靠的消息处理
Storm保证每个消息至少能得到一次完整处理。任务失败时，它会负责从消息源重试消息。
6）高效消息处理
系统的设计保证了消息能得到快速的处理，使用?MQ作为其底层消息队列。
StreamBase
StreamBase 是IBM开发的一款商业流式计算系统，在金融行业和政府部门使用，其本身是商业应用软件，但提供了develop edition。相对于付费使用的enterprise edition，前者的功能更少，但这并不妨碍我们从外部使用和API接口来对StreamBase本身分析。StreamBase的设计特点有以下几个方面：
1）超便捷的应用接口
StreamBase 使用Java语言开发，IDE是基于Eclipse来进行二次开发，功能非常强大。StreamBase也提供了相当多的operator、functor以及其他组件来帮助构建应用程序。用户只需要通过IDE拖拉控件，然后关联一下，设置好传输的schema并且设置一下控件计算过程，就可以编译出一个高效处理的流式应用程序了。同时，StreamBase还提供了类SQL语言来描述计算过程。
2）支持异构流输入输出
StreamBase通过Adapter组件支持异构数据流的输入和输出，数据源或者目的地可以是CSV文件、JDBC、JMS、Simulation（系统提供了流产生模拟器）等，也可以用户自行定制。
3） 支持计算状态保存
StreamBase通过QueryTable保存数据流的tuples，QueryTable支持内存表和磁盘表，对于磁盘表的话支持三种写模式：
non-transaction模式，只写入并不做transaction。
half-transaction模式，保证transaction，但flush时机并不确定。
full-transaction模式，这种模式保证transaction，并且强制每次flush。
4）支持多种容错方案
StreamBase 提出了以下4种模板策略来解决容错问题：
Hot-Hot Server Pair Template
primary和secondary server都在同时计算，并且将计算结果交给下游。优点是primary server如果故障的话那么secondary server依然工作，几乎没有任何切换时间；并且下游只需要选取先到来的tuple就可以处理了，保证处理速度最快。缺点是浪费计算和网络资源。
Hot-Warm Server Pair Template
primary和secondary server都在同时计算，但只有primary server将计算结果交给下游。优点是如果primary server故障，secondary server可以很快切换，而不需要任何恢复状态的工作。相对于Hot-Hot方式时间稍微长一些，但没有Hot-Hot那么耗费网络资源，同时也浪费了计算资源。
Shared Disk Template
primary server在计算之后，将计算的一些中间关键状态存储到磁盘、SAN（Storage Area Network）或是可靠的存储介质。如果primary server故障， secondary server会从介质中读取出关键状态，然后接着继续计算。优点是没有浪费任何计算和网路资源，但是恢复时间依赖状态的量级而定，相对于前两种，恢复时间可能会稍长。
Fast Restart Template
这种方案限定了应用场景，只针对无状态的应用。对于无状态的情况，方案可以非常简单，只要发现primary server故障，secondary server立即启动，并接着上游的数据流继续计算即可。
Borealis
Borealis是Brandeis University、 Brown University和 MIT合作开发的分布式流式系统。Borealis系统是三所大学在之前的流式系统Aurora、Medusa演化而来。目前Borealis系统已经停止维护，最新的Release版本发布于2008年。
Borealis具有丰富的论文、完整的用户/开发者文档，系统是C++实现的，运行于x86-based Linux平台。系统自身是开源的，同时使用了较多的第三方开源组件，包括用于查询语言翻译的ANTLR、C++的网络编程框架库NMSTL等。
Borealis系统的流式模型和其他流式系统基本一致：接受多元的数据流和输出，为了容错，采用确定性计算，对于容错性要求高的系统，会对输入流使用算子进行定序。Borealis的设计特点有以下几个方面：
1）可变集群架构
Borealis集群的节点可以部署为对等架构，也可以设计一个协作节点来执行全局的系统监控和其他优化任务，比如全局的负载分布和global load shedding。Borealis实际上提供了完整的3级监控和优化（local，neighborhood，global）。
2）支持多种负载均衡机制
负载均衡方面，Borealis提供了动态和静态两种部署机制：
Correlation-based operator distribution
通过分析不同operators和nodes间的负载变化的关系，决定和动态调整operatpr的部署，使之达到负载均衡。
Resilient operator distribution algorithm
该算法的目标是提供一种静态的operator部署方案，该方案能够在不需要重新调整的情况下处理最大可能的输入速度变化范围。
由于动态调整需要时间和消耗，前者适用于负载变化持续时间较长的系统；而后者则能处理较快较短的负载峰值。在实现上前者使用相关系数作为节点关联度指标，并通过贪心算法将NP问题转化为多项式求解；而后者在部署前计算完毕，保证系统能够容忍负载峰值。该算法在线性代数上建模，包括Operator Ordering、Operator Assignment两个阶段。
3）支持多种容错方案
Borealis通过多种容错机制来满足用户需求：
Amnesia Backup
备机发现主机故障，立即从一个空的状态开始重做。
Passive Standby
主机处理，备机待命，主机按周期做checkpoints，主机故障后切换到备机，重放checkpoint和数据流，对于不确定性计算可以很好地支持，缺点是恢复时间较长。
Active Standby
主备机同时计算，主机故障时直接切换到备机，不支持不确定性计算，浪费计算资源，优势在于几乎没有恢复时间。
Upstream Backup
通过上游备份来容错，故障时从上游重放数据即可，恢复时间最长，不过最节省资源。
Rollback Recovery
除了基础的容错方案，Borealis还提供了更高级的容错机制Rollback Recovery，它是一种基于副本在节点失效、网络失效或网络分区时的故障恢复机制，在尽量减少系统不一致的情况下，尽可能的保证系统的可用性。该机制允许用户定义一个阈值来在一致性和可用性之间做一个平衡。当系统数据恢复后，系统支持重新计算输出正确的结果，保证最终一致性。该机制使用了data-serializing operator（SUnion）来确保所有的副本处理同样顺序的数据。当失效恢复后，通过checkpoint/redo、undo/redo来实现恢复重放。
6. 结论与展望
实时计算是近年来分布式计算领域研究的重点，无论是工业界还是学术界，都诞生了几个具有代表性的实时数据流计算系统，用于解决实际生产问题和进行学术研究。
S4的最新版本是alpha version v0.3.0，动态负载均衡和在线服务迁移等重要功能都尚未实现；Storm通过简单实现满足Twitter实际需求，但基于重放的恢复机制很难保证高可用性和计算一致性，另外基于函数式语言Clojure开发也使得它很难广泛开源使用；StreamBase虽然功能齐全却是商用软件，使用成本较大；Borealis对数据流计算的各方面研究广泛且深入，有很好的参考价值，但由于是学术界产物，尚未在工业界大规模使用。
百度现有实时流式计算平台多为独立系统或者依赖MapReduce框架，在可靠性、高可用、实时性、伸缩性、维护成本、开发成本等方面都存在不足。
基于数据流计算领域业界系统分析和百度现状分析，我们基础架构部的实时计算小组决定开发属于百度自己的通用实时数据流计算系统——DStream，用于满足百度内部所有的实时数据流处理需求，并希望DStream能在实时计算领域成为集大成者。
实时计算是分布式计算领域重要组成部分，随着应用规模的不断扩大以及对实时性需求的不断提高，实时数据流计算的前景一片光明，欢迎大家关注和参与实时计算项目。
近年来，一种新的数据密集型应用已经得到了广泛的认同，这类应用的特征是：数据不宜用持久稳定关系建模，而适宜用瞬态数据流建模。这些应用的实例包括金融服务、网络监控、电信数据管理、Web应用、生产制造、传感检测等等。在这种数据流模型中，单独的数据单元可能是相关的元组（tuples），例如网络测量、呼叫记录、网页访问等产生的数据。但是，这些数据以大量、快速、时变（可能是不可预知）的数据流持续到达，由此产生了一些基础性的新的研究问题。
数据流计算来自于一个信念：数据的价值随着时间的流逝而降低，所以事件出现后必须尽快地对它们进行处理，最好数据出现时便立刻对其进行处理，发生一个事件进行一次处理，而不是缓存起来成一批处理。例如商用搜索引擎，像Google、Bing和Yahoo !等，通常在用户查询响应中提供结构化的Web结果，同时也插入基于流量的点击付费模式的文本广告。为了在页面上最佳位置展现最相关的广告，通过一些算法来动态估算给定上下文中一个广告被点击的可能性。上下文可能包括用户偏好、地理位置、历史查询、历史点击等信息。一个主搜索引擎可能每秒钟处理成千上万次查询，每个页面都可能会包含多个广告。为了及时处理用户反馈，需要一个低延迟、可扩展、高可靠的处理引擎。
对于这些实时性要求很高的应用，若把持续到达的数据简单地放到传统数据库管理系统（DBMS）中，并在其中进行操作，是不太切实的。传统的DBMS并不是为快速连续的存放单独的数据单元而设计的，而且也并不支持“持续处理”，而“持续处理”是数据流应用的典型特征。另外，现在人们都认识到，“近似性”和“自适应性”是对数据流进行快速查询和其他处理（如数据分析和数据采集）的关键要素，而传统DBMS的主要目标恰恰与之相反：通过稳定的查询设计，得到精确的答案。
另外一些方案是采用MapReduce来进行实时数据流处理。但是，尽管MapReduce做了实时性改进，仍然很难稳定地满足应用需求。这是因为MapReduce（Hadoop）框架为批处理做了高度优化，系统典型地通过调度批量任务来操作静态数据，任务不是常驻服务，数据也不是实时流入；而数据流计算的典型范式之一是不确定数据速率的事件流流入系统，系统处理能力必须与事件流量匹配。
最近Facebook在SIGMOD’ 2011上发表了利用Hbase/Hadoop进行实时处理数据的论文，通过一些实时性改造，让批处理计算平台也具备实时计算的能力。这类基于MapReduce流式处理的缺点有三：
1）将输入数据分隔成固定大小的片段，再由MapReduce平台处理，缺点在于处理延迟与数据片段的长度、初始化处理任务的开销成正比。小的分段会降低延迟，增加附加开销，并且分段之间的依赖管理更加复杂（例如一个分段可能会需要前一个分段的信息）；反之，大的分段会增加延迟。最优化的分段大小取决于具体应用。
2）为了支持流式处理，MapReduce需要被改造成Pipeline的模式，而不是reduce直接输出；考虑到效率，中间结果最好只保存在内存中等等。这些改动使得原有的MapReduce框架的复杂度大大增加，不利于系统的维护和扩展。
3）用户被迫使用MapReduce的接口来定义流式作业，这使得用户程序的可伸缩性降低。
综上所述，流式处理的模式决定了要和批处理使用非常不同的架构，试图搭建一个既适合流式计算又适合批处理的通用平台，结果可能会是一个高度复杂的系统，并且最终系统可能对两种计算都不理想。
2. 数据流模型
在数据流模型中，需要处理的输入数据（全部或部分）并不存储在可随机访问的磁盘或内存中，但它们却以一个或多个“连续数据流”的形式到达。数据流不同于传统的存储关系模型，主要区别有如下几个方面：
流中的数据元素在线到达；
系统无法控制将要处理的新到达的数据元素的顺序，无论这些数据元素是在一个数据流中还是跨多个数据流；也即重放的数据流可能和上次数据流的元素顺序不一致；
数据流的潜在大小也许是无穷无尽的；
一旦数据流中的某个元素经过处理，要么被丢弃，要么被归档存储。因此，除非该数据被直接存储在内存中，否则将不容易被检索。相对于数据流的大小，这是一种典型的极小相关。
数据流模型中的操作并不排除传统关系型数据的存在。通常，数据流操作将建立数据流和关系型数据的联系。在数据流处理过程中，更新存储关系的同时可能会产生传输处理问题。
3. 百度现有数据流系统
百度内部有很多独立的数据流计算系统，用来满足各产品线的业务需求。以下列举几个典型系统稍作分析。
广告点击计费反作弊系统
对于商务搜索部门来说，广告点击计费和网页检索反作弊是非常重要的两个方面。点击计费业务对时效性、高可靠和准确度的要求都非常高，目前由独立的数据流处理系统支撑业务。系统的每来一个元组就处理一次；为了保证业务处理的及时性，在关键处理环节上进行拆分，尽量并行处理；系统本身有容错支持，但非全局容错，只支持某些功能模块的双机互为热备，异常情况下仍然存在丢失少量数据的风险；另外，现有系统仅仅通过目前点击流量进行反作弊计费，而点击依赖的网页检索流量并没有流入系统，反作弊准确性方面还有提升空间。
广告检索反作弊系统
出于实时性和开发效率的权衡，许多实时系统都借助Hadoop来解决问题。相对而言，检索反作弊的时效性要求要低于点击，现有系统也是基于MapReduce框架实现的。MapReduce提供了容错机制，提供了Order By等机制，并保证了最多30分钟的执行时间，这些特性都支撑该系统的运行。不过，检索反作弊系统的设计初衷也是希望做到尽量实时，目前该系统的时效性受限于上游日志文件的生成时限，以及Hadoop平台执行时任务启动开销和执行时间的不稳定。
统一日志统计平台
LOG日志统计平台上运行着一些实时性作业，例如Columbus等，时效性是它们关注的重点。5分钟的统计作业目前在Hadoop实时集群执行，期望保证时效性。不过类似于检索反作弊系统，MapReduce作业的启动开销不可避免；另外，如果Hadoop集群某些机器出现问题，至少需要重新执行多个任务，也会影响作业的时效性；再者，如果统计作业发现数据出现问题，想从某个时间点重新计算，则可能会重复执行以前的大量计算。
统一服务监控平台
对诺亚监控系统而言，时效性和准确度也是其关心的问题，不过由于不涉及钱的问题，它相对要求低一些。诺亚的集群是人工配置的，存在宕机风险；如果流量增大，也需要人工修改配置；诺亚的大部分算子是Aggregator，涉及中间状态的保存，目前没有冗余备份机制，如果发生故障会导致结果不准。
站点统计平台
对福尔摩斯站点统计系统来说，已经基本做到了实时统计，但其现有架构仍然存在很多问题。例如不支持自动容错，不支持自动扩展，不能很好的保证线上服务的可用性和稳定性，系统扩容时往往会影响线上服务，运维人力成本高等；再者，福尔摩斯是个专用系统，许多业务逻辑和系统逻辑混合在一起，每每需要进行业务变更时，改动量很大，也不适合一些规则和业务的快速上线。
综上所述，实现百度公司通用的数据流计算平台是非常必要、非常迫切的一件事情，有助于提升公司业务水平，节省维护成本和开发成本。
4. 百度下一代数据流系统
在百度基础架构部的下一代规划中，实时计算是重要的组成部分。图1从整个分析系统的架构角度，给出了实时计算子系统所处的位置。实时计算系统和批处理计算系统同属于计算这个大的范畴，批处理计算可以是MapReduce、MPI等，实时计算可以是DStream等，批处理和实时都可以或不依赖统一的资源调度系统。另外，计算系统的输入、输出，包括中间过程的输入、输出，都与存储系统或者传输通道（Bigpipe）交互。计算系统的上层是 数据仓库，或者计算系统直接和用户交互，交互方式可以是SQL-like，或者是MR-like等。
(图 1 数据分析系统整体组成示意图)
实时计算方向重要的一个模块就是实时数据流计算。如图2所示，百度下一代通用数据流计算系统DStream提供分布式的、高可靠的、高可用的、可伸缩的、可扩展的、易开发的流式计算服务，一般故障恢复时间在10s以内，极端故障恢复在5分钟内。DStream的Release 1.0版本将在2012年上半年发布。
如图2所示，DStream包括Client、Processing Master（PM）、Processing Node（PN）三大组件，PN上有多个Processing Element（PE）实例执行。DStream依赖几个第三方系统，Bigpipe、Zookeeper和HDFS，分别用于数据流输入输出和操作日志的存储、分布式异常监控、用户文件存储和计算状态存储。
(图 2 数据流计算系统DStream结构示意图)
5. 业界数据流项目
近年来，业界出现了不少实时数据流计算系统，虽然没有一个类似于Hadoop的集大成者，但是也都各具特色，值得我们学习和研究。下面简单介绍几种业界典型的流式计算系统，包括Yahoo! S4、Twitter Storm、IBM StreamBase 及学术界开源的Borealis。
S4
Yahoo! S4（Simple Scalable Streaming System）是一个通用的、分布式的、可扩展的、分区容错的、可插拔的流式系统。基于S4框架，开发者可以容易地开发面向持续流数据处理的应用。S4的最新版本是alpha version v0.3.0，最近刚成为Apache孵化项目，其设计特点有以下几个方面：
1）Actor计算模型
为了能在普通机型构成的集群上进行分布式处理，并且集群内部不使用共享内存，S4架构采用了Actor模式，这种模式提供了封装和地址透明语义，因此在允许应用大规模并发的同时，也提供了简单的编程接口。S4系统通过处理单元（Processing Elements，PEs）进行计算，消息在处理单元间以数据事件的形式传送，PE消费事件，发出一个或多个可能被其他PE处理的事件，或者直接发布结果。每个PE的状态对于其他PE不可见，PE之间唯一的交互模式就是发出事件和消费事件。框架提供了路由事件到合适的PE和创建新PE实例的功能。S4的设计模式符合封装和地址透明的特性。
2）对等集群架构
除了遵循Actor模式，S4也参照了MapReduce模式。为了简化部署和运维，从而达到更好地稳定性和扩展性，S4采用了对等架构，集群中的所有处理节点都是等同的，没有中心控制。这种架构将使得集群的扩展性很好，处理节点的总数理论上无上限；同时，S4将没有单点容错的问题。
3）可插拔体系架构
S4系统使用Java语言开发，采用了极富层次的模块化编程，每个通用功能点都尽量抽象出来作为通用模块，而且尽可能地让各模块实现可定制化。
4）支持部分容错
基于Zookeeper服务的集群管理层将会自动路由事件从失效节点到其他节点。除非显式保存到持久性存储，否则节点故障时，节点上处理事件的状态会丢失。
5）支持面向对象
节点间通信采用“plain old Java objects”(POJOs) 模式，应用开发者不需要写schemas 或用哈希表来在节点间发送tuples。
Storm
Storm是Twitter近期开源的实时数据流计算系统，它被托管在GitHub上，遵循 Eclipse Public License 1.0。GitHub上的最新版本是Storm 0.5.2，用Clojure函数式语言开发。Storm为分布式实时计算提供了一组通用原语，可被用于“流处理”之中，实时处理消息并更新数据库，这是管理队列及工作者集群的另一种方式。Storm的主要特点如下：
1）简单的编程模型
类似于MapReduce降低了并行批处理复杂性，Storm降低了进行实时处理的复杂性。
2）支持各种编程语言
可以在Storm之上使用各种编程语言。默认支持Clojure、Java、Ruby和Python。要增加对其他语言的支持，只需实现一个简单的Storm通信协议即可。
3）支持容错
Storm会管理工作进程和节点的故障。
4）支持水平扩展
计算是在多个线程、进程和服务器之间并行进行的。
5）可靠的消息处理
Storm保证每个消息至少能得到一次完整处理。任务失败时，它会负责从消息源重试消息。
6）高效消息处理
系统的设计保证了消息能得到快速的处理，使用?MQ作为其底层消息队列。
StreamBase
StreamBase 是IBM开发的一款商业流式计算系统，在金融行业和政府部门使用，其本身是商业应用软件，但提供了develop edition。相对于付费使用的enterprise edition，前者的功能更少，但这并不妨碍我们从外部使用和API接口来对StreamBase本身分析。StreamBase的设计特点有以下几个方面：
1）超便捷的应用接口
StreamBase 使用Java语言开发，IDE是基于Eclipse来进行二次开发，功能非常强大。StreamBase也提供了相当多的operator、functor以及其他组件来帮助构建应用程序。用户只需要通过IDE拖拉控件，然后关联一下，设置好传输的schema并且设置一下控件计算过程，就可以编译出一个高效处理的流式应用程序了。同时，StreamBase还提供了类SQL语言来描述计算过程。
2）支持异构流输入输出
StreamBase通过Adapter组件支持异构数据流的输入和输出，数据源或者目的地可以是CSV文件、JDBC、JMS、Simulation（系统提供了流产生模拟器）等，也可以用户自行定制。
3） 支持计算状态保存
StreamBase通过QueryTable保存数据流的tuples，QueryTable支持内存表和磁盘表，对于磁盘表的话支持三种写模式：
non-transaction模式，只写入并不做transaction。
half-transaction模式，保证transaction，但flush时机并不确定。
full-transaction模式，这种模式保证transaction，并且强制每次flush。
4）支持多种容错方案
StreamBase 提出了以下4种模板策略来解决容错问题：
Hot-Hot Server Pair Template
primary和secondary server都在同时计算，并且将计算结果交给下游。优点是primary server如果故障的话那么secondary server依然工作，几乎没有任何切换时间；并且下游只需要选取先到来的tuple就可以处理了，保证处理速度最快。缺点是浪费计算和网络资源。
Hot-Warm Server Pair Template
primary和secondary server都在同时计算，但只有primary server将计算结果交给下游。优点是如果primary server故障，secondary server可以很快切换，而不需要任何恢复状态的工作。相对于Hot-Hot方式时间稍微长一些，但没有Hot-Hot那么耗费网络资源，同时也浪费了计算资源。
Shared Disk Template
primary server在计算之后，将计算的一些中间关键状态存储到磁盘、SAN（Storage Area Network）或是可靠的存储介质。如果primary server故障， secondary server会从介质中读取出关键状态，然后接着继续计算。优点是没有浪费任何计算和网路资源，但是恢复时间依赖状态的量级而定，相对于前两种，恢复时间可能会稍长。
Fast Restart Template
这种方案限定了应用场景，只针对无状态的应用。对于无状态的情况，方案可以非常简单，只要发现primary server故障，secondary server立即启动，并接着上游的数据流继续计算即可。
Borealis
Borealis是Brandeis University、 Brown University和 MIT合作开发的分布式流式系统。Borealis系统是三所大学在之前的流式系统Aurora、Medusa演化而来。目前Borealis系统已经停止维护，最新的Release版本发布于2008年。
Borealis具有丰富的论文、完整的用户/开发者文档，系统是C++实现的，运行于x86-based Linux平台。系统自身是开源的，同时使用了较多的第三方开源组件，包括用于查询语言翻译的ANTLR、C++的网络编程框架库NMSTL等。
Borealis系统的流式模型和其他流式系统基本一致：接受多元的数据流和输出，为了容错，采用确定性计算，对于容错性要求高的系统，会对输入流使用算子进行定序。Borealis的设计特点有以下几个方面：
1）可变集群架构
Borealis集群的节点可以部署为对等架构，也可以设计一个协作节点来执行全局的系统监控和其他优化任务，比如全局的负载分布和global load shedding。Borealis实际上提供了完整的3级监控和优化（local，neighborhood，global）。
2）支持多种负载均衡机制
负载均衡方面，Borealis提供了动态和静态两种部署机制：
Correlation-based operator distribution
通过分析不同operators和nodes间的负载变化的关系，决定和动态调整operatpr的部署，使之达到负载均衡。
Resilient operator distribution algorithm
该算法的目标是提供一种静态的operator部署方案，该方案能够在不需要重新调整的情况下处理最大可能的输入速度变化范围。
由于动态调整需要时间和消耗，前者适用于负载变化持续时间较长的系统；而后者则能处理较快较短的负载峰值。在实现上前者使用相关系数作为节点关联度指标，并通过贪心算法将NP问题转化为多项式求解；而后者在部署前计算完毕，保证系统能够容忍负载峰值。该算法在线性代数上建模，包括Operator Ordering、Operator Assignment两个阶段。
3）支持多种容错方案
Borealis通过多种容错机制来满足用户需求：
Amnesia Backup
备机发现主机故障，立即从一个空的状态开始重做。
Passive Standby
主机处理，备机待命，主机按周期做checkpoints，主机故障后切换到备机，重放checkpoint和数据流，对于不确定性计算可以很好地支持，缺点是恢复时间较长。
Active Standby
主备机同时计算，主机故障时直接切换到备机，不支持不确定性计算，浪费计算资源，优势在于几乎没有恢复时间。
Upstream Backup
通过上游备份来容错，故障时从上游重放数据即可，恢复时间最长，不过最节省资源。
Rollback Recovery
除了基础的容错方案，Borealis还提供了更高级的容错机制Rollback Recovery，它是一种基于副本在节点失效、网络失效或网络分区时的故障恢复机制，在尽量减少系统不一致的情况下，尽可能的保证系统的可用性。该机制允许用户定义一个阈值来在一致性和可用性之间做一个平衡。当系统数据恢复后，系统支持重新计算输出正确的结果，保证最终一致性。该机制使用了data-serializing operator（SUnion）来确保所有的副本处理同样顺序的数据。当失效恢复后，通过checkpoint/redo、undo/redo来实现恢复重放。
6. 结论与展望
实时计算是近年来分布式计算领域研究的重点，无论是工业界还是学术界，都诞生了几个具有代表性的实时数据流计算系统，用于解决实际生产问题和进行学术研究。
S4的最新版本是alpha version v0.3.0，动态负载均衡和在线服务迁移等重要功能都尚未实现；Storm通过简单实现满足Twitter实际需求，但基于重放的恢复机制很难保证高可用性和计算一致性，另外基于函数式语言Clojure开发也使得它很难广泛开源使用；StreamBase虽然功能齐全却是商用软件，使用成本较大；Borealis对数据流计算的各方面研究广泛且深入，有很好的参考价值，但由于是学术界产物，尚未在工业界大规模使用。
百度现有实时流式计算平台多为独立系统或者依赖MapReduce框架，在可靠性、高可用、实时性、伸缩性、维护成本、开发成本等方面都存在不足。
基于数据流计算领域业界系统分析和百度现状分析，我们基础架构部的实时计算小组决定开发属于百度自己的通用实时数据流计算系统——DStream，用于满足百度内部所有的实时数据流处理需求，并希望DStream能在实时计算领域成为集大成者。
实时计算是分布式计算领域重要组成部分，随着应用规模的不断扩大以及对实时性需求的不断提高，实时数据流计算的前景一片光明，欢迎大家关注和参与实时计算项目。