starrocks查询比clickhouse慢

为了更快的定位您的问题,请提供以下信息,谢谢
【详述】相同的数据量用clickhouse很快,用starrocks比较慢
【背景】数据总体是2700万数据,查询一个月数据和clickhouse差不多1秒多出来,但是查询3个月就需要好久,和clickhouse没法比较
【业务影响】查询慢
【StarRocks版本】3.1
【集群规模】例如:3fe(1 follower+2observer)+3be(fe与be混部)
【机器信息】3台单体机器组成,
1:SSD,内存16G,CPU:Intel® Core™ i5-7400 CPU @ 3.00GHz 物理核心 *4 逻辑核心 *4
2:SSD,内存16G,CPU:Intel® Core™ i5-7400 CPU @ 3.00GHz 物理核心 *4 逻辑核心 *4
3:SSD,内存16G,CPU:Intel® Core™ i5-9400 CPU @ 2.90GHz 物理核心 *6 逻辑核心 *6

【联系方式】QQ:329629067
【附件】
SQL附件.txt (10.3 KB)
_explain_SELECT_COALESCE_SUM_t0_c_0_0_AS_OverseaStorageAmt_COALE_202309221205.txt (1.4 MB)

获取Profile,通过Profile分析查询瓶颈 请提供下profile

profile.txt (173.1 KB)

有了大佬分析下,我看不懂

添加hints 执行sql,然后再发一下 profile文件。
select /*+ SET_VAR(streaming_preaggregation_mode = force_preaggregation) */ MIN(g.Id) AS Id,…

本地聚合可以增加速度,但是还是不太快的样子20230925profile.txt (147.7 KB)

靠大佬了 :smiley:

clickhouse 大概只需要1-2秒,如果和clickhouse差不多速度就可以使用这个数据库

根据 profile 文件看,GP_ListingProfit 表存在一定的数据倾斜

  1. 在leader fe上执行 show tablet from GP_ListingProfit; 提供一下结果文件
  2. 提供下 explain costs +sql 的结果文件

_explain_costs_SELECT_MIN_g_Id_AS_Id_g_AccountId_g_SellerSku_g_I_202309251755.txt (1.3 MB)

_show_tablet_from_GP_ListingProfit__202309251755.txt (57.4 KB)

大佬为什么一定要加force_preaggregation

建表语句:
CREATE TABLE IF NOT EXISTS AukeysDataWarehouse.GP_ListingProfit2
(
SettlementTime DATE NOT NULL,
AccountId INT NOT NULL,
SiteID INT NOT NULL,
Id INT NOT NULL COMMENT “用户id”,
SellerSku VARCHAR(60),
ItemId VARCHAR(20),
ItemName VARCHAR(1000),
Period VARCHAR(10),
SalesPlatformID INT NOT NULL,
Sku VARCHAR(30),
SalesPrice DECIMAL(18, 6),
DiscountPrice DECIMAL(18, 6),
NetSalesPrice DECIMAL(18, 6),
SalesQty INT,
PurchaseAmt DECIMAL(18, 6),
FirstShipAmt DECIMAL(18, 6),
TransferAmt DECIMAL(18, 6),
FBAStorageAmt DECIMAL(18, 6),
OverseaStorageAmt DECIMAL(18, 6),
RefundAmt DECIMAL(18, 6),
ShipAmt DECIMAL(18, 6),
CommissionAmt DECIMAL(18, 6),
TaxAmt DECIMAL(18, 6),
LDAmt DECIMAL(18, 6),
CPCAmt DECIMAL(18, 6),
FBAReimbursedAmt DECIMAL(18, 6),
GrossProfit DECIMAL(18, 6),
UpdateTime DATETIME,
BudgetType INT,
SalesUserName VARCHAR(10),
DevelopUserName VARCHAR(10),
ShopName VARCHAR(30),
ShopId INT,
TwoLevelTeamId INT,
FBARemovalPurchaseAmt DECIMAL(18, 6),
FBARemovalFirstShipAmt DECIMAL(18, 6),
FBARemovalFeeAmt DECIMAL(18, 6)
)
PRIMARY KEY(SettlementTime,AccountId,SiteID,Id)
PARTITION BY date_trunc(‘month’, SettlementTime)
DISTRIBUTED BY HASH(AccountId)
PROPERTIES (
“replication_num” = “3”,
“enable_persistent_index” = “true”
);

尝试用 Id(唯一ID)分桶也是存在数据倾斜,速度差不多
尝试用 AccountIdSiteID 也有一定的倾斜,速度差不多
尝试用 SettlementTime 也有一定的倾斜,速度差不多
尝试用 AccountIdSiteIDId 一定的倾斜,速度差不多
以上分桶查询速度都差不多,表总共有2700万数据,每天的数据大概10W,AccountId这个有些数据量比较多

image
这块网络耗时比较多,有当时的网络监控么

这个没有,不过我调整了下分桶键就没有这个问题了,但是速度没什么改变

20230926profile.txt (146.6 KB) 全新版本

做不到秒级,要优化硬件吗

set pipeline_dop=1,重新跑下

设置了,一个月的速度慢好了好多,如果查询一年的数据和不设置差不多