背景
非实时计算几乎都基于MapReduce计算框架，但MapReduce并不是万能的。对于搜索应用环境中的某些现实问题，MapReduce并不能很好地解决问题。
商用搜索引擎，像Google、Bing和Yahoo!等，通常在用户查询响应中提供结构化的Web结果，同时也插入基于流量的点击付费模式的文本广告。为了在页面上最佳位置展现最相关的广告，通过一些算法来动态估算给定上下文中一个广告被点击的可能性。上下文可能包括用户偏好、地理位置、历史查询、历史点击等信息。一个主搜索引擎可能每秒钟处理成千上万次查询，每个页面都可能会包含多个广告。为了及时处理用户反馈，需要一个低延迟、可扩展、高可靠的处理引擎。然而，对于这些实时性要求很高的应用，尽管MapReduce作了实时性改进，但仍很难稳定地满足应用需求。因为Hadoop为批处理作了高度优化，MapReduce系统典型地通过调度批量任务来操作静态数据;而流式计算的典型范式之一是不确定数据速率的事件流流入系统，系统处理能力必须与事件流量匹配，或者通过近似算法等方法优雅降级，通常称为负载分流(load-shedding)。当然，除了负载分流，流式计算的容错处理等机制也和批处理计算不尽相同。
最近Facebook在Sigmod 11上发表了利用HBase/Hadoop进行实时数据处理的论文，通过一些实时性改造，让批处理计算平台也具备实时计算的能力。这类基于MapReduce进行流式处理的方案有三个主要缺点。
将输入数据分隔成固定大小的片段，再由MapReduce平台处理，缺点在于处理延迟与数据片段的长度、初始化处理任务的开销成正比。小的分段会降低延迟，增加附加开销，并且分段之间的依赖管理更加复杂(例如一个分段可能会需要前一个分段的信息);反之，大的分段会增加延迟。最优的分段大小取决于具体应用。
为了支持流式处理，MapReduce需要被改造成Pipeline的模式，而不是Reduce直接输出;考虑到效率，中间结果最好只保存在内存中等。这些改动使得原有的MapReduce框架的复杂度大大增加，不利于系统的维护和扩展。
用户被迫使用MapReduce的接口来定义流式作业，这使得用户程序的可伸缩性降低。
综上所述，流式处理的模式决定了要和批处理使用非常不同的架构，试图搭建一个既适合流式计算又适合批处理计算的通用平台，结果可能会是一个高度复杂的系统，并且最终系统可能对两种计算都不理想。
目前流式计算是业界研究的一个热点，最近Twitter、LinkedIn等公司相继开源了流式计算系统Storm、Kafka等，加上Yahoo!之前开源的S4，流式计算研究在互联网领域持续升温。不过流式计算并非最近几年才开始研究，传统行业像金融领域等很早就已经在使用流式计算系统，比较知名的有StreamBase、Borealis等。
本文简单介绍几种业界使用的流式计算系统，希望流式系统的设计者或开发者们能从中获得启示。
图1 数据分析系统整体组成示意图
图1从整个分析系统的架构角度，给出了实时计算子系统所处的位置。实时计算系统和批处理计算系统同属于计算这个大的范畴，批处理计算可以是MapReduce、MPI、SCOPE等，实时计算可以是S4、Storm等，批处理和实时都可以或不依赖统一的资源调度系统。另外，计算系统的输入、输出，包括中间过程的输入、输出，都与存储系统交互，可以是块存储系统HDFS，也可以是K-V存储系统Hypertable等。计算层的上层是数据仓库，或者直接和用户交互，交互方式可以是SQL-like或者MR-like等。
系统
S4
S4是一个通用的、分布式的、可扩展的、分区容错的、可插拔的流式系统。基于S4框架，开发者可以轻松开发面向持续流数据处理的应用。
S4的设计特点有以下几个方面。
Actor Model
为了能在普通机型构成的集群上进行分布式处理，并且集群内部不使用共享内存，S4架构采用了Actor模式，这种模式提供了封装和地址透明语义，因此在允许应用大规模并发的同时，也提供了简单的编程接口。S4系统通过处理单元(Processing Elements，PEs)进行计算，消息在处理单元间以数据事件的形式传送，PE消费事件，发出一个或多个可能被其他PE处理的事件，或者直接发布结果。每个PE的状态对于其他PE不可见，PE之间唯一的交互模式就是发出事件和消费事件。框架提供了路由事件到合适的PE和创建新PE实例的功能。S4的设计模式符合封装和地址透明的特性。
Decentralized and Symmetric Architecture
除了遵循Actor模式，S4也参照了MapReduce模式。为了简化部署和运维，从而达到更好地稳定性和扩展性，S4采用了对等架构，集群中的所有处理节点都是等同的，没有中心控制。这种架构将使得集群的扩展性很好，处理节点的总数理论上无上限;同时，S4将没有单点容错的问题。
Pluggable Architecture
S4系统使用Java开发，采用了极富层次的模块化编程，每个通用功能点都尽量抽象出来作为通用模块，而且尽可能让各模块实现可定制化。
Partial Fault-Tolerance
基于Zookeeper服务的集群管理层将会自动路由事件从失效节点到其他节点。除非显式保存到持久性存储，否则节点故障时，节点上处理事件的状态会丢失。
Object Oriented
节点间通信采用“Plain Old Java Objects”(POJOs)模式，应用开发者不需要写Schemas 或用哈希表来在节点间发送Tuples。
S4的功能组件分3大类，Clients、Adapters和PNode Cluster，图2显示了S4系统框架。
图2 Yahoo! S4流式系统框架结构图
S4提供Client Adapter，允许第三方客户端向S4集群发送事件和接收事件。Adapter实现了基于JSON的API，支持多语言实现的客户端驱动。
Client通过Driver组件与Adapter进行交互，Adapter也是一个Cluster，其中有多个Adapter结点，Client可以通过多个Driver与多个Adapter进行通信，这样可以保证单个Client在分发大数据量时Adapter不会成为瓶颈，也可以确保系统支持多个Client应用并发执行的快速、高效和可靠性。