极速查询：StarRocks 存算分离 Compaction 原理 & 调优指南

StarRocks 在数据摄入过程中，每次操作都会创建一个新的数据版本。在查询时，为了得到准确的结果，必须将所有版本合并。然而，随着历史数据版本的累积，需要合并的文件数量增多，这将显著降低查询效率。为了解决这个问题，StarRocks 会定期执行内部任务，通过合并历史数据版本来消除重复记录，这个过程被称为 Compaction。

举个例子：下图中 version 1 和 version 2 数据文件进行 Compaction 后，消除了 version 1 中的旧版本数据（id = 2, value = 11, id = 5, value = 30），最终生成了新的数据版本文件 version 3。

从上述说明可以看出，Compaction 是将不同版本的数据文件合并成大文件的过程，旨在减少系统中小文件数量、从而提升查询效率。相比于存算一体表，StarRocks 存算分离实现了新的 Compaction 调度机制，具有以下特点：

如前所述，每次导入都会在 FE 内生成一个新版本，而该版本被标记在 Partition 之上。一旦导入事务成功提交，便会更新 Partition 的可见数据版本号，Partition 的数据版本号单调递增。

需要注意的是，一个 Partition 内可能存在多个 Tablet，这些 Tablet 都共享相同的数据版本号，即使一次导入可能只涉及其中部分 Tablet，一旦导入事务成功提交，Partition 下所有的 Tablet 的版本都会相应地得到提升。

StarRocks 存算分离表 Compaction 由两个角色组成：调度者（Compaction Scheduer）和执行者（Compaction Executor）。调度者通过 RPC 发起 Compaction 任务（Compaction Job），而执行者负责执行 Compaction Job。

在 StarRocks 存算分离中，FE 作为 Compaction Scheduler，而 BE 或者 CN 都作为 Compaction Executor。每个 Compaction Executor 内都存在一个线程池专门用于执行 Compaction Job。

Compaction Scheduer 调度

FE 上存在一个周期性运行线程 Compaction Scheduler，负责调度发起所有的 Compaction Task。FE 以 Partition 为调度的基本单位。

FE 上掌握了每个 Partition 的 Compaction Score 信息，该信息用来表示 Partition 内所有 Tablet 的需要进行 Compaction 的优先级，Compaction Score 越高，表示 Partition 需要合并的紧急程度越高。

每次 Compaction Scheduler 线程运行时，会挑选出当前 Compaction Score 最高的 Partition，并为这些 Partition 构造 Compaction Task。当然，Compaction Scheduler 也会控制每次最多发起的 Compaction Task 数量。

构造 Compaction Task 的逻辑相对比较简单，对于每个 Partition，Scheduler 会获得其所有的 Tablet，然后为每个 Compute Node （CN）构造一个 Compaction Task，Task 内包含需要在该 CN 上执行 Compaction 任务的 Tablet 列表，然后发送 Task 给 CN 节点。

在上图中，FE 上存在两个 Partition 需要执行 Compaction，分别为 Partition X 和 Partition Y。Partition X 内含4个 Tablet（1 ~ 4），而 Partition Y 内含3个 Tablet（5~7）。

Partition X 内，Tablet-2 和 Tablet-4 位于相同的 CN-1，而 Tablet-1 和 Tablet-3 位于相同的 CN-2，于是为 Partition X 构造了两个 Compaction Task（Task-1 与 Task-2），其中 Task-1 内包含 Tablet-2 和 Tablet-4，而 Task-2 内包含 Tablet-1 和 Tablet-3。

Partition Y 内，Tablet-5 和 Tablet-7 位于相同的 CN-1，而 Tablet-6 位于另外一个CN-2，于是为 Partition Y 也构造了两个 Compaction Task（Task-3 与 Task-4），其中 Task-3 内包含 Tablet-5 和 Tablet-7，而 Task-4 内包含 Tablet-6。

目前 StarRocks 存算分离表使用了数据多版本技术，整体上的存储结构如下图所示：

观察上例并思考可知，如果系统在运行过程中一直不会进行 Compaction。那么系统中的数据文件永远也无法被删除。试想上例中我们可以将 Tablet Meta V1，Tablet Meta V2 文件删除，但我们无法删除 file-1、file-2、file-3 以及 file-4，因为这些文件依然被 Tablet Meta V3 所引用。

但有了数据合并（Compaction）后，情况就变得不一样了。上例中，由于发生了一次 Compaction（上图中的 Compact Txn 4），将 file-1、file-2、file-3、file-4 合并生成了新文件 file-6 并生成了新的 Tablet Meta V4。由于 file-1 至 file-4 中的内容已经在 file-6 中存在，所以当版本 V1、V2、V3 不再被访问，file-1 至 file-4 便可以被安全删除。此时的数据版本情况如下图所示：

因此，综合上面的讨论，我们可以发现，只有在 Compaction 完成后原始的数据文件方可被删除。因而，判断数据文件能否安全删除的最直观的规则是：该数据文件不再被任何 Tablet Meta 所引用。

查看分区的 Compaction score

StarRocks 在内部为每个分区（Partition) 维护了一个 Compaction Score 值，它反映了分区当前数据文件合并情况，Compaction score 越高，代表了数据文件合并程度越低。

StarRocks 提供了命令可查看 Partition 当前的 Compaction Score，FE 会以此作为发起 Compaction 任务的参考，用户也可以此作为判断当前 Partition 是否存在版本数过多的依据：

自从新版本 3.1.9 & 3.2.4 ，我们在系统表中增加了 partitions_meta 表，方便用户通过各种复杂 SQL 来查看系统所有 Partition 信息：

查看 Compaction 任务

首先，用户可以通过如下命令来观察系统当前所有 Compaction 任务的整体情况：

取消 Compaction 任务

参数调优

FE 参数

FE 所有上述 Compaction 相关参数均可通过 SQL 命令动态修改，例如：

BE / CN 参数

最佳实践

关于 StarRocks

Linux 基金会项目 StarRocks 是新一代极速全场景 MPP 数据库，遵循 Apache 2.0 开源协议。

面世三年来，StarRocks 致力于帮助企业构建极速统一的湖仓分析新范式，是实现数字化转型和降本增效的关键基础设施。目前，全球 380 家以上市值超过 70 亿元人民币的顶尖企业选择用 StarRocks 来构建新一代数据分析能力，这些企业包括腾讯、携程、平安银行、中原银行、中信建投、招商证券、大润发、百草味、顺丰、京东物流、TCL、OPPO 等。StarRocks 也已经和全球云计算领导者亚马逊云、阿里云、腾讯云等达成战略合作关系。

StarRocks 全球开源社区也正飞速成长。目前，StarRocks 的 GitHub star 数已达 8100，吸引了超过 350 位贡献者和数十家国内外行业头部企业参与共建，用户社区也有过万人的规模。凭借其卓越的表现，StarRocks 荣获了全球著名科技媒体 InfoWorld 颁发的 2023 BOSSIE Award 最佳开源软件奖项。