首页
/ Apache Doris 数据合并(Compaction)机制深度解析与调优指南

Apache Doris 数据合并(Compaction)机制深度解析与调优指南

2025-06-27 09:38:59作者:伍希望

概述

Apache Doris 采用类似 LSM-Tree 的结构存储数据,通过后台的数据合并(Compaction)机制持续将小文件合并为大的有序文件。合理调整合并策略可以显著提升数据导入和查询效率。本文将全面解析 Doris 的各种合并机制及其适用场景。

核心合并机制详解

垂直合并(Vertical Compaction)

技术背景: 传统合并算法在处理宽表场景时存在内存消耗大、执行效率低的问题。垂直合并是 Doris 1.2.2 引入的创新算法,专为大规模宽表场景优化。

实现原理

  • 将传统的按行合并改为按列组(Column Group)合并
  • 每次合并的粒度变为列组而非整行
  • 显著减少单次合并涉及的数据量

性能表现

  • 内存消耗仅为传统算法的 1/10
  • 合并速度提升约 15%

配置参数

enable_vertical_compaction = true  # 启用垂直合并
vertical_compaction_num_columns_per_group = 5  # 每组列数,默认5列性能最佳
vertical_compaction_max_segment_size = 268435456  # 合并后文件大小(字节)

段合并(Segment Compaction)

设计目标: 解决大规模数据导入时产生过多小文件的问题,避免出现 OLAP_ERR_TOO_MANY_SEGMENTS(-238)错误。

技术特点

  • 在数据导入过程中并行执行合并
  • 不会增加导入总时长
  • 资源消耗均匀分布在整个导入过程
  • 为后续查询和标准合并提供性能优势

配置建议

enable_segcompaction = true  # 启用段合并
segcompaction_batch_size = 10  # 合并间隔(每10个段触发一次)

适用场景

  1. 大数据量导入频繁出现 -238 错误
  2. 导入产生过多小文件(低基数字段或内存限制导致)
  3. 导入后需要立即查询
  4. 导入后标准合并压力过大

不适用场景: 当导入操作本身已耗尽内存资源时,不建议启用

单副本合并(Single Replica Compaction)

优化原理

  • 传统方式:每个副本独立执行合并,消耗 N 倍资源
  • 单副本合并:仅主副本执行合并,其他副本同步结果
  • 节省 N-1 倍 CPU 资源(N 为副本数)

配置方式

-- 建表时指定
CREATE TABLE ... PROPERTIES ("enable_single_replica_compaction" = "true");

-- 修改已有表
ALTER TABLE table_name SET("enable_single_replica_compaction" = "true");

合并策略选择

基于大小的策略(默认)

"compaction_policy" = "size_based"

适用大多数通用场景,按文件大小自动触发合并。

时间序列策略

"compaction_policy" = "time_series"

专为日志、时序数据优化,利用时间局部性原理:

  • 合并相邻时间段的小文件
  • 每个文件仅参与一次合并
  • 显著降低写放大问题

触发条件

  1. 未合并文件总大小 > time_series_compaction_goal_size_mbytes(默认1GB)
  2. 未合并文件数 > time_series_compaction_file_count_threshold(默认2000)
  3. 距上次合并时间 > time_series_compaction_time_threshold_seconds(默认1小时)

动态调整

ALTER TABLE table_name SET("time_series_compaction_goal_size_mbytes"="2048");

并发控制与资源管理

通过 BE 配置控制合并资源消耗:

max_base_compaction_threads = 4       # 基础合并线程数
max_cumu_compaction_threads = -1      # 累积合并线程数(-1表示每磁盘1线程)
max_single_replica_compaction_threads = 10  # 单副本合并传输线程数

最佳实践建议

  1. 宽表场景:优先启用垂直合并,列组大小保持默认5列
  2. 批量导入:预估会产生大量小文件时启用段合并
  3. 多副本集群:启用单副本合并节省资源
  4. 时序数据:选择时间序列策略并适当调整阈值
  5. 资源紧张时:降低合并并发度,优先保证导入和查询性能

通过合理配置这些合并机制,可以显著提升 Doris 集群的整体性能和稳定性。建议根据实际业务特点进行针对性调优。

登录后查看全文
热门项目推荐

热门内容推荐

最新内容推荐

项目优选

收起
docsdocs
OpenHarmony documentation | OpenHarmony开发者文档
Dockerfile
144
1.93 K
kernelkernel
deepin linux kernel
C
22
6
ohos_react_nativeohos_react_native
React Native鸿蒙化仓库
C++
192
274
openGauss-serveropenGauss-server
openGauss kernel ~ openGauss is an open source relational database management system
C++
145
189
RuoYi-Vue3RuoYi-Vue3
🎉 (RuoYi)官方仓库 基于SpringBoot,Spring Security,JWT,Vue3 & Vite、Element Plus 的前后端分离权限管理系统
Vue
930
553
nop-entropynop-entropy
Nop Platform 2.0是基于可逆计算理论实现的采用面向语言编程范式的新一代低代码开发平台,包含基于全新原理从零开始研发的GraphQL引擎、ORM引擎、工作流引擎、报表引擎、规则引擎、批处理引引擎等完整设计。nop-entropy是它的后端部分,采用java语言实现,可选择集成Spring框架或者Quarkus框架。中小企业可以免费商用
Java
8
0
openHiTLSopenHiTLS
旨在打造算法先进、性能卓越、高效敏捷、安全可靠的密码套件,通过轻量级、可剪裁的软件技术架构满足各行业不同场景的多样化要求,让密码技术应用更简单,同时探索后量子等先进算法创新实践,构建密码前沿技术底座!
C
423
392
金融AI编程实战金融AI编程实战
为非计算机科班出身 (例如财经类高校金融学院) 同学量身定制,新手友好,让学生以亲身实践开源开发的方式,学会使用计算机自动化自己的科研/创新工作。案例以量化投资为主线,涉及 Bash、Python、SQL、BI、AI 等全技术栈,培养面向未来的数智化人才 (如数据工程师、数据分析师、数据科学家、数据决策者、量化投资人)。
Jupyter Notebook
75
66
CangjieCommunityCangjieCommunity
为仓颉编程语言开发者打造活跃、开放、高质量的社区环境
Markdown
1.11 K
0
openHiTLS-examplesopenHiTLS-examples
本仓将为广大高校开发者提供开源实践和创新开发平台,收集和展示openHiTLS示例代码及创新应用,欢迎大家投稿,让全世界看到您的精巧密码实现设计,也让更多人通过您的优秀成果,理解、喜爱上密码技术。
C
64
511