hive_catalog查询的优化器耗时比较久

为了更快的定位您的问题,请提供以下信息,谢谢
【详述】问题详细描述
【背景】做过哪些操作?
【业务影响】
【是否存算分离】
【StarRocks版本】例如:1.18.2
【集群规模】例如:3fe(1 follower+2observer)+5be(fe与be混部)
【机器信息】CPU虚拟核/内存/网卡,例如:48C/64G/万兆
【联系方式】为了在解决问题过程中能及时联系到您获取一些日志信息,请补充下您的联系方式,例如:社区群4-小李或者邮箱,谢谢
【附件】

  • Profile信息,如何获取profile
  • 并行度:show variables like ‘%parallel_fragment_exec_instance_num%’;
    show variables like ‘%pipeline_dop%’;
  • pipeline是否开启:show variables like ‘%pipeline%’;
  • 执行计划:explain costs + sql
  • be节点cpu和内存使用率截图

starrocks版本3.2.9。 执行查询hive_catalog的数据,sql脚本复杂,存在很多表的join操作,执行时长比较久,查看proflie是优化器那里耗时比较久

profile.txt (775.9 KB)

https://github.com/StarRocks/starrocks/issues/53923

抓一个query dump看看

然后执行一个 trace logs SQL


扫描的hive分区比较多,不知道是不是有这里影响

dump_file.txt (330.0 KB)

tracelog.txt (25.2 MB)

看的话 是慢在解析paimon的表上面了
trace ALL OPTIMIZER + sql。

一个简单的select * from paimon的表

查询的是paimon还是hive?

看上去是分区数量太大导致的?

这个是第一次还是之后都会花费这么长的时间?

如果分区数量比较大,或者是HMS比较慢的话,那么这个结果是正常的。

另外第二次查询会缓存,所以第二次通常会比较快。

查的paimon的表,不正常的, 数据量不大,一天的分区, 如果查询的底层的hdfs的paimon的 比oss的paimon的表 快很多

hdfs的paimon是 500ms左右,如果是oss的paimon的表 1600ms~2000ms左右,跟表大小关系不大

能帮忙看下这快为啥慢这么多吗
第二次查询的时间都是一致的

TRACE times OPTIMIZER + sql 看的,是慢在这一步,能看下具体的原因吗
图片