Storm基本原理

原文地址：http://storm.apache.org/documentation/Rationale.html

然而大规模实时数据处理的需求与日俱增，缺少一个“实时的Hadoop”已经成为数据处理领域最大的缺憾。

Storm填补了这个缺憾。

在Storm出现以前，通常你需要手工建立一个队列节点与工作节点的网络来进行实时数据处理。工作节点处理队列中的消息，更新数据库，发送消息到另一个队列以进行进一步的处理。这样的方式有许多问题：

1. 编码枯燥。你需要花费很多时间去做配置，消息要发送到哪，怎么部署队列节点，怎么部署工作节点。而你真正关心的实时处理逻辑只占你代码的一小部分。
2. 系统脆弱。容错性太差，你需要自己去注意每一个队列节点和工作节点的状态。
3. 不易扩展。当单个节点的消息吞吐量过高时，你需要对消息进行切分。对于其他工作节点则需要进行重新配置，这样才能将消息发送给新的节点。其中引入的节点变更都有可能失败。

尽管在处理大量消息时，队列节点与工作节点这样的处理方式运转得不是太好，但消息处理无疑是实时计算的基本范式。问题是应该怎么样才能让消息处理可以做到不丢数据，可以处理超大规模的数据，并且可以很简单的来使用和运维？

Storm可以解决这些问题。

Storm的重要性

Storm暴露了一系列的原语用于实时计算。就像MapReduce极大的简化了并行批处理程序的编写，Storm的原语也极大的简化了并行实时计算程序的编写。

Storm的关键特性：

1. 使用场景非常广泛。Storm可以用于处理消息，更新数据库（流式处理），对数据流进行连续查询并将结果流式的返回给客户端（连续计算），分布式RPC等等。少量的原语满足了大量的使用需求。
2. 扩展性。Storm可以扩展到每秒钟可处理大量的消息。要扩展一个拓扑，你只需要添加机器并修改拓扑的设置就可以。作为例子，Storm的一个初始应用，在拥有10个节点的集群上面，每秒钟可以处理1,000,000条消息，其中还包括了每秒钟几百次的数据库访问。通过使用ZooKeeper，Storm的集群可以扩展到一个更大的规模。
3. 可靠性。一个实时系统必须能够保证所有的数据都被成功处理，如果无法保证将会限制它的使用场景。Storm可以保证每一条消息都被处理。这是Storm与其他系统，比如S4，最大的不同。
4. 鲁棒性。Hadoop是出了名的难管理，而Storm不一样。让用户尽可能不费力气的来管理Storm集群是Storm项目的一个目标。
5. 容错性。当计算过程中发生了故障，如果有必要的话Storm会重新分配任务。Storm会确保计算任务一直进行下去，除非你去终止它。
6. 编程语言无关性。拥有鲁棒性与扩展性的实时处理系统不应该局限在单一的平台上。可以使用任何的语言来定义Storm的拓扑逻辑和组件，这使得几乎所有人都可以使用Storm。