前言
StarRocks 存算分离支持使用各种外部独立存储系统来存储业务数据，而很多对象存储服务会根据存储容量收费（如 AWS S3、OSS 等），因此，我们需要特别关注实际存储在对象存储上数据容量。
我们从个别用户处得到反馈，对象存储的实际使用量相比真实表数据量有膨胀，本文档会解释可能产生容量膨胀的原因以及提供对应的清理方法。
容量检查
StarRocks 存算分离新架构使用采用数据多版本技术，每次导入会产生新的数据版本，用户通过对象存储观察到存储空间使用是所有历史版本的容量之和，而用户通过 show data 查看到的则是当前最新版本的数据容量，这两者之间可能存在一些差异，这属于正常现象。
首先，可通过 show data 命令可以看到集群的各个表以及数据库的容量，如下：
mysql> show data;+-------------+----------------+---------------------+| TableName | Size | ReplicaCount |+-------------+----------------+---------------------+| store_sales | 133.351 GB | 256 || Total | 133.351 GB | 256 || Quota | 8388608.000 TB | 9223372036854775807 || Left | 8388607.870 TB | 9223372036854775551 |+-------------+----------------+---------------------+4 rows in set (0.17 sec)
复制代码
然后通过如下命令确认该表在 S3 上的存储路径：
mysql> show proc '/dbs/tpcds_1t';+---------+-------------+----------+---------------------+--------------+--------+--------------+--------------------------+--------------+---------------+------------------------------------------------------------------------------------------------------------+| TableId | TableName | IndexNum | PartitionColumnName | PartitionNum | State | Type | LastConsistencyCheckTime | ReplicaCount | PartitionType | StoragePath |+---------+-------------+----------+---------------------+--------------+--------+--------------+--------------------------+--------------+---------------+------------------------------------------------------------------------------------------------------------+| 10081 | store_sales | 1 | NULL | 1 | NORMAL | CLOUD_NATIVE | NULL | 256 | UNPARTITIONED | s3://starrocks-common/skr2veiad-jeff-test-1709792626564/d256bc54-08e0-495b-826e-3b12d97ae455/db10079/10081 |+---------+-------------+----------+---------------------+--------------+--------+--------------+--------------------------+--------------+---------------+------------------------------------------------------------------------------------------------------------+1 row in set (0.18 sec)
复制代码
StoragePath 字段清晰地显示了该表在 S3 上的路径：
s3://starrocks-common/skr2veiad-jeff-test-1709792626564/d256bc54-08e0-495b-826e-3b12d97ae455/db10079/10081
复制代码
最后我们通过如下命令检查对象存储上实际容量（以 AWS S3 为例说明，其他的对象存储服务提供商一般也会提供类似的命令）：
aws s3 ls s3://starrocks-common/skr2veiad-jeff-test-1709792626564/d256bc54-08e0-495b-826e-3b12d97ae455/db10079/10081/ --summarize --recursive --human-readable
2024-03-08 14:28:16 1.2 KiB skr2veiad-jeff-test-1709792626564/d256bc54-08e0-495b-826e-3b12d97ae455/db10079/10081/10080/SCHEMA_00000000000027622024-03-08 14:49:39 533.5 MiB skr2veiad-jeff-test-1709792626564/d256bc54-08e0-495b-826e-3b12d97ae455/db10079/10081/10080/data/0000000000000005_01c7761a-b5e1-4376-8355-a7f6c7ae10b5.dat...2024-03-08 14:53:10 2.5 KiB skr2veiad-jeff-test-1709792626564/d256bc54-08e0-495b-826e-3b12d97ae455/db10079/10081/10080/meta/0000000000002862_0000000000000003.meta
Total Objects: 513 Total Size: 133.4 GiB
复制代码
可以看到，系统正常运行时，实际的对象存储相比数据容量（133.4 GB VS 133.35 GB），几乎无膨胀。
膨胀原因
在某些用户处有时候会观察到对象存储实际使用量比 show data 看到的容量要高出不少，可能由以下原因造成：
用户删除表后，但对象存储上数据并未真正删除，这里也可能有几个原因
没有使用 drop table force，导致删除表并未真正执行数据物理删除，表信息还在回收站中
对象存储删除文件是一个比较耗时的动作，可能删除表时实际删除对象存储文件出现超时，导致删除失败
其他原因导致删除失败（例如我们观察到某些用户由于权限配置不当问题造成数据删除失败）
2. 老版本中未自动清理导入或 Compaction 失败时遗留的垃圾数据
3. Compaction 不及时导致老版本数据文件未能被及时合并和回收
需要说明的是，由于后台清理也需要时间，因此，show data 看到的数据量和对象存储实际数据量并不是马上就会一致，这需要一定的时间来清理。
清理方法
针对上面的每种可能原因，这里给出相应的处理办法。
表或分区已删除但数据未删除
这里建议首先编写脚本扫描出那些占据对象存储空间大部分容量的子目录，然后按照下面的方法逐个处理。然后，根据路径信息按照以下方式解析出 Table id、Partition id 等。
老版本(3.1.3 以及之前的版本)表数据的存储路径按照如下格式组织:
s3://${bucket_name}/${prefix}/${cluster_id}/${table_id}/
复制代码
用户可以解析出 Table id。
中间版本中(3.1.4 以及 3.2.0 后)表数据的存储路径按照如下格式组织：
s3://${bucket_name}/${prefix}/${cluster_id}/${table_id}/${partition_id}/
复制代码
用户可以解析出 Table id 和 Partition id。
最新版本（3.1.8 及 3.2.3 后）中表数据的存储路径按照如下格式组织：
s3://${bucket_name}/${prefix}/${cluster_id}/db{dbid}/${table_id}/${partition_id}
复制代码
用户可以解析出 DB id、Table id 以及 Partition id。
然后，用户可以根据解析出相应的 DB id、Table id、Partition id 等信息，然后在系统中查询该 Table、Partition 等是否存在，如果不存在，可以安全地删除对象存储上的数据（直接使用对象存储的命令行工具物理删除即可）。
失败任务残留的垃圾数据
当导入或者后台 Compaction 任务由于种种原因失败时，在对象存储中可能会产生垃圾文件，老版本中未能清理这些文件也可能会产生垃圾。此时，可利用我们提供的手动清理脚本工具来协助清理这些垃圾文件，使用方法可参考：
StarRocks 存算分离垃圾数据清理工具使用手册starrocks.feishu.cn/docx/Qah6d6hXZo3yWrx9iGicw2a6njd
需要特别说明的是，在新版本中（3.1.8 和 3.2.3 开始）我们已经增加了任务失败时的自动清理机制，建议用户升级至新版本。
Compaction 不及时
当前只有在小文件被 Compaction 合并生成大文件后，历史版本的小文件才可以被安全清理，因此，如果后台的 Compaction 任务不及时，也可能会造成历史数据清理的延误，因此，我们建议日常需要重点关注 Compaction 任务的执行情况，为此，我们也提供了丰富的观测手段，具体可参考：
StarRocks 存算分离 Compaction 运维手册starrocks.feishu.cn/docx/GvgmdyK03olcFoxCs7rcHjKVnod
其他
如果上述手段未能帮您处理对象存储实际容量膨胀问题，那么可以直接去论坛反馈。
评论