StarRocks 存算分离集群 Compaction 管理与监控完全指南【免费下载链接】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本文围绕 StarRocks 存算分离Shared-data架构下的 Compaction 机制展开系统讲解 Compaction Score 的含义与计算规则、FE 统一调度的 Compaction 工作流、分数与任务的多视角监控手段、FE/CN 关键参数调优、手动触发与取消任务的方法以及慢查询、分数过高两类典型问题的排查路径。读完本文你将能够独立监控分区合并进度、定位 Compaction 卡顿根因并基于源码理解每个参数与监控指标背后的实现原理。Overview为什么存算分离集群需要 Compaction在 StarRocks 中每一次数据导入loading都会为表生成一个新版本的数据文件。随着写入持续进行一个分区内会累积大量小文件文件数量多、单文件数据量小会导致查询时需要打开与扫描大量文件元数据膨胀查询效率随之下降。Compaction 的作用就是把来自不同版本的数据文件合并为更大的文件从而减少小文件数量降低查询时的文件打开与扫描开销让同一分区内的数据文件大小分布更加均匀提升查询效率为后续的版本清理vacuum与远端存储空间回收创造条件。在存算分离集群中数据文件存放在远端对象存储上合并操作在 Compute NodeCN上执行并由 FrontendFE统一调度这与存算一体集群由 BE 本地自行调度 Compaction 的模式有本质区别。Compaction Score衡量分区合并进度的核心指标概念与判定阈值Compaction Score 反映一个分区内数据文件的合并进度分数越高说明合并进度越低、尚未合并的数据文件版本越多。FE 会为每个分区维护 Compaction Score 信息其中最关键的是Max Compaction Score分区内所有 Tablet 中分数的最大值。围绕 Compaction ScoreStarRocks 定义了三个关键判定阈值阈值判定含义FE 参数lake_compaction_score_selector_min_score默认 10分区的 Max Compaction Score 低于该值时Compaction 视为完成不再调度FE 参数lake_ingest_slowdown_threshold默认 100Max Compaction Score 超过该值时系统会降速该分区的数据导入事务提交FE 参数lake_compaction_score_upper_bound默认 2000Max Compaction Score 超过该值时系统会拒绝该分区的导入事务也就是说Max Compaction Score 低于 10 表示健康超过 100 即进入不健康状态并触发写入降速超过 2000 则直接拒绝新写入防止小文件无限膨胀拖垮查询性能。从源码看这三个参数都定义在 Config.java 中并且是mutable true的动态配置。其中写入降速还有一个配套开关lake_enable_ingest_slowdown默认true以及降速力度参数lake_ingest_slowdown_ratio默认 0.1分数每超过阈值 1 点导入耗时按该比例递增延迟例如正常导入 10 分钟、超阈值 5 点时会额外延迟约10 分钟 × 0.1 × 5 5 分钟。此外lake_ingest_slowdown_threshold的实际生效值取配置值与lake_compaction_score_selector_min_score两者中的较大者。计算规则Compaction Score 的计算遵循以下规则通常情况下每个数据文件贡献 1 分。例如一个分区只有 1 个 Tablet第一次导入生成了 10 个数据文件则该分区的 Max Compaction Score 为 10。一个事务在某个 Tablet 内产生的所有数据文件被归为一组称为Rowset。计算分数时Tablet 的 Rowsets 会按大小分组文件数最多的一组决定该 Tablet 的 Compaction Score。举例说明一个 Tablet 经历了 7 次导入生成的 Rowset 大小分别为 100 MB、100 MB、100 MB、10 MB、10 MB、10 MB、10 MB。计算时系统会把 3 个 100 MB 的 Rowset 分成一组、4 个 10 MB 的 Rowset 分成另一组Compaction Score 取文件数更多的一组——即第二组4 个文件分数更高。Compaction 优先处理分数高的组因此第一次合并后Rowset 分布会变为100 MB、100 MB、100 MB 和一个合并后的 40 MB。这种按大小分桶、取桶内文件数的设计保证了分数能够真实反映文件数量压力而非数据量压力从而让调度器优先合并小文件堆积严重的分区。从源码看分数统计最终以Quantiles对象包含 avg / p50 / max 三个统计值的形式保存在 FE 的PartitionStatistics中见 PartitionStatistics.java 与 Quantiles.java。FE 在事务发布publish完成后调用CompactionMgr.handleLoadingFinished()更新分数调度器再据此决定是否对该分区发起新一轮合并。Compaction WorkflowFE 统一调度的六步流水线与存算一体架构不同存算分离集群引入了FE 控制的 Compaction 机制完整流程如下Score 计算Leader FE 节点根据事务发布结果计算并存储各分区的 Compaction Score。候选选择FE 选出 Max Compaction Score 最高的分区作为 Compaction 候选。任务生成FE 为选中的分区发起 Compaction 事务生成 Tablet 级子任务并分发给各 CN直到达到 FE 参数lake_compaction_max_tasks限定的并发上限。子任务执行CN 在后台执行 Compaction 子任务每个 CN 的并发子任务数由 CN 参数compact_threads控制。结果收集FE 汇总各子任务结果提交 Compaction 事务。发布FE 发布提交成功的 Compaction 事务新版本对查询可见。这套流水线在源码中有清晰对应调度器主体是 CompactionScheduler.java它继承自Daemon以 1 秒为周期LOOP_INTERVAL_MS 1000L循环执行只有 Leader FE 且 edit log 回放完成后才会真正调度新任务。候选选择由 ScoreSelector.java 实现它会过滤掉没有分数、被禁用的表/分区且只有当分区的nextCompactionTime已到并且compactionScore.getMax() minScore时才入选手动触发priority 非 DEFAULT时则跳过分数与时间检查立即调度。任务并发上限、超时等控制参数同样定义在 Config.java 所读取的 FE 配置中例如lake_compaction_default_timeout_second默认 86400 秒即 1 天、lake_compaction_allow_partial_success默认 true允许部分 Tablet 失败时仍提交成功、lake_compaction_history_size默认 20控制SHOW PROC /compactions历史记录条数。查看 Compaction Score通过 SHOW 语句查看有两种方式查看指定表的各分区 Compaction ScoreSHOW PARTITIONS FROM table_name SHOW PROC /dbs/database_name/table_name/partitions示例输出摘自SHOW PROC /dbs/load_benchmark/store_sales/partitions------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | PartitionId | PartitionName | CompactVersion | VisibleVersion | NextVersion | State | PartitionKey | Range | DistributionKey | Buckets | DataSize | RowCount | CacheTTL | AsyncWrite | AvgCS | P50CS | MaxCS | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | 38028 | store_sales | 913 | 921 | 923 | NORMAL | | | ss_item_sk, ss_ticket_number | 64 | 15.6GB | 273857126 | 2592000 | false | 10.00 | 10.00 | 10.00 | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------日常巡检时一般只需关注MaxCS字段MaxCS低于 10Compaction 视为完成MaxCS超过 100分数偏高需要留意MaxCS超过 500分数很高可能需要人工干预。通过系统视图查询也可以查询系统视图information_schema.partitions_meta获得全集群范围的分数概览SELECT * FROM information_schema.partitions_meta ORDER BY Max_CS LIMIT 10;该视图每个分区一行关键列包括DB_NAME、TABLE_NAME、PARTITION_NAME、COMPACT_VERSION、VISIBLE_VERSION、BUCKETS、DATA_SIZE、ROW_COUNT、AVG_CS、P50_CS、MAX_CS以及STORAGE_PATH远端存储路径。示例中tpcds_1t库下各表分区的MAX_CS均为 0说明合并进度健康。相比SHOW PROC该视图适合对多个数据库、多张表做批量排序筛选例如快速找出全集群分数最高的前 10 个分区。查看 Compaction 任务数据持续导入期间FE 会不断把 Compaction 任务调度到不同 CN 上执行。建议先在 FE 侧查看任务总体状态再下钻到 CN 侧查看每个任务的执行细节。查看任务总体状态FE 侧SHOW PROC /compactions;示例输出---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | Partition | TxnID | StartTime | CommitTime | FinishTime | Error | Profile | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ssb.lineorder.10081 | 15 | 2026-01-10 03:29:07 | 2026-01-10 03:29:11 | 2026-01-10 03:29:12 | NULL | {sub_task_count:12,read_local_sec:0,read_local_mb:218,read_remote_sec:0,read_remote_mb:0,read_segment_count:120,write_segment_count:12,write_segment_mb:219,write_remote_sec:4,in_queue_sec:18,score_before:{avg:10.0,p50:10.0,max:10.0},score_after:{avg:8.0,p50:8.0,max:8.0},partial_success:false} | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------各字段含义如下PartitionCompaction 任务所属分区。TxnIDCompaction 任务对应的事务 ID。StartTime任务开始时间NULL表示尚未发起。CommitTime任务提交数据的时间NULL表示数据尚未提交。FinishTime任务发布数据的时间NULL表示数据尚未发布。Error任务错误信息如有。Profile自 v3.2.12 与 v3.3.4 起支持任务完成后的 Profile其中sub_task_count分区内子任务数等价于 Tablet 数read_local_sec/read_local_mb所有子任务从本地缓存读取数据的总耗时秒与总大小MBread_remote_sec/read_remote_mb所有子任务从远端存储读取数据的总耗时秒与总大小MBread_segment_count所有子任务读取的文件总数write_segment_count/write_segment_mb所有子任务生成的新文件总数与总大小MBwrite_remote_sec所有子任务写远端存储的总耗时秒in_queue_sec所有子任务在队列中等待的总时长秒score_before/score_after合并前后分区的 Compaction Score均含avg、p50、max三个字段partial_successCompaction 任务是否部分成功部分 Tablet 失败。查看任务执行细节CN 侧information_schema.be_cloud_native_compactions中的每一行代表一个 Tablet 级 Compaction 执行单元。当启用 Tablet 并行合并时每个并行子任务会以相同的事务 ID 与 Tablet ID、但不同的SUBTASK_ID单独返回一行并行合并的聚合上下文只是聚合产物而非执行单元不会出现在该视图中。该视图由 FE 侧系统表 BeCloudNativeCompactionsSystemTable.java 实现。示例查询SELECT BE_ID, TXN_ID, TABLET_ID, VERSION, SKIPPED, RUNS, START_TIME, FINISH_TIME, PROGRESS, STATUS, PROFILE FROM information_schema.be_cloud_native_compactions;示例输出------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | BE_ID | TXN_ID | TABLET_ID | VERSION | SKIPPED | RUNS | START_TIME | FINISH_TIME | PROGRESS | STATUS | PROFILE | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | 10001 | 51047 | 43034 | 12 | 0 | 1 | 2024-09-24 19:15:15 | NULL | 82 | | {read_local_sec:0,read_local_mb:31,read_remote_sec:0,read_remote_mb:0,read_remote_count:0,read_local_count:1900,segment_init_sec:0,column_iterator_init_sec:0,in_queue_sec:0} | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------各字段含义BE_ID执行子任务的 CNBEID。TXN_ID子任务所属事务 ID。TABLET_ID子任务所属 Tablet ID。VERSIONTablet 的版本号。RUNS子任务已执行的次数。START_TIME/FINISH_TIME子任务开始/结束时间。PROGRESSTablet 合并进度百分比。STATUS子任务状态出错时错误信息会显示在此字段。PROFILE自 v3.2.12 与 v3.3.4 起支持子任务运行时 Profile含read_local_sec、read_local_mb、read_remote_sec、read_remote_mb、read_local_count、read_remote_count、in_queue_sec等字段。SUBTASK_ID从 0 开始的并行子任务 ID普通非并行 Tablet 任务该字段为NULL。BE_ID、TXN_ID、TABLET_ID相同但SUBTASK_ID不同的多行是同一个 Tablet 合并的并行执行单元。全链路 Profile 字段纳米级计账自 v3.2.12 与 v3.3.4 起子任务PROFILE中的全链路字段采用纳秒单位精确计账可分为四类Profile 状态profile_final任务运行中为false结束后为true。实时 Profile 会把当前尝试已耗时间计入task_total_ns进入执行器后再计入task_execute_ns其他阶段计时器在其作用域退出时才更新因此实时 Profile 中task_unaccounted_ns可能暂时偏大。任务外壳Task envelopequeue_wait_ns从进入 CN Compaction 队列到工作线程开始执行的时间不计入task_total_ns。task_prepare_ns选择输入 Rowset、加载 Tablet 元数据、构造 Compaction 任务的时间。task_execute_ns在横向horizontal、纵向vertical或索引indexCompaction 执行器内的墙钟时间实时 Profile 含当前执行器的已耗时间。task_total_ns从 CN 工作线程开始任务准备到 Profile 快照或任务返回的墙钟时间。task_accounted_ns所有互不重叠的顶层阶段之和。task_unaccounted_nstask_total_ns - task_accounted_ns数值偏大说明存在未计账的阶段或调度/运行时开销。互不重叠的执行阶段input_prepare_ns、reader_prepare_ns、reader_open_ns、reader_get_next_ns、reader_close_ns、chunk_transform_ns、writer_create_ns、writer_open_ns、writer_write_ns、writer_flush_ns、writer_finish_ns、writer_close_ns、mask_io_ns、txn_log_build_ns、pk_sst_merge_ns、txn_log_write_ns、preload_compaction_state_ns、tablet_write_log_ns。嵌套的 Reader 明细read_remote_ns、read_local_ns、create_segment_iter_ns、segment_init_ns、column_iterator_init_ns、block_load_ns、block_fetch_ns、block_seek_ns、decompress_ns、decode_dict_ns以及 delete-vector / filter 相关计时器。这些字段用于解释 reader 阶段内部耗时不能再累加进task_accounted_ns。纵向合并明细column_group_count、vertical_key_group_ns、vertical_value_group_ns。分组时间与 reader/writer 阶段存在重叠仅作诊断用途不可相加。任务结束后同一份单 Tablet Profile 会连同 Tablet ID、事务 ID、状态、表 ID、分区 ID 一起写入 CN 的 INFO 日志即使该行随后从be_cloud_native_compactions中消失也能保留按 Tablet 粒度的 Profile 记录供事后分析。配置 Compaction 任务Compaction 任务可通过 FE 参数与 CNBE参数两类配置项进行调优。FE 参数动态生效ADMIN SET FRONTEND CONFIG (lake_compaction_max_tasks -1);lake_compaction_max_tasks默认值-1类型Int是否动态是说明存算分离集群中允许的最大并发 Compaction 任务数。设为-1表示自适应计算并发数即存活 CN 节点数 × 16设为0则完全禁用 Compaction。引入版本v3.1.0ADMIN SET FRONTEND CONFIG (lake_compaction_disable_tables 11111;22222);lake_compaction_disable_tables默认值类型String是否动态是说明禁用某些表的 Compaction不影响已经开始的任务值为表 ID多个值以;分隔。引入版本v3.2.7从源码看该参数在 Config.java 中实际对应字段lake_compaction_disable_idslake_compaction_disable_tables是其别名注释明确说明表 ID 与分区 ID 均支持格式为id1;id2。禁用 ID 集合会被CompactionScheduler持有在候选选择阶段直接过滤对应表/分区的任务见 ScoreSelector.java 中的excludeTableOrPartition判断。CNBE参数动态生效UPDATE information_schema.be_configs SET VALUE 8 WHERE name compact_threads;compact_threads默认值4类型Int是否动态是自 v3.1.7 与 v3.2.2 起改为动态配置说明CN 上用于并发执行 Compaction 任务的最大线程数。引入版本v3.0.0生产建议设置为 BE/CNCPU 核数的 25%。该参数定义于 config.hCONF_mInt32(compact_threads, 4)m前缀表示可动态修改其配套的队列深度参数compact_thread_pool_queue_size默认 100。max_cumulative_compaction_num_singleton_deltas默认值500类型Int是否动态是说明单次 Cumulative Compaction 最多可合并的 Segment 数量。若合并过程中出现 OOM可调低该值。引入版本-生产建议建议设为100以加速 Compaction 并降低资源消耗。lake_pk_compaction_max_input_rowsets默认值500类型Int是否动态是说明存算分离集群中主键表Primary Key单次 Compaction 任务允许的最大输入 Rowset 数。该参数默认值经历了多次调整自 v3.2.4 与 v3.1.10 起由5调整为1000自 v3.3.1 与 v3.2.9 起调整为500。当主键表启用 Sized-tiered Compaction 策略设置enable_pk_size_tiered_compaction_strategy为true后StarRocks 不再需要通过限制每次合并的 Rowset 数来降低写放大因此默认值得以提高。引入版本v3.1.8、v3.2.3从源码看lake_pk_compaction_max_input_rowsets定义于 config.h并在主键表合并策略 primary_key_compaction_policy.cpp 中用于控制输入 Rowset 上限而enable_pk_size_tiered_compaction_strategy定义于 config.h默认值为true。手动触发 Compaction正常情况下无需手动干预但以下场景可以手动触发以加速合并-- 触发整张表的 Compaction ALTER TABLE table_name COMPACT; -- 触发指定分区的 Compaction ALTER TABLE table_name COMPACT partition_name; -- 触发多个分区的 Compaction ALTER TABLE table_name COMPACT (partition_name, partition_name, ...);手动触发的分区在 ScoreSelector.java 中具有非 DEFAULT 的CompactionPriority会跳过最小分数与时间检查立即进入调度队列。手动触发的任务会通过CompactionMgr.triggerManualCompaction()记录到 FE 元数据可随 Image 持久化见 CompactionMgr.java 的save/load方法。取消 Compaction 任务可以使用任务的事务 ID 手动取消 CompactionCANCEL COMPACTION WHERE TXN_ID TXN_ID;注意事项CANCEL COMPACTION语句必须提交到 Leader FE 节点仅对尚未提交的事务生效即SHOW PROC /compactions返回中CommitTime为NULL的任务取消是异步过程可再次执行SHOW PROC /compactions确认任务是否已被取消。Best Practices监控与调优建议Compaction 对查询性能至关重要建议定期监控表和分区的数据合并状态。实践建议如下控制导入节奏尽量拉长两次导入之间的时间间隔避免小于 10 秒的频繁小批量导入并增大单次导入的批大小避免单批小于 100 行从源头减少小文件与 Rowset 的产生。合理设置 CN 并行度生产环境建议将compact_threads设置为 BE/CN CPU 核数的 25%加速任务执行同时可将max_cumulative_compaction_num_singleton_deltas调至100以降低单次合并的资源占用。持续监控任务状态定期执行SHOW PROC /compactions与SELECT * FROM information_schema.be_cloud_native_compactions;结合Profile中的in_queue_sec、read_remote_mb、write_remote_sec等指标判断合并是否健康。基于 Compaction Score 配置告警StarRocks 内置的 Grafana 监控模板中已包含 Compaction Score 相关指标可围绕MaxCS超过 100/500 等阈值配置告警。关注资源消耗尤其关注 Compaction 期间的内存使用Grafana 监控模板同样包含该指标可及时发现 OOM 风险并调整相关参数。Troubleshooting典型问题排查慢查询怀疑由 Compaction 不及时引起在 SQL Profile 中查看单个 Fragment 内的SegmentsReadCount除以TabletCount的比值。若该值很大达到几十或更高说明查询扫描了远超 Tablet 数量的文件段很可能就是 Compaction 不及时导致的慢查询。集群中 Max Compaction Score 过高按以下步骤逐层排查检查参数是否合理执行ADMIN SHOW FRONTEND CONFIG LIKE %lake_compaction%与SELECT * FROM information_schema.be_configs WHERE name compact_threads确认 Compaction 相关参数在合理范围内。判断 Compaction 是否卡住执行SHOW PROC /compactions若CommitTime一直为NULL查看系统视图information_schema.be_cloud_native_compactions定位 Compaction 卡住的原因若FinishTime一直为NULL到 Leader FE 日志中用TxnID搜索 Publish 失败原因。判断 Compaction 是否执行缓慢执行SHOW PROC /compactions结合Profile字段若sub_task_count过大可用SHOW PARTITIONS核对分区内每个 Tablet 的大小可能是建表方式不合理如分桶数设置不当若read_remote_mb过大占总读取数据量的 30% 以上检查服务器磁盘大小并通过SHOW BACKENDS中的DataCacheMetrics字段检查缓存配额若write_remote_sec过大占 Compaction 总耗时的 90% 以上说明写远端存储过慢可通过存算分离专属监控指标中关键字为single upload latency和multi upload latency的指标进一步验证若in_queue_sec过大每个 Tablet 平均等待时间超过 60 秒说明参数设置不合理或存在其他运行中的 Compaction 过慢导致任务在队列中积压。参考资源本文依据的核心文档docs/en/administration/management/compaction.mdFE 参数定义与注释fe/fe-core/src/main/java/com/starrocks/common/Config.javaCompaction 调度器实现fe/fe-core/src/main/java/com/starrocks/lake/compaction/CompactionScheduler.java分数选择器实现fe/fe-core/src/main/java/com/starrocks/lake/compaction/ScoreSelector.java分数管理与手动触发fe/fe-core/src/main/java/com/starrocks/lake/compaction/CompactionMgr.java分区统计与分位数PartitionStatistics.java、Quantiles.javaCN 侧参数定义be/src/common/config.h主键表合并输入 Rowset 上限实现be/src/storage/lake/primary_key_compaction_policy.cpp系统视图实现fe/fe-core/src/main/java/com/starrocks/catalog/system/information/BeCloudNativeCompactionsSystemTable.java【免费下载链接】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 存算分离集群 Compaction 管理与监控完全指南
StarRocks 存算分离集群 Compaction 管理与监控完全指南【免费下载链接】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本文围绕 StarRocks 存算分离Shared-data架构下的 Compaction 机制展开系统讲解 Compaction Score 的含义与计算规则、FE 统一调度的 Compaction 工作流、分数与任务的多视角监控手段、FE/CN 关键参数调优、手动触发与取消任务的方法以及慢查询、分数过高两类典型问题的排查路径。读完本文你将能够独立监控分区合并进度、定位 Compaction 卡顿根因并基于源码理解每个参数与监控指标背后的实现原理。Overview为什么存算分离集群需要 Compaction在 StarRocks 中每一次数据导入loading都会为表生成一个新版本的数据文件。随着写入持续进行一个分区内会累积大量小文件文件数量多、单文件数据量小会导致查询时需要打开与扫描大量文件元数据膨胀查询效率随之下降。Compaction 的作用就是把来自不同版本的数据文件合并为更大的文件从而减少小文件数量降低查询时的文件打开与扫描开销让同一分区内的数据文件大小分布更加均匀提升查询效率为后续的版本清理vacuum与远端存储空间回收创造条件。在存算分离集群中数据文件存放在远端对象存储上合并操作在 Compute NodeCN上执行并由 FrontendFE统一调度这与存算一体集群由 BE 本地自行调度 Compaction 的模式有本质区别。Compaction Score衡量分区合并进度的核心指标概念与判定阈值Compaction Score 反映一个分区内数据文件的合并进度分数越高说明合并进度越低、尚未合并的数据文件版本越多。FE 会为每个分区维护 Compaction Score 信息其中最关键的是Max Compaction Score分区内所有 Tablet 中分数的最大值。围绕 Compaction ScoreStarRocks 定义了三个关键判定阈值阈值判定含义FE 参数lake_compaction_score_selector_min_score默认 10分区的 Max Compaction Score 低于该值时Compaction 视为完成不再调度FE 参数lake_ingest_slowdown_threshold默认 100Max Compaction Score 超过该值时系统会降速该分区的数据导入事务提交FE 参数lake_compaction_score_upper_bound默认 2000Max Compaction Score 超过该值时系统会拒绝该分区的导入事务也就是说Max Compaction Score 低于 10 表示健康超过 100 即进入不健康状态并触发写入降速超过 2000 则直接拒绝新写入防止小文件无限膨胀拖垮查询性能。从源码看这三个参数都定义在 Config.java 中并且是mutable true的动态配置。其中写入降速还有一个配套开关lake_enable_ingest_slowdown默认true以及降速力度参数lake_ingest_slowdown_ratio默认 0.1分数每超过阈值 1 点导入耗时按该比例递增延迟例如正常导入 10 分钟、超阈值 5 点时会额外延迟约10 分钟 × 0.1 × 5 5 分钟。此外lake_ingest_slowdown_threshold的实际生效值取配置值与lake_compaction_score_selector_min_score两者中的较大者。计算规则Compaction Score 的计算遵循以下规则通常情况下每个数据文件贡献 1 分。例如一个分区只有 1 个 Tablet第一次导入生成了 10 个数据文件则该分区的 Max Compaction Score 为 10。一个事务在某个 Tablet 内产生的所有数据文件被归为一组称为Rowset。计算分数时Tablet 的 Rowsets 会按大小分组文件数最多的一组决定该 Tablet 的 Compaction Score。举例说明一个 Tablet 经历了 7 次导入生成的 Rowset 大小分别为 100 MB、100 MB、100 MB、10 MB、10 MB、10 MB、10 MB。计算时系统会把 3 个 100 MB 的 Rowset 分成一组、4 个 10 MB 的 Rowset 分成另一组Compaction Score 取文件数更多的一组——即第二组4 个文件分数更高。Compaction 优先处理分数高的组因此第一次合并后Rowset 分布会变为100 MB、100 MB、100 MB 和一个合并后的 40 MB。这种按大小分桶、取桶内文件数的设计保证了分数能够真实反映文件数量压力而非数据量压力从而让调度器优先合并小文件堆积严重的分区。从源码看分数统计最终以Quantiles对象包含 avg / p50 / max 三个统计值的形式保存在 FE 的PartitionStatistics中见 PartitionStatistics.java 与 Quantiles.java。FE 在事务发布publish完成后调用CompactionMgr.handleLoadingFinished()更新分数调度器再据此决定是否对该分区发起新一轮合并。Compaction WorkflowFE 统一调度的六步流水线与存算一体架构不同存算分离集群引入了FE 控制的 Compaction 机制完整流程如下Score 计算Leader FE 节点根据事务发布结果计算并存储各分区的 Compaction Score。候选选择FE 选出 Max Compaction Score 最高的分区作为 Compaction 候选。任务生成FE 为选中的分区发起 Compaction 事务生成 Tablet 级子任务并分发给各 CN直到达到 FE 参数lake_compaction_max_tasks限定的并发上限。子任务执行CN 在后台执行 Compaction 子任务每个 CN 的并发子任务数由 CN 参数compact_threads控制。结果收集FE 汇总各子任务结果提交 Compaction 事务。发布FE 发布提交成功的 Compaction 事务新版本对查询可见。这套流水线在源码中有清晰对应调度器主体是 CompactionScheduler.java它继承自Daemon以 1 秒为周期LOOP_INTERVAL_MS 1000L循环执行只有 Leader FE 且 edit log 回放完成后才会真正调度新任务。候选选择由 ScoreSelector.java 实现它会过滤掉没有分数、被禁用的表/分区且只有当分区的nextCompactionTime已到并且compactionScore.getMax() minScore时才入选手动触发priority 非 DEFAULT时则跳过分数与时间检查立即调度。任务并发上限、超时等控制参数同样定义在 Config.java 所读取的 FE 配置中例如lake_compaction_default_timeout_second默认 86400 秒即 1 天、lake_compaction_allow_partial_success默认 true允许部分 Tablet 失败时仍提交成功、lake_compaction_history_size默认 20控制SHOW PROC /compactions历史记录条数。查看 Compaction Score通过 SHOW 语句查看有两种方式查看指定表的各分区 Compaction ScoreSHOW PARTITIONS FROM table_name SHOW PROC /dbs/database_name/table_name/partitions示例输出摘自SHOW PROC /dbs/load_benchmark/store_sales/partitions------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | PartitionId | PartitionName | CompactVersion | VisibleVersion | NextVersion | State | PartitionKey | Range | DistributionKey | Buckets | DataSize | RowCount | CacheTTL | AsyncWrite | AvgCS | P50CS | MaxCS | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | 38028 | store_sales | 913 | 921 | 923 | NORMAL | | | ss_item_sk, ss_ticket_number | 64 | 15.6GB | 273857126 | 2592000 | false | 10.00 | 10.00 | 10.00 | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------日常巡检时一般只需关注MaxCS字段MaxCS低于 10Compaction 视为完成MaxCS超过 100分数偏高需要留意MaxCS超过 500分数很高可能需要人工干预。通过系统视图查询也可以查询系统视图information_schema.partitions_meta获得全集群范围的分数概览SELECT * FROM information_schema.partitions_meta ORDER BY Max_CS LIMIT 10;该视图每个分区一行关键列包括DB_NAME、TABLE_NAME、PARTITION_NAME、COMPACT_VERSION、VISIBLE_VERSION、BUCKETS、DATA_SIZE、ROW_COUNT、AVG_CS、P50_CS、MAX_CS以及STORAGE_PATH远端存储路径。示例中tpcds_1t库下各表分区的MAX_CS均为 0说明合并进度健康。相比SHOW PROC该视图适合对多个数据库、多张表做批量排序筛选例如快速找出全集群分数最高的前 10 个分区。查看 Compaction 任务数据持续导入期间FE 会不断把 Compaction 任务调度到不同 CN 上执行。建议先在 FE 侧查看任务总体状态再下钻到 CN 侧查看每个任务的执行细节。查看任务总体状态FE 侧SHOW PROC /compactions;示例输出---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | Partition | TxnID | StartTime | CommitTime | FinishTime | Error | Profile | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ssb.lineorder.10081 | 15 | 2026-01-10 03:29:07 | 2026-01-10 03:29:11 | 2026-01-10 03:29:12 | NULL | {sub_task_count:12,read_local_sec:0,read_local_mb:218,read_remote_sec:0,read_remote_mb:0,read_segment_count:120,write_segment_count:12,write_segment_mb:219,write_remote_sec:4,in_queue_sec:18,score_before:{avg:10.0,p50:10.0,max:10.0},score_after:{avg:8.0,p50:8.0,max:8.0},partial_success:false} | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------各字段含义如下PartitionCompaction 任务所属分区。TxnIDCompaction 任务对应的事务 ID。StartTime任务开始时间NULL表示尚未发起。CommitTime任务提交数据的时间NULL表示数据尚未提交。FinishTime任务发布数据的时间NULL表示数据尚未发布。Error任务错误信息如有。Profile自 v3.2.12 与 v3.3.4 起支持任务完成后的 Profile其中sub_task_count分区内子任务数等价于 Tablet 数read_local_sec/read_local_mb所有子任务从本地缓存读取数据的总耗时秒与总大小MBread_remote_sec/read_remote_mb所有子任务从远端存储读取数据的总耗时秒与总大小MBread_segment_count所有子任务读取的文件总数write_segment_count/write_segment_mb所有子任务生成的新文件总数与总大小MBwrite_remote_sec所有子任务写远端存储的总耗时秒in_queue_sec所有子任务在队列中等待的总时长秒score_before/score_after合并前后分区的 Compaction Score均含avg、p50、max三个字段partial_successCompaction 任务是否部分成功部分 Tablet 失败。查看任务执行细节CN 侧information_schema.be_cloud_native_compactions中的每一行代表一个 Tablet 级 Compaction 执行单元。当启用 Tablet 并行合并时每个并行子任务会以相同的事务 ID 与 Tablet ID、但不同的SUBTASK_ID单独返回一行并行合并的聚合上下文只是聚合产物而非执行单元不会出现在该视图中。该视图由 FE 侧系统表 BeCloudNativeCompactionsSystemTable.java 实现。示例查询SELECT BE_ID, TXN_ID, TABLET_ID, VERSION, SKIPPED, RUNS, START_TIME, FINISH_TIME, PROGRESS, STATUS, PROFILE FROM information_schema.be_cloud_native_compactions;示例输出------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | BE_ID | TXN_ID | TABLET_ID | VERSION | SKIPPED | RUNS | START_TIME | FINISH_TIME | PROGRESS | STATUS | PROFILE | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | 10001 | 51047 | 43034 | 12 | 0 | 1 | 2024-09-24 19:15:15 | NULL | 82 | | {read_local_sec:0,read_local_mb:31,read_remote_sec:0,read_remote_mb:0,read_remote_count:0,read_local_count:1900,segment_init_sec:0,column_iterator_init_sec:0,in_queue_sec:0} | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------各字段含义BE_ID执行子任务的 CNBEID。TXN_ID子任务所属事务 ID。TABLET_ID子任务所属 Tablet ID。VERSIONTablet 的版本号。RUNS子任务已执行的次数。START_TIME/FINISH_TIME子任务开始/结束时间。PROGRESSTablet 合并进度百分比。STATUS子任务状态出错时错误信息会显示在此字段。PROFILE自 v3.2.12 与 v3.3.4 起支持子任务运行时 Profile含read_local_sec、read_local_mb、read_remote_sec、read_remote_mb、read_local_count、read_remote_count、in_queue_sec等字段。SUBTASK_ID从 0 开始的并行子任务 ID普通非并行 Tablet 任务该字段为NULL。BE_ID、TXN_ID、TABLET_ID相同但SUBTASK_ID不同的多行是同一个 Tablet 合并的并行执行单元。全链路 Profile 字段纳米级计账自 v3.2.12 与 v3.3.4 起子任务PROFILE中的全链路字段采用纳秒单位精确计账可分为四类Profile 状态profile_final任务运行中为false结束后为true。实时 Profile 会把当前尝试已耗时间计入task_total_ns进入执行器后再计入task_execute_ns其他阶段计时器在其作用域退出时才更新因此实时 Profile 中task_unaccounted_ns可能暂时偏大。任务外壳Task envelopequeue_wait_ns从进入 CN Compaction 队列到工作线程开始执行的时间不计入task_total_ns。task_prepare_ns选择输入 Rowset、加载 Tablet 元数据、构造 Compaction 任务的时间。task_execute_ns在横向horizontal、纵向vertical或索引indexCompaction 执行器内的墙钟时间实时 Profile 含当前执行器的已耗时间。task_total_ns从 CN 工作线程开始任务准备到 Profile 快照或任务返回的墙钟时间。task_accounted_ns所有互不重叠的顶层阶段之和。task_unaccounted_nstask_total_ns - task_accounted_ns数值偏大说明存在未计账的阶段或调度/运行时开销。互不重叠的执行阶段input_prepare_ns、reader_prepare_ns、reader_open_ns、reader_get_next_ns、reader_close_ns、chunk_transform_ns、writer_create_ns、writer_open_ns、writer_write_ns、writer_flush_ns、writer_finish_ns、writer_close_ns、mask_io_ns、txn_log_build_ns、pk_sst_merge_ns、txn_log_write_ns、preload_compaction_state_ns、tablet_write_log_ns。嵌套的 Reader 明细read_remote_ns、read_local_ns、create_segment_iter_ns、segment_init_ns、column_iterator_init_ns、block_load_ns、block_fetch_ns、block_seek_ns、decompress_ns、decode_dict_ns以及 delete-vector / filter 相关计时器。这些字段用于解释 reader 阶段内部耗时不能再累加进task_accounted_ns。纵向合并明细column_group_count、vertical_key_group_ns、vertical_value_group_ns。分组时间与 reader/writer 阶段存在重叠仅作诊断用途不可相加。任务结束后同一份单 Tablet Profile 会连同 Tablet ID、事务 ID、状态、表 ID、分区 ID 一起写入 CN 的 INFO 日志即使该行随后从be_cloud_native_compactions中消失也能保留按 Tablet 粒度的 Profile 记录供事后分析。配置 Compaction 任务Compaction 任务可通过 FE 参数与 CNBE参数两类配置项进行调优。FE 参数动态生效ADMIN SET FRONTEND CONFIG (lake_compaction_max_tasks -1);lake_compaction_max_tasks默认值-1类型Int是否动态是说明存算分离集群中允许的最大并发 Compaction 任务数。设为-1表示自适应计算并发数即存活 CN 节点数 × 16设为0则完全禁用 Compaction。引入版本v3.1.0ADMIN SET FRONTEND CONFIG (lake_compaction_disable_tables 11111;22222);lake_compaction_disable_tables默认值类型String是否动态是说明禁用某些表的 Compaction不影响已经开始的任务值为表 ID多个值以;分隔。引入版本v3.2.7从源码看该参数在 Config.java 中实际对应字段lake_compaction_disable_idslake_compaction_disable_tables是其别名注释明确说明表 ID 与分区 ID 均支持格式为id1;id2。禁用 ID 集合会被CompactionScheduler持有在候选选择阶段直接过滤对应表/分区的任务见 ScoreSelector.java 中的excludeTableOrPartition判断。CNBE参数动态生效UPDATE information_schema.be_configs SET VALUE 8 WHERE name compact_threads;compact_threads默认值4类型Int是否动态是自 v3.1.7 与 v3.2.2 起改为动态配置说明CN 上用于并发执行 Compaction 任务的最大线程数。引入版本v3.0.0生产建议设置为 BE/CNCPU 核数的 25%。该参数定义于 config.hCONF_mInt32(compact_threads, 4)m前缀表示可动态修改其配套的队列深度参数compact_thread_pool_queue_size默认 100。max_cumulative_compaction_num_singleton_deltas默认值500类型Int是否动态是说明单次 Cumulative Compaction 最多可合并的 Segment 数量。若合并过程中出现 OOM可调低该值。引入版本-生产建议建议设为100以加速 Compaction 并降低资源消耗。lake_pk_compaction_max_input_rowsets默认值500类型Int是否动态是说明存算分离集群中主键表Primary Key单次 Compaction 任务允许的最大输入 Rowset 数。该参数默认值经历了多次调整自 v3.2.4 与 v3.1.10 起由5调整为1000自 v3.3.1 与 v3.2.9 起调整为500。当主键表启用 Sized-tiered Compaction 策略设置enable_pk_size_tiered_compaction_strategy为true后StarRocks 不再需要通过限制每次合并的 Rowset 数来降低写放大因此默认值得以提高。引入版本v3.1.8、v3.2.3从源码看lake_pk_compaction_max_input_rowsets定义于 config.h并在主键表合并策略 primary_key_compaction_policy.cpp 中用于控制输入 Rowset 上限而enable_pk_size_tiered_compaction_strategy定义于 config.h默认值为true。手动触发 Compaction正常情况下无需手动干预但以下场景可以手动触发以加速合并-- 触发整张表的 Compaction ALTER TABLE table_name COMPACT; -- 触发指定分区的 Compaction ALTER TABLE table_name COMPACT partition_name; -- 触发多个分区的 Compaction ALTER TABLE table_name COMPACT (partition_name, partition_name, ...);手动触发的分区在 ScoreSelector.java 中具有非 DEFAULT 的CompactionPriority会跳过最小分数与时间检查立即进入调度队列。手动触发的任务会通过CompactionMgr.triggerManualCompaction()记录到 FE 元数据可随 Image 持久化见 CompactionMgr.java 的save/load方法。取消 Compaction 任务可以使用任务的事务 ID 手动取消 CompactionCANCEL COMPACTION WHERE TXN_ID TXN_ID;注意事项CANCEL COMPACTION语句必须提交到 Leader FE 节点仅对尚未提交的事务生效即SHOW PROC /compactions返回中CommitTime为NULL的任务取消是异步过程可再次执行SHOW PROC /compactions确认任务是否已被取消。Best Practices监控与调优建议Compaction 对查询性能至关重要建议定期监控表和分区的数据合并状态。实践建议如下控制导入节奏尽量拉长两次导入之间的时间间隔避免小于 10 秒的频繁小批量导入并增大单次导入的批大小避免单批小于 100 行从源头减少小文件与 Rowset 的产生。合理设置 CN 并行度生产环境建议将compact_threads设置为 BE/CN CPU 核数的 25%加速任务执行同时可将max_cumulative_compaction_num_singleton_deltas调至100以降低单次合并的资源占用。持续监控任务状态定期执行SHOW PROC /compactions与SELECT * FROM information_schema.be_cloud_native_compactions;结合Profile中的in_queue_sec、read_remote_mb、write_remote_sec等指标判断合并是否健康。基于 Compaction Score 配置告警StarRocks 内置的 Grafana 监控模板中已包含 Compaction Score 相关指标可围绕MaxCS超过 100/500 等阈值配置告警。关注资源消耗尤其关注 Compaction 期间的内存使用Grafana 监控模板同样包含该指标可及时发现 OOM 风险并调整相关参数。Troubleshooting典型问题排查慢查询怀疑由 Compaction 不及时引起在 SQL Profile 中查看单个 Fragment 内的SegmentsReadCount除以TabletCount的比值。若该值很大达到几十或更高说明查询扫描了远超 Tablet 数量的文件段很可能就是 Compaction 不及时导致的慢查询。集群中 Max Compaction Score 过高按以下步骤逐层排查检查参数是否合理执行ADMIN SHOW FRONTEND CONFIG LIKE %lake_compaction%与SELECT * FROM information_schema.be_configs WHERE name compact_threads确认 Compaction 相关参数在合理范围内。判断 Compaction 是否卡住执行SHOW PROC /compactions若CommitTime一直为NULL查看系统视图information_schema.be_cloud_native_compactions定位 Compaction 卡住的原因若FinishTime一直为NULL到 Leader FE 日志中用TxnID搜索 Publish 失败原因。判断 Compaction 是否执行缓慢执行SHOW PROC /compactions结合Profile字段若sub_task_count过大可用SHOW PARTITIONS核对分区内每个 Tablet 的大小可能是建表方式不合理如分桶数设置不当若read_remote_mb过大占总读取数据量的 30% 以上检查服务器磁盘大小并通过SHOW BACKENDS中的DataCacheMetrics字段检查缓存配额若write_remote_sec过大占 Compaction 总耗时的 90% 以上说明写远端存储过慢可通过存算分离专属监控指标中关键字为single upload latency和multi upload latency的指标进一步验证若in_queue_sec过大每个 Tablet 平均等待时间超过 60 秒说明参数设置不合理或存在其他运行中的 Compaction 过慢导致任务在队列中积压。参考资源本文依据的核心文档docs/en/administration/management/compaction.mdFE 参数定义与注释fe/fe-core/src/main/java/com/starrocks/common/Config.javaCompaction 调度器实现fe/fe-core/src/main/java/com/starrocks/lake/compaction/CompactionScheduler.java分数选择器实现fe/fe-core/src/main/java/com/starrocks/lake/compaction/ScoreSelector.java分数管理与手动触发fe/fe-core/src/main/java/com/starrocks/lake/compaction/CompactionMgr.java分区统计与分位数PartitionStatistics.java、Quantiles.javaCN 侧参数定义be/src/common/config.h主键表合并输入 Rowset 上限实现be/src/storage/lake/primary_key_compaction_policy.cpp系统视图实现fe/fe-core/src/main/java/com/starrocks/catalog/system/information/BeCloudNativeCompactionsSystemTable.java【免费下载链接】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），仅供参考