Twitter 新一代流处理工具——Heron 该纸币Storm Limitations
（空格分隔）： Streaming-Processing
Storm Problems
scalability, debug-ability, manageability, and efficient sharing of cluster resources with other data services。
Storm Worker Architecture: Limitations
- Storm的worker就是一个JVM进程。每一个worker能够跑多个executor。眼下依据Storm现有的调度机制。我们无法确定那个task被分配到了哪个worker上。哪台物理机器上。
- 因为不知道task被分配到哪个worker上。有可能是同一个，考虑join的情况，一个join task和一个output 到 DB Store或其它存储的task被分配到同一个worker。这样性能可能无法保证
- 当前正在跑的topology假设重新启动的话，之前分派在同一个worker的task因为toplogy重新启动。可不能不会再被分配到同一个worker上，这给debug带来了困难。
- Storm 提供自己实现的isolate 调度，可是要交于开发者来分配集群资源是个及其不好的做法。
- 资源分配浪费。
Storm假设每一个worker都是homogenous，这种做法常常会造成在资源预的超额分配。比如3个spouts和1个bolt，增加每一个spout和bolt各自须要5G和10G内存，这种话，topoogy必须为每一个worker预留15G的内存来跑一个spout和一个bolt。假设用户设置worker数为2，那么两个worker就要总共预留30G内存，可是实际上仅仅须要 3*5 + 1 *10 = 25G内存，这样就浪费了5G。
- 假设对一个worker进行heap dump时。可能会堵塞worker hearbeats的发送，导致supervisor觉得该worker心跳超时，kill 和重新启动了该worker
- worker用thread和queue来做tuple的接收和发送，每一个worker有一个receive-thread接收上游tuple，一个全局send-thread负责往下游发送tuple，然后executor有一个logic-thread来运行用户的代码逻辑，最后有一个本地的send-thread来做logic-thread和全局send-thread做数据通信，到这里，一个tuple须要从进入一个worker到出来总共要通过4个thread转发。
Issues with the Storm Nimbus
Storm的NImbus任务非常多非常艰巨，包含调度，监听，分发JAR等等。topology多的时候。Nimbus将变成瓶颈。
- Nimbus调度器不支持worker细粒度的resource reservation和isolation。不同topology的worker被分配到了同一个物理node上。非常有可能会相互影响。
- Storm利用Zookeeper来存储worker和supervisor以及executor的心跳信息。假设topology非常多，每一个topology的并发非常多。这样Zookeeper就是瓶颈。
- 就是老生常谈的nimbus单点故障。Nimbus不是HA。
Lack of Backpressure
Storm没有backpressure机制，假设下游接收数据的component没有及时处理数据的话，发送者就会drop message。这是一种fail-fast机制，也非常easy，可是有下面缺点：
- If acknowledgements are disabled, this mechanism will resultin unbounded tuple drops, making it hard to get visibility about these drops.
- Work done by upstream components is lost.
- System behavior becomes less predictable.
Efficiency
- Suboptimal replays
- Long Garbage Collection cycles
- Queue contention
未完待续，下次讲述Twitter的新利器——Heron的架构以及是怎样解决上述Storm存在的问题的
Reference
版权声明：本文博主原创文章，博客，未经同意不得转载。