Doris 中 Cumulative Compaction（CC）和 Base Compaction（BC）的区别...

在 Apache Doris 中，Cumulative Compaction（CC，累积合并） 和 Base Compaction（BC，基础合并） 是存储引擎中负责数据合并（Compaction）的两个核心机制。

它们的设计基础是 LSM-Tree 架构。由于 Doris 写入数据时会生成大量细碎的 Rowset（数据版本文件），为了避免“读放大”（读取时需要合并太多文件导致变慢），Doris 需要通过后台的 Compaction 任务将小文件合并为大文件。

以下是这两者的详细区别和工作原理：

维度	Cumulative Compaction (CC)	Base Compaction (BC)
定义	累积合并：将新写入的、细碎的小 Rowset 合并成一个较大的 Rowset。	基础合并：将 CC 合并后的较大 Rowset 与最老的 Base Rowset（通常是 Version 0-1）进行合并。
合并对象	增量数据（刚写入的、版本较新的小文件）。	存量数据 + 增量数据（历史最大的 Base 文件 + CC 产生的较大文件）。
触发频率	高频。通常在数据写入后快速触发。	低频。只有当累积的数据达到一定规模时才会触发。
资源消耗	低。每次处理的数据量较小，对 CPU 和 I/O 消耗较低。	高。因为涉及历史存量数据的重写，会消耗大量的 CPU 和磁盘 I/O。
主要目的	快速减少分片（Tablet）中的文件数量，防止读取时小文件过多导致性能急剧下降。	彻底消除过期版本，物理删除数据（Delete），做深度的聚合/去重，减少存储空间。
数据冷热	处理的是热数据。	处理的是冷数据（历史归档数据）。

为了更好地理解它们，需要引入一个核心概念：Cumulative Point（CP，累积点）。
Doris 会将一个 Tablet 中的所有 Rowset 分为两个部分，分界线就是 CP：

数据写入：每次 INSERT 或导入都会生成一个新的、版本号递增的 Rowset（例如 Version [4-4], [5-5], [6-6]）。
触发 CC：当 CP 之后的小 Rowset 数量达到阈值（默认 5 个，由 cumulative_compaction_min_multi_segments 控制）时，触发 CC。
合并：将这些小 Rowset 合并成一个稍微大一点的 Rowset（例如合并为 Version [4-6]）。
移动 CP：合并成功后，Cumulative Point (CP) 随之向右移动，将新合并的 Rowset 纳入 Base 区的边界内。

触发 BC：随着 CC 的不断进行，CP 不断右移，Base 区（CP 左边）积累的 Rowset 越来越多。当这些 Rowset 的尺寸或数量达到触发阈值时（例如未合并的段大小达到了 Base 尺寸的比例），触发 BC。
合并：将最古老的 Base Rowset (Version [0-3]) 与 CC 生成的 Rowset (Version [4-6]) 进行深度合并。
生成新 Base：生成一个全新的、超大的 Base Rowset (Version [0-6])。
空间释放：彻底物理删除旧的 Rowset，释放磁盘空间。

如果只有一种 Compaction，会带来严重的写放大（Write Amplification）问题：

假设只有 BC：每次新写入 1MB 的数据，都要和历史 1TB 的 Base 数据合并重写一次。这会导致磁盘 I/O 被瞬间写满，系统无法正常提供查询服务。
分层的优势（CC + BC）：
- CC 作为“缓冲垫”：快速把 1MB、2MB 的碎文件合并成 1GB 的中等文件。这个过程非常快，消耗资源少。
- BC 作为“终极整理”：等中等文件攒得足够多了（比如积攒到了 100GB），再和 1TB 的 Base 文件进行一次大合并。
- 通过这种“小步快跑（CC）”+“大步跨越（BC）”的机制，Doris 平衡了写入延迟、读取性能和资源消耗。

播面