1. Doris数据库优化概述

Apache Doris作为一款开源的MPP分析型数据库，凭借其出色的实时分析能力和易用性，近年来在数据仓库、用户行为分析、日志分析等场景中得到了广泛应用。但在实际生产环境中，随着数据量的增长和查询复杂度的提升，性能问题往往会逐渐显现。作为一名经历过多个Doris集群从零搭建到千万级数据量优化的DBA，我想分享一些实战中总结的优化经验。

Doris的优化工作不同于传统关系型数据库，它需要从分布式架构的特性出发，综合考虑数据分布、查询模式、硬件资源等多方面因素。一个未经优化的Doris集群与经过系统调优的集群，在相同硬件条件下性能可能相差数倍。本文将基于2.x版本的生产实践经验，从系统参数、表设计、查询模式三个核心维度展开具体优化方法。

2. 系统级参数调优

2.1 基础资源配置

BE节点的资源配置直接影响查询性能，以下是关键参数建议：

# BE节点JVM配置(建议总内存的70-80%) JAVA_OPTS="-Xmx64g -Xms64g -XX:+UseG1GC" # 单个查询内存限制(根据并发量调整) mem_limit=80% # 并行扫描线程数(建议CPU核数的50-75%) doris_scanner_thread_pool_thread_num=48

内存配置需要特别注意：BE节点的总内存应保留20%给操作系统和其他进程，避免OOM。我们曾在一个256GB内存的节点上配置了220GB给BE，结果频繁触发Linux OOM Killer导致节点异常。

2.2 存储引擎参数

针对SSD和HDD混合部署的环境，建议调整以下参数：

# 优化SSD上的数据写入 disable_storage_medium_check=true storage_engine=columnar # 调整compaction策略 cumulative_compaction_min_deltas=5 base_compaction_interval_seconds=86400

对于高频写入场景，需要特别关注compaction积压情况。通过以下命令监控：

SHOW PROC '/compactions'\G

当Running状态的compaction任务持续超过3小时，就需要考虑调整上述参数或增加BE节点。

2.3 网络与并发控制

跨节点数据传输是MPP架构的性能瓶颈，这些参数值得关注：

# 单个查询最大网络带宽(MB/s) query_bandwidth_limit=100 # 最大并行查询数 max_query_instances=32 # 连接池大小(建议每核2-3连接) brpc_max_connection=96

在万兆网络环境下，我们通过调整query_bandwidth_limit使跨节点分析查询性能提升了40%。但要注意设置过高会导致网络拥塞，建议通过逐步压测找到最佳值。

3. 表设计与数据分布优化

3.1 分区与分桶策略

合理的分区分桶设计是Doris性能的基石。以下是一个电商日志表的优化案例：

CREATE TABLE user_behavior ( dt DATE, user_id BIGINT, item_id BIGINT, -- 其他字段... ) PARTITION BY RANGE(dt) ( PARTITION p202301 VALUES LESS THAN ('2023-02-01'), PARTITION p202302 VALUES LESS THAN ('2023-03-01') ) DISTRIBUTED BY HASH(user_id) BUCKETS 32 PROPERTIES ( "replication_num" = "3", "storage_medium" = "SSD", "storage_cooldown_time" = "7 days" );

关键设计原则：

1. 分区粒度按查询模式确定，通常按天/周
2. 分桶数建议是BE节点数的整数倍（3-10倍）
3. 分布式键选择高基数且常作为JOIN条件的字段

我们曾将一个未合理分桶的20亿行表从16桶改为64桶，聚合查询速度提升了8倍。

3.2 数据模型选择

Doris支持三种模型，选择建议如下：

一个典型的物化视图使用案例：

-- 原始表 CREATE TABLE sales ( order_date DATE, region VARCHAR(50), product_id BIGINT, amount DOUBLE ) DUPLICATE KEY(order_date, region); -- 物化视图 CREATE MATERIALIZED VIEW mv_region_sales REFRESH ASYNC AS SELECT order_date, region, SUM(amount) AS total_amount FROM sales GROUP BY order_date, region;

物化视图可自动路由查询，但要注意：

• 单个表物化视图不超过10个
• 刷新间隔根据数据时效性需求设置
• 监控ALTER MATERIALIZED VIEW任务状态

3.3 冷热数据分离

对于时序数据，建议采用分层存储策略：

ALTER TABLE logs SET ( "storage_policy" = "hot_7d,cold_30d", "storage_cooldown_time" = "7 days" );

配合BE节点的存储路径配置：

storage_root_path=/ssd1;/hdd1

通过SHOW PARTITIONS监控数据迁移状态，确保热数据始终在SSD上。

4. 查询模式优化

4.1 执行计划分析

使用EXPLAIN命令深入理解查询行为：

EXPLAIN SELECT region, SUM(amount) FROM sales WHERE dt='2023-01-01' GROUP BY region;

重点关注：

• SCAN阶段的tabletRatio是否接近100%（数据倾斜）
• AGGREGATE是否出现LOCAL和GLOBAL两阶段
• EXCHANGE节点的数据量估算是否准确

我们曾通过分析执行计划发现一个JOIN查询因缺少本地谓词导致全表扫描，添加过滤条件后从30秒降到0.5秒。

4.2 索引与谓词下推

Doris的智能索引机制需要配合特定查询模式：

-- 优化前（无法利用索引） SELECT * FROM orders WHERE DATE_FORMAT(create_time,'%Y-%m')='2023-01'; -- 优化后（谓词下推） SELECT * FROM orders WHERE create_time>='2023-01-01' AND create_time<'2023-02-01';

建立合适的索引：

ALTER TABLE orders ADD INDEX idx_category(category) USING BITMAP;

注意点：

• 高基数字段不适合BITMAP索引
• 索引会增加约30%存储空间
• 监控SHOW INDEX_STATISTICS使用情况

4.3 并发控制与资源隔离

对于多租户环境，通过资源组实现隔离：

CREATE RESOURCE GROUP report_group TO ( 'user_report1','user_report2' ) WITH ( "cpu_share" = "50", "mem_limit" = "40%" );

在混合负载场景下，我们通过资源组将即席查询对固定报表的影响降低了70%。

5. 监控与持续优化

5.1 关键指标监控

建议监控的核心指标包括：

我们开发了一个基于Grafana的监控看板，包含以下关键面板：

• 查询热力图（按用户、类型分类）
• 资源使用率（CPU/Mem/Network）
• 数据分布均衡度

5.2 定期维护操作

建议的维护周期表：

一个实用的维护脚本框架：

#!/bin/bash # 自动统计信息收集 for tbl in $(mysql -hFE_HOST -P9030 -uroot -e "SHOW DATABASES" | grep -v Database); do mysql -hFE_HOST -P9030 -uroot -e "ANALYZE TABLE $tbl.*" done

5.3 版本升级策略

Doris的版本迭代较快，建议：

1. 先在测试环境验证SQL兼容性
2. 使用SHOW BACKEND确认各节点状态
3. 滚动升级时控制批次间隔（至少10分钟）
4. 监控升级后compaction积压情况

我们在2.0.2升级到2.0.4时曾遇到BE内存泄漏，通过分批回滚最小化影响。

经过以上系统化的优化，我们成功将一个查询P99延迟从15秒降到800毫秒，同时支持了3倍以上的并发量。Doris的优化是个持续过程，需要结合业务特点不断调整。建议每月进行一次全面的性能评估，及时发现潜在瓶颈。