flink standalone和yarn如何选择

结论:生产环境推荐使用yarn方式部署

 

使用standalone遇到的问题

1) 同一个standalone cluster中的job相互抢占资源,而standalone cluster的模式仅仅只能通过task slot在task manager的堆内内存上做到资源隔离。同时由于前文提到过的Flink在standalone cluster中deploy job的方式本来就会造成资源分配不均衡,从而会导致App Analytics线流量大时而引起Game Analytics线淤积的问题;

2) 我们的source operator的并行度等同于所消费Kafka topic的partition数量,而中间做etl的operator的并行度往往会远大于Kafka的partition数量。因此最后的job graph不可能完全被链成一条operator chain,operator之间的数据传输必须通过Flink的network buffer的申请和释放,而1.1.x 版本的network buffer在数据量大的时候很容易在其申请和释放时造成死锁,而导致Flink明明有许多消息要处理,但是大部分线程处于waiting的状态导致业务的大量延迟。

Standalone模式下job的deploy与资源隔离共享

结合我们之前的使用经验,Flink的standalone cluster在发布具体的job时,会有一定的随机性。举个例子,如果当前集群总共有2台8核的机器用以部署TaskManager,每台机器上一个TaskManager实例,每个TaskManager的TaskSlot为8,而我们的job的并行度为12,那么就有可能会出现下图的现象:

第一个TaskManager的slot全被占满,而第二个TaskManager只使用了一半的资源!资源严重不平衡,随着job处理的流量加大,一定会造成TM1上的task消费速度慢,而TM2上的task消费速度远高于TM1的task的情况。假设业务量的增长迫使我们不得不扩大job的并行度为24,并且扩容2台性能更高的机器(12核),在新的机器上,我们分别部署slot数为12的TaskManager。经过扩容后,集群的TaskSlot的占用可能会形成下图:

新扩容的配置高的机器并没有去承担更多的Task,老机器的负担仍然比较严重,资源本质上还是不均匀!

除了standalone cluster模式下job的发布策略造成不均衡的情况外,还有资源隔离差的问题。因为我们在一个cluster中往往会部署不止一个job,而这些job在每台机器上都共用JVM,自然会造成资源的竞争。起初,我们为了解决这些问题,采用了如下的解决方法:

  1. 将TaskManager的粒度变小,即一台机器部署多个实例,每个实例持有的slot数较少;
  2. 将大的业务job隔离到不同的集群上。

这些解决方法增加了实例数和集群数,进而增加了维护成本。因此我们决定要迁移到on yarn上,目前看Flink on yarn的资源分配和资源隔离确实比standalone模式要优秀一些。

 

原文链接:https://segmentfault.com/a/1190000020209179

上一篇:手把手教你使用Selenium Grid实现分布式自动化测试【建议收藏】


下一篇:Nacos系列(一)docker安装单机版nacos服务