第3.2章：Doris进阶使用——Compaction机制

吵吵叭火

已于 2024-03-01 07:18:09 修改

阅读量1.3k

点赞数 22

分类专栏： # Doris 文章标签： sql 数据库

于 2024-02-19 18:14:26 首次发布

本文链接：https://blog.csdn.net/SHWAITME/article/details/136172846

版权

Doris 专栏收录该内容

26 篇文章 8 订阅

订阅专栏

注：本篇文章阐述的是Doris 1.2.2版本之前的compaction机制

一、Compaction机制

1.1 LSM-Tree概述

LSM-Tree( Log Structured-Merge Tree)是数据库中最为常见的存储结构之一，核心思想是充分发挥磁盘连续读写的性能优势，以短时间的内存和IO磁盘开销换取最大的写入性能，数据以Append-only的方式写入Memtable ，达到阈值后冻结Memtable并Flush为磁盘文件，再结合compaction机制将多个小文件进行多路归并排序形成新的文件，最终实现数据的高效写入。为了降低读取时需要合并的数据量，基于LSM-Tree的系统会引入后台数据合并的逻辑，以一定策略定期的对数据进行合并，Doris中这种机制被称为compaction。 Doris中每批次的数据写入会生成一个数据版本，因此compaction机制就是异步将底层小的rowset数据版本合并成一个更大的版本。

1.2 Compaction概述

Doris 通过类似 LSM-Tree 的结构写入数据，后台通过 Compaction机制不断将小文件合并成有序的大文件。对于单一的数据分片（tablet），数据会按照顺序写入内存（写缓存memstore），达到阈值后刷写到磁盘，这些文件保存在一个rowset中。在Doris中，Compaction机制根据一定的策略对这些rowset合并成有序的大文件，极大地提升查询性能。

ps： Doris中数据组织如下图：

将数据表按照分区分桶规则，切分成若干个数据分片（tablet）存储在不同的be节点上。每个tablet都有多个副本（默认是3副本）。compaction是在每个be上独立进行的，compaction逻辑处理的就是一个be节点上所有的数据分片tablet。

1.3 Rowset数据版本

一个tablet中包含若干连续的rowset(rowset是逻辑概念)，rowset代表tablet中一次数据变更的数据集合（数据变更包括了数据新增，更新或删除等）。rowset按版本信息进行记录，版本信息中包含了两个字段first和second，first表示当前rowset的起始版本（start version），end表示当前rowset的结束版本（endversion）。

Doris的数据写入是以微批的方式进行的，每一个批次的数据针对每个tablet都会形成一个rowset（一个tablet是由多个rowset组成的）。每个rowset都有一个相应的起始版本和终止版本。对于新增的rowset，起始版本和终止版本是一样的，表示为[ 6-6]、[ 7-7]等。多个 rowset经过compaction会形成一个大的rowset。合并后的起始版本和终止版本是多个版本的并集，如[ 6-6]、[ 7-7]、[8-8]合并后变成 [6-8]，如下图：

rowset的数量直接影响到compaction是否能及时完成，那么一个批次的数据导入会生成多少个rowset呢？结论：rowset的数量直接取决表的分片数据Tablet。（一个表的Tablet总数量等于 = Partition num * Bucket num* Replica Num ）。即：当表的tablet数量是num时，一个批次的数据导入会新增num个rowset，也就意味着当前同时存在的rowset（数据变更的集合）就有num个。

有个疑问：单个tablet中的rowset版本个数过多会什么影响？

主要影响两个方面，一个是be存储节点的内存占用，当rowset的版本过多时，be节点的table_meta部分（主要是其中的rowset元数据部分）占用的内存可能非常多。同时compaction任务就会消耗大量内存与磁盘IO，资源开销较大容易引起oom，影响集群稳定性；二是查询会变慢，查询过程需要对tablet中的数据进行解压处理，当rowset版本很多时，数据解压会变慢，导致查询scan的耗时增加。

1.4 Compaction执行方式

Compaction执行方式可以分为两种类型：base compaction（基线合并）和cumulative compaction（增量合并），其中cumulative compaction（简称CC）负责将多个最新导入的增量数据进行合并，当增量数据合并后的大小达到一定阈值后，base compaction（简称BC）将基线版本（起始版本start version为0的数据）和与该增量数据版本合并。BC操作因为涉及到基线数据，而基线数据通常比较大，所以操作耗时会比CC长。

这两种compaction的边界通过cumulative point （简称CP）来确定。CP是一个动态变化的版本号，比CP小的数据版本只能触发BC，而比CP大的数据版本，只会触发CC。

1.5 Compaction优点

使得数据更加有序

每个rowset内部的数据是按主键有序的，但是rowset与rowset之间的数据是无序的，compaction会将多个rowset的数据从无序变成有序，提升数据再读取时的效率。

消除数据变更

数据以Append-only的方式写入，因此Delete，Update等操作都是标记写入，compaction会将标记的数据进行真正的删除或更新，避免数据再读取时进行额外的扫描及过滤。

增加数据聚合度

在aggregate模型上，compaction还可以将不同的rowset中相同key的数据进行预聚合，减少数据读取时的局和计算，进一步提升读取效率。

1.6 Compaction问题

虽然compaction在写入和查询性能方面发挥着关键作用，但是compaction任务执行期间的写放大问题以及随之而来的磁盘I/O和CPU资源开销，也会影响系统稳定性和性能。

不用应用场景，数据写入需求，写入任务并行度，单次提交数据量的大小，提交频次的高低等因素影响compaction策略，不合理的compaction策略则会导致：

1.6.1 Compaction速度低

在高频写入场景下，短时间内生成的rowset版本太快，如果compaction不及时，就会造成大量版本堆积，最终导致写入失败（-235/-238）；

理论上每次导入操作，不论是只导入一条还是十万、百万条，对于Doris来说，都是只生成一个新的roswet版本。那么在compaction效率有限的情况下，完全可以通过“攒微批+降频率”来规避roswet版本过多的问题。

1.6.2 写放大问题

Compaction本质上是将已经写入的数据读取后，重新写回的过程（读取多个小文件，合并成有序的大文件后再写回），这种重复的数据写入被称为写放大。一个好的compaction策略应该在保证效率的前提下，尽量降低写放大系数，因为过多的compaction会占用大量的内存及磁盘io资源，影响Doris集群的稳定性及查询性能，可能会导致BE OOM。

1.7 Compaction 调优

针对上述的compaction问题，可以从业务侧及运维侧进行调优。

1.7.1 业务侧

通过引导业务侧进行合理优化，对表设置合理的分区分桶，避免生成过多的数据分片
引导用户尽量降低数据的导入频率，增加每批次的导入数据量，从而降低compaction压力
引导用户避免过多的Delete 操作，Delete操作在底层会对数据标记成Delete版本

1.7.2 运维侧

针对不同的业务集群配置不同的Compaction参数

有些业务是实时写入数据，查询该数据的需求较多，此时可以将Compaction开的大一点以达到快速合并目的，避免影响查询性能。
而有些业务数据写入当天的分区，查询需求针对之前的分区，在这种情况下，可以适当的将Compaction 放的小一点，避免Compaction占用过大内存或CPU资源。在晚上的低峰阶段对新导入的小版本进行合并，这样对第二天查询效率也不会有很大影响。