最近遇到了一些storm的问题，在这里总结一下。

一、我有一个数据文件，或者我有一个系统里面有数据，怎么导入storm做计算？
你需要实现一个Spout，Spout负责将数据emit到storm系统里，交给bolts计算。怎么实现spout可以参考官方的kestrel spout实现：
https://github.com/nathanmarz/storm-kestrel
如果你的数据源不支持事务性消费，那么就无法得到storm提供的可靠处理的保证，也没必要实现ISpout接口中的ack和fail方法。

 

二、Storm为了保证tuple的可靠处理，需要保存tuple信息，这会不会导致内存OOM？
Storm为了保证tuple的可靠处理，acker会保存该节点创建的tuple id的xor值，这称为ack value，那么每ack一次，就将tuple id和ack value做异或(xor)。当所有产生的tuple都被ack的时候， ack value一定为0。这是个很简单的策略，对于每一个tuple也只要占用约20个字节的内存。对于100万tuple，也才20M左右。关于可靠处理看这个：
https://github.com/nathanmarz/storm/wiki/Guaranteeing-message-processing

 

三、Storm计算后的结果保存在哪里？可以保存在外部存储吗？
Storm不处理计算结果的保存，这是应用代码需要负责的事情，如果数据不大，你可以简单地保存在内存里，也可以每次都更新数据库，也可以采用NoSQL存储。storm并没有像s4那样提供一个Persist API，根据时间或者容量来做存储输出。这部分事情完全交给用户。
数据存储之后的展现，也是你需要自己处理的，storm UI只提供对topology的监控和统计。

 

四、Storm怎么处理重复的tuple？
因为Storm要保证tuple的可靠处理，当tuple处理失败或者超时的时候，spout会fail并重新发送该tuple，那么就会有tuple重复计算的问题。这个问题是很难解决的，storm也没有提供机制帮助你解决。一些可行的策略：
（1）不处理，这也算是种策略。因为实时计算通常并不要求很高的精确度，后续的批处理计算会更正实时计算的误差。
（2）使用第三方集中存储来过滤，比如利用mysql,memcached或者redis根据逻辑主键来去重。
（3）使用bloom filter做过滤，简单高效。

 

五、Storm的动态增删节点
我在storm和s4里比较里谈到的动态增删节点，是指storm可以动态地添加和减少supervisor节点。对于减少节点来说，被移除的supervisor上的worker会被nimbus重新负载均衡到其他supervisor节点上。在storm 0.6.1以前的版本，增加supervisor节点不会影响现有的topology，也就是现有的topology不会重新负载均衡到新的节点上，在扩展集群的时候很不方便，需要重新提交topology。因此我在storm的邮件列表里提了这个问题，storm的开发者nathanmarz创建了一个issue 54并在0.6.1提供了rebalance命令来让正在运行的topology重新负载均衡，具体见：
https://github.com/nathanmarz/storm/issues/54
和0.6.1的变更：
http://groups.google.com/group/storm-user/browse_thread/thread/24a8fce0b2e53246
storm并不提供机制来动态调整worker和task数目。

 

六、Storm UI里spout统计的complete latency的具体含义是什么？为什么emit的数目会是acked的两倍？
这个事实上是storm邮件列表里的一个问题。Storm作者marz的解答：

The complete latency is the time from the spout emitting a tuple to that
tuple being acked on the spout. So it tracks the time for the whole tuple
tree to be processed.

 

If you dive into the spout component in the UI, you'll see that a lot of
the emitted/transferred is on the __ack* stream. This is the spout
communicating with the ackers which take care of tracking the tuple trees.

简单地说，complete latency表示了tuple从emit到被acked经过的时间，可以认为是tuple以及该tuple的后续子孙（形成一棵树）整个处理时间。其次spout的emit和transfered还统计了spout和acker之间内部的通信信息，比如对于可靠处理的spout来说，会在emit的时候同时发送一个_ack_init给acker，记录tuple id到task id的映射，以便ack的时候能找到正确的acker task。