我另外建了张tablet为400的聚合模型表,数据量、表结构和之前的test_src一样,sql耗时降到了7m28s。global和session参数如下:
以下是profile:
profile_tablet400.yml (1.4 MB)
我另外建了张tablet为400的聚合模型表,数据量、表结构和之前的test_src一样,sql耗时降到了7m28s。global和session参数如下:
我这边做了几个测试,有个点挺困惑的,pipeline_dop好像没用。。
【测试场景1】
参数:
global和session:
enable_pipeline_engine=false
pipeline_dop=2
parallel_fragment_exec_instance_num=5
【测试场景2】
参数:
global和session:
enable_pipeline_engine=true
pipeline_dop=2
parallel_fragment_exec_instance_num=5
【测试场景3】
参数:
global和session:
enable_pipeline_engine=true
pipeline_dop=1
parallel_fragment_exec_instance_num=5
【测试场景4】
参数:
global和session:
enable_pipeline_engine=true
pipeline_dop=10
parallel_fragment_exec_instance_num=5
如上所测,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(不超过该表的分桶数)
还是有不少的数据倾斜。可以执行下show tablet from table_name;来看下具体tablet的大小来做调整,另外可以使用高基数列来做分桶键。
目前来看网络花费的时间约为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的。
那篇文章里的工具,我这边使用报错了:
另外,论坛里( StarRocks-Profile分析及优化指南 - StarRocks技术分享 / 经验教程 - StarRocks数据库论坛)这篇文章里的tablet分析工具我这边跑了后没任何输出:
不知道是不是版本不兼容,我用的starrocks版本是2.3.0