看Heron细数Storm弊端

Heron作为Twitter下一代的流式计算产品。随着业务量的增长，Storm已经不能满足需求，于是Heron诞生。诞生之初Twitter对于Storm的弊端和Heron的设计做了详细的说明。以下信息总结自Twitter官方说明。也许对于当前各种流式计算产品的分析稍有帮助。

1. 资源调度模型缺陷

• Tasks共享Worker（JVM进程），相互干扰；
• 资源管理模块nimbus 单点；

2. 效率问题

• 错误恢复慢。单个Tuple处理出错，会要求整个Tuple Tree重新处理；
• GC耗时。内存占用率越高，GC的耗时越长。会加大处理延时，增加错误风险；
• Tasks间数据传输模型不完善，一次传递多次内存拷贝；

3.Tasks调度复杂，Task何时被执行不可预期

• Worker的线程调度。Worker同时存在多个Executor，每Executor包含多个线程；
• Executor有独立的Task调度。

4. 会出现错误不可恢复的情景

• 情景：多个资源消耗较大的Tasks在同一Worker运行，某些Task因为缺少资源而失败。该情况下，重新运行Topology并不能保证将这个Tasks分开到不同的Work上，可能再次失败。

5. 单一日志文件，日志分析困难

• 同Worker内所有Tasks的日志写入在同一文件，通过日志定位较难。