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
版权声明:本文博主原创文章,博客,未经同意不得转载。