前言
使用 StarRocks 存算分離功能的同學可能之前常常被 DDL (常見的如增加列等)所困擾,主要在於 DDL 的執行時間過長並可能由此引發的一系列問題(如超時失敗等),使用者可能有時候不得不采用其他方式來替代(如按照新的 Schema 來重建表並重新匯入數據)。
幸運的是,我們在 3.3.0 版本中即將推出的 Fast Schema Evolution 能力讓這一困擾我們許久的問題徹底變為歷史。
Fast Schema Evolution 是現代大數據處理系統中至關重要的功能。它能夠在無需重寫整個數據集的情況下高效地修改表結構,顯著提升數據管理的靈活性和敏捷性。在即將釋出的 3.3.0 版本中,我們將為存算分離版本引入全新設計實作的 Fast Schema Evolution 能力,幫使用者極大地提升了DDL的效率。
Fast Schema Evolution 的關鍵在於無需重寫歷史數據,而是只需要向物件儲存中寫入少量Tablet 後設資料即可完成 DDL,這帶來了顯著的效能提升,尤其是針對處理包含大量歷史數據的表時。
本文章將會透過真實測試來展示全新設計的 Fast Schema Evolution 的效能表現。
測試環境
硬體規格
測試中使用1 FE + 4 CN 配置,FE例項規格如下:
硬體 | 規格說明 |
CPU | 4 vCPU |
記憶體 | 8 GB |
CN 例項規格如下:
硬體 | 規格說明 |
CPU | 16 vCPU |
記憶體 | 64 GB |
軟體版本
測試中分別使用 3.3.0-rc02 和 3.2.7 版本進行對比測試。
數據集
使用 TPC-DS 1TB 標準數據集,針對 store_sales 表進行加列(add column)操作並對比兩個版本耗時。壓縮後儲存數據量如下:
mysql> show data;
+-------------+----------------+---------------------+
| TableName | Size | ReplicaCount |
+-------------+----------------+---------------------+
| store_sales | 133.431 GB | 256 |
| Total | 133.431 GB | 256 |
+-------------+----------------+---------------------+
4 rows in set (0.01 sec)
原始表結構如下:
mysql> show create table store_sales\G
*************************** 1. row ***************************
Table: store_sales
Create Table: CREATE TABLE `store_sales` (
`ss_sold_date_sk`int(11) NULL COMMENT "",
`ss_item_sk`int(11) NOT NULL COMMENT "",
`ss_ticket_number` bigint(20) NOT NULL COMMENT "",
`ss_sold_time_sk`int(11) NULL COMMENT "",
`ss_customer_sk`int(11) NULL COMMENT "",
`ss_cdemo_sk`int(11) NULL COMMENT "",
`ss_hdemo_sk`int(11) NULL COMMENT "",
`ss_addr_sk`int(11) NULL COMMENT "",
`ss_store_sk`int(11) NULL COMMENT "",
`ss_promo_sk`int(11) NULL COMMENT "",
`ss_quantity`int(11) NULL COMMENT "",
`ss_wholesale_cost` decimal(7, 2) NULL COMMENT "",
`ss_list_price` decimal(7, 2) NULL COMMENT "",
`ss_sales_price` decimal(7, 2) NULL COMMENT "",
`ss_ext_discount_amt` decimal(7, 2) NULL COMMENT "",
`ss_ext_sales_price` decimal(7, 2) NULL COMMENT "",
`ss_ext_wholesale_cost` decimal(7, 2) NULL COMMENT "",
`ss_ext_list_price` decimal(7, 2) NULL COMMENT "",
`ss_ext_tax` decimal(7, 2) NULL COMMENT "",
`ss_coupon_amt` decimal(7, 2) NULL COMMENT "",
`ss_net_paid` decimal(7, 2) NULL COMMENT "",
`ss_net_paid_inc_tax` decimal(7, 2) NULL COMMENT "",
`ss_net_profit` decimal(7, 2) NULL COMMENT ""
) ENGINE=OLAP
DUPLICATE KEY(`ss_sold_date_sk`, `ss_item_sk`, `ss_ticket_number`)
COMMENT "OLAP"
DISTRIBUTED BY HASH(`ss_item_sk`, `ss_ticket_number`) BUCKETS 256
PROPERTIES (
"compression" = "LZ4",
"datacache.enable" = "true",
"enable_async_write_back" = "false",
"replication_num" = "1",
"storage_volume" = "builtin_storage_volume"
);
1 row in set (0.00 sec)
測試結果
Fast Schema Evolution vs Old Schema Evolution
以下結果展示了 Fast Schema Evolution 和 老版本的效能對比:
mysql> alter table store_sales add column new_column varchar(16);
Query OK, 0 rows affected (0.03 sec)
mysql> show alter table COLUMN from tpcds\G
*************************** 1. row ***************************
JobId: 10362
TableName: store_sales
CreateTime: 2024-06-10 14:50:30
RewriteFinishTime: 2024-06-10 14:50:38
FinishTime: 2024-06-10 14:50:38
IndexName: store_sales
IndexId: 10099
OriginIndexId: 10099
SchemaVersion: 1:0
TransactionId: 6
State: FINISHED
Msg:
Progress: NULL
Timeout: 86400
Warehouse: default_warehouse
1 row in set (0.00 sec)
mysql> show alter table COLUMN from tpcds\G
*************************** 1. row ***************************
JobId: 10352
TableName: store_sales
CreateTime: 2024-06-10 15:51:30
FinishTime: 2024-06-10 16:02:49
IndexName: store_sales
IndexId: 10353
OriginIndexId: 10090
SchemaVersion: 0:0
TransactionId: 6
State: FINISHED
Msg:
Progress: NULL
Timeout: 86400
1 row in set (0.00 sec)
可以看到,在只有 130 GB 數據規模情況下,加列的延遲降低了 85 倍(8s VS 680s)。如果數據量進一步提升,提升的振幅會更加顯著。
不同 Tablet 時 DDL 效能對比
StarRocks 存算分離的 Fast Schema Evolution 在實作時是只為每個 Tablet 寫入後設資料資訊,其耗時與 Tablet 數量息息相關,本著嚴謹的原則補充測試了不同 Tablet 規模下的加列效能。
這裏調整了部份預設參數值 :
# 控制 FE 後台排程執行 DDL Task 周期,預設為10s
admin set frontend config("alter_scheduler_interval_millisecond"="1000");
# 控制 CN 執行 ddl 任務的並列度,預設為 4
update information_schema.be_configs setvalue = 4wherename = "max_update_tablet_meta_threads";
Tablet 數量 | Add Column 耗時 (s) |
10 | 1 |
100 | 1 |
1000 | 2 |
10000 | 6 |
不同並列度下 DDL 效能對比
StarRocks 存算分離的 Fast Schema Evolution 在實作時是只為每個 Tablet 寫入後設資料資訊,其耗時與 Tablet 數量息息相關,本著嚴謹的原則補充測試了不同 Tablet 規模下的加列效能,透過調整如下參數來調整工作執行緒數量:
update information_schema.be_configs setvalue = x wherename = "max_update_tablet_meta_threads";
另外測試中也調大了 publish 工作執行緒池數量:
update information_schema.be_configs setvalue = 512wherename = "transaction_publish_version_worker_count";
並列度 | Add Column 耗時 (s) |
1 | 47 |
2 | 23 |
4 | 13 |
8 | 7 |
16 | 5 |
32 | 3 |
總結
Fast Schema Evolution 能力的釋出,也意味著 StarRocks 存算分離也基本補齊了成為未來湖倉分析新範式的一塊巨大短板,必定給使用者體驗帶來極大的提升,感興趣的朋友也歡迎嘗試該能力並提寶貴的建議。