一、背景
StarRocks（以下簡稱SR）是新一代極速全場景 MPP 資料庫，可以滿足多種分析需求，包括 OLAP 多元分析、定制報表、實時資料分析；伴随公司 WOS 更新戰略，BI 在 WOS 系統中的選型 SR 作為資料分析層資料庫；SR 應用實踐過程中随遷移 WOS 的商戶越來越來多，SR 内資料随之增大，逐漸暴露出來一些記憶體不足問題，主要為以下問題造成：
- 主鍵模型表常駐記憶體持續增大，最高占用可用記憶體的16%。
- tablet過多，270張表160W+個tablets，小于100M的約占90%。
二、問題分析
2.1 第一個問題主鍵模型常駐記憶體較大，查詢官方對主鍵模型的介紹。
- 主鍵模型适用于主鍵占用空間相對可控的場景。主鍵模型會将主鍵索引加載至記憶體中，是以相對于其他模型，主鍵模型對記憶體的要求比較高
- 主鍵模型資料有冷熱特征：即最近幾天的熱資料才經常被修改，老的冷資料很少被修改。例如，MySQL 訂單表實時同步到 SR 中提供分析查詢。其中，資料按天分區，對訂單的修改集中在最近幾天新建立的訂單，老的訂單完成後就不再更新，是以導入時其主鍵索引就不會加載，也就不會占用記憶體，記憶體中僅會加載最近幾天的索引。
經查詢分析庫中主鍵模型主要應用在實時分析中，實時分析主要為當天資料，資料量不會太大，根據官方描述主鍵模型資料有冷熱特征，對實時分析 DB 的表進行Show data 查詢：發現三張表資料量總量為 17GB 左右，查詢三張表的 DDL 發現三張表均未分區，是以三張表的資料會全部加載到記憶體，最終造成了主鍵模型常駐記憶體較大。
2.2、Tablet過多，且單個 Ttablet 資料量較小
官方對 Tablet 定義：在同⼀分區内，分桶鍵哈希值相同的資料形成 Tablet，Tablet 以多副本備援的形式存儲，是資料均衡和恢複的最⼩機關。Tablet 的副本由⼀個單獨的本地存儲引擎管理，資料導⼊和查詢最終都下沉到所涉及的 Tablet 副本上。
官方建議：單個分區原始資料量建議不要超過 100 GB，每個 Tablet 資料檔案大小在 100 MB 至 1 GB 左右。
執行如下語句:
SHOW DATA; SHOW DATA; 分析庫中表，存在以下問題：
- 大部分表是按日分區，3個副本，3個分桶；目前一些表資料量很小，但是ReplicaCount（分片數）很多，算下來每個分片資料量很少。
- 以某一表 ads_xxxx_d 為例，ReplicaCount=BUCKETS 3 * replication_num = 3 * dd(2019-12-20 到 2022-07-08)分區數量=5598 個tablet，算下來每個 Tablet 資料量 17Kb 左右，與官方建議相差巨大，Tablet 過多浪費大量中繼資料。
- 目前我們大部分使用更新模型，Tablet 過多，多次導入資料，資料版本較多，compaction 速度較慢，導緻表的存儲量大于實際存儲量很多。
三、優化方案
3.1、第一個問題主鍵模型常駐記憶體較大
優化方案：3張表修改為分區表，且增加分區生命周期，隻保持近10天資料。
優化執行步驟如下：
--第一步停止實時任務
--第二步建立bak表
CREATE TABLE realtime_sr_db.`ads_xxx_d_bak` (
`id` bigint(20) NOT NULL COMMENT "id",
`dd` date NOT NULL COMMENT "日期",
) ENGINE=OLAP
PRIMARY KEY(`id`,`dd`)
COMMENT "實時xxx明細"
PARTITION BY RANGE(`dd`)
( START ('2022-07-12') END ('2022-08-25') EVERY (INTERVAL 1 DAY) )
DISTRIBUTED BY HASH(`id`) BUCKETS 3
PROPERTIES (
"replication_num" = "3",
"dynamic_partition.enable" = "true",
"dynamic_partition.time_unit" = "day",
"dynamic_partition.time_zone" = "Asia/Shanghai",
"dynamic_partition.start" = "-10",
"dynamic_partition.end" = "2",
"dynamic_partition.prefix" = "p",
"dynamic_partition.buckets" = "3",
"in_memory" = "false",
"storage_format" = "DEFAULT"
);
--第三步遷移資料
INSERT INTO realtime_sr_db.ads_xxx_d_bak SELECT * FROM realtime_sr_db.ads_xxx_d where topicdate>'2022-08-08';
--第四步更換表名稱
ALTER TABLE ads_xxx_d RENAME ads_xxx_d_bak_1;
ALTER TABLE ads_xxx_d_bak RENAME ads_xxx_d;
--第五步删除表
DROP TABLE ads_xxx_d_bak_1;
--第六步 開啟實時任務 3.2、第二個問題：tablet過多，且單個tablet資料量較小
優化方案：梳理出 132 張需要治理的表，分三批進行優化，第一批治理資料量小于1GB 的 53 張表，第二批治理資料量小于 20G 的表，第三批治理 20G 以上的表；對每一批表分别進行評估，根據資料量将分區修改為按周、按月、按年分區。
評估規則：
1、檢視分區資料占用詳情
執行如下語句，檢視 ads_xxx_dwm 表中分區情況：
SHOW PARTITIONS FROM ads_xxx_dwm; 根據分區詳情資料，該表目前是按天分區，每分區當資料極小分桶後，每個桶資料量遠遠小于官方建議的100M。
2、分區合并規則
根據分區資料量判斷，例如下圖 DDL 内，2021 年之前的曆史資料量，按年分區，才會滿足 Tablet 大于 100MB 的條件，是以可以把 2021 年之前的資料按年分區；2021-01-01 到 2022-06-01 期間的資料按照月分區滿足 tablet 大于 100MB 的條件，可以将這部分資料按照月分區；以此類推，WEEK，DAY 分區時間段都可按照資料量判斷。
優化執行步驟如下：
--第一步建立新結構bak表
CREATE TABLE `ads_xxx_d_bak` (
`id` bigint(20) NULL COMMENT "ID",
`dd` date NULL COMMENT "資料日期",
) ENGINE=OLAP
UNIQUE KEY(`id`, `dd`)
COMMENT "xxx"
PARTITION BY RANGE(`dd`)
( START ('2021-01-01') END ('2023-01-01') EVERY (INTERVAL 1 YEAR),
START ('2023-01-01') END ('2023-02-01') EVERY (INTERVAL 1 MONTH)
)
DISTRIBUTED BY HASH(`id` ) BUCKETS 3
PROPERTIES (
"replication_num" = "3",
"dynamic_partition.enable" = "true",
"dynamic_partition.time_unit" = "MONTH",
"dynamic_partition.time_zone" = "Asia/Shanghai",
"dynamic_partition.start" = "-2147483648",
"dynamic_partition.end" = "1",
"dynamic_partition.prefix" = "p",
"dynamic_partition.buckets" = "3",
"in_memory" = "false",
"storage_format" = "DEFAULT"
);
--第二步遷移資料到bak表
INSERT INTO tmp.ads_xxx_d_bak SELECT * FROM tmp.ads_xxx_d;
--第三步更換表名稱
ALTER TABLE ads_xxx_d RENAME ads_xxx_d_bak_1;
ALTER TABLE ads_xxx_d_bak RENAME ads_xxx_d;
--第四步删除表
DROP TABLE ads_xxx_d_bak_1; 四、優化效果對比
4.1、主鍵模型優化後:
每台 BE 平均占用記憶體由 7G 下降為 1G 左右，相比之前平均每台下降了 6G，下降了85%。
4.2、Tablet過多優化：
經過三輪分區合并，Tablet 數量由治理前的 160W+下降為 30W+，大約下降了81%，BE meta Men記憶體由原來的平均每台 10.9GB 降為平均每台 8.9GB，下降18.34% 左右。
優化後FE及BE記憶體變化：
FE jvm heap:
FE 的 JVM 堆使用情況,之前最高為 18G,優化後峰值在 4G。
BE Mem ：BE的使用記憶體使用情況，叢集層面，常駐記憶體下降55g。
優化結論總結：
經過4輪優化，BE 的使用記憶體叢集層面，常駐記憶體下降 55GB，FE 節點 JVM 堆記憶體占用下降了77.77%，Tablet 數量大約下降了 81%，叢集健康度有所提高。
作者:蔣賽
來源:微信公衆号:微盟技術中心
出處:https://mp.weixin.qq.com/s/RH5g8rXeWEg9JbXiD_9Jkg