腾讯面试：介绍一下 Doris 问题排查思路，有没有总结过相关文档？

Apache Doris 作为一款高性能的 MPP 分析型数据库，在数据处理和分析领域得到了广泛应用。然而，在使用过程中难免会遇到各种问题，如查询性能问题、数据导入问题、数据副本异常等。

本方案旨在详细介绍 Doris 常见问题的排查方法和解决方案，帮助用户快速定位和解决问题，确保 Doris 系统的稳定运行。

一、常见问题分类及排查方法

1. 查询性能问题

(1) 表现及原因

在 Doris 执行查询时，可能会遇到查询性能未达预期的情况，如查询速度慢、资源不足导致查询失败等。可能的原因包括 SQL 任务过大、数据分布不均、系统资源配置不足、索引未正确使用等。

(2) 排查步骤

获取 Profile：通过 Profile 可以查看查询的执行情况，找出可以优化的地方。在不同环境下获取 Profile 的方法如下：Doris 集群能够正常访问：使用请求方式 HTTP://FE_IP:HTTP_PORT GET /API/Profile。开启 Profile 上报参数 enable_profile，此参数为 session 变量，不建议全局开启。分析 SQL 任务：检查 SQL 任务是否可以进行拆分，对于包含大表计算的任务，分析是否有分区设计，以更好地利用分区裁剪能力。检查数据分布：使用 EXPLAIN 语句查看查询执行计划，确认索引是否被使用。如果数据在集群中分布不均，某些节点可能承担过多的计算任务，导致整体性能下降。可以重新设计分片键或调整数据分区策略。检查系统资源配置：查看系统的 CPU、内存、磁盘 I/O 和网络带宽等资源是否紧张。可以使用系统监控工具（如 top、iostat 等）来检查这些资源的使用情况。调整查询参数：适当调整 Doris 的查询参数，例如调整分片数或优化 Join 操作。2. 数据导入问题

(1) 表现及原因

数据导入问题包括导入失败、导入速度慢等。可能的原因有分区字段问题、数据类型不匹配、网络问题、资源瓶颈、配置错误等。

(2) 排查步骤

① Stream Load 导入慢

监控资源使用情况：确保 BE 的 CPU、内存、IO 等资源充足。查看日志：根据 Load ID 和 Txn ID 在 BE.INFO 日志中搜索慢请求，重点查看进行输送的 Coordinator BE。检查网络连通情况：检查客户端到 BE 的网络连通情况，如实时 ping 延迟和网络带宽。检查并发数：确认导入对应的并发数是否过高，如果并发数超过 HTTP Server 线程数（默认为 48），可能导致接收客户端数据慢。检查是否触发内存下刷：通过搜索 BE.INFO 中的 reducing 日志确认。检查是否导入 Mow 表：因 Mow 表需要计算 delete bitmap，并分析计算时间。

② Routine Load 消费慢

检查配置：确认 Routine Load 配置正确。查看任务状态：使用 SHOW ROUTINE LOAD 查看 abortedTaskNum，如果很多表明 Task 一直失败，需要在 FE 日志中根据 Job ID 查详细失败原因。检查资源瓶颈：如果配置没有问题，且 Task 没有失败，检查是否存在资源瓶颈。分析 Kafka 是否慢：可在 BE 日志中搜索 blocking get time(us)，如有显著高值，表明 Kafka 慢了。

③ Insert Into Select 导入慢

确认是否为查询慢导致：利用 SET dry_run_query = true 先运行查询。启用新最优化器：如果是 Doris 2.0 到 2.1.3 之间的版本，设置 enable_nereids_dml = true，2.1.3 之后默认开启。测试非前移对导入的影响：2.1 以上版本设置 enable_memtable_on_sink_node = false 进行测试。测试关 shuffle 对导入的影响：2.1 以上版本设置 enable_strict_consistency_dml = false 进行测试。调整并发数：Pipeline 模式调大 parallel_pipeline_task_num 增大并发；非 Pipeline 模式调大 parallel_fragment_exec_instance_num 增大并发。3. 数据副本问题

(1) 表现及原因

查询时可能会出现报错，如 Failed to initialize storage reader, tablet = {tablet_id}. xxx. xxx，原因可能是迁移副本过程丢 version、数据导入过程中 be 宕机等。

(2) 排查步骤

① 问题定位

获取异常 tablet 的详细信息：使用 show tablet {tablet_id} 拿到 detail cmd。执行 detail cmd：找出该 BE 所在的副本(compact status url 中包含有该 BE 的 ip)。执行 curl 请求：查看该副本的 rowset 和 missing_rowset，重点看 rowset 的最大版本和 missing_rowsets。

② 问题处理

确认是否自动修复：由于 Doris 内部会自动做数据均衡和修复，先确认异常数据副本能否自动修复。如果是多副本，查看是否存在健康副本，将查询报错的副本 set bad。

重新导数手动修复：如果是多个副本都损坏，并且是分区表的情况下，可以删除这个分区，然后手动重建这个分区，重新导入数据;如果是非分区表的情况下，只能删除这个表重新导入数据。填充空副本进行修复：使用一个空的 rowset 填充损坏的副本，缺多少个 rowset，就调用多少次修补的方法。4. 数据均衡问题

(1) 表现及原因

可能出现 BE 节点之间的数据不均、单个 BE 节点上的多个磁盘之间的数据不均、BE 节点的上线和下线进度卡死等情况。原因可能是参数配置不当、长事务阻塞、副本迁移超时、版本 BUG 等。

(2) 排查步骤

① 确认 FE 参数：使用 admin show frontend config like %xxxx% 检查 FE 的以下参数是否正确：

disable_balance = falsedisable_disk_balance = falsedisable_colocate_balance = falsedisable_tablet_scheduler = false

当 Doris 版本为 2.0.4 之后，对于单副本的数据，需要将 enable_disk_balance_for_single_replica 改成 true。

② 均衡状态检查

查看当前正在执行的调度：如果 running 任务正常，但是磁盘空间不下降，可能是均衡调度任务正常，需要清理下 trash，执行 admin clean trash；也可能是均衡调度异常，查看均衡调度的历史信息，查看是否有报错。查看均衡的历史记录信息：根据 Finished 进行排序，看是否有大量的 CANCELLED 状态。如果有，可以看最左边的 ErrMsg 日志，或者通过搜索 Master FE 的日志 grep "tablet schedule|TableSch" fe.log|grep tablet_id。均衡权重检查：可以通过 FE 的 8030 端口对应的 web 界面（点击 System=>cluster_balance）或 SQL 语句 show proc /cluster_balance/cluster_load_stat/location_default/HDD 查看。当 Class 均为 MID 时，代表当前集群的 BE 之间和单个 BE 的磁盘之间数据已均衡。均衡任务执行情况检查

③ 均衡参数调优

数据不够均衡：适当调小 balance_load_score_threshold 参数，触发均衡调度执行；调整 backend_load_capacity_coeficient 参数，决定让磁盘使用率更均衡，还是让 tablet 数目更加均衡。均衡速度慢：检查 BE 的 IO 是否很高，通过 `iostat -x 1` 查看读写的 IO 延时;调整均衡的线程数，如 `be.conf` 中的 `storage_medium_migrate_count` 和 `clone_worker_count`。5. Compaction 问题

(1) 表现及原因

可能出现 compaction score 高、Compaction 失败等问题，原因包括 compaction 持续失败、用户使用不当（如 bucket 数量设置不合适）、compaction 策略问题、导入速度超过 compaction 速度等。

(2) 排查步骤

① compaction score 高

判断是否为 compaction 持续失败导致：使用 grep ${tablet_id} be.INFO | grep compaction 查看是否有持续失败的日志，使用 curl ip:port/api/compaction/show?tablet_id=${tablet_id} 查看 compaction status。检查用户使用情况：确认建表时 bucket 数量设置是否合适。检查 compaction 策略：通过 curl ip:port/api/compaction/show?tablet_id=${tablet_id} 查看 tablet compaction 上一次执行的时间，使用 grep ${tablet_id} be.INFO | grep compaction 查看该 tablet compaction 执行的历史。如果是策略问题，可手动触发 compaction。判断是否为导入速度超过 compaction 速度：查看 compaction 一段时间内的平均并发数，计算统计的 clock time，比较实际并发和设置的并发限制。如果 CPU 负载不高，可调整 compaction 并发配置;如果 CPU 负载比较高，可考虑攒批导入或扩容。

② Compaction 失败：通过 grep compaction be.INFO | grep {tablet_id} 查看 compaction 失败的具体原因。

二、日志分析

Doris 提供了丰富的日志信息，帮助用户定位和解决问题。主要日志文件包括：

FE 日志（fe.log）：记录前端节点的运行信息和错误，可用于排查 FE 相关的问题，如查询计划生成、元数据管理等。BE 日志（be.INFO）：记录后端节点的运行信息和错误，可用于排查 BE 相关的问题，如数据存储、计算、导入等。Audit 日志：记录用户的操作日志，可用于审计和追踪用户的操作。

通过分析日志文件，用户可以了解集群的运行状态，发现异常情况，并采取相应的措施解决问题。例如，在排查查询性能问题时，可以查看 FE 日志中是否有查询超时、资源不足等信息；在排查数据导入问题时，可以查看 BE 日志中是否有导入失败、写入错误等信息。

三、监控与预警

1. 监控指标系统指标：如集群负载、CPU 使用率、内存使用率、磁盘 IO 等。查询指标：如查询数量、查询延迟、查询错误等。存储指标：如数据大小、数据压缩率、数据分布等。2. 监控工具

Doris 监控系统：Doris 数据库内置了完善的监控系统，提供丰富的监控指标和图表，帮助用户实时了解集群的运行状态和性能表现。

第三方监控工具：如 Prometheus、Grafana 等，可提供更丰富的监控指标和可视化功能，帮助用户深入分析集群性能。

3. 预警设置

根据监控指标设置合理的预警阈值，当指标超过阈值时及时发出预警，以便用户及时处理问题。例如，设置 CPU 使用率超过 80% 时发出预警，提醒用户检查系统资源使用情况。

Doris 问题排查需要综合考虑多个方面，包括查询性能、数据导入、数据副本、数据均衡、连接等问题。