原文地址：http://storm.apache.org/documentation/Rationale.html
过去的10年见证了数据处理领域的1次革命。MapReduce，Hadoop和其它相干的技术使得我们可以存储与处理的数据到达了过去想都不敢想的量级。不幸的是，这些数据处理技术其实不能用于实时系统。本身这些技术也不是为了用于实时系统而生的。我们也没有任何方式可以将Hadoop改造以用于实时系统；实时数据处理与批处理截然不同。
但是大范围实时数据处理的需求与日俱增，缺少1个“实时的Hadoop”已成为数据处理领域最大的缺憾。
Storm弥补了这个缺憾。
在Storm出现之前，通常你需要手工建立1个队列节点与工作节点的网络来进行实时数据处理。工作节点处理队列中的消息，更新数据库，发送消息到另外一个队列以进行进1步的处理。这样的方式有许多问题：
- 编码枯燥。你需要花费很多时间去做配置，消息要发送到哪，怎样部署队列节点，怎样部署工作节点。而你真正关心的实时处理逻辑只占你代码的1小部份。
- 系统脆弱。容错性太差，你需要自己去注意每个队列节点和工作节点的状态。
- 不容易扩大。当单个节点的消息吞吐量太高时，你需要对消息进行切分。对其他工作节点则需要进行重新配置，这样才能将消息发送给新的节点。其中引入的节点变更都有可能失败。
虽然在处理大量消息时，队列节点与工作节点这样的处理方式运转得不是太好，但消息处理无疑是实时计算的基本范式。问题是应当怎样样才能让消息处理可以做到不丢数据，可以处理超大范围的数据，并且可以很简单的来使用和运维？
Storm可以解决这些问题。
Storm的重要性
Storm暴露了1系列的原语用于实时计算。就像MapReduce极大的简化了并行批处理程序的编写，Storm的原语也极大的简化了并行实时计算程序的编写。
Storm的关键特性：
- 使用处景非常广泛。Storm可以用于处理消息，更新数据库（流式处理），对数据流进行连续查询并将结果流式的返回给客户端（连续计算），散布式RPC等等。少许的原语满足了大量的使用需求。
- 扩大性。Storm可以扩大到每秒钟可处理大量的消息。要扩大1个拓扑，你只需要添加机器并修改拓扑的设置就能够。作为例子，Storm的1个初始利用，在具有10个节点的集群上面，每秒钟可以处理1,000,000条消息，其中还包括了每秒钟几百次的数据库访问。通过使用ZooKeeper，Storm的集群可以扩大到1个更大的范围。
- 可靠性。1个实时系统必须能够保证所有的数据都被成功处理，如果没法保证将会限制它的使用处景。Storm可以保证每条消息都被处理。这是Storm与其他系统，比如S4，最大的不同。
- 鲁棒性。Hadoop是出了名的难管理，而Storm不1样。让用户尽量不费力气的来管理Storm集群是Storm项目的1个目标。
- 容错性。当计算进程中产生了故障，如果有必要的话Storm会重新分配任务。Storm会确保计算任务1直进行下去，除非你去终止它。
- 编程语言无关性。具有鲁棒性与扩大性的实时处理系统不应当局限在单1的平台上。可使用任何的语言来定义Storm的拓扑逻辑和组件，这使得几近所有人都可使用Storm。