前言
使用 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 存算分离也基本补齐了成为未来湖仓分析新范式的一块巨大短板,必定给用户体验带来极大的提升,感兴趣的朋友也欢迎尝试该能力并提宝贵的建议。