flink-user-zh mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shi Quan <qua...@outlook.com>
Subject RE: flink并行度设置问题
Date Tue, 23 Apr 2019 02:02:32 GMT
这个问题好全面,本质上是一个如何提高性能的问题。

首先,我们明确整条流中性能的瓶颈处在哪里?同时也要考虑到数据混洗的问题。



针对你的一些疑问:

  1.  不是并发度一样才好,因为各个operator的复杂度不一样,简单的可以认为复杂的可以给更高的并发度。这个问题说大了会很复杂,会涉及到是不是一个chain,会不会带来额外数据混洗等问题;
  2.  从kafka的模型看,you are right啊,如果source不是瓶颈,就没必要并发度拉这么高;
  3.  kafka source的并发度降低时一种节省资源的方式。建议重点去解决瓶颈问题
  4.  & 5 介意结合代码和数据情况说明么?





Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10



________________________________
From: 1900 <575209351@qq.com>
Sent: Tuesday, April 23, 2019 9:47:08 AM
To: user-zh
Subject: flink并行度设置问题

目前flink用的版本是社区版1.7.2,hadoop版本是2.8.5,采用flink on yarn ha部署,服务启动采用
run a job on yarn


现在简单流程是,从kafka读取数据,然后window时间窗口聚合(假如5秒钟窗口,形成一个list数据,然后输出),然后写入db


1.每个算子的并行度是不是设置一样比较好?
2.读取kafka算子的并发度,理论上上设置于topic的分区一致,假设topic是8个分区,并发度设置8最好
,是不是这样能最大化性能
3.同第二点,现在发现读取kafka的速度真的非常快,往往瓶颈在后面,现在瓶颈就在window时间窗口聚合算子上,
假设调小读取kafka数据的并发度,假如调成4,背压还会体现在读取kafka数据这个算子上,是不是读取kafka只能设置成1了?
窗口的聚合算子不管怎么调大,都会反压到读取kafka数据的算子,请问是哪边有什么问题吗?
4.现在窗口聚合的分组的key是自定义的,选取唯一ID,通过hash对并行度求模,然后取绝对值
拆分开看,只有读取kafka数据,窗口合并两个算子,并发度会很大
加入入DB的算子,并发度就大幅降低,但是拆个窗口聚合的背压一点都没有,背压还是体现在读取kafka数据算子上,请问是什么原因
5.上述的自定义分组key是否有什么问题?从监控页面观察到,现在窗口聚合的slot没有完全使用掉,假设设置8个并行度,实际只有6个子任务在处理数据,
有2个子任务永远没有获取到数据,而且有另外两个子任务数据是其他的两倍

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message