StarRocks 2.0 版本发布全解析Primary Key 表正式 GA、外部表能力与存储层表达式下推【免费下载链接】starrocksThe worlds fastest open query engine for sub-second analytics both on and off the data lakehouse. With the flexibility to support nearly any scenario, StarRocks provides best-in-class performance for multi-dimensional analytics, real-time analytics, and ad-hoc queries. A Linux Foundation project.项目地址: https://gitcode.com/GitHub_Trending/st/starrocksStarRocks 2.0 是该项目迈向实时分析与湖仓一体方向的关键里程碑版本本指南以官方 2.0 版本发布说明为主线系统梳理 2.0.0 至 2.0.9 共 10 个子版本的新特性、性能优化、关键缺陷修复与升级注意事项并对照当前仓库源码be 与 fe印证各能力的底层实现帮助读者理解 StarRocks 2.0 的能力边界、演进脉络与实战选型要点。一、版本总览2.0 系列定位StarRocks 2.0 系列自 2022 年 1 月 5 日发布 2.0.0 起到 2022 年 8 月 6 日发布 2.0.9 收官共历经 10 个子版本。这一版本线的核心主题可以概括为三件事Primary Key 表从实验走向正式发布GA补齐了实时更新、实时同步场景的核心拼图外部表能力扩展开始支持访问 Hive on S3向湖仓一体迈出第一步存储层计算下推与查询优化包括复杂表达式下推、低基数字典优化、内存管理重构等进一步压榨单机性能。2.0 系列文档原文位于 docs/en/release_notes/release-2.0.md以下各节按版本号顺序展开并对官方描述补充源码级证据。二、2.0.0 核心特性主键表正式发布2.1 Primary Key 表正式 GA2.0.0 发布说明明确指出Primary Key 表正式发布Primary Key is officially released并且同步支持了 Stream Load、Broker Load、Routine Load 三种导入方式还提供了基于 Flink CDC 的 MySQL 秒级同步工具。从当前仓库源码看主键表能力已深度嵌入 BE 的存储层主键索引核心实现在 be/src/storage/primary_index.cpp其中PrimaryIndex类提供了prepare、upsert等批量接口例如HashIndexImpl::upsert、SliceHashIndex::upsert分别面向定长/变长主键列用于在写入时将主键映射到具体的行位置rowid从而支撑按主键去重与更新数据写入链路中be/src/storage/delta_writer.cpp 负责将导入批次落地为增量数据而版本发布publish环节由 FE 驱动确保所有副本达成一致的可见版本在湖仓一体化Lake形态下主键表的写入与合并逻辑在 be/src/storage/lake/pk_tablet_writer.cpp、be/src/storage/lake/rowset_update_state.cpp 中实现说明主键更新机制在共享数据湖存储上同样适用。需要特别说明的是2.0.0 发布说明中的表述是正式发布GA而非实验特性这一点与外部表标注为 Experimental Function 形成鲜明对比——主键表在 2.0 中已成为受支持的正式能力可用于实时更新场景如订单状态变更、库存扣减等。2.2 外部表支持 Hive on S3实验特性2.0.0 的第二个新特性是外部表Hive 外部表支持 S3标注为 Experimental FunctionDecimalV3 数据类型在外部表中的支持对应 PR #425。外部表的底层实现在 FE 侧由 fe/fe-core/src/main/java/com/starrocks/catalog/HiveTable.java 承载。从该类源码可见其核心设计通过hive.metastore.uris常量HIVE_METASTORE_URIS指向 Hive Metastore获取表结构与分区元数据通过HiveTableType枚举区分EXTERNAL_TABLE、MANAGED_TABLE、VIRTUAL_VIEW、MATERIALIZED_VIEW等类型说明外部表与后续的 Catalog/物化视图体系在架构上共享同一套表模型类中维护hive.table.serde.lib、hive.table.input.format、hive.table.column.names、hive.table.column.types等属性键分别描述 SerDe、输入格式与列结构对应 Hive 元数据的关键字段。2.3 复杂表达式下推到存储层2.0.0 实现了将复杂表达式下推到存储层进行计算Implement complex expressions to be pushed down to the storage layer for computation从而获得查询性能收益。这一特性意味着并非只有简单的等值/范围谓词才能下推由多个算子组合的复杂表达式也可以在扫描阶段提前求值减少从存储层返回 BE 执行引擎的数据量。结合本仓库后续版本更高版本分支中存储层针对下推表达式的持续演进可以推断该能力是 StarRocks 列存 延迟物化 下推优化体系的一部分其收益在宽表、过滤率高的场景中尤为明显。2.4 性能优化低基数字典、count(distinct) 与内存管理2.0.0 的 Improvements 集中在两个方向。算术/查询算子优化低基数字典性能优化对应 PR #791单表 int 列扫描优化对应 issue #273高基数下count(distinct int)的性能优化对应 PR #139、#250、#544、#570实现层优化group by int、limit、case when、not equal等算子。低基数low-cardinality优化在 FE 优化器中已有完整落点当前仓库中 fe/fe-core/src/main/java/com/starrocks/sql/optimizer/rule/tree/AddDecodeNodeForDictStringRule.java 负责为低基数字符串列插入字典解码节点fe/fe-core/src/main/java/com/starrocks/sql/optimizer/rule/tree/lowcardinality 目录下则集中了DecodeContext、DecodeCollector、DecodeInfo等实现类。其核心思路是将重复度高的字符串列编码为紧凑的整数 ID 参与计算join、聚合、谓词过滤大幅减少内存占用与比较开销在查询结束后再解码回原始字符串。内存管理优化对应 PR #1093重构内存统计与控制框架精确统计内存使用彻底解决 OOM优化元数据内存占用解决大内存释放长时间卡住执行线程的问题新增进程优雅退出机制并支持内存泄漏检查。结合 2.0.5 中 BE 失败可能导致数据丢失 的修复引入批量发布版本机制见下文可以理解 2.0 在正确性 内存稳定性两个维度同时做了大手术。2.5 2.0.0 缺陷修复清单修复 Hive 外部表在大量元数据获取时超时的问题修复物化视图创建时错误信息不清晰的问题修复向量化引擎中like的实现对应 PR #722修复alter table中谓词解析错误对应 PR #725修复curdate函数无法格式化日期的问题。三、2.0.1Hive 隐式转换、CBO 并发与行为变更发布于 2022 年 1 月 21 日的 2.0.1 主要带来以下改进Improvements使用外部表查询 Hive 数据时可以读取 Hive 的implicit_cast操作对应 PR #2829使用读写锁修复 StarRocks CBO 收集统计信息时的高 CPU 占用支撑高并发查询对应 PR #2901CBO 统计信息收集与 UNION 算子得到优化。Bug Fixes修复副本间全局字典不一致导致的查询错误对应 PR #2700、#2765修复数据导入时exec_mem_limit参数不生效的问题对应 PR #2693——该参数用于限制数据导入期间每个 BE 节点的内存上限修复主键表导入时的 OOM 错误对应 PR #2743、#2777修复外部表查询大 MySQL 表时 BE 停止响应的问题对应 PR #2881。Behavior Change行为变更需重点关注StarRocks 可以使用外部表访问 Hive 及其基于 AWS S3 的外部表。但访问 S3 数据所需的 jar 文件体积过大未包含在 StarRocks 二进制包中。如需使用需自行从 Hive_s3_lib 归档下载。这意味着在 2.0.1 中Hive on S3 外部表并不是开箱即用的部署时需要手动补齐 S3 访问依赖这是生产部署前必须确认的环境事项。四、2.0.2 与 2.0.3稳定性修复密集期4.1 2.0.22022-03-02Improvements内存使用优化新增label_keep_max_num参数用于控制在指定时间内保留的导入任务最大数量。在高频数据导入场景下FE 因内存中的导入任务元数据过多可能触发 Full GC该参数让用户可以主动收紧保留上限从而规避频繁导入导致的 FE 内存压力。Bug Fixes列解码器column decoder异常时 BE 节点失败的问题指定jsonpaths加载 JSON 数据时自动__op映射不生效的问题Broker Load 导入过程中源数据发生变化导致 BE 失败的问题创建物化视图后部分 SQL 报错的问题SQL 子句中同时包含支持全局字典低基数优化与不支持全局字典的谓词时查询可能失败的问题。4.2 2.0.32022-03-14修复 BE 节点假死suspended animation时查询失败的问题修复单 tablet 表 JOIN 无合适执行计划导致查询失败的问题对应 issue #3854修复 FE 收集低基数优化全局字典信息时可能发生的死锁问题对应 issue #3839。2.0.2 与 2.0.3 的修复集中在导入可靠性、低基数优化链路与 BE 稳定性上其中多处在低基数全局字典相关问题上反复打磨印证了该优化在 2.0 中的核心地位——同时也提示使用方该特性涉及的副本一致性、谓词混用等边界场景在 2.0 早期版本仍需谨慎验证。五、2.0.4Schema 变更与复制一致性发布于 2022 年 4 月 18 日修复内容包括删除列、新增分区并克隆 tablet 后新旧 tablet 中列的唯一 IDunique id可能不一致而系统使用共享 tablet schema导致 BE 停止工作对应 issue #4514向 StarRocks 外部表加载数据时如果目标 StarRocks 集群配置的 FE 不是 Leader会导致 FE 停止工作对应 issue #4573Duplicate Key 表同时执行 Schema Change 与创建物化视图时查询结果可能不正确对应 issue #4839通过批量发布版本Batch publish version解决 BE 失败导致的数据丢失问题对应 issue #3140。其中批量发布版本机制是 2.0 数据可靠性修复的关键动作它将逐个副本发布版本改为一次性向多个 BE 发布指定版本缩短了版本发布窗口内副本之间的不一致暴露时间从机制上降低了 BE 故障引发数据丢失的概率。六、2.0.5数据正确性关键修复版发布于 2022 年 5 月 13 日。官方明确给出升级建议本版本修复了多个与存储数据/查询结果正确性相关的关键缺陷强烈建议尽早升级集群。本版本修复的关键缺陷Critical Bug包括BE 失败可能导致数据丢失——通过批量发布版本机制修复对应 issue #3140与 2.0.4 中的修复一脉相承特定导入阶段发生 tablet 迁移时数据仍写入原磁盘导致数据丢失、查询异常对应 issue #5160多次 DELETE 后执行查询若对低基数列做优化可能得到错误结果对应 issue #5712——再次显示低基数优化在写删交错场景下的正确性风险JOIN 组合 DOUBLE 列与 VARCHAR 列时查询结果可能错误对应 PR #5809特定情况下 FE 在副本生效前将其标记为有效查询对应版本时报错对应 issue #5153SPLIT函数参数为NULL时 BE 可能停止运行对应 issue #4092从 Apache Doris 0.13 升级到 1.19.x 并运行一段时间后进一步升级到 2.0.1 可能失败对应 issue #5309。七、2.0.6导入正确性与 Colocate Join 稳定性发布于 2022 年 5 月 25 日修复内容包括部分 GUI 工具自动配置set_sql_limit变量导致 ORDER BY LIMIT 被忽略、查询返回行数错误对应 issue #5966当 Colocation GroupCG包含大量表且高频导入时CG 可能无法保持stable状态此时 JOIN 无法使用 Colocate Join。StarRocks 通过优化数据导入时的等待时长最大化被导入 tablet 副本的完整性少量副本因负载高或网络延迟导入失败而触发克隆时可能发生死锁表现为进程负载低但大量请求超时对应 issue #5646、#6290主键表 Schema 变更后导入数据时可能报 duplicate key xxx 错误对应 issue #5878对数据库执行 DROP SCHEMA 时数据库被强制删除且无法恢复对应 issue #6201。八、2.0.7 与 2.0.8压缩、元数据与 Routine Load 修复8.1 2.0.72022-06-13表在压缩compaction过程中某列重复值数量超过 0x40000000约 10.7 亿时压缩被挂起对应 issue #6513FE 重启后因 BDB JE v7.3.8 的若干问题出现高 I/O 与磁盘占用异常增长且无法恢复回滚到 BDB JE v7.3.7 后恢复对应 issue #6634。BDB JE 是 StarRocks FE 元数据存储的底层依赖该问题提示生产环境升级需要关注依赖组件版本组合的兼容性。8.2 2.0.82022-07-15反复切换 Leader FE 节点可能导致所有导入任务挂起失败对应 issue #7350导入数据倾斜时部分字段占用大量内存MemTable 内存估算超过 4GB 时 BE 崩溃对应 issue #7161重启 FE 后因大小写字母解析错误导致物化视图 Schema 变化对应 issue #7362使用 Routine Load 从 Kafka 加载 JSON 数据时若 JSON 中存在空行空行之后的数据会丢失对应 issue #8534。九、2.0.9最终补丁版本发布于 2022 年 8 月 6 日作为 2.0 系列收官版本修复了 4 个问题Broker Load 任务中 broker 负载过高时内部心跳可能超时导致数据丢失对应 issue #8282Broker Load 目标表中不存在COLUMNS FROM PATH AS参数指定的列时BE 停止运行对应 issue #5346部分查询被转发到 Leader FE导致/api/query_detail对 SHOW FRONTENDS 等 SQL 返回错误的执行信息对应 issue #9185多个 Broker Load 任务同时加载同一 HDFS 数据文件时若其中一个任务异常其他任务可能也无法正常读取数据并失败对应 issue #9506。十、从发布说明看 2.0 的工程主线综合 10 个子版本可以梳理出 StarRocks 2.0 的四条工程主线数据可靠性优先2.0.4/2.0.5 连续引入并强化批量发布版本机制修复 BE 失败导致的数据丢失、迁移期写错磁盘等关键正确性问题2.0.9 继续收紧 Broker Load 心跳超时、同源文件并发加载等边界场景。升级到 2.0.5 及以上是数据安全的基本要求。主键表Primary Key成为正式能力2.0.0 宣布 GA 后后续版本持续修补其导入 OOM2.0.1、Schema 变更后重复键报错2.0.6等问题。从 be/src/storage/primary_index.cpp 中批量 upsert 接口与 be/src/storage/delta_writer.cpp 写入链路可以看到其主键索引 行更新的核心机制在后续版本中持续演进是实时更新类业务的基石。低基数优化贯穿始终从 2.0.0 的性能优化到 2.0.1/2.0.3 的全局字典一致性修复再到 2.0.5 的 DELETE 场景正确性修复低基数字典优化在 FE 侧由 AddDecodeNodeForDictStringRule.java 及 lowcardinality 包支撑。它带来显著性能收益的同时也要求使用者注意副本一致性、写删交错等边界场景。湖仓一体萌芽Hive on S3 外部表实验特性在 2.0.0 引入、2.0.1 明确 S3 访问依赖需要单独部署 jarFE 侧 HiveTable.java 已勾勒出资源 → 外部表 → Catalog的演进雏形为后续版本完善的湖仓分析能力奠定基础。十一、升级与使用建议基于 2.0 各版本的修复内容与升级建议给出以下实践要点务必升级到 2.0.5 或更高版本2.0.5 官方明确建议尽早升级其修复的 BE 失败数据丢失、DELETE 后低基数查询错误、DOUBLE/VARCHAR JOIN 结果错误均属于数据正确性问题生产环境最终落到 2.0.9作为 2.0 系列收官版本2.0.9 修复了 Broker Load 心跳超时数据丢失、同源 HDFS 文件并发加载互相干扰等问题是 2.0 线上环境的最稳选择关注 FE 元数据与内存参数label_keep_max_num2.0.2 引入可缓解高频导入下 FE 的 Full GC 压力exec_mem_limit控制导入时每个 BE 的内存上限在导入 OOM 排查时应优先检查其是否生效主键表导入 OOM 与 Schema 变更风险2.0 早期主键表存在导入 OOM2.0.1 修复与 Schema 变更后 duplicate key 报错2.0.6 修复使用主键表做实时更新前请确认所在版本已包含对应修复Hive on S3 外部表需手动部署依赖二进制包不含 S3 访问 jar部署前需按 2.0.1 行为变更说明补齐避免线上查询失败低基数优化相关查询需回归验证涉及多次 DELETE 后查询、低基数谓词与其他谓词混用的 SQL在升级后建议做结果正确性回归。StarRocks 2.0 通过主键表 GA 外部表起步 存储层下推 内存重构四大动作完成了从 OLAP 查询引擎向实时 湖仓双能力引擎的关键一跳其后的每个补丁版本都在为这一跳的稳定落地持续加固这也是理解 StarRocks 后续版本演进逻辑的重要起点。【免费下载链接】starrocksThe worlds fastest open query engine for sub-second analytics both on and off the data lakehouse. With the flexibility to support nearly any scenario, StarRocks provides best-in-class performance for multi-dimensional analytics, real-time analytics, and ad-hoc queries. A Linux Foundation project.项目地址: https://gitcode.com/GitHub_Trending/st/starrocks创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 StarRocks 2.0 版本发布全解析：Primary Key 表正式 GA、外部表能力与存储层表达式下推
StarRocks 2.0 版本发布全解析Primary Key 表正式 GA、外部表能力与存储层表达式下推【免费下载链接】starrocksThe worlds fastest open query engine for sub-second analytics both on and off the data lakehouse. With the flexibility to support nearly any scenario, StarRocks provides best-in-class performance for multi-dimensional analytics, real-time analytics, and ad-hoc queries. A Linux Foundation project.项目地址: https://gitcode.com/GitHub_Trending/st/starrocksStarRocks 2.0 是该项目迈向实时分析与湖仓一体方向的关键里程碑版本本指南以官方 2.0 版本发布说明为主线系统梳理 2.0.0 至 2.0.9 共 10 个子版本的新特性、性能优化、关键缺陷修复与升级注意事项并对照当前仓库源码be 与 fe印证各能力的底层实现帮助读者理解 StarRocks 2.0 的能力边界、演进脉络与实战选型要点。一、版本总览2.0 系列定位StarRocks 2.0 系列自 2022 年 1 月 5 日发布 2.0.0 起到 2022 年 8 月 6 日发布 2.0.9 收官共历经 10 个子版本。这一版本线的核心主题可以概括为三件事Primary Key 表从实验走向正式发布GA补齐了实时更新、实时同步场景的核心拼图外部表能力扩展开始支持访问 Hive on S3向湖仓一体迈出第一步存储层计算下推与查询优化包括复杂表达式下推、低基数字典优化、内存管理重构等进一步压榨单机性能。2.0 系列文档原文位于 docs/en/release_notes/release-2.0.md以下各节按版本号顺序展开并对官方描述补充源码级证据。二、2.0.0 核心特性主键表正式发布2.1 Primary Key 表正式 GA2.0.0 发布说明明确指出Primary Key 表正式发布Primary Key is officially released并且同步支持了 Stream Load、Broker Load、Routine Load 三种导入方式还提供了基于 Flink CDC 的 MySQL 秒级同步工具。从当前仓库源码看主键表能力已深度嵌入 BE 的存储层主键索引核心实现在 be/src/storage/primary_index.cpp其中PrimaryIndex类提供了prepare、upsert等批量接口例如HashIndexImpl::upsert、SliceHashIndex::upsert分别面向定长/变长主键列用于在写入时将主键映射到具体的行位置rowid从而支撑按主键去重与更新数据写入链路中be/src/storage/delta_writer.cpp 负责将导入批次落地为增量数据而版本发布publish环节由 FE 驱动确保所有副本达成一致的可见版本在湖仓一体化Lake形态下主键表的写入与合并逻辑在 be/src/storage/lake/pk_tablet_writer.cpp、be/src/storage/lake/rowset_update_state.cpp 中实现说明主键更新机制在共享数据湖存储上同样适用。需要特别说明的是2.0.0 发布说明中的表述是正式发布GA而非实验特性这一点与外部表标注为 Experimental Function 形成鲜明对比——主键表在 2.0 中已成为受支持的正式能力可用于实时更新场景如订单状态变更、库存扣减等。2.2 外部表支持 Hive on S3实验特性2.0.0 的第二个新特性是外部表Hive 外部表支持 S3标注为 Experimental FunctionDecimalV3 数据类型在外部表中的支持对应 PR #425。外部表的底层实现在 FE 侧由 fe/fe-core/src/main/java/com/starrocks/catalog/HiveTable.java 承载。从该类源码可见其核心设计通过hive.metastore.uris常量HIVE_METASTORE_URIS指向 Hive Metastore获取表结构与分区元数据通过HiveTableType枚举区分EXTERNAL_TABLE、MANAGED_TABLE、VIRTUAL_VIEW、MATERIALIZED_VIEW等类型说明外部表与后续的 Catalog/物化视图体系在架构上共享同一套表模型类中维护hive.table.serde.lib、hive.table.input.format、hive.table.column.names、hive.table.column.types等属性键分别描述 SerDe、输入格式与列结构对应 Hive 元数据的关键字段。2.3 复杂表达式下推到存储层2.0.0 实现了将复杂表达式下推到存储层进行计算Implement complex expressions to be pushed down to the storage layer for computation从而获得查询性能收益。这一特性意味着并非只有简单的等值/范围谓词才能下推由多个算子组合的复杂表达式也可以在扫描阶段提前求值减少从存储层返回 BE 执行引擎的数据量。结合本仓库后续版本更高版本分支中存储层针对下推表达式的持续演进可以推断该能力是 StarRocks 列存 延迟物化 下推优化体系的一部分其收益在宽表、过滤率高的场景中尤为明显。2.4 性能优化低基数字典、count(distinct) 与内存管理2.0.0 的 Improvements 集中在两个方向。算术/查询算子优化低基数字典性能优化对应 PR #791单表 int 列扫描优化对应 issue #273高基数下count(distinct int)的性能优化对应 PR #139、#250、#544、#570实现层优化group by int、limit、case when、not equal等算子。低基数low-cardinality优化在 FE 优化器中已有完整落点当前仓库中 fe/fe-core/src/main/java/com/starrocks/sql/optimizer/rule/tree/AddDecodeNodeForDictStringRule.java 负责为低基数字符串列插入字典解码节点fe/fe-core/src/main/java/com/starrocks/sql/optimizer/rule/tree/lowcardinality 目录下则集中了DecodeContext、DecodeCollector、DecodeInfo等实现类。其核心思路是将重复度高的字符串列编码为紧凑的整数 ID 参与计算join、聚合、谓词过滤大幅减少内存占用与比较开销在查询结束后再解码回原始字符串。内存管理优化对应 PR #1093重构内存统计与控制框架精确统计内存使用彻底解决 OOM优化元数据内存占用解决大内存释放长时间卡住执行线程的问题新增进程优雅退出机制并支持内存泄漏检查。结合 2.0.5 中 BE 失败可能导致数据丢失 的修复引入批量发布版本机制见下文可以理解 2.0 在正确性 内存稳定性两个维度同时做了大手术。2.5 2.0.0 缺陷修复清单修复 Hive 外部表在大量元数据获取时超时的问题修复物化视图创建时错误信息不清晰的问题修复向量化引擎中like的实现对应 PR #722修复alter table中谓词解析错误对应 PR #725修复curdate函数无法格式化日期的问题。三、2.0.1Hive 隐式转换、CBO 并发与行为变更发布于 2022 年 1 月 21 日的 2.0.1 主要带来以下改进Improvements使用外部表查询 Hive 数据时可以读取 Hive 的implicit_cast操作对应 PR #2829使用读写锁修复 StarRocks CBO 收集统计信息时的高 CPU 占用支撑高并发查询对应 PR #2901CBO 统计信息收集与 UNION 算子得到优化。Bug Fixes修复副本间全局字典不一致导致的查询错误对应 PR #2700、#2765修复数据导入时exec_mem_limit参数不生效的问题对应 PR #2693——该参数用于限制数据导入期间每个 BE 节点的内存上限修复主键表导入时的 OOM 错误对应 PR #2743、#2777修复外部表查询大 MySQL 表时 BE 停止响应的问题对应 PR #2881。Behavior Change行为变更需重点关注StarRocks 可以使用外部表访问 Hive 及其基于 AWS S3 的外部表。但访问 S3 数据所需的 jar 文件体积过大未包含在 StarRocks 二进制包中。如需使用需自行从 Hive_s3_lib 归档下载。这意味着在 2.0.1 中Hive on S3 外部表并不是开箱即用的部署时需要手动补齐 S3 访问依赖这是生产部署前必须确认的环境事项。四、2.0.2 与 2.0.3稳定性修复密集期4.1 2.0.22022-03-02Improvements内存使用优化新增label_keep_max_num参数用于控制在指定时间内保留的导入任务最大数量。在高频数据导入场景下FE 因内存中的导入任务元数据过多可能触发 Full GC该参数让用户可以主动收紧保留上限从而规避频繁导入导致的 FE 内存压力。Bug Fixes列解码器column decoder异常时 BE 节点失败的问题指定jsonpaths加载 JSON 数据时自动__op映射不生效的问题Broker Load 导入过程中源数据发生变化导致 BE 失败的问题创建物化视图后部分 SQL 报错的问题SQL 子句中同时包含支持全局字典低基数优化与不支持全局字典的谓词时查询可能失败的问题。4.2 2.0.32022-03-14修复 BE 节点假死suspended animation时查询失败的问题修复单 tablet 表 JOIN 无合适执行计划导致查询失败的问题对应 issue #3854修复 FE 收集低基数优化全局字典信息时可能发生的死锁问题对应 issue #3839。2.0.2 与 2.0.3 的修复集中在导入可靠性、低基数优化链路与 BE 稳定性上其中多处在低基数全局字典相关问题上反复打磨印证了该优化在 2.0 中的核心地位——同时也提示使用方该特性涉及的副本一致性、谓词混用等边界场景在 2.0 早期版本仍需谨慎验证。五、2.0.4Schema 变更与复制一致性发布于 2022 年 4 月 18 日修复内容包括删除列、新增分区并克隆 tablet 后新旧 tablet 中列的唯一 IDunique id可能不一致而系统使用共享 tablet schema导致 BE 停止工作对应 issue #4514向 StarRocks 外部表加载数据时如果目标 StarRocks 集群配置的 FE 不是 Leader会导致 FE 停止工作对应 issue #4573Duplicate Key 表同时执行 Schema Change 与创建物化视图时查询结果可能不正确对应 issue #4839通过批量发布版本Batch publish version解决 BE 失败导致的数据丢失问题对应 issue #3140。其中批量发布版本机制是 2.0 数据可靠性修复的关键动作它将逐个副本发布版本改为一次性向多个 BE 发布指定版本缩短了版本发布窗口内副本之间的不一致暴露时间从机制上降低了 BE 故障引发数据丢失的概率。六、2.0.5数据正确性关键修复版发布于 2022 年 5 月 13 日。官方明确给出升级建议本版本修复了多个与存储数据/查询结果正确性相关的关键缺陷强烈建议尽早升级集群。本版本修复的关键缺陷Critical Bug包括BE 失败可能导致数据丢失——通过批量发布版本机制修复对应 issue #3140与 2.0.4 中的修复一脉相承特定导入阶段发生 tablet 迁移时数据仍写入原磁盘导致数据丢失、查询异常对应 issue #5160多次 DELETE 后执行查询若对低基数列做优化可能得到错误结果对应 issue #5712——再次显示低基数优化在写删交错场景下的正确性风险JOIN 组合 DOUBLE 列与 VARCHAR 列时查询结果可能错误对应 PR #5809特定情况下 FE 在副本生效前将其标记为有效查询对应版本时报错对应 issue #5153SPLIT函数参数为NULL时 BE 可能停止运行对应 issue #4092从 Apache Doris 0.13 升级到 1.19.x 并运行一段时间后进一步升级到 2.0.1 可能失败对应 issue #5309。七、2.0.6导入正确性与 Colocate Join 稳定性发布于 2022 年 5 月 25 日修复内容包括部分 GUI 工具自动配置set_sql_limit变量导致 ORDER BY LIMIT 被忽略、查询返回行数错误对应 issue #5966当 Colocation GroupCG包含大量表且高频导入时CG 可能无法保持stable状态此时 JOIN 无法使用 Colocate Join。StarRocks 通过优化数据导入时的等待时长最大化被导入 tablet 副本的完整性少量副本因负载高或网络延迟导入失败而触发克隆时可能发生死锁表现为进程负载低但大量请求超时对应 issue #5646、#6290主键表 Schema 变更后导入数据时可能报 duplicate key xxx 错误对应 issue #5878对数据库执行 DROP SCHEMA 时数据库被强制删除且无法恢复对应 issue #6201。八、2.0.7 与 2.0.8压缩、元数据与 Routine Load 修复8.1 2.0.72022-06-13表在压缩compaction过程中某列重复值数量超过 0x40000000约 10.7 亿时压缩被挂起对应 issue #6513FE 重启后因 BDB JE v7.3.8 的若干问题出现高 I/O 与磁盘占用异常增长且无法恢复回滚到 BDB JE v7.3.7 后恢复对应 issue #6634。BDB JE 是 StarRocks FE 元数据存储的底层依赖该问题提示生产环境升级需要关注依赖组件版本组合的兼容性。8.2 2.0.82022-07-15反复切换 Leader FE 节点可能导致所有导入任务挂起失败对应 issue #7350导入数据倾斜时部分字段占用大量内存MemTable 内存估算超过 4GB 时 BE 崩溃对应 issue #7161重启 FE 后因大小写字母解析错误导致物化视图 Schema 变化对应 issue #7362使用 Routine Load 从 Kafka 加载 JSON 数据时若 JSON 中存在空行空行之后的数据会丢失对应 issue #8534。九、2.0.9最终补丁版本发布于 2022 年 8 月 6 日作为 2.0 系列收官版本修复了 4 个问题Broker Load 任务中 broker 负载过高时内部心跳可能超时导致数据丢失对应 issue #8282Broker Load 目标表中不存在COLUMNS FROM PATH AS参数指定的列时BE 停止运行对应 issue #5346部分查询被转发到 Leader FE导致/api/query_detail对 SHOW FRONTENDS 等 SQL 返回错误的执行信息对应 issue #9185多个 Broker Load 任务同时加载同一 HDFS 数据文件时若其中一个任务异常其他任务可能也无法正常读取数据并失败对应 issue #9506。十、从发布说明看 2.0 的工程主线综合 10 个子版本可以梳理出 StarRocks 2.0 的四条工程主线数据可靠性优先2.0.4/2.0.5 连续引入并强化批量发布版本机制修复 BE 失败导致的数据丢失、迁移期写错磁盘等关键正确性问题2.0.9 继续收紧 Broker Load 心跳超时、同源文件并发加载等边界场景。升级到 2.0.5 及以上是数据安全的基本要求。主键表Primary Key成为正式能力2.0.0 宣布 GA 后后续版本持续修补其导入 OOM2.0.1、Schema 变更后重复键报错2.0.6等问题。从 be/src/storage/primary_index.cpp 中批量 upsert 接口与 be/src/storage/delta_writer.cpp 写入链路可以看到其主键索引 行更新的核心机制在后续版本中持续演进是实时更新类业务的基石。低基数优化贯穿始终从 2.0.0 的性能优化到 2.0.1/2.0.3 的全局字典一致性修复再到 2.0.5 的 DELETE 场景正确性修复低基数字典优化在 FE 侧由 AddDecodeNodeForDictStringRule.java 及 lowcardinality 包支撑。它带来显著性能收益的同时也要求使用者注意副本一致性、写删交错等边界场景。湖仓一体萌芽Hive on S3 外部表实验特性在 2.0.0 引入、2.0.1 明确 S3 访问依赖需要单独部署 jarFE 侧 HiveTable.java 已勾勒出资源 → 外部表 → Catalog的演进雏形为后续版本完善的湖仓分析能力奠定基础。十一、升级与使用建议基于 2.0 各版本的修复内容与升级建议给出以下实践要点务必升级到 2.0.5 或更高版本2.0.5 官方明确建议尽早升级其修复的 BE 失败数据丢失、DELETE 后低基数查询错误、DOUBLE/VARCHAR JOIN 结果错误均属于数据正确性问题生产环境最终落到 2.0.9作为 2.0 系列收官版本2.0.9 修复了 Broker Load 心跳超时数据丢失、同源 HDFS 文件并发加载互相干扰等问题是 2.0 线上环境的最稳选择关注 FE 元数据与内存参数label_keep_max_num2.0.2 引入可缓解高频导入下 FE 的 Full GC 压力exec_mem_limit控制导入时每个 BE 的内存上限在导入 OOM 排查时应优先检查其是否生效主键表导入 OOM 与 Schema 变更风险2.0 早期主键表存在导入 OOM2.0.1 修复与 Schema 变更后 duplicate key 报错2.0.6 修复使用主键表做实时更新前请确认所在版本已包含对应修复Hive on S3 外部表需手动部署依赖二进制包不含 S3 访问 jar部署前需按 2.0.1 行为变更说明补齐避免线上查询失败低基数优化相关查询需回归验证涉及多次 DELETE 后查询、低基数谓词与其他谓词混用的 SQL在升级后建议做结果正确性回归。StarRocks 2.0 通过主键表 GA 外部表起步 存储层下推 内存重构四大动作完成了从 OLAP 查询引擎向实时 湖仓双能力引擎的关键一跳其后的每个补丁版本都在为这一跳的稳定落地持续加固这也是理解 StarRocks 后续版本演进逻辑的重要起点。【免费下载链接】starrocksThe worlds fastest open query engine for sub-second analytics both on and off the data lakehouse. With the flexibility to support nearly any scenario, StarRocks provides best-in-class performance for multi-dimensional analytics, real-time analytics, and ad-hoc queries. A Linux Foundation project.项目地址: https://gitcode.com/GitHub_Trending/st/starrocks创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考