优化慢sql碰到的问题,如何控制一个Fragment的Instance数量

我另外建了张tablet为400的聚合模型表,数据量、表结构和之前的test_src一样,sql耗时降到了7m28s。global和session参数如下:


以下是profile:
profile_tablet400.yml (1.4 MB)

我这边做了几个测试,有个点挺困惑的,pipeline_dop好像没用。。
【测试场景1】
参数:
global和session:
enable_pipeline_engine=false
pipeline_dop=2
parallel_fragment_exec_instance_num=5


sql耗时7m42s,Fragment 0下Instance数量100,每个be节点上跑5个Instance,ScanConcurrency为4
profile:
profile-test1.yml (368.7 KB)

【测试场景2】
参数:
global和session:
enable_pipeline_engine=true
pipeline_dop=2
parallel_fragment_exec_instance_num=5


sql耗时7m10s,Fragment 0下Instance数量100,每个be节点上跑5个Instance,ScanConcurrency为4
profile:
profile-test2.yml (368.8 KB)

【测试场景3】
参数:
global和session:
enable_pipeline_engine=true
pipeline_dop=1
parallel_fragment_exec_instance_num=5


sql耗时6 min 51.37 sec,Fragment 0下Instance数量100,每个be节点上跑5个Instance,ScanConcurrency为4
profile:
profile-test3.yml (368.9 KB)

【测试场景4】
参数:
global和session:
enable_pipeline_engine=true
pipeline_dop=10
parallel_fragment_exec_instance_num=5


sql耗时7 min 34.50 sec,Fragment 0下Instance数量100,每个be节点上跑5个Instance,ScanConcurrency为4
profile:
profile-test4.yml (368.8 KB)

如上所测,pipeline_dop参数值为2时,enable_pipeline_engine为true和false,都对sql执行并发度无影响。enable_pipeline_engine为true时,pipeline_dop参数值为1、2、10,sql的并发度也无变化。

似乎除了enable_pipeline_engine为true,pipeline_dop为0时sql执行会自适应调节并发度,其他情况sql并发度只和parallel_fragment_exec_instance_num参数有关,parallel_fragment_exec_instance_num设为多少,一个fragment下每个be节点就会跑几个instance(不超过表在当前be节点的分桶数),一个fragment下总的instance数就是be节点数*parallel_fragment_exec_instance_num(不超过该表的分桶数)

image
还是有不少的数据倾斜。可以执行下show tablet from table_name;来看下具体tablet的大小来做调整,另外可以使用高基数列来做分桶键。

image
目前来看网络花费的时间约为5min,还有一些优化的空间,但是可能不太大了。再调整下表结构看下吧。

这张表是建的聚合模型表,主键是order_id,分桶键也是用的order_id,算是这张表里最高基数的字段了。

我show tablet看了下,20个be节点,每个节点60(3副本数*20分桶数)个tablet,每个table的大小都是900M左右,在官方文档推荐的100M~1G之间。be节点CPU40核,建表时分桶数20,该表总分桶数为20(be节点数)*20(be节点CPU核数一半)=400,也是用官网分桶数公式计算出来的。以下是show tablet的结果:
show_tablet.txt (268.2 KB)

请问还有其他什么方式可以缓解数据倾斜呢?另外再请教个问题,你截图里的maxTime和minTime是取的OLAP_SCAN_NODE 的active time的最大最小值吗?但是我查了下那4个profile,所有的OLAP_SCAN_NODE的active time都比较平均,都在1~4s浮动,没有找到耗时30s的。

https://blog.csdn.net/ult_me/article/details/123707037?spm=1001.2014.3001.5502
可以参考下流木大佬的博客

那篇文章里的工具,我这边使用报错了:
image

另外,论坛里( StarRocks-Profile分析及优化指南 - StarRocks技术分享 / 经验教程 - StarRocks数据库论坛)这篇文章里的tablet分析工具我这边跑了后没任何输出:
image
image

不知道是不是版本不兼容,我用的starrocks版本是2.3.0