为什么选择Twitter Storm？

Rationale

在过去的十年里，数据处理发生了革命性的变化。MapReduce，Hadoop，以及相关的技术使我们可以存储和处理以前不可想象规模的数据。很遗憾，这些数据处理系统都不是实时系统，命中注定也不是它们。根本没办法把Hadoop变成一个实时系统；实时数据处理和批处理的许多要求在根本上有很大不同。

然而，企业对大规模实时数据处理要求越来越多。缺乏“实时Hadoop”是数据处理生态系统中最大的窘境。

Storm解决了这个窘境。

Storm之前，你通常必须手动建立一个由许多队列和许多worker组成的网络来实现实时处理。worker处理队列消息，更新数据库，发送新消息给其它队列以供后续处理。很遗憾，这种方法有很大的局限性。

乏味：你大部份开发时间花费在配置消息发送，部署worker，部署中间队列。你关心的实时处理逻辑对应到你的代码的比例相对较小 。

脆弱：没有多少容错。你负责保持每个worker和队列正常工作。

痛苦伸缩：当单个worker或队列的消息吞吐量太高时，你需要分区，即数据如何分散。你需要重新配置其它worker，让它们发送消息到新位置。这导致删除或添加部件都可能失败。

虽然队列+workers的范式能解决大量的消息，消息处理显然是实时计算的基本范式。问题是：你要怎么做，才能在某种程度上保证数据不会丢失，对海量消息轻松扩容，并且使用和运营工作都超级简单呢？

Storm满足这些目标。

Storm如此重要，为什么？

Storm公开（expose）一组实时计算原语。类似MapReduce极大地简化了编写并行批处理程序，storm的原语极大地简化了编写并行实时计算程序。

Storm的关键特性：

用例非常广泛：Storm可用于处理消息和更新数据库（流处理），在数据流上进行持续查询，并以流的形式返回结果到客户端（持续计算），并行化一个类似实时查询的热点查询（分布式的RPC），还有更多的用例。Storm的一组很小的原语满足了惊人数量的用例。

可伸缩：Storm随时都可对大规模消息进行扩容。扩容一个拓扑，你只需要添加机器和增加的拓扑结构的并行设置。看一个storm规模的例子，一个storm集群有10个节点，一个最初的Storm应用每秒可以处理1,000,000个消息（指spout和bolt总共发射的消息总和），拓扑的其中一部分每秒数有数百个数据库调用。Storm使用Zookeeper协调集群，使其集群可以扩容到非常大。

保证数据不丢失：实时系统必须对成功处理数据提供有力保证 。系统丢弃数据的用例非常有限。Storm保证每个消息都被处理，这直接与其它系统截然不同，如S4。

非常健壮：Storm与Hadoop不同，Hadoop难于管理早已臭名昭著，Storm集群只是干活。使用户尽可能方便地管理storm集群是storm项目的一个明确目标。

容错：计算的执行过程中如果发生故障，Storm将在必要时重新分配任务。Storm确保计算永远运行（或者直到你kill此计算） 。

编程语言无关性：健壮和可伸缩的实时处理不应仅限于一个单一的平台。Storm的拓扑结构和处理组件可以用任何语言定义，对任何人而言，Storm都是易接受的。

英文：https://github.com/nathanmarz/storm/wiki/Rationale