storm-rationale

2014-07-07

本文为Storm官方文档Rationale的读书笔记

Storm基本原理

过去十年见证了数据处理的革命。MapReduce、Hadoop以及相关技术使得存储和处理之前不可想象的规模的数据变成可能。不幸的是，这些数据处理技术不是实时系统，也不是被设计为实时系统的。没有办法让Hadoop变身为实时系统，实时数据处理和批处理在需求上有着根本性的不同。

然而，商业对于大规模实时数据处理的需求越来越大。“实时Hadoop”的缺乏变成数据处理生态圈最大的缺口。

Storm填补了这个缺口。

在Storm之前，为了做实时处理，典型地你需要手工创建一个队列网络和工作者。工作者从队列中获取消息、处理、写DB、发送消息给其他队列以供后续处理。不幸的是，这个方法有一系列限制：

• 沉闷乏味。 你的大部分开发时间被用于配置发送消息去哪里、部署Workers、部署中间队列。真正关心的实时处理逻辑只占了代码的很小一部分。
• 脆弱。 几乎没有容错。你需要为每一个worker和队列负责。
• 扩容痛苦。 当消息流量大到超过了一个worker或者queue的处理能力，你需要partition分发消息。你需要重新配置workers以让其知道新的发送消息位置。这引入了新的可能失败的部分。

虽然“队列&Worker的范例”在大量消息面前失败了，消息处理显然是实时计算的基本范例。问题是：如何在不丢数据、扩容方便、易于使用和操作的方式下实现？

Storm满足这些目标。

Why Storm is important

Storm暴露了一套原语来支撑实时计算。就像MapReduce极大的简化了并行批处理的开发，Storm原语也极大的简化了并行实时计算的开发。

Storm的关键属性如下：

1. 极广泛的用例 Storm可以被用与消息处理写db（流式处理）、对数据流做持续query将结果发给客户端（持续计算）、并行化远程较重的查询（分布式RPC），以及其他。Storm的语言满足了很多使用场景。

2. 可扩展性 想要对一个拓扑扩容，你只需要加机器并增加拓扑的并发设置。作为Storm扩容的例子，Storm最开始的一个应用在10台机器上每秒处理1000000个消息，包括每秒上百的db调用。Storm使用Zookeeper做集群协调，使得其可以扩容至更大的规模。

3. 保证不丢数据 实时系统需要保证数据被成功处理。会丢数据的系统使用场景会变得很窄。Storm保证每个消息都会被处理，这直接与S4形成对比。

4. 极其稳定 不像Hadoop，出了名的难以管理。Storm项目的一个重要目标就是让管理Storm集群的用户体验变得尽量轻松。

5. 容错性 如果在计算的执行过程中出错了，Storm会重新分配一个task。Storm保证一个计算永远运行（除非杀死）。

6. 编程语言无关 鲁棒的、易扩容的实时处理不应该被限制在单平台上。Storm拓扑和处理组件可以使用任意语言编写，这让Storm可以被每个人使用。