14. Doris 系列第14篇：Compaction 深度解析｜原理、类型、配置与版本数限制全攻略

关注

原创最新推荐文章于 2026-11-07 19:12:46 发布 737 阅读 AI 写同款· GEO 优化 ›

一次实时数据链路丢数排查：从 MQTT 队列积压到 SQL 统计开销本文通过一次实时数据链路压测，排查了从MQTT到ClickHouse的端到端数据丢失问题。核心方法是为每条消息添加序号，建立独立观察点（MQTT订阅端、Kafka消费者），结合转发服务阶段统计与线程栈分析，定位到下游处理速度不足源于Druid SQL合并统计的高开销。优化措施包括关闭SQL合并、扩容代理队列、增强生产侧失败处理，并验证15分钟内实现全链路对账一致，显著缓解积压与丢包。关键收获：数据可对账、明确各阶段“成功”定义、关注客户端队列状态。阅读详情

适合人群：Doris运维工程师、大数据开发、数仓架构师、生产环境调优人员

核心价值：从底层原理到生产实操，全面拆解Doris Compaction机制，含3种Compaction类型、关键配置、监控告警、版本数限制及应急处理，解决生产中Compaction积压、版本数过高导致的写入拒绝、查询变慢问题

系列说明：本文是Doris进阶第13篇，承接前文监控指标内容，聚焦Compaction这一核心运维痛点，基于Doris 2.2版本，结合生产真实案例，覆盖“原理-配置-监控-应急-预防”全流程，看完可直接落地Compaction优化与版本数管控。

一、Compaction 核心概念：为什么它是Doris性能的“关键开关”？

Doris 底层基于 LSM-Tree（Log-Structured Merge-Tree）架构，这种架构的核心优势是高写入吞吐量，但随之会产生大量小文件，而Compaction就是解决这一问题的核心机制，相当于Doris的“文件整理工”。

1.1 为什么必须要有 Compaction？

Doris 数据写入的完整流程，决定了小文件会持续累积，进而引发性能问题：

写入内存：数据先写入 MemTable（内存中的有序数据结构），享受高速写入性能；
触发刷盘：当 MemTable 达到阈值（默认64MB），会异步刷盘，生成磁盘上的 Segment 文件（小文件）；
版本累积：随着持续写入，刷盘操作不断进行，会产生大量分散的小 Segment 文件；
性能瓶颈：大量小文件会直接导致三大问题，严重影响集群稳定性：
- 元数据膨胀：集群需要维护所有小文件的元信息，占用更多内存；
- IO 开销剧增：查询时需要同时打开、读取多个小文件，磁盘IO压力暴增；
- 版本合并耗时：查询需合并所有数据版本，才能返回最新结果，查询延迟大幅上升。

✅ Compaction 的核心作用：将多个小的 Segment 文件合并成大的、有序的文件，同时清理删除、过期的数据，减少版本数量，从根本上解决小文件带来的性能问题，平衡写入与查询性能。

1.2 关键概念区分：数据版本 vs Rowset

理解 Compaction 必须先分清两个易混淆的概念，避免后续配置、监控踩坑：

Rowset：一次数据导入（如Stream Load、Broker Load）生成的数据集合，本质是一组有序的 Segment 文件，是 Compaction 的最小合并单元；
版本（Version）：每个 Rowset 会对应一个唯一的版本号，版本号按导入顺序递增，查询时会合并所有版本的 Rowset，最终返回最新的数据；
关联关系：一个版本 = 一个 Rowset，Compaction 的本质就是“合并多个版本的 Rowset”，减少版本数量，生成新的 Rowset（新版本）。

二、Doris 三种 Compaction 类型：适用场景与核心区别

Doris 针对不同的场景，设计了三种 Compaction 机制，分别对应“轻量合并、深度合并、手动维护”，运维时需根据业务场景选择合适的方式，避免资源浪费或合并不及时。

2.1 Base Compaction（深度合并，重量级）

Base Compaction 是“深度合并”，主要用于将轻量合并后的 Cumulative Rowset 与基础的 Base Rowset 合并，彻底减少版本数量，适合写入量稳定后的深度优化。

触发条件（满足任一即可）：

Cumulative 层的 Rowset 数量达到阈值（默认5个，由 base_compaction_num_cumulative_rowsets 控制）；
定期触发：默认每30分钟检查一次（由 base_compaction_interval_seconds 控制）；
Cumulative 层的数据量超过 Base Rowset 数据量的一定比例（默认25%）。

核心特点：

合并粒度大：将 Cumulative 层所有符合条件的 Rowset，一次性合并到 Base Rowset 中；
资源消耗高：合并数据量大，IO、CPU 占用较高，建议在业务低峰期触发；
产出单一：合并后只生成一个新的 Base Rowset，版本数量大幅减少；
核心作用：彻底清理过期数据、减少版本数，最大化提升查询性能。

2.2 Cumulative Compaction（轻量合并，高频）

Cumulative Compaction 是“轻量合并”，高频触发，主要用于合并近期产生的小 Rowset，避免小文件快速累积，是日常最常执行的合并方式。

触发条件（满足任一即可）：

Cumulative 层的 Rowset 数量超过阈值（默认5个，由 cumulative_compaction_num_cumulative_rowsets 控制）；
定期触发：默认每10秒检查一次，高频扫描是否需要合并；
Cumulative 层的 Rowset 总大小达到阈值（由 cumulative_compaction_max_output_size 控制）。

核心特点：

合并粒度小：只合并近期的小 Rowset，不触及 Base Rowset，操作轻量；
资源消耗低：IO、CPU 占用较少，可在业务高峰期正常执行，不影响写入和查询；
产出灵活：合并后生成新的 Cumulative Rowset，版本数适度减少；
合并策略：支持两种策略，按需选择：
- Size-tiered：按文件大小分层合并，适合写多读少、小文件较多的场景；
- Num-based：按文件数量合并，适合持续高频导入、小批量写入的场景。

2.3 Full Compaction（手动触发，强制合并）

Full Compaction 是手动触发的“强制合并”，不依赖自动触发条件，可将一张表（或分区）的所有版本 Rowset 合并成一个版本，适合生产环境的定期维护。

核心特点：

手动触发：需通过 SQL 命令执行（ALTER TABLE table_name COMPACT），无法自动触发；
合并彻底：将表的所有版本（Base + Cumulative）合并成一个版本，版本数降至最低；
资源消耗最大：合并全量数据，IO、CPU 占用极高，必须在业务低峰期（如凌晨）执行；
适用场景：版本数过高、查询性能严重下降、定期维护（如每周一次）。

实操命令（生产常用）：

-- 1. 对整个表执行 Full Compaction
ALTER TABLE example_table COMPACT;

-- 2. 对指定分区执行（推荐，减少资源消耗）
ALTER TABLE example_table PARTITION(p20240301) COMPACT;

-- 3. 查看 Compaction 执行状态
SHOW PROC '/compactions';

三、Compaction 关键配置参数详解（BE+表级别，直接套用）

Compaction 的性能和触发时机，完全由配置参数控制，核心分为「BE 端全局配置」和「表级别个性化配置」，需结合业务写入量、磁盘IO能力、CPU资源灵活调整，以下是生产环境最优配置建议。

3.1 BE 端全局配置（be.conf，需重启BE生效）

BE 是 Compaction 的执行节点，所有核心配置都在 be.conf 中，重点关注以下3类参数，无需修改所有参数，聚焦核心即可。

1. Compaction 线程配置（控制合并速度）

# Compaction 总线程数，默认 10
# 核心建议：设置为 CPU 核心数的 50%-100%（如16核CPU设为8-16）
# 线程数过少：合并速度慢，易导致版本积压；线程数过多：占用过多CPU，影响查询
max_compaction_threads = 10

# 单次 Compaction 任务可用的最大线程数，默认4
# 建议：与 max_compaction_threads 保持一致，或略低（避免单任务占用过多资源）
compaction_task_num_per_disk = 4

2. Cumulative Compaction 配置（高频轻量合并）

# 触发 Cumulative Compaction 的最小 Rowset 数量，默认5
# 核心建议：写入频繁（如每秒导入）可调大到8-10；写入量小可调小到3-4
cumulative_compaction_num_cumulative_rowsets = 5

# Cumulative Compaction 最大产出文件大小，默认10GB（10737418240字节）
# 建议：根据磁盘IO能力调整，SSD可设为10-20GB，机械硬盘设为5-10GB
cumulative_compaction_max_output_size = 10737418240

# Cumulative Compaction 的最小产出文件大小，默认1GB（1073741824字节）
# 建议：不小于1GB，避免合并后仍产生小文件
cumulative_compaction_min_output_size = 1073741824

3. Base Compaction 配置（深度合并）

# 触发 Base Compaction 的最小 Rowset 数量，默认5
# 建议：与 cumulative_compaction_num_cumulative_rowsets 保持一致
base_compaction_num_cumulative_rowsets = 5

# Base Compaction 最小数据量（字节），默认5GB（5368709120字节）
# 建议：写入量大时可调小到3GB，写入量小时保持默认
base_compaction_min_data_size = 5368709120

# Base Compaction 间隔（秒），默认86400秒（1天）
# 核心建议：写入量大时缩短到12小时（43200秒）或6小时（21600秒）
base_compaction_interval_seconds = 86400

3.2 表级别配置（建表/修改表，灵活适配不同表）

不同表的写入频率、数据量差异较大，可通过表级别配置，为单个表定制 Compaction 相关参数，无需修改全局配置，更灵活。

实操命令（生产常用）：

-- 1. 建表时指定 Compaction 相关属性
CREATE TABLE example_table (
    id INT,
    name STRING,
    date DATE
) DUPLICATE KEY(id)  -- 表模型根据业务选择
DISTRIBUTED BY HASH(id) BUCKETS 10  -- 分桶数根据数据量调整
PROPERTIES (
    -- 单个 Segment 文件大小，默认256MB（268435456字节）
    -- 建议：写入频繁表设为512MB（536870912），减少小文件数量
    "segment_size" = "268435456",
    
    -- 是否开启写时合并（MOW），默认false，适合Unique Key模型
    -- 开启后：更新操作会合并版本，减少 Compaction 压力
    "enable_unique_key_merge_on_write" = "false",
    
    -- 数据压缩方式，默认LZ4，兼顾压缩率和性能
    "compression" = "LZ4"
);

-- 2. 修改已有表的 Compaction 相关属性（无需重启集群）
ALTER TABLE example_table SET (
    "segment_size" = "536870912",  -- 调整为512MB
    "enable_unique_key_merge_on_write" = "true"  -- 开启写时合并
);

关键参数说明：

segment_size：单个 Segment 文件大小，是影响小文件数量的核心参数，越大，刷盘产生的小文件越少，Compaction 压力越小；
enable_unique_key_merge_on_write：仅适用于 Unique Key 模型，开启后更新操作会实时合并版本，减少 Compaction 任务量，避免版本数快速增长；
compression：压缩方式，LZ4 适合高频写入场景，ZSTD 压缩率更高但性能略差，可根据查询优先级选择。

四、Compaction 监控指标与告警（提前规避积压问题）

生产环境中，Compaction 最常见的问题是“合并不及时”，导致版本数积压、查询变慢，甚至写入拒绝，因此必须建立完善的监控告警体系，提前发现、及时处理。

4.1 核心监控指标（SQL+Prometheus，双维度监控）

推荐两种监控方式结合：SQL 用于实时排查，Prometheus 用于长期监控和告警，覆盖 Compaction 状态、版本数、资源消耗。

1. SQL 实时排查（生产应急首选）

-- 1. 查看 Compaction 队列状态（核心！）
SHOW PROC '/compactions';
-- 重点关注字段：
-- pending_num：等待合并的 Compaction 任务数，持续>0表示合并跟不上
-- running_num：正在执行的任务数，反映当前合并压力
-- type：任务类型（BASE/CUMULATIVE）
-- progress：任务执行进度（0-100）

-- 2. 查看指定表的所有 Tablet 版本数
SHOW TABLET FROM table_name;
-- 重点关注：VersionCount（单个Tablet的版本数）
-- 正常范围：<50，超过100需关注，超过400需紧急处理

-- 3. 查看磁盘 IO 使用情况（判断 Compaction 是否受 IO 瓶颈限制）
SHOW PROC '/statistic';
-- 重点关注：Compaction 相关 IO 指标（read_bytes/write_bytes）
-- 若 IO 使用率>90%，说明 Compaction 受 IO 限制，需优化磁盘

-- 4. 查看全局版本数分布（Doris 2.0+）
SELECT 
    t.table_id,
    t.table_name,
    MAX(t.version_count) AS max_version,
    AVG(t.version_count) AS avg_version
FROM information_schema.tablets t
GROUP BY t.table_id, t.table_name
ORDER BY max_version DESC
LIMIT 10;

2. Prometheus 监控指标（长期监控+告警）

通过 Doris 自带的 HTTP 接口（BE：http://be_host:8040/metrics）采集指标，核心关注以下4个指标：

doris_be_compaction_total：Compaction 总执行次数，反映合并频率；
doris_be_compaction_duration_ms：Compaction 平均耗时，耗时过长说明资源不足；
doris_be_compaction_bytes：Compaction 处理的数据总量，反映合并压力；
doris_be_cumulative_compaction_rowsets：Cumulative 层 Rowset 数量，持续增长说明合并不及时。

4.2 告警阈值建议（生产直接套用）

结合生产经验，设置三级告警，提前规避风险，避免达到写入拒绝阈值：

警告（需要关注）：
- 单个 Tablet 版本数 > 100；
- Compaction 队列 pending_num > 5，持续10分钟；
- Compaction 平均耗时 > 30分钟。
紧急（需要立即处理）：
- 单个 Tablet 版本数 > 400；
- Compaction 队列 pending_num > 10，持续5分钟；
- Compaction 耗时 > 1小时。
严重（即将拒绝写入）：
- 单个 Tablet 版本数 > 450；
- Compaction 队列 pending_num > 20，持续3分钟。

Prometheus 告警规则示例（可直接导入）：

groups:
  - name: doris_compaction_alerts
    rules:
      # 单个Tablet版本数过高（紧急）
      - alert: DorisTabletVersionTooHigh
        expr: doris_be_tablet_version_count > 400
        for: 5m
        annotations:
          summary: "Tablet版本数过高，即将触发写入拒绝"
          description: "Tablet {{ $labels.tablet_id }} 版本数为 {{ $value }}，超过400阈值"
          
      # Compaction队列积压（紧急）
      - alert: DorisCompactionPending
        expr: doris_be_compaction_pending > 10
        for: 10m
        annotations:
          summary: "Compaction队列积压严重"
          description: "当前Compaction等待任务数为 {{ $value }}，持续10分钟未缓解"
          
      # Compaction耗时过长（警告）
      - alert: DorisCompactionDurationTooLong
        expr: doris_be_compaction_duration_ms > 1800000  # 30分钟
        for: 5m
        annotations:
          summary: "Compaction任务耗时过长"
          description: "Compaction平均耗时为 {{ $value/1000 }} 秒，超过30分钟"

五、版本数限制与写入拒绝机制（生产必避坑）

Doris 对单个 Tablet 的版本数有硬性限制，当版本数达到阈值时，会直接拒绝写入，这是生产环境中最常见的故障之一，必须重点掌握限制机制、应急处理和预防方法。

5.1 核心限制参数（全局配置，不可随意修改）

Doris 不会因为版本数过多直接拒绝写入，而是分阶段触发保护机制，最终达到硬性阈值后拒绝，核心限制参数如下：

参数名称	默认值	核心作用	注意事项
max_tablet_version_num	500	单个 Tablet 最大版本数，超过后禁止写入	硬性限制，无法绕过，调大仅延迟拒绝，不解决根本问题
max_cumulative_compaction_num_singleton_deltas	1000	Cumulative 层最大文件数，超过后强制合并	保护机制，避免小文件过多导致元数据膨胀
max_compaction_concurrency	-1（自动）	Compaction 并发度限制，自动适配CPU资源	不建议手动修改，避免影响集群性能

查看当前限制参数的 SQL：

-- 查看 FE 全局版本数限制
SHOW FRONTEND CONFIG LIKE '%max_tablet_version_num%';

-- 查看 BE 版本数相关配置
SHOW BACKEND CONFIG LIKE '%version%';

5.2 版本数达到限制的三个阶段（必懂！）

版本数从正常到触发写入拒绝，分为三个阶段，每个阶段的表现和处理方式不同，需针对性应对：

1. 努力期（版本数 100-500）

表现：写入正常，但查询性能开始逐步下降（版本合并耗时增加）；Compaction 会自动加速（提高并发、缩短检查间隔）；
处理：无需紧急处理，但需关注 Compaction 队列和版本数增长趋势，避免进入保护期。

2. 保护期（版本数 ≥ 500）

表现：立即拒绝该 Tablet 的所有写入操作，返回明确错误；查询仍可执行，但性能极差（需合并500+版本）；Compaction 持续高速运行，直到版本数降至500以下；
错误信息示例：
ERROR 1105 (HY000): errCode = 2, detailMessage = Tablet [tablet_id] has too many versions [501] > max_tablet_version_num [500]

3. 恢复期（版本数 < 500）

表现：Compaction 完成后，版本数降至500以下，写入能力自动恢复，无需人工干预；查询性能逐步回升；
注意：恢复后需优化 Compaction 配置，避免再次达到阈值。

5.3 版本数过高的危害（生产案例数据）

版本数过高不仅会导致写入拒绝，还会严重影响查询性能，以下是生产环境实测的性能影响曲线，供参考：

版本数范围	查询性能影响	写入影响	Compaction 状态
< 50	正常，无明显延迟	正常，无延迟	正常，低压力
50-100	轻微下降（+10-30%）	正常	开始繁忙，偶有积压
100-200	明显下降（+50-100%）	轻微延迟（<1s）	持续高压，队列偶有积压
200-500	严重下降（+200-500%）	明显延迟（1-5s）	接近极限，队列持续积压
≥ 500	查询极慢（+500%+），甚至超时	拒绝写入	紧急合并，全力清理版本
💡 生产案例：某电商 Doris 集群，单表版本数达到300时，查询耗时从500ms增加到1500ms（+200%）；版本数达到450时，写入延迟达到3s，最终触发写入拒绝，影响业务数据同步。

六、版本数过高的应急处理与预防（生产实操）

应急处理的核心是“快速降低版本数，恢复写入”，预防的核心是“优化 Compaction 配置，控制版本数增长”，两者结合才能彻底解决问题。

6.1 应急处理流程（版本数接近/达到500时）

按以下步骤操作，最快10-30分钟可恢复写入，避免业务中断：

步骤1：确认问题 Tablet 和表

-- 1. 查看版本数最高的前10个 Tablet
SELECT 
    t.table_id,
    t.table_name,
    t.tablet_id,
    t.version_count
FROM information_schema.tablets t
WHERE t.version_count > 400
ORDER BY t.version_count DESC
LIMIT 10;

-- 2. 若已触发写入拒绝，从错误日志中提取 tablet_id，定位对应表
-- 错误日志路径：FE日志 → doris/fe/log/fe.log

步骤2：手动触发 Full Compaction（核心操作）

-- 1. 优先对指定分区执行（减少资源消耗，推荐）
ALTER TABLE problem_table PARTITION(p20240301) COMPACT;

-- 2. 若分区较多或无分区，对整个表执行
ALTER TABLE problem_table COMPACT;

-- 3. 同时监控 Compaction 进度，确保正常执行
SHOW PROC '/compactions';
-- 关注 progress 字段，直到进度达到100%

步骤3：临时降低导入压力（辅助）

应用层：暂时降低该表的导入频率，合并导入批次（如将每秒1次导入改为每10秒1次）；
集群层：临时增加 Compaction 线程数（修改 be.conf 的 max_compaction_threads），重启BE（应急时可操作，平时不建议频繁重启）。

步骤4：确认恢复状态

-- 查看问题 Tablet 的版本数，降至400以下即可恢复写入
SHOW TABLET FROM problem_table 
WHERE version_count > 400;

-- 测试写入，确认恢复正常
INSERT INTO problem_table VALUES (1, 'test', '2024-03-01');

6.2 预防性配置调整（长期优化，避免复发）

应急处理后，必须调整配置，从根本上避免版本数再次达到阈值，以下是生产最优配置调整建议：

1. BE 端配置调整（be.conf）

# 1. 降低 Cumulative Compaction 触发阈值，提前合并
cumulative_compaction_num_cumulative_rowsets = 3  # 默认5，写入频繁时调整

# 2. 增加 Compaction 线程数，加快合并速度
max_compaction_threads = 20  # 根据CPU核数调整（如16核设为16）

# 3. 缩短 Base Compaction 间隔，更频繁深度合并
base_compaction_interval_seconds = 43200  # 12小时，默认1天

# 4. 调整 Cumulative 层最大产出大小，减少合并次数
cumulative_compaction_max_output_size = 5368709120  # 5GB，默认10GB（机械硬盘适用）

2. 表级别配置调整（重点优化高频写入表）

-- 1. 增大 Segment 大小，减少刷盘产生的小文件
ALTER TABLE high_write_table SET (
    "segment_size" = "536870912"  -- 512MB，默认256MB
);

-- 2. Unique Key 模型开启写时合并，减少版本产生
ALTER TABLE unique_key_table SET (
    "enable_unique_key_merge_on_write" = "true"
);

-- 3. 细化分区，避免单分区数据量过大、版本数过多
ALTER TABLE large_table ADD PARTITION (
    PARTITION p20240302 VALUES [('2024-03-02'), ('2024-03-03'))
);

3. 导入策略优化（核心预防手段）

控制导入频率：单表导入频率建议 < 30 次/分钟，避免高频小批量导入；
合并导入批次：使用 Stream Load 批量导入，将小批量数据合并为大批量，减少 Rowset 数量；
避免高峰期导入：大批量导入放在业务低峰期（如凌晨），减少 Compaction 压力。

6.3 版本数过高的根本原因与解决方案

很多时候，版本数过高是“配置不当+业务场景不匹配”导致的，需找到根本原因，针对性优化：

常见原因	典型表现	解决方案（优先落地）
高频小批量导入	每秒数十次导入，版本数快速增长，pending_num 持续>0	1. 应用层合并导入批次；2. 使用 Group Commit 功能
Compaction 资源不足	pending_num 持续>0，Compaction 耗时过长	1. 增加 max_compaction_threads；2. 升级CPU/SSD
磁盘 IO 瓶颈	Compaction 进度缓慢，IO 使用率>90%	1. 更换 SSD；2. 调整 Compaction 产出大小
Unique Key 模型无 MOW	更新操作频繁，版本数暴涨	开启 enable_unique_key_merge_on_write
分区设计不当	单分区数据量过大，版本数累积过快	细化分区（按天/小时），分散版本压力

七、总结：Compaction 运维核心要点

Compaction 是 Doris 平衡写入与查询性能的核心机制，版本数限制是集群的“安全红线”，生产运维需牢记以下4个核心要点，避免踩坑：

核心原则：预防为主，应急为辅，通过配置优化和监控告警，避免版本数达到500的硬性阈值；
关键配置：优先调整 Compaction 线程数、触发阈值、Segment 大小，匹配业务写入场景；
监控重点：聚焦“版本数（VersionCount）、Compaction 队列（pending_num）、合并耗时”三大指标，设置三级告警；
最佳实践：
- 高频写入表：开启 MOW（Unique Key）、增大 Segment 大小、合并导入批次；
- 定期维护：每天低峰期手动触发 Full Compaction，每周检查一次版本数分布；
- 资源配置：Compaction 线程数设为 CPU 核心数的50%-100%，避免资源浪费或不足。