在大数据处理领域，Doris 凭借高效的查询与分析能力成为众多企业的选择，而数据导入作为数据处理的首要环节，其性能直接影响整个系统的效率。实际应用中，Stream Load、Routine Load、Insert Into Select 等导入方式常出现速度缓慢的问题。本文将结合官方文档、实战经验以及关键优化策略，为大家提供一套完整且详细的性能优化方案。
一、数据导入核心优化原则
在深入探讨具体导入方式优化前，先了解 Doris 数据导入的通用优化原则，这些原则贯穿于各种导入场景，是提升整体性能的基础。
1.1 表模型选择策略
优先选用明细模型。明细模型在数据导入时，无需复杂的数据聚合转换，减少了计算开销；在查询阶段，能够快速响应复杂查询需求，相比其他模型具有显著优势。若需深入了解不同模型的特点与适用场景，可参考数据模型官方文档。
1.2 分区分桶精细配置
科学合理的分区分桶设置对 Doris 性能至关重要。建议将单个 tablet 的大小控制在 1 - 10G 范围内。若 tablet 过小，数据聚合效果不佳，频繁的小文件操作会增加元数据管理压力，降低查询效率；若 tablet 过大，在副本迁移、补齐等操作时会耗费大量时间和资源。具体配置方法可查阅建表最佳实践官方文档。
1.3 导入策略深度优化
Random 分桶优化技巧：当使用 Random 分桶时，通过设置
load_to_single_tablet=true启用单分片导入模式。此模式在处理大规模数据导入时，能显著提升导入的并发度和吞吐量，有效减少写放大问题。相关详细内容可参考 Random分桶官方文档。攒批导入策略：客户端攒批是避免高频小导入引发性能问题的有效手段。建议将数据在客户端攒批至数 MB 到数 GB 大小后再进行导入，这样可以减少 compaction 的频率，降低写放大。对于高并发小数据量导入场景，可在服务端打开 Group Commit 功能实现攒批导入，提高导入效率。Group commit 官方文档
分区与大规模导入策略：每次导入尽量只涉及少量分区的数据，防止过多分区同时导入导致内存占用过高，进而引发性能问题。因为 Doris 每个 tablet 在内存中对应一个活跃的 Memtable，当 Memtable 达到一定大小或活跃 Memtable 占用内存过高时，会触发下刷操作，过多分区同时导入可能导致频繁下刷，产生大量小文件，影响导入性能。在处理大规模数据导入时，应采用分批导入的方式，对于 Broker Load，每批次导入的数据量建议不超过 100G；对于本地的大数据量文件，可借助 Doris 提供的 streamloader 工具，其会自动进行分批导入，降低系统压力。
并发控制策略：根据不同的导入方式和数据类型，合理设置并发数。对于压缩文件、Parquet、ORC 文件，建议将文件分割成多个小文件进行多并发导入；非压缩的 CSV 和 JSON 文件，Doris 内部会自动切分文件并并发导入。在 Stream load 导入时，单 BE 上的并发数建议不超过 128（由 BE 的
webserver_num_workers参数控制），过高的并发数可能导致 webserver 线程资源不足，影响导入性能，当单个 BE 的并发数超过 512（doris_max_remote_scanner_thread_pool_thread_num参数）时，甚至可能导致 BE 进程卡住。
二、Stream Load 导入性能深度优化
Stream Load 是通过 HTTP 协议将本地文件或数据流导入到 Doris 的常用方式，以下从性能瓶颈诊断到解决方案进行详细阐述。
2.1 性能瓶颈精准诊断流程
当 Stream Load 导入出现延迟时，可按以下步骤逐步定位问题：
资源实时监控：借助系统命令实时监测 BE 节点的 CPU、内存、IO 及网络状态。例如，使用
top命令查看 CPU 和内存使用率，判断是否存在资源争抢；通过iostat命令分析磁盘 IO 情况，检查是否有磁盘读写瓶颈；利用iftop等工具监控网络带宽，查看是否存在网络延迟或丢包问题。日志深度分析：利用 Load ID 和 Txn ID 在BE.INFO日志中检索慢请求，重点关注 Coordinator BE（即接收 Stream Load 请求的节点）。对日志中的关键信息进行深入解读：
接收数据阶段：若
Received time耗时较长，或出现mark closed慢、finished to close olap table sink后端处理快的情况，表明接收数据过程存在延迟。此时可进一步检查客户端与 BE 之间的网络连接，或客户端自身的发送数据能力。内存下刷阶段：通过
finished to close olap table sink中的node add batch time或close time判断 memtable 下刷是否缓慢。同时，结合curl 127.1:8040/metrics命令查看doris_be_flush_thread_pool_queue_size和memtable_flush_task_num指标，若队列长度或任务数过高，说明存在 memtable flush 排队积压问题。提交发布阶段：检查返回客户端的
CommitAndPublishTimeMs，或在日志中搜索finished to execute stream load查看commit_and_publish_txn_cost_ms，通过这些指标判断 FE 或 BE 是否存在耗时瓶颈。若commit_and_publish_txn_cost_ms时间过长，可通过 txn id 在be.INFO和 fe.log 日志中进一步分析是 FE 还是 BE 导致的延迟。
2.2 常见问题与详细解决方案
| 问题类型 | 可能原因 | 详细解决方案 |
|---|---|---|
| 接收数据慢 | 客户端网络延迟或资源不足 | 1. 使用ping命令测试客户端到 BE 的网络延迟，若延迟过高，可优化网络拓扑，增加带宽或调整物理距离。 2. 监控客户端 CPU、IO、内存等资源使用情况，若存在资源瓶颈，可关闭不必要的进程或升级硬件 配置。 3. 调整客户端导入并发，避免单 BE 过高压力，可通过降低导入任务的并发数量，观察导入性能是否改善。 |
| Http server 处理能力不足 | curl 127.1:8040/metrics | grep doris_be_streaming_load_current_processing，看下当前正在处理stream Load数是不远大于web_server的线程数，如果大于基本是http sever这的瓶颈。 | |
| 内存下刷慢 | IO 性能瓶颈 | 1. 检查磁盘ioutil使用率，若接近 100%，说明磁盘 IO 已打满，可考虑更换高速磁盘（比如hdd换ssd）。 2. 使用pstack查看下刷线程是否卡在写盘操作上，若存在此情况，可进一步排查磁盘驱动或文件系统问题。 3. 优化磁盘配置，如采用 RAID 阵列提高读写性能，或调整磁盘缓存参数。 |
| 内存使用过高 | 1. 调整导入批次大小，减少单次导入数据量，通过多次小批次导入替代一次大批量导入，降低内存峰值占用。 2. 优化表结构，去除冗余字段，减少数据存储所需内存空间；同时，合理设置列的数据类型，避免过度占用内存。 | |
| Commit 和 Publish 慢 | BE 计算 Delete Bitmap 耗时 | 1. 对于 Mow 表，优化表结构设计，减少不必要的复杂计算，例如简化分区键和分桶键的设置。 2. 调整数据分布，避免数据倾斜导致某一节点计算压力过大。 3. 定期对 Mow 表进行优化操作，如重建索引或统计信息更新。 |
| FE 锁竞争或 GC 延迟 | 1. 降低导入并发，减少多个任务同时竞争 FE 资源的情况，通过逐步降低并发数量，观察性能改善情况。 2. 分析 FE 的 GC 日志，调整 JVM 参数，如增大堆内存、调整垃圾回收算法等，优化 GC 性能。 3. 优化 edit log 写入配置，例如调整写入频率、使用更高效的存储介质，提升 edit log 写入性能。 |
三、Routine Load 消费性能全面优化
Routine Load 用于持续消费 Kafka Topic 中的数据，以下是针对其消费慢问题的详细排查与优化方法。
3.1 消费慢问题系统排查
配置详细校验：仔细核对 Routine Load 配置参数，包括 Kafka 连接地址、端口、Topic 订阅信息、数据转换规则（如字段映射、数据类型转换等）。任何一个参数配置错误都可能导致数据消费异常，例如 Kafka 连接地址错误会使 Doris 无法获取数据，数据类型转换错误可能导致数据解析失败。
任务状态深度检查：通过
SHOW ROUTINE LOAD命令查看abortedTaskNum，若该数值较高，说明存在大量任务失败。此时需在 FE 日志中根据 Job ID 定位失败原因，日志中会详细记录任务失败的具体信息，如网络连接失败、数据格式不匹配等。资源与 Kafka 性能综合分析：
检查 BE 节点资源是否充足，包括 CPU、内存、磁盘等。若资源不足，可能导致 Kafka 数据消费缓慢，例如内存不足会使数据处理速度下降，磁盘 IO 瓶颈会影响数据落地效率。
在 BE 日志中搜索
blocking get time(us)，若存在显著高值，表明 Kafka 消费延迟。此时需排查 Kafka 集群性能问题，如 Kafka 分区负载不均衡、消息堆积等。
3.2 优化建议与实施细节
任务并发度精准调整：根据集群资源情况和数据量，合理调整 Routine Load 任务并发度。过高的并发度可能导致资源过度占用，反而降低消费效率；过低的并发度则无法充分利用系统资源。可通过逐步增加或减少并发任务数量，观察数据消费速度和系统资源利用率，找到最佳并发设置。
Kafka 分区配置优化：优化 Kafka 分区配置，确保分区数量与 Doris 消费能力相匹配。适当增加分区数量可以提高消费并行性，但过多的分区也会增加管理成本。同时，保证 Kafka 分区负载均衡，避免部分分区数据过多，影响整体消费性能。
定期数据清理策略：定期清理过期数据，减少 Kafka Topic 中的数据积压，降低 Doris 的数据处理压力。可根据业务需求设置数据保留期限，例如对于时效性较低的日志数据，可保留一周或一个月后自动清理。
四、Insert Into Select 导入性能高效优化
Insert Into Select 用于将 Doris 查询结果导入到另一个表中，以下是提升其性能的具体策略。
4.1 性能提升系统策略
查询性能优先优化：使用
SET dry_run_query = true模拟查询，该命令不会实际执行数据导入操作，但会执行查询部分，通过分析模拟查询的执行计划和耗时，定位是否因查询本身缓慢导致导入延迟。若查询存在性能问题，可进一步优化查询语句，如添加合适的索引、优化 JOIN 条件等。优化器与功能开关精细调整：
Doris 2.0 - 2.1.3：设置
enable_nereids_dml = true启用新优化器，Nereids 优化器能够更高效地生成查询执行计划，提升查询性能。(这个版本还是推荐升级一波)2.1 以上版本：
通过
set enable_memtable_on_sink_node = false测试关闭 MemTable 前移的影响。MemTable 前移在 2.1 版本中默认开启，可提升导入性能，但在某些特殊场景下可能会带来问题，关闭此功能可作为一种性能调优手段。使用
Set enable_strict_consistency_dml = false调整 Shuffle 策略，关闭严格一致性可减少数据在 SINK 上的分布不均衡问题，但需注意对数据一致性的影响。开关
Pipeline相关参数（experimental_enable_pipeline_engine和experimental_enable_pipeline_x_engine），并调整并发参数（parallel_fragment_exec_instance_num或parallel_pipeline_task_num）。开启 Pipeline 模式可提高查询执行的并行性，通过调整并发参数，可根据系统资源情况优化执行效率。
Profile 深度分析与优化：开启
enable_profile = true获取导入的 Profile，深入剖析各阶段耗时。通过 Profile 信息，可清晰了解查询执行过程中各个算子的执行时间、资源占用情况等，从而针对性地进行优化。例如，若发现某个 JOIN 算子耗时较长，可优化 JOIN 算法或调整表的分布方式。
通过以上对 Doris 数据导入的优化策略，从通用原则到具体导入方式的深度优化，可根据实际业务场景和系统状况，灵活调整优化方案，有效提升数据导入性能，充分发挥 Doris 在大数据分析场景中的强大潜力。如有其他疑问或者方案欢迎留言讨论～