一、背景

（以下簡稱SR）是新一代快速全場景MPP數據庫，可滿足多種分析需求，包括OLAP多維分析、定制報表、實時數據分析； 隨著公司WOS的升級戰(zhàn)略，BI選擇了WOS系統中的SR作為數據分析層數據庫； 在SR應用實踐過程中，隨著越來越多的商家遷移到WOS，SR中的數據急劇減少，一些顯存不足的問題也逐漸暴露出來，主要有以下問題：

字段模型表的常駐顯存不斷減少，最多占用可用顯存的16%。 太多了，270張表160W+表，大概90%大于100M。

二、問題分析

2.1 第一個問題是場模型常駐顯存大，查看場模型官方介紹。

在分析數據庫中查詢字段模型后，主要用于實時分析。 實時分析主要是當天的數據，數據量不會太大。 根據官方描述，現場模型數據具有冷熱特性。 對實時分析DB表進行查詢：發(fā)現三張表的數據總量約為17GB。 在查詢三張表的DDL時，發(fā)現三張表沒有分區(qū)，所以三張表的數據都會加載到顯存中，最終導致字段模型常駐顯存很大。

2.2. 太多了，個體數據量小

官方pair定義：在同一個中dnastar可以在64位系統上用么， key的hash值相同的數據以多副本的方式冗余存儲，是數據平衡和恢復的最小單位。 數據庫的副本由單獨的本地存儲引擎管理，數據導入和查詢最終下沉到涉及的副本。

官方建議：建議單個分區(qū)的原始數據量不要超過100GB，每個數據文件的大小在100MB到1GB左右。

執(zhí)行以下語句：

SHOW DATA;

顯示數據； 分析庫中的表，存在以下問題：

大多數表按天分區(qū)，有 3 個副本和 3 個桶。 目前有些表的數據量很小，而且（shard個數）很多，所以每個shard的數據量極小。 以一張表為例，=3*=3*dd (2019-12-20 to 2022-07-08) = 5598，計算出每比特數據量約17Kb，與官方推薦有巨大差異，太多的元數據被浪費了。

目前我們大多使用更新模型，太多，多次導出數據，數據版本多，速度慢，導致表的存儲容量遠小于實際存儲容量。

3.優(yōu)化方案

3.1. 第一個問題場模型常駐顯存大

優(yōu)化方案：3張表改為分區(qū)表，分區(qū)生命周期減少，只保留近10天的數據。

優(yōu)化執(zhí)行步驟如下：

--第一步停止實時任務
--第二步新建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. 第二個問題：太多，個體數據量小

優(yōu)化方案：整理出需要整改的132張表，分三批進行優(yōu)化。 第一批整改數據量大于1GB的表53張，第二批整改數據量大于20G的表，第三批整改大于20G的表；分別對每批表進行評估，將分區(qū)改為根據數據量按周、月、年分區(qū)。

評價規(guī)則：

1.查看分區(qū)數據使用詳情

執(zhí)行以下語句查看表格短發(fā)區(qū)域的情況：

SHOW PARTITIONS FROM ads_xxx_dwm;

根據詳細的分區(qū)數據，該表目前是按天分區(qū)的。 當每個分區(qū)的數據分桶時，每個桶的數據量遠大于官方推薦的100M。

2.分區(qū)合并規(guī)則

根據分區(qū)數據量判斷，比如右邊的DDL中，2021年之前的歷史數據量必須按年分區(qū)才能滿足小于100MB的條件，所以2021年之前的數據可以按年分區(qū); 2021-01-01至2022-06-01期間的數據按月分區(qū)滿足小于100MB的條件，這部分數據可以按月分區(qū)； 這樣就可以根據數據量來確定WEEK和DAY分區(qū)的時間段了。

優(yōu)化執(zhí)行步驟如下：

--第一步新建新結構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.優(yōu)化療效比較 4.1． 主鍵模型優(yōu)化后：每個BE平均占用顯存從7G增加到1G左右，比之前平均增加了6G，增幅85%。

4.2. 過度優(yōu)化：

經過兩輪分區(qū)合并，數量從整改前的160W+增加到30W+，增幅約81%。 顯存從原來平均每單位10.9GB下降到平均每單位8.9GBdnastar可以在64位系統上用么，增幅約為18.34%。

優(yōu)化后FE和BE顯存變化：

FEjvm堆：

之前FE的JVM heap占用高達18G，優(yōu)化后峰值為4G。

BEMem：BE的顯存占用，在集群級別，常駐顯存增加了55g。

優(yōu)化推理總結：

經過4輪優(yōu)化，在BE對顯存使用的集群層面，常駐顯存增加了55GB，FE節(jié)點的JVM堆內存使用量增加了77.77%，數量增加了約81%。 集群的健康狀況有所改善。

如有侵權請聯系刪除！