Storm 学习曲线

目前业界 Storm 的学习资料大多比较零散，系统性的资料不多，新手（从零开始，完全没有分布式计算经验积累的新人）往往很容易会被各种概念迷惑，加上 Storm 社区非常活跃，各个发行版之间的变化较大，而网上的很多帖子、博客还是几年前的资料，并不完全兼容当前版本的特性，导致新手阶段的学习异常痛苦。笔者按照个人的经验总结了一些基本的学习路径，希望能够对新同学有所帮助。由于笔者也才入门不久，以下内容还存在不少问题，欢迎大家批评指正。

1. Storm 集群组件 —— nimbus/supervisor;
2. Storm topology 组件 —— spout/bolt;
3. Storm 的并发模型 —— worker/executor/task;
4. Storm 高级模型 —— Trident;
5. Storm 的分布式RPC —— DRPC;
6. Storm 的消息可靠性保障 —— ack 机制;
7. Storm 的集群协调 —— Storm 与 ZooKeeper;
8. Storm 的消息传输机制（worker内部/worker之间）;
9. Storm 实时计算的平滑窗口;
10. 大规模数据流的 partition 与 join；
11. TBC...

---

几点说明

• 1~3 是 Storm 的基础，是必须掌握的内容；
• 如果需要使用简单的封装模型快速开发，需要先了解 4；
• 如果有 RPC 应用开发需求，需要了解 5；
• 如果实时计算应用对消息可靠性要求较高，必须熟悉 6，进一步可以了解 7, 8的相关内容；
• 9 及后续内容是目前实时计算的技术难点，尚未有较完美的解决方案，可以根据需要深入钻研。

---

Storm 最佳实践

Good Use of Storm+Trident

摘自 Storm 官方 FAQ

• number of workers a multiple of number of machines; parallelism a multiple of number of workers; number of kafka partitions a multiple of number of spout parallelism
• Use one worker per topology per machine
• Start with fewer, larger aggregators, one per machine with workers on it
• Use the isolation scheduler
• Use one acker per worker -- 0.9 makes that the default, but earlier versions do not.
• enable GC logging; you should see very few major GCs if things are in reasonable shape.
• set the trident batch millis to about 50% of your typical end-to-end latency.
• Start with a max spout pending that is for sure too small -- one for trident, or the number of executors for storm -- and increase it until you stop seeing changes in the flow. You'll probably end up with something near 2(throughput in recs/sec)(end-to-end latency) (2x the Little's law capacity).

翻译说明：

• worker 的数量最好是服务器数量的倍数；topology 的总并发度(parallelism)最好是 worker 数量的倍数；Kafka 的分区数(partitions)最好是 Spout (特指 KafkaSpout)的并发度的倍数
• 每个机器(supervisor)上最好只部署一个worker
• 应该在一开始使用较少的大聚合器，并且最好在每个有 worker 进程的机器上分配一个
• 使用独立的调度器(scheduler)
• 每个 worker 上只配置使用一个 acker —— 这是 0.9.x 版本的默认特性，但在早期版本中有所不同；
• 在配置文件中开启 GC 日志记录；如果一切正常，日志中的 major GC 应该会非常少；
• 将 trident 的 batch interval 配置为大约50%的端到端平均时延大小的千分之一
• 开始时设置一个很小的 TOPOLOGY_MAX_SPOUT_PENDING（对于 trident 可以设置为1，对于一般的 topology 可以设置为 executor 的数量），然后逐渐增大，直到数据流不再发生变化。这时你可能会发现结果大约等于 “2 × 吞吐率(每秒收到的消息数) × 端到端时延” （最小的额定容量的2倍）。

---

Updating...

---