[Bug] Doris Routine Load 消费 Kafka数据异常

[AlexLWei]

Search before asking

• I had searched in the issues and found no similar issues.

Version

Doris version 1.1.5-rc02-ef0635dae7

What's Wrong?

问题描述

Doris Routine load 消费Kafka某个Topic时会导致异常，有时候所有消费分组都会卡在同一个Offset上（不同消费分组可能不太一样），有时候只能消费某一两个分区。

以上图为例：
当前只能消费该Topic的2号分区，而且其Lag异常为小于-1的负数

当前环境描述：

Doris能继续正常消费除该分区以外的其他。
该topic的指定OFFSET也能通过其他方式消费出数据。

#做过的尝试：
修改OFFSET，各分区跳过20条数据——无效
stop 该routine load，删除消费分组，重新创建一模一样的routine load，消费OFFSET设定为原样——无效

What You Expected?

我不知道是什么原因导致的。

How to Reproduce?

No response

Anything Else?

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[AlexLWei]

需要补充一下的就是，如果一个分区消费堵塞了，那么他的Lag是>0的，而其他正常消费的分区Lag显示都是很大的负数，并随着消费数据量的上升而变小。

[whywuzeng]

你的 ROUTINE LOAD 创建语句 没发出来。看你这个bug ，惊得我专门去试了一下，没了问题。

[AlexLWei]

CREATE ROUTINE LOAD mapp_play_source_task ON app_play_source_tb
WITH APPEND
COLUMNS(date,dateTime,appId,bussType,userId,cdnType,title,mCode,programCode,appVer,catonNum,catonDuration,playDuration,duration,errsSum,eCode,category,model,sn,netType,cause,player,vcodec,quality,source,sourceCount,host,domain,ip,country,city,ISP,playCount,accumulative)
PROPERTIES
(
"desired_concurrent_number" = "1",
"max_error_number" = "3000",
"max_batch_interval" = "20",
"max_batch_rows" = "300000",
"max_batch_size" = "209715200",
"format" = "json",
"strip_outer_array" = "false",
"num_as_string" = "false",
"fuzzy_parse" = "false",
"strict_mode" = "false",
"timezone" = "+00:00",
"exec_mem_limit" = "4294967296"
)
FROM KAFKA
(
"kafka_broker_list" = "@@@",
"kafka_topic" = "AppPlaySourceSink3",
"property.group.id" = "AppPlaySourceGroupDoris",
"property.client.id" = "AppPlaySourceClientDoris",
"kafka_partitions" = "0, 1, 2",
"kafka_offsets" = "@@@, @@@, @@@"
);

以上是 routineload 的创建语句，

[AlexLWei]

你的 ROUTINE LOAD 创建语句 没发出来。看你这个bug ，惊得我专门去试了一下，没了问题。

我刚刚补充了下创建语句，具体我也不清楚是什么原因触发的

[BleethNie]

参考下我这个问题 #19174 看看是不是一样的问题

[AlexLWei]

更新一下，之后通过日志定位到相关问题：

，意思似乎是单挑数据过大导致消费堵塞，但是通过修改receive.message.max.bytes 也还是会报错。

关于如上问题我觉得已经与这个issus没有太大关系了，所以关闭了。