开发者社区> 问答> 正文

Flink SQL1.10 大表join如何优化?

我在ui里面可以看到任务也在正常运行,只是每秒输入700条左右,每秒输出1700,所以对比总量来说十分缓慢。 

目前不太清楚性能的瓶颈点和优化的方向:  1 网络传输太慢,导致两表不能及时join?这里不知道如何排查,Metrics里面有个netty的相关指标,看不出什么;其他的指标除了hashjoin in和out缓慢变化,其他的都没有什么变化。  2 并行度过低,导致单点slot需要执行两个千万级表的关联?可否动态修改或者配置probe表的并行度?  3 JVM内存问题?详情见附件,观察内存还是很充足的,貌似垃圾回收有点频繁,是否有必要修改jvm配置?  4 taskmanager的日志不太理解….到build phase就停住了,是日志卡主了 还是 此时正在进行build的网络传输?  |  2020-03-21 09:23:14,732 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 4 ms for 32768 segments  2020-03-21 09:23:14,738 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 4 ms for 32768 segments  2020-03-21 09:23:14,744 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 4 ms for 32768 segments  2020-03-21 09:23:14,750 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 4 ms for 32768 segments  2020-03-21 09:23:14,756 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 4 ms for 32768 segments  2020-03-21 09:23:14,762 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 4 ms for 32768 segments  2020-03-21 09:23:14,772 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 4 ms for 32768 segments  2020-03-21 09:23:14,779 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 4 ms for 32768 segments  2020-03-21 09:23:16,357 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 14 ms for 65536 segments  2020-03-21 09:23:16,453 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 10 ms for 65536 segments  2020-03-21 09:23:16,478 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 9 ms for 65536 segments  2020-03-21 09:23:16,494 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 9 ms for 65536 segments  2020-03-21 09:23:16,509 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 10 ms for 65536 segments  2020-03-21 09:23:16,522 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 9 ms for 65536 segments  2020-03-21 09:23:16,539 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 9 ms for 65536 segments  2020-03-21 09:23:16,554 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 10 ms for 65536 segments  2020-03-21 09:23:16,574 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 9 ms for 65536 segments  2020-03-21 09:23:16,598 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 9 ms for 65536 segments  2020-03-21 09:23:16,611 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 10 ms for 65536 segments  2020-03-21 09:23:20,157 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 213 ms for 131072 segments  2020-03-21 09:23:21,579 INFO org.apache.flink.table.runtime.operators.join.HashJoinOperator - Finish build phase.  |*来自志愿者整理的flink邮件归档

展开
收起
玛丽莲梦嘉 2021-12-02 16:45:27 865 0
1 条回答
写回答
取消 提交回答
  • 看了下源代码,了解了下Hybrid hash join。大致了解了瓶颈点:  Hybrid hash join,会把build表(也就是我的右表)通过hash映射成map,并按照某种规则进行分区存储(有的在内存,超过的放入磁盘)。  目前看磁盘上的那部分join应该是整个任务的瓶颈。  具体调优方法,还在探索中...也许有什么配置可以控制build表内存存储的大小.*来自志愿者整理的FLINK邮件归档

    2021-12-02 17:32:20
    赞同 展开评论 打赏
问答排行榜
最热
最新

相关电子书

更多
SQL Server在电子商务中的应用与实践 立即下载
GeoMesa on Spark SQL 立即下载
原生SQL on Hadoop引擎- Apache HAWQ 2.x最新技术解密malili 立即下载