1.2 其他流式处理框架
1.2.1 Apache S4
Apache S4（http://incubator.apache.org/s4/）是由Yahoo开源的多用途、分布式的、可伸缩的、容错的、可插入式的实时数据流计算平台。
S4填补了复杂的专有系统和面向批处理的开源计算平台之间的差距。其目标是开发一个高性能计算平台，对应用程序开发者隐藏并行处理系统固有的复杂性。S4已经在Yahoo!系统中大规模使用，目前最新版本是0.6.0。
S4相对于Storm在可靠性和容错性上差一些，S4不保证完全不丢失数据。在用户活跃度上S4也要差一些。
1.2.2 Spark Streaming
Spark是UC Berkeley AMP Lab开源的类Hadoop MapReduce的通用的并行计算框架。Spark基于MapReduce算法实现的分布式计算拥有Hadoop MapReduce所具有的优点，但不同于MapReduce的是，作业中间输出结果可以保存在内存中，从而不再需要读写HDFS，因此Spark能更好地适用于数据挖掘与机器学习等需要迭代的MapReduce的算法。
Spark Streaming是建立在Spark上的实时计算框架，通过它提供的API和基于内存的高速执行引擎，用户可以结合流式、批处理和交互式进行查询和实时计算。Spark Streaming的基本的原理是将Stream数据分成小的时间片断（几秒钟到几分钟），以类似batch批量处理的方式来处理这些小部分数据。Spark Streaming构建在Spark上，一方面是因为Spark的低延迟执行引擎可以用于实时计算，另一方面相比基于Record的其他处理框架（如Storm），弹性分布式数据集（Resilient Distributed Datasets，RDD）更容易实现高效的容错处理。此外，小批量处理的方式使得它可以同时兼容批量和实时数据处理的逻辑和算法，方便了一些需要历史数据和实时数据联合分析的特定应用场合。
Spark Streaming和Storm两个框架都提供了可扩展性和容错性，它们根本的区别在于它们的处理模型。Storm处理的是每次传入的一个事件，而Spark Streaming是处理某个时间段窗口内的事件流。因此，Storm处理一个事件可以达到极低的延迟，而Spark Streaming的延迟相对较高。
1.2.3 流计算和Storm的应用
大数据的价值在各行各业中得到了广泛使用。针对离线处理，Hadoop已经成为事实上的标准；针对数据实时处理的需求，目前涌现出了许多平台和解决方案。以下汇总了截至2014年流计算和Storm的使用情况。
1．新浪的实时分析平台
新浪实时分析平台的计算引擎是Storm，整个实时计算平台包括可视化的任务提交Portal界面、对实时计算任务的管理监控平台以及核心处理实时计算平台。
Storm作为核心处理，待处理数据来源为Kafka。对于实时性要求比较高的应用、数据会直接发送到Kafka，然后由Storm中的应用进行实时分析处理；而对实时性要求不太高的应用，则由Scribe收集数据，然后转发到Kafka中，再由Storm进行处理。
任务提交到Portal之前，作业的提交者需要确定数据源、数据的每个处理逻辑，同时确定处理完成后数据的存储、获取和展示方式。在任务提交后，可以完成对任务的管理：编辑、停止、暂停和恢复等。
整个核心处理平台提供了一些通用的模块，如数据的解析（不同的应用有不同的数据格式，可以是简单的分隔符分隔和正则表达式）、对特定字段的TopN计数以及数据的过滤和去重，数据处理过程中使用到了缓存Redis，支持多种存储方式（数据处理完成后可选择的持久化方式有HBase、HDFS、本地文件和MySQL等）。
在应用上，实时分析平台的应用包括HTTP日志分析、PV计算等。
在监控上，通过Storm的Nimbus节点，获取集群的运行数据，结合JMX收集到进程状态信息，将数据发送到统一的监控工具中（如Ganglia）。
2．腾讯的实时计算平台
腾讯的实时计算平台Tencent Real-time Computing主要由两部分组成：分布式K/V存储引擎TDEngine和支持数据流计算的TDProcess。TDProcess是基于Storm的计算引擎，提供了通用的计算模型，如Sum、Count、PV/UV计算和TopK统计等。整个平台修复了运行中发现的Storm的问题，同时引入YARN进行资源管理。
据称，整个计算平台每天承载了超过1000亿数据量的计算，支持广点通、微信、视频、易迅、秒级监控、电商和互娱等业务上百个实时统计的需求。
3．奇虎360实时平台
奇虎360从2012年开始引入Storm，Storm主要应用场景包括云盘缩略图、日志实时分析、搜索热词推荐、在线验证码识别、实时网络入侵检测等包括网页、图片、安全等应用。在部署中，使用了CGroup进行资源隔离，并向Storm提交了很多补丁，如log UI（https://github.com/nathanmarz/storm/pull/598）等。在部署上，Storm集群复用了其他机器的空闲资源（Storm部署在其他服务的服务器上，每台机器贡献1～2核处理器、1～2 GB内存），整个规模达到60多个集群，15 000多台物理机，服务于170多个业务。每天处理数据量约几百TB、几百亿条记录。
4．京东的实时平台
京东的实时平台基于LinkedIn开源的Samza，整个Samza包括流处理层Kafka，执行层YARN和处理层Samza API。一个流式处理由一个或多个作业组成，作业之间的信息交互借助Kafka实现，一个作业在运行状态表现为一个或者多个Task，整个处理过程实际上是在Task中完成的。在Samza中，Kafka主要的角色是消息的缓冲、作业交互信息的存储，同一个业务流程中使用YARN进行任务调度。在其整个架构中，引入了Redis作为数据处理结果的存储，并通过Comet技术将实时分析的数据推送到前台展示，整个业务主要应用于京东大家电的订单处理，实时分析统计出待定区域中各个状态的订单量（包括待定位、待派工、待拣货、待发货、待配送、待妥投等）。
5．百度的实时系统
相对而言，百度在实时系统上开展的比较早，在其流计算平台DStream开发时业界尚未有类似的开源系统。截至2014年，从公开的资料可以发现，DStream平台的集群规模已超千台，单集群最大处理数据量超过50 TB/天，集群峰值QPS 193W/S，系统稳定性、计算能力已完全满足海量数据时效性处理需求。另一个平台TM则保证数据不重不丢，主要用于报表生成系统、计费流计算等。
6．阿里巴巴团队的JStorm
JStorm（https://github.com/alibaba/jstorm）是阿里巴巴团队基于Storm二次开发的，Spout/Bolt等接口的使用方式和Storm保持完全一致，在Storm上开发和运行的代码可以一行不修改就运行在JStorm上。Storm的内核是Clojure编写，JStorm完全用Java重写。JStorm还提供了一些Storm没有的特性。
- Nimbus实现HA：当一台Nimbus宕机，自动热切到备份Nimbus。
- 任务之间影响小：新上线的任务不会冲击老的任务。采用CGroups对资源进行硬隔离，保证程序之间CPU不发生抢占。
- 解决Disruptor急剧消耗CPU问题：当原生Disruptor队列慢时，生产方会不断轮询检查Disruptor队列是否有空的Slot，极大消耗队列。
- 调度更强大，彻底解决了Storm任务分配不均衡问题。从CPU、内存、磁盘、网络4个维度进行任务分配。
- Classloader隔离：解决应用的类和JStorm的类发生冲突的问题。将应用的类放置在自己的类空间中。
- 监控更强大：Web UI上展示更多的监控。Task级别，每一个模块消耗时间和队列长度；Worker级别，每一个模块消耗时间、队列长度、CPU/Memory使用以及网络时延；还包括用户自定义监控数据。
- 在JStorm的介绍中，JStorm上的应用能够在一行代码都不需要改动的情况下运行在Storm平台上，结合JStorm的其他特性，这将给JStorm带来更广阔的使用选择。
JStrom的开发和更新速度非常快，用户活跃度也很高。更多详细信息可以参考GitHub的介绍。