kai_ding的专栏

StarRocks 存算分离新架构使用采用数据多版本技术，每次导入会产生新的数据版本，用户通过对象存储观察到存储空间使用是所有历史版本的容量之和，而用户通过 show data 查看到的则是当前最新版本的数据容量，这两者之间可能存在一些差异，这属于正常现象。然后，用户可以根据解析出相应的 DB id、Table id、Partition id 等信息，然后在系统中查询该 Table、Partition 等是否存在，如果不存在，可以安全地删除对象存储上的数据（直接使用对象存储的命令行工具物理删除即可）。

StarRocks存算分离表中，垃圾回收是为了删除那些无用的历史版本数据，从而节约存储空间。考虑到对象存储按照存储容量收费，因此，节约存储空间对于降本增效尤为必要。用户手动执行了删除库、表、分区等命令，如执行了 drop table、drop database 以及 drop partition 等命令随着系统内 Compaction 任务不断进行，合并之前的数据文件可以被安全回收目前在 StarRocks 的存算分离表存储在对象存储上的文件类型包含如下几种：Segment 文件。

StarRocks 中每次数据摄入都会生成一个新的数据版本，而查询时需要将所有版本数据进行合并才能获得一个正确的结果，如果历史数据版本太多，那么查询时需要读取的文件数也会很多，造成查询效率低下。因而 StarRocks 存在内部任务定期将历史数据版本进行整合，消除重复数据记录，我们称之为 Compaction。Compaction 是为了将不同版本的数据文件进行整合，合并成大文件的动作，减少系统中小文件数量，进而提升查询效率。Compaction 调度由 FE 发起，BE执行。

StarRocks 存算分离模式架构中，数据导入后，会被写入远端对象存储。而对象存储由于其访问延迟较高特性，如果没有任何优化，每次查询直接访问后端对象存储，那么性能就会变得非常差，也就失去了 StarRocks 的性能优势。一般而言，在存算分离架构下需要在计算节点上使用本地磁盘来缓存系统经常访问的热点数据，这样，当查询访问到这些数据时，直接访问本地磁盘中的缓存即可，可以提供与存算一体架构同等的查询性能。

使用 StarRocks 存算分离功能的同学可能之前常常被 DDL （常见的如增加列等）所困扰，主要在于 DDL 的执行时间过长并可能由此引发的一系列问题（如超时失败等），用户可能有时候不得不采用其他方式来替代（如按照新的 Schema 来重建表并重新导入数据）。幸运的是，在 3.3.0 版本中即将推出的 Fast Schema Evolution 能力让这一困扰我们许久的问题彻底变为历史。

快速解决你在集群管理中遇到的问题！

除此之外，对于某些导入模型，例如 Routine Load，我们还可以降低 Job 的并发 Task 数量来降低对象存储的写入频率，我们可以观察 BE 日志中每个 Task 的单次 KafKa 消费数据量，如果发现量较小，那我们就可以降低 并发 Task 数量来降低对象存储写入次数。由于 StarRocks 使用了多版本存储机制，用户通过 show data 命令看到的表的大小与表实际在对象存储可能会有所差距，因此，我们建议用户应当特别关注在对象存储上实际占据的存储容量。