开发者社区> 问答> 正文

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个子任务永远没有获取到数据,而且有另外两个子任务数据是其他的两倍*来自志愿者整理的flink邮件归档

展开
收起
毛毛虫雨 2021-12-07 14:07:23 870 0
1 条回答
写回答
取消 提交回答
  • 这个问题好全面,本质上是一个如何提高性能的问题。

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

    针对你的一些疑问:

    1. 不是并发度一样才好,因为各个operator的复杂度不一样,简单的可以认为复杂的可以给更高的并发度。这个问题说大了会很复杂,会涉及到是不是一个chain,会不会带来额外数据混洗等问题;
    2. 从kafka的模型看,you are right啊,如果source不是瓶颈,就没必要并发度拉这么高;
    3. kafka source的并发度降低时一种节省资源的方式。建议重点去解决瓶颈问题
    4. & 5 介意结合代码和数据情况说明么?*来自志愿者整理的flink
    2021-12-07 15:24:58
    赞同 展开评论 打赏
问答排行榜
最热
最新

相关电子书

更多
Flink CDC Meetup PPT - 龚中强 立即下载
Flink CDC Meetup PPT - 王赫 立即下载
Flink CDC Meetup PPT - 覃立辉 立即下载