doris用kettle进行抽数时Doris端单次最大导入行数与kettle端stream-loader组件限制的行数不一致

可能原因：

• 并发加载：多个Kettle任务可能同时向Doris提交stream load，导致同时处理的数据量远超单个批次的5万行

• TabletsChannel存活时间：如果channel在1200秒内没有接收到数据才会被移除，可能导致多个channel同时存在

• 批处理累积：网络延迟或处理慢时，多个批次可能在Doris侧累积，造成瞬时数据量激增

调优方案

1. BE端Stream Load参数调优
   核心参数调整：

调整单次Stream Load的数据量限制 ，建议从默认的100GB降低到合理范围：

streaming_load_max_mb = 1024 # 降低到1GB
对于JSON格式数据，调整 config.cpp:583 ：

streaming_load_json_max_mb = 50 # 从100MB降低到50MB
Channel生命周期管理：

调整TabletsChannel的存活时间 ，避免过多channel同时存在：

streaming_load_rpc_max_alive_time_sec = 600 # 从1200秒降低到600秒
调整tablet writer的RPC超时：

tablet_writer_open_rpc_timeout_sec = 30 # 从60秒降低到30秒
2. FE端超时和并发控制
Stream Load超时控制：

调整默认超时时间 ，避免任务长时间占用资源：

stream_load_default_timeout_second = 3600 # 从3天降低到1小时
设置最大超时限制：

max_stream_load_timeout_second = 7200 # 从3天降低到2小时
记录和监控：

启用Stream Load记录功能：

enable_stream_load_record = true
调整记录批次大小 ：

stream_load_record_batch_size = 100 # 从50增加到100
3. 资源控制和线程池调优
Fragment执行线程池：

调整fragment管理器的线程池配置 ：

fragment_mgr_asynic_work_pool_thread_num_min = 8 # 从16降低
fragment_mgr_asynic_work_pool_thread_num_max = 256 # 从512降低
fragment_mgr_asynic_work_pool_queue_size = 2048 # 从4096降低
发送批次控制：

调整发送线程池：

send_batch_thread_pool_thread_num = 32 # 从64降低
send_batch_thread_pool_queue_size = 51200 # 从102400降低
4. Kettle端配置建议
批次大小控制：

将Kettle的批次大小从5万行降低到1万行
设置合理的提交间隔，避免数据积压
并发控制：

限制同时运行的Stream Load任务数量不超过4个
在Kettle作业间添加适当的延迟间隔

这是有可能的，如果StreamLoad 写入慢了，客户端就会尝试攒更多的数据去做写入，这样可以减少streamload的频率，提高吞吐。这里没办法严格控制。