标签：Flink standalone flink yarn TaskManager cluster job task
结论：生产环境推荐使用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，自然会造成资源的竞争。起初，我们为了解决这些问题，采用了如下的解决方法:
- 将TaskManager的粒度变小，即一台机器部署多个实例，每个实例持有的slot数较少；
- 将大的业务job隔离到不同的集群上。
这些解决方法增加了实例数和集群数，进而增加了维护成本。因此我们决定要迁移到on yarn上，目前看Flink on yarn的资源分配和资源隔离确实比standalone模式要优秀一些。
原文链接：https://segmentfault.com/a/1190000020209179
标签：Flink,standalone,flink,yarn,TaskManager,cluster,job,task 来源： https://www.cnblogs.com/gentlescholar/p/15043086.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。