Routine Load 导入问题处理指南
在使用 Apache Doris 的 Routine Load 时，你是否曾经被各种奇奇怪怪的问题卡住？今天就来分享一些最常见的 Routine Load 问题，并提供相应的解决方案，让你快速应对，高效解决！
一、服务端参数配置
在 Doris 2.1.4 之前，你需要手动配置一些服务端参数：
FE 参数
max_routine_load_task_num_per_be=256max_routine_load_task_concurrent_num=256
BE 参数
routine_load_consumer_pool_size=256
在 2.1.4 之后，这些参数可以不用配置。
二、任务参数配置
常见参数
desired_concurrent_number:如果配置了max_routine_load_task_concurrent_num，这个参数可以不配置max_batch_interval：最大批次间隔时间max_batch_size：最大批次数据量max_batch_rows：最大批次行数
注意⚠️：任意三者达到任意一个条件，则 task 将结束。
如果对数据可见性时间没有固定要求，可以将 max_batch_interval 设置举值大些，如 30s 或 60s。
max_batch_size 和 max_batch_rows 设置大一点，如：
max_batch_rows=200,000,000max_batch_size=10G
三、通过 SSL Kafka 集群进行导入
如果你需要访问带 SSL 认证的 Kafka 集群，完整的过程如下：
1. 上传认证文件
通过 CREATE FILE 命令上传认证文件，并设置 catalog 为 kafka：
CREATE FILE "ca.pem" PROPERTIES("url" = "https://example_url/kafka-key/ca.pem", "catalog" = "kafka");
CREATE FILE "client.key" PROPERTIES("url" = "https://example_url/kafka-key/client.key", "catalog" = "kafka");
CREATE FILE "client.pem" PROPERTIES("url" = "https://example_url/kafka-key/client.pem", "catalog" = "kafka");
2. 创建任务
设置与 Kafka 相关的认证参数：
CREATE ROUTINE LOAD db1.job1 on tbl1
PROPERTIES
("desired_concurrent_number"="1"
)
FROM KAFKA
("kafka_broker_list"= "broker1:9091,broker2:9091","kafka_topic" = "my_topic","property.security.protocol" = "ssl","property.ssl.ca.location" = "FILE:ca.pem","property.ssl.certificate.location" = "FILE:client.pem","property.ssl.key.location" = "FILE:client.key","property.ssl.key.password" = "abcdefg"
);
更多 Kafka 参数，可参阅 librdkafka 配置文档。
四、常见问题及解决方案
1. 默认参数过低：max_filter_ratio 和 max_error_number
- 默认值：
max_filter_ratio= 1max_error_number= 0
任意一项超出则抛出异常。结合自己对于数据质量的要求，做出适当调整。
2. Failed to get latest offset
有两种可能：
（1） Kafka 网络不通
//报错案例
failed to get partition meta: Local:'Broker transport failure
- 一般都是到kafka的网络不通，ping或者telnet kafka的域名确认下。
- 如果使用的是域名的方式，需要在配置/etc/hosts 域名映射
（2） 超时问题
//报错案例
java.util.concurrent.TimeoutException: Waited X seconds
目前有一个已知的三分库bug，会导致和kafka通信的consumer析构的时候卡住，导致持有锁，进而这个be所有的consumer都无法拿到锁导致无法消费和获取元数据，在fe端的表现可能为超时，下面这个栈
注意⚠️：这里只是可能，并不是一定是触发了这个bug
如何判断是不是触发了这个bug
- be没有获取元数据错误的日志，即搜不到下面这两个日志
- failed to get partition meta
- failed to get latest offset for partition
- 打一个pastack，搜routine_load/clean_idle_consumer线程，卡在consumer析构的栈上
可能避免出现bug的方法（不完全保证）
- 删除topic之前先pause/stop routine load
- 设置be参数routine_load_consumer_pool_size = 0
出现了该如何解决
重启be即可
3. 报错Bad message format
原因：Kafka 域名解析失败
- 修改
/etc/hosts，配置正确的域名映射。
4. 报错TOO_MANY_TASKS
- 首先检查配置，配置参考前面内容。
- 如果是 2.0.9 和 2.1.3 之前的版本，可以升级到更新版本，2.0.9和2.1.3之前都存在已知的bug导致TOO_MANY_TASKS的问题。紧急情况下可以重启BE尝试解决。
5. 创建任务时有字段带特殊字符
比如某些列名上有些特殊字符，加上反引号(``)即可
参考案例：
6. 升级后Routine load报语法错误
注意⚠️：不是常见问题，遇到了，按照下面的方式解决就行了
这是因为升级后报错关键词冲突了，比如desc group cross key workload这些关键词。原来创建的时候，加了反引号可以避免这个问题。
解决方案
这里需要回退版本，在老版本彻底删除routine load job, 具体删除步骤（确保create routine load的editlog被彻底删除）：
- stop routine load
- 触发checkpoint之后算彻底删除，这里可以通过缩短label_keep_max_second配置来加快checkpoint的频率。
7.routineload导入的数据时间点比kafka的小
如果routine load 使用now() 作为字段值的时候，数据时间有时候比实际入库的晚，有时候更早，这是符合预期的。
这是因为routineload的写入时间会在规划的时候确定，一个task的所有数据的时间都会用这个写入时间。
8. 其他情况
其他正常情况下，导入报错会返回一个Error URL，可点击链接获取具体报错原因。
注意⚠️：有些版本（如：2.1.3/2.1.4/2.1.5）没有报错URL，可以在
be.conf中storage_root_path配置的第一个目录下的be/storage/error_log找一下。2.1.6 修复了这个问题
学习这些实用技巧，直面 Routine Load 问题，你也可以轻松解决。下次看到各种奇奇怪怪的报错，就用这些方法和提示试试吧！
