最近看到一篇文章,是关于设定topology中并行度的设定,用于提高storm的整体处理速度。文章的作者按照ui的显示内容,使用数学中的比例来进行各bolt的并行度的设定,比较具有理论意义。
主要是这样的方法:
首先,如下图,
component | name | executor latency(ms) |
spout | s | - |
bolt | A | 0.5 |
bolt | B | 0.1 |
bolt | C | 0.5 |
bolt | D | 1.0 |
bolt | E | 0.2 |
其中,component是指组件的类型,name是指组件的指代名称,executor latency是指本组件处理完一个tuple所需要的时间长度(spout是没有的,因为spout一般不用于处理数据)。从里面的数据来看,,根据处理时间,如果设单位时间为x,那么这里的时间比例即为:A:B:C:D:E=5x:x:5x:10x:2x。在整个topology中,制约整体处理时间的便是这些处理比较慢的组件,所以我们需要按照它的这个时间比例,来进行并行度的设定:A并行度为5,B为1,C为5,D为10,E为2(其中这些数据值为倍数关系,而非具体的值)。这样,就在一种理想状况下对storm的组件进行了一种比较准确的并行度设定。
同时,还有种衡量topology中个组件的资源使用情况的字段:
如下图,
component | name | Capacity |
spout | s | - |
bolt | A | 0.5 |
bolt | B | 0.1 |
bolt | C | 0.5 |
bolt | D | 1.0 |
bolt | E | 0.2 |
类似的,其中component和name不再解释,capacity是指针对于这个组件占用的系统分配的资源的比例。如对于A为0.5,则表示占用了分配给他的资源的使用量的50%(有点类似于它的CPU使用率为50%)。因此这个值,是随着bolt的处理复杂性的增加而增加。当超过1时,表用这个组件在单位时间内使用这些资源已经处理不了,可以通过增大它的并行度来调整。类似与上面,这里也可以使用比例来进行预估计:
A:B:C:D:E=5x:x:5x:10x:2x。如果出现这样的比例,则设置A并行度为5,B为1,C为5,D为10,E为2(其中这些数据值为倍数关系,而非具体的值)。
上面的内容均是理论上的,并且以上两者可能互相之间并不太符合,大家可以借鉴一下,需要等待实际情况的检验。