指如疾风，势如闪电 -StarRocks Fast Schema Evolution in V3.3.0

2024-08-11
北京
本文字数：2844 字
阅读完需：约 9 分钟

前言

使用 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 实例规格如下：

CN 实例规格如下：

软件版本

测试中分别使用 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_salesCreate 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 "",  `new_column` varchar(16) 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 ("replication_num" = "1","datacache.enable" = "true","storage_volume" = "builtin_storage_volume","enable_async_write_back" = "false","enable_persistent_index" = "false","compression" = "LZ4");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:30RewriteFinishTime: 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_warehouse1 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: 10353OriginIndexId: 10090SchemaVersion: 0:0TransactionId: 6        State: FINISHED          Msg:      Progress: NULL      Timeout: 864001 row in set (0.00 sec)

复制代码

可以看到，在只有 130 GB 数据规模情况下，加列的延迟降低了 85 倍（8s VS 680s）。如果数据量进一步提升，提升的幅度会更加显著。

不同 Tablet 时 DDL 性能对比

StarRocks 存算分离的 Fast Schema Evolution 在实现时是只为每个 Tablet 写入元数据信息，其耗时与 Tablet 数量息息相关，本着严谨的原则补充测试了不同 Tablet 规模下的加列性能。这里调整了部分默认参数值：

# 控制 FE 后台调度执行 DDL Task 周期，默认为10sadmin set frontend config("alter_scheduler_interval_millisecond"="1000"); 
# 控制 CN 执行 ddl 任务的并行度，默认为 4update information_schema.be_configs set value = 4 where name = "max_update_tablet_meta_threads";

复制代码

不同并行度时 DDL 性能对比

StarRocks 存算分离的 Fast Schema Evolution 在实现时是只为每个 Tablet 写入元数据信息，其耗时与 Tablet 数量息息相关，本着严谨的原则补充测试了不同 Tablet 下的加列性能，通过调整如下参数来调整工作线程数量：

update information_schema.be_configs set value = x where name = "max_update_tablet_meta_threads";

复制代码

另外测试中也调大了 publish 工作线程池数量：

update information_schema.be_configs set value = 512 where name = "transaction_publish_version_worker_count";

复制代码

总结

Fast Schema Evolution 能力的发布，也意味着 StarRocks 存算分离也基本补齐了成为未来湖仓分析新范式的一块巨大短板，必定给用户体验带来极大的提升，感兴趣的朋友也欢迎尝试该能力并提宝贵的建议。

发布于: 刚刚阅读数: 2

Ding_Kai

关注

还未添加个人签名 2022-09-27 加入

还未添加个人简介

发布

暂无评论

创作场景

指如疾风，势如闪电 -StarRocks Fast Schema Evolution in V3.3.0

前言

测试环境

硬件规格

软件版本

数据集

测试结果

Fast Schema Evolution vs Old Schema Evolution

不同 Tablet 时 DDL 性能对比

不同并行度时 DDL 性能对比

总结

Ding_Kai

评论