Doris 常见问题--E-MapReduce-火山引擎

文档中心

立即注册

导航

Doris 常见问题

最近更新时间：2025.11.13 17:35:28首次发布时间：2025.11.07 23:38:46

Doris 集群如何添加访问白名单

问题现象
连接Doris实例时，连接超时：

原因分析
连接Doris实例的主机或客户端IP地址未加入Doris实例的网络连接白名单。
解决方法
- 打开Doris实例，依次打开网络连接 > 白名单管理 > 入方向白名单 > 添加白名单组，完成添加后点击确定，示例：
- 非同一个VPC下面的连接实例，请使用公网地址，示例：
注意事项
- 不建议设置0.0.0.0/0，允许所有地址访问，将产生安全访问风险；

Doris 集群通过公网导入数据或查询时失败

问题现象

通过与Doris实例不在同一VPC下面的主机或客户端连接Doris实例时，连接超时或网络不通。

原因分析

需要通过公网地址连接Doris实例，并将目标主机的公网地址加入Doris实例的网络连接白名单。

解决办法
- 打开Doris实例详情，并依次打开网络连接 -> 公网连接 -> 开启公网 IP -> 绑定公网 IP，选择可用的公网IP地址后，点击确定。若无可用的公网IP地址，请通过创建公网IP进行新建。
- 将目标主机的公网地址加入当前实例的白名单组，请参考“如何添加Doris集群访问白名单”进行添加。

Doris 集群不同业务之间的资源隔离

问题现象

不同业务线使用同一个Doris集群，导致作业相互影响。

原因分析

未做资源隔离，导致作业之间相互影响。

解决方法
参考Doris官方文档，进行资源划分：
[推荐使用] Resource Group方式：多租户和资源划分
Workload Group方式：Workload Group

Doris 集群Tablet不均衡

问题现象
通过 show backends; 查询BE节点上的Tablet数量，出现不均衡现象：
原因分析
扩容等操作完成后未执行re-balance操作，导致数据不均衡，且Doris自动均衡参数lake_enable_balance_tablets_between_workers默认值为false。
解决方法
- 通过以下命令开启自动均衡

ADMIN SET FRONTEND CONFIG (lake_enable_balance_tablets_between_workers=true);

注意事项
- 开启自动均衡后会产生额外的资源消耗，建议业务低峰期进行操作，且在完成后关闭该设置；
- 存算分离场景下，长时间开启Tablet均衡会导致冷查询数量增加，增大查询延时。

Doris FE 连接池打满

问题现象

向Doris建立新连接时报下列错误

Reach limit of connection

原因分析

集群新建连接数过多，达到FE或用户的连接数上限

解决办法
- 先确认是否达到FE的连接数上限，打开Doris实例详情，并依次打开监控告警 > FE连接数情况查看监控情况，如果连接数达到FE配置 qe_max_connection 所设定的上限，可通过修改FE配置文件中的 qe_max_connection 参数上调至合理阈值，修改后重启FE使其生效

若监控表示未达到FE配置 qe_max_connection 所设定的上限，则是由于达到了User级别的连接数上限，通过

-- 查看user的连接数上限
show property for '用户名';

-- 修改user级的连接数限制
set property for '用户名' 'max_user_connections' = 'xxx';

Doris BE 节点执行Compaction操作导致CPU持续打高

问题现象

BE节点CPU持续打满，Compaction任务数与BE节点的核数相同。

原因分析

BE节点的规格为4 vCPU，通过Base Compaction进行小文件合并时的并发限制为4，导致CPU资源被打满。

解决方法
- 减少同时执行Compaction任务的线程数：

-- base compaction 的线程数，默认是 4
max_base_compaction_threads
-- cumulative compaction 的线程数，默认是 10
max_cumu_compaction_threads

对BE节点进行升配，提高集群配置: 实例升配

Doris 大查询导致资源打满

问题现象

单个查询/作业将CPU使用率打满到100%，并持续10秒以上，大量挤占集群资源，导致正常的查询失败或者延时增加。

排查思路
- 参考大查询定位定位正在运行的大查询
解决办法
- 根据大查询定位的结果，将大查询手动终止；并结合业务使用与查询审计日志表进行查询治理
- 可选择基于大查询防御来部署防御策略，以降低未知大查询带来的业务影响

Doris BE Compaction Score 过高

问题现象

Doris集群读写性能下降或报错，通过监控发现BE节点上的Compaction Score过高

原因分析
- Compaction score过高，说明当前集群小文件较多，根本原因是由于写入频率与小文件的合并效率不匹配
解决方法
- 建议降低客户端写入频率，增大客户端数据攒批，避免产生大量小文件
- 在资源允许的情况下，参考 Compaction 优化提高Compaction的并发度

Doris BE Tablet Version 超限

说明

该说明仅适用于存算一体Doris实例

问题现象

Tablet version数量超出限制，执行Insert Into等操作时出现错误：

ERROR 5025 (HY000): Failed to load data into tablet XXXX, because of too many versions, current/limit: 6/5. You can reduce the loading job concurrency, or increase loading data batch size. If you are loading data with Routine Load, you can increase FE configs routine_load_task_consume_second and max_routine_load_batch_size... ...

原因分析

上述报错是因为导入频率太快，数据没能及时合并 (Compaction)，从而导致版本数超过支持的最大未合并版本数。默认支持的最大未合并版本数为 1000

解决方法
- 上调参数限制，重启集群生效，让写入事务先提交

Doris 事务超限

问题现象

写入事务数量超出限制，写入操作时出现错误：

current running txns on db xxxx is xxxx, larger than limit xxxx

问题排查
- 查看每个database的事务积压情况：

-- Doris
show proc '/transactions';
-- 查看每个db的情况
show proc '/transactions/${db_id}';
-- 查看已完成的导入事务 找到失败事务 查看原因
show proc '/transactions/${db_id}/finished';

解决方法

动态将事务上限提高，让事务先进来，缓解上游写入任务的时延：

-- Doris引擎
-- 调整FE配置 需要重启才能生效
-- 默认 1000
admin set frontend config ("max_running_txn_num_per_db" = "xxx")

评估集群资源水位情况，考虑升配或扩容

Doris 写入报错 `too many filter rows`

问题现象

数据写入 Doris 时失败，报错提示 too many filtered rows。举例：

{
  "Status": "Fail",
  "BeginTxnTimeMs": 101,
  "Message": "too many filtered rows",
  "NumberUnselectedRows": 0,
  "CommitAndPublishTimeMs": 0,
  "Label": "xxxxxxxxx",
  "LoadBytes": 245396,
  "StreamLoadPlanTimeMs": 102,
  "NumberTotalRows": 984,
  "WriteDataTimeMs": 265,
  "TxnId": 13787,
  "LoadTimeMs": 469,
  "ErrorURL": "http://xx.xx.xx.xx:8040/api/_load_error_log?file=error_log_5a4aad49f7900ad7_9dec92739f8027b7",
  "ReadDataTimeMs":0,
  "NumberLoadedRows":0,
  "NumberFilteredRows":984
}

问题排查

Doris 为保证数据质量，默认会对写入数据进行合法性校验，当数据不符合 Doris 表的字段类型时，会被过滤掉。当过滤行占总行数的比例超过阈值时，系统会终止写入，避免大量无效数据占用资源或破坏数据一致性。
用户可通过报错信息中的url查看具体的报错原因，常见原因有：

数据本身存在问题（脏数据）。
字段分区配置错误，如：列字段无法对齐、类型不一致等。

解决办法
- 规范数据源头校验：在上游业务系统中添加数据校验逻辑（如类型检查、格式校验、约束校验），从源头减少脏数据；
- 合理设置容错率：生产环境中 max_filter_ratio 建议设置为 0.05~0.1（5%-10%），既允许少量偶发脏数据，又避免大量无效数据写入。
- 更多操作可参考数据导入故障排查。

E-MapReduce