前言
大家已经了解，StarRocks的更新模型、主键模型等在Flush和Compaction过程中会产生历史版本数据，这些垃圾数据需要及时被清理，以防止存储空间浪费。而StarRocks在存算分离部署下，用户一般都会选择对象存储作为底层存储。对象存储是按照空间使用计费，且延迟比起本地盘更高，删除操作也相对更重，所以高效的垃圾清理机制显得尤为重要。本文简单介绍存算分离StarRocks的垃圾清理（Vacuum）实现，以及给出部分监控和调优实践。
FE调度Vacuum
FE以分区为粒度调度Vacuum线程。该调度线程池的大小由参数lake_autovacuum_parallel_partitions决定，默认值为8，即默认最多同时有8个分区发起垃圾清理。然后，FE会筛选出所有云原生表和物化视图，并按以下规则选取需要清理的分区：
- 分区不为空（即版本号大于1），且最新版本时间距离当前时间不多于
lake_autovacuum_stale_partition_threshold（默认值12）小时，即在该区间内发生过写入； - 分区上一次被清理的时间距离当前时间超过
lake_autovacuum_partition_naptime_seconds（默认值180）秒。
对于符合条件的分区，首先从存算分离的WarehouseManager组件获取分区Tablet及对应CN节点的映射信息，然后为每个(CN, List<TabletID>)对，构造VacuumRequest请求。为了防止耗时较长的查询执行过程中历史版本被清理导致失败，VacuumRequest请求也涉及两个控制清理积极性的参数：
-
lake_autovacuum_grace_period_minutes，表示该时间区间内的历史版本不清理，单位为分钟，默认值为30。此值应大于查询超时query_timeout； -
lake_autovacuum_max_previous_versions，表示保留多少个历史版本不清理，默认值为0。
可见，如果从对象存储观察到的实际占用量比SHOW DATA命令看到的大小多一些，属于正常现象，特别是对于Stream Load / Routine Load持续写入的表。例如笔者前期进行实验的一张大主键表，每小时发生1亿多次更新，在解除积压阶段，OSS空间和SHOW DATA空间的差异最大可有约100G。积压解除后的平稳写入阶段，两者的差异可缩小到20G以内。
FE通过BRPC向CN节点发起VacuumRequest，后续由CN节点进行处理。
CN执行Vacuum
CN节点上也有一个线程池接收Vacuum动作，称为vacuum_thread_pool。该线程池的大小由参数release_snapshot_worker_count决定，默认值为5，即默认最多同时有5个分区执行垃圾清理。待清理的分区会先放到一个unordered_set集合中，避免重复执行。
接下来CN筛选Vacuum请求中的每个Tablet，并删除垃圾文件：
- 扫描所有无效的版本号（即根据上文
lake_autovacuum_grace_period_minutes和lake_autovacuum_max_previous_versions计算出的版本区间）； - 通过Tablet Metadata获取已经执行完Compaction的Rowset集合，以及没有引用的文件（即所谓Orphan File）集合；
- 通过
AsyncFileDeleter组件对数据目录（data）和元数据目录（meta）执行异步清理，同时将无效的元数据从Metadata Cache中移除。为了降低请求频率，AsyncFileDeleter的删除批次的最小值可由参数lake_vacuum_min_batch_delete_size控制，默认值为100。 - 同时遍历事务日志目录（
log），将所有事务ID小于当前最小活动事务ID的日志一并删除。
最后，CN收集Vacuum过程中的统计信息，将响应VacuumResponse消息发回FE。正常情况下FE会输出日志：
2024-07-28 11:34:37.433+08:00 INFO (autovacuum-pool1-t1|3810) [AutovacuumDaemon.vacuumPartitionImpl():208] Vacuumed some_db.some_table.10669 hasError=false vacuumedFiles=1309 vacuumedFileSize=125648700 visibleVersion=30429 minRetainVersion=30429 minActiveTxnId=108885 cost=4731ms
可以通过存算分离监控面板中的Vacuum Deletes折线图观察垃圾清理的QPS、均值和TP99指标。
Vacuum监控与调优
如果对象存储的空间占用和实际占用量差距很大，首先应该排除写入频率和Compaction的问题。如果Stream Load攒批参数设置正确，且Compaction的调度和Score都正常，则应观察以下两个Vacuum监控指标：
-
lake_vacuum_queued_delete_file_tasks：积压的清理任务数，如果居高不下，说明清理不及时； -
lake_vacuum_metadata_travel_latency：遍历元数据文件的时延，meta目录下文件越多，时延越长。
官方提供的Dashboard中默认没有这两个指标，可以自行添加。
建议同时观察OSS Bucket的监控，如果请求数距离单个Bucket的阈值仍然比较宽松，且CN节点的CPU利用率有空闲，则可以调大Vacuum的频率：
-- FE
lake_autovacuum_parallel_partitions = 12
lake_autovacuum_stale_partition_threshold = 24
lake_autovacuum_partition_naptime_seconds = 120
-- CN
release_snapshot_worker_count = 12
lake_vacuum_min_batch_delete_size = 50
特别需要注意，如果同一个存算分离集群同时写多个存储卷上的多个表，且它们的负载不均匀，很有可能造成多个Bucket的存储空间同时膨胀，因为这些表的Vacuum线程池是共享的。建议在规划集群时提前考虑这点，并且预先调整上述参数，防患于未然。
相反地，如果FE日志出现类似Delete objects error: Reduce your request rate的报错，说明Vacuum太过频繁，应适当降低频率。
The End
感谢StarRocks社区大佬的鼎力支持。
大家午安。
