优化流式任务
去年花了大半年的时间在Fregata项目上,目前的部署规模在12000个docker的水平。今年上半年打算
对Fregata项目进行一次框架上的升级,目标是提升性能,为上下游生态系统减负。
拓扑
旧拓扑
之前的拓扑是树形拓扑,意味下游节点的并行度不能低于上游的,至少保持一致。
1个Source,3个Parser,3个Sink,Parser和Sink一一对应,数据不会交叉。
1个Source,3个Parser,6个Sink,每个Parser后面对应2个Sink。
新拓扑
新拓扑中的Parser可以将数据分发给任何一个Sink。
1个Source,2个Parser,5个Sink 每个Parser后面都对应5个Sink。
通过控制数据的离散规则可以达到旧拓扑的效果,也就是说,旧拓扑是新拓扑的一种特例。
好处
通过更加合理的配比,达到最小资源和最大性能,举例说明:
老:1×Source + 5×Parser + 5×Sink = 11×Component
新:1×Source + 3×Parser + 6×Sink = 10×Component
在我们的测试中,新拓扑方案比老的快20%,因为整个Stream的瓶颈在Sink,Parser只需要3个就可以。
在减少component的情况下,性能依然得到的提升,减少component,意味着线程数的减少,
buffer区个数会减少,内存预分配的占用也会减少。
Buffer
在这次调优过程中,我们测试了buffer的大小,前后比例对性能的影响。
buffer超过1024后,对性能的提升帮助不大,前提是sink端的性能相对稳定。
source到parser间的buffer设置的更大一下,更有利于性能的稳定。
KafkaSink
老版里我们在Sink上抽象了一层BatchSink,这次重构我们将Batch的逻辑全部交给Kafka的
Client去处理,利用它的linger和batchsize等操作。性能得到20%-30%的提升。
我们对Kafka的Producer也进行了大量的测试,如果我们最大限度的让Producer积攒数据,
会让数据的体积更小,网络和磁盘的开销都会有2-3倍的节约,在消费解压时也会更快。
SpinTime
在老版里,我们就使用SpinTime来进行系统性能的预警,在新版里我们主要使用Spintime来进行
自动伸缩容的评判,目前还在测试中。