StarRocks 3.5 新特性解读：Snapshot 快照恢复、大导入性能全面升级、分区管理更智能

自 2023 年 4 月推出存算分离架构以来，StarRocks 在性能优化和功能迭代方面不断加速，以持续满足企业日益增长的数据分析需求。最新发布的 StarRocks 3.5 版本再次聚焦用户痛点，带来了一系列实用的新特性：新增的 Snapshot 快照恢复机制有效提升数据安全与灾备能力，大规模数据导入流程的优化持续提升易用性与稳定性。

此外，3.5 版本还对多项核心功能进行了升级，包括更加智能灵活的分区管理策略、ETL 与事务能力的进一步增强，以及对 Iceberg 等数据湖格式查询体验的持续改进。同时，安全性方面也有了实质性的提升，支持 OAuth 2.0 和 JWT 等企业级认证方案。

本文将逐一解读这些新特性，帮助读者全面了解 StarRocks 3.5 版本的技术升级与优化。

存算分离备份恢复：Snapshot

在存算分离架构下，StarRocks 3.5 新增支持集群级别的 Snapshot 功能，提供完整的集群快照能力。Snapshot 可自动创建，记录集群在某一时间点的完整状态（包括 catalog、database、table、user 等元数据），并存储于对象存储中，实现快速的原地或异地恢复。

Snapshot 功能弥补了之前存算分离备份恢复的空缺。使用集群级别的 Snapshot 集群会定期将快照存储到对象存储中。备份与恢复操作均为轻量级，通常可在数分钟内完成。

Cluster Snapshot 包含两部分内容：Metadata Snapshot 和 Data Snapshot。

• Metadata Snapshot
  

FE 定期通过 checkpoint 的方式生成的 image 文件为 Metadata Snapshot。image 文件中包含了集群的元数据信息，包括库表，用户，权限等相关内容。

• Data Snapshot
  

在存算分离的架构中，数据会存储在对象存储上。而对象存储具有高可靠，接近无限容量等特性。所以在 Snapshot 产生的过程中，我们并不需要对数据进行拷贝，只需要保留 Metadata Snapshot 对应的数据版本即可。在恢复时可以将元数据与对应的数据版本进行映射。

在启用集群自动快照功能后，系统会按照设定周期（默认每 10 分钟）生成一份完整快照，并将 FE 的元数据 image 文件写入指定的对象存储路径（如 S3）。系统默认保留最近一次快照及其所依赖的数据版本。数据文件仍保存在原对象存储路径，不会发生额外的数据搬迁，系统也会确保当前快照所需的数据版本不会被清理。

当需要恢复时，用户只需在新集群或原集群中指定快照在对象存储上的路径与存储卷配置，即可将系统恢复至指定时间点的状态。恢复过程将自动加载元数据并清理冗余数据，确保数据一致性和可用性。

Snapshot 提供了一种高效、低成本、自动化的数据保护机制，提升了系统的可用性与容灾能力。面对系统故障、误操作或区域性宕机等场景，Snapshot 可支持分钟级快速恢复，最大限度减少数据丢失与业务中断风险。通过将完整集群状态快照化并持备份至对象存储， Snapshot 简化了传统灾备方案的复杂流程，使灾难恢复变得更加便捷。该机制适用于金融、零售、SaaS 等对稳定性要求较高的关键业务场景。

存算分离：大导入优化

在进行大规模数据导入时，导入内存限制可能导致最终生成的 Rowset 包含大量的小文件，过多的小文件不仅影响导入完成后的查询性能，还会增加后续 Compaction 的资源消耗，导致在 Compaction 完成前，新写入的数据查询性能不稳定。

为了解决这一问题，StarRocks 在 3.5 版本中引入了批量导入优化功能，旨在提升大数据量导入后查询的稳定性，降低后续 Compaction 资源的开销。

整体优化方案复用了现有的 Spill 模块能力。在导入执行阶段，对 memtable 执行 Spill 操作，以解决小文件过多导致的查询性能下降和资源开销问题。

• 避免生成大量小文件，减少元数据管理开销；
  
• 导入完成后，即达到最佳可查询状态。
  

整体流程如下图所示：

经测试验证，在开启 Load Spill 后，数据在导入完成时已基本处于最佳可查询状态，降低了 Compaction 阶段发生 OOM 的风险。

1. 查询延迟：导入完成后立刻查询，延迟可控。
   
2. 导入延迟：开启 Load Spill 后，导入阶段的延迟平均增加 13% ~ 26%。但综合考虑后续 Compaction 的耗时，总体导入效率提升 5% ~ 45%，具体效果与系统资源状况相关。在资源紧张时，优化收益更为明显。
   
3. 资源开销：Load Spill 完全解决了由于导入内存限制而产生过多小文件的问题，极大的降低了后续 Compaction 的资源开销。
   

分区管理

StarRocks 在分区管理方面进行了重大的功能优化，推出了基于时间表达式的分区合并、通用分区表达式 TTL。帮助用户自动化管理分区生命周期，减少过多的细粒度分区。

时间表达式分区合并

在 StarRocks 3.4 版本中，系统已支持使用常见时间函数作为分区表达式，为用户提供了更灵活的分区管理能力。然而，分区表达式的时间粒度在所有分区中保持一致，这在某些场景下存在局限。

例如，用户对近实时数据通常需要较细粒度（如天级、小时级）进行查询，而对历史数据的访问则偏向于更粗粒度（如月度、季度）。在此前版本中，用户往往需要以最细粒度进行统一分区，导致分区数量膨胀，不仅增加元数据开销，也降低了查询效率。

为此，StarRocks 在 3.5 版本中。通过 ALTER TABLE ... PARTITION BY <time_expr> 语句。用户可以指定合并的时间范围，将相邻的历史分区合并为更大的分区，减少大量小分区数量。这样能够显著简化分区管理，并降低查询时的分区遍历开销。

该功能带来以下优化效果：

• 查询优化器在裁剪分区时更加高效，只对业务关注的时间范围内数据进行快速扫描，进一步提升查询性能
  
• 整体减少分区数和分桶数，降低内存占用，使存储结构更紧凑，元数据更简洁，有助于提高系统的整体稳定性和管理效率。
  

ALTER TABLE [<db_name>.]<table_name>
PARTITION BY <time_expr>
WHERE dt BETWEEN <start_time> AND <end_time>;

细粒度（天）合并为月粒度

ALTER TABLE sales PARTITION BY date_trunc('month', dt) 
WHERE dt BETWEEN '2024-01-01' AND '2024-03-31';

效果:

• 2024-01-01 ~ 2024-01-31 的天级分区 → 2024-01 月级分区
  
• 2024-02-01 ~ 2024-02-29 的天级分区 → 2024-02 月级分区
  
• 2024-03-01 ~ 2024-03-31 的天级分区 → 2024-03 月级分区
  

通用的分区 TTL

StarRocks 3.5 引入了通用分区表达式 TTL 功能，支持基于分区表达式定义分区的生命周期管理策略。用户可通过在表属性中配置 partition_retention_condition，声明保留分区的过滤条件，例如保留最近三个月的数据。

系统会定期检测并自动删除不满足条件的过期分区，无需人工干预。

该机制支持所有类型的分区方式，包括 List 分区、Range 分区和表达式分区，能够有效简化旧数据的清理流程。

-- 定义表时带上`partition_retention_condition`属性
CREATE TABLE t1 (
    dt date,
    province string,
    num int
)
DUPLICATE KEY(dt)
PARTITION BY (dt, province)
PROPERTIES (
    -- 创建表时支持通用表达式语义，进保留最近3个月的数据
    "partition_retention_condition" = "dt >= CURRENT_DATE() - INTERVAL 3 MONTH",
    "replication_num" = "1"
);
-- 调整`partition_retention_condition`属性
ALTER TABLE t1 SET('partition_retention_condition' = 'dt >= CURRENT_DATE() - INTERVAL 1 MONTH');

除了支持更通用的分区表达式 TTL，StarRocks 也支持基于通用分区表达式删除表的分区，便于对多列分区表进行更灵活的管理。

CREATE TABLE t1 (
    dt date,
    province string,
    num int
)
DUPLICATE KEY(dt)
PARTITION BY (dt, province)
PROPERTIES (
    "replication_num" = "1"
);
insert into t1 values ('2024-01-01', 'zhejiang', 1), ('2025-01-01', 'shanghai', 2);
-- drop partitions支持通用表达式分区，将符合WHERE条件的分区删除掉
ALTER TABLE t1 DROP PARTITIONS WHERE dt < CURRENT_DATE() - INTERVAL 3 MONTH;

物化视图分区增强

StarRocks 3.5 对异步物化视图功能也进行了增强，特别是在分区相关功能方面。

1. 支持多列分区表达式：异步物化视图不再局限于单列分区，支持创建与基表一一映射的多列分区表达式。对于位于 Lakehouse 架构下的基表，物化视图不仅实现了湖仓一体化的融合，也能够复用 StarRocks 内表的能力，进一步提升 Lakehouse 解决方案的可用性与性能。
   
2. 支持分区级 TTL 策略：物化视图支持为分区单独设置 TTL。在视图刷新过程中，系统仅保留符合保留条件的最新分区，自动清理过期数据，从而实现“部分数据物化”场景。
   
3. 透明查询改写增强：StarRocks 支持基于分区 TTL 自动进行透明改写。例如在开启 force_mv 模式后，查询将仅命中最新的有效分区；如查询涉及过期分区数据，则自动回退至基表执行，确保结果的一致性与完整性。
   

通过以上增强，物化视图能够更灵活地加速对最新数据的查询，同时显著节省存储成本，避免了过期分区对查询计划和资源的影响。

如下图所示，当前物化视图中的分区 20242231 已因过期被系统自动清理。当查询命中不满足 partition_retention_condition 条件的分区时，会通过 MV+BaseTable 自动补偿。同样地，对于尚未创建的分区（如 20241203），查询也将自动路由至 BaseTable 完成补偿。

ETL 增强

Multi statement transaction

随着越来越多用户将 StarRocks 用作企业数据仓库，在迁移原有数仓的加工任务时，常常面临一项挑战：传统任务流程通常由多个彼此依赖的任务组成，一旦某个中间任务失败，StarRocks 早期版本因不支持回滚机制，往往需要重跑整个流程，造成资源浪费与效率下降。

为解决这一问题，StarRocks 在 3.5 版本中引入了多语句事务（Multi-statement Transaction）能力。用户可通过标准的 BEGIN、COMMIT 和 ROLLBACK 语法，将多个写入语句（如多个 INSERT）封装为一个事务单元执行，从而实现完整的原子性和一致性保障。

当某个语句执行出现异常时，用户可以便捷地进行回滚与重试整个任务。

ACID 事务保障

• 原子性（Atomicity）：多个 INSERT 要么全部成功提交，要么全部不生效。成功返回即表示所有数据均已写入；如失败，则不会写入任何一行数据。
  
• 一致性（Consistency）：仅在不违反表约束（如数据类型）的情况下才会成功提交；如有违反，则整批写入全部失败。
  
• 隔离性（Isolation）：当前支持 Read Committed 级别的隔离，事务未提交前，其写入数据对其他会话不可见。
  
• 持久性（Durability）：
  在存算一体架构下，依托本地磁盘多副本机制，保障数据持久性。
  在存算分离架构下，数据会被可靠地持久化至对象存储。
  

示例如下：

BEGIN;
INSERT INTO orders (order_id, customer_id, amount) VALUES (1, 101, 250.00);
INSERT INTO order_items (order_id, item_id, quantity) SELECT * FROM orders_details where product_id=1009;
COMMIT;

数据湖分析

性能优化

在数据湖分析场景（如 Hive、Iceberg 表）中，表结构通常包含大量低基数的字符串维度列，如地区、分类、性别等。针对这些列的查询操作，传统执行引擎往往需要逐行进行字符串比对，效率低、资源消耗大。

StarRocks 在早期版本中已引入全局低基数字典优化机制，可将低基数的字符串列编码为整数，从而加快查询速度。例如，对于基数低于 255 的列（如城市、性别），StarRocks 会自动创建低基数字典来加速查询。

然而，该优化此前仅适用于 StarRocks 的内部表，对于存储在对象存储中的 Lake 表（如 S3、OSS 等）尚未支持。因此，在对 Lake 表执行复杂查询时，仍需扫描原始字符串数据，导致查询延迟高、资源消耗大，难以充分发挥 StarRocks 的性能优势。

为解决这一问题，需要在 Lake 表查询中引入低基数字典优化机制。

整体流程如下：

1. 触发采样规则（Trigger）
   

当优化器检测到查询涉及低基数列时，会通过 LowCardinalityRewriteRule 启动字典采样流程。此流程由异步缓存控制（AsyncLoadingCache），避免重复采样。

1. 从数据文件中采样构建候选字典（Sampling）
   

系统会从 Lake 表（如 Hive、Iceberg）中的 Parquet 文件中随机抽取少量数据文件（如 5 个），并读取目标列的值。

1. 生成并保存全局字典（Build & Persist）
   

若采样数据满足低基数特性（如唯一值数量在可控范围内），系统将构建并缓存该列的全局字典。字典的版本信息也会被记录，以便后续查询比对和判断是否需要更新。

1. 查询阶段校验字典是否匹配（Validate）
   

执行查询时，如果数据文件中的某行或某个 row group 中存在字典无法覆盖的新值，会触发 GlobalDictNotMatch 异常。

1. 失败重试与反馈更新（Retry & Feedback）
   

• 若匹配失败，系统自动回退到非优化路径（如直接使用原始字符串查询），保证查询不失败。
  
• 同时系统会提取失败信息（列名、文件名），并异步触发对该文件的补充采样与字典更新操作，提升后续查询命中率。
  

在使用 100GB SSB 数据集进行测试时，数据经打平处理并以 Parquet + LZ4 格式存储于对象存储中。测试环境采用 4 台阿里云 16 核 64G 服务器，对比开启与关闭低基数全局字典的查询性能。

结果显示：包含低基数列的查询场景中，整体性能提升达 2.62 倍。

功能优化

• 【Beta】支持创建 Iceberg View（hive catalog type）且支持为 Iceberg 视图添加和修改方言（Dialect）。
  

ALTER VIEW qualifiedName SET properties
ALTER VIEW qualifiedName (ADD | MODIFY) DIALECT (STARROCKS)?  queryStatement

• 支持 Iceberg REST Catalog 的嵌套命名空间。
  

其它

• 新版本支持 MySQL 协议的 SSL 加密连接。同时引入 Security Integration 机制，简化认证配置流程，并新增对 OAuth2 与 OIDC（OpenID Connect）认证方式的支持。
  
• StarRocks 默认运行环境由 JDK 11 升级至 JDK 17，进一步提升系统性能、内存管理能力与运行时稳定性。
  

👇更详细的 feature 介绍参考：

Release note：https://docs.mirrorship.cn/zh/releasenotes/release-3.5/

下载：https://www.mirrorship.cn/zh-CN/download/starrocks