Routine Load 导入问题处理指南

在使用 Apache Doris 的 Routine Load 时，你是否曾经被各种奇奇怪怪的问题卡住？今天就来分享一些最常见的 Routine Load 问题，并提供相应的解决方案，让你快速应对，高效解决！

一、服务端参数配置

在 Doris 2.1.4 之前，你需要手动配置一些服务端参数：

FE 参数

max_routine_load_task_num_per_be=256
max_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,000
max_batch_size=10G

三、通过 SSL Kafka 集群进行导入

如果你需要访问带 SSL 认证的 Kafka 集群，完整的过程如下：

1. 上传认证文件

通过 CREATE FILE 命令上传认证文件，并设置 catalog 为 kafka：

sql 复制代码

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 相关的认证参数：

sql 复制代码

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 = 1
- max_error_number = 0

任意一项超出则抛出异常。结合自己对于数据质量的要求，做出适当调整。

2. Failed to get latest offset

有两种可能：

（1） Kafka 网络不通

java 复制代码

//报错案例
failed to get partition meta: Local:'Broker transport failure

一般都是到kafka的网络不通，ping或者telnet kafka的域名确认下。
如果使用的是域名的方式，需要在配置/etc/hosts 域名映射

（2）超时问题

java 复制代码

//报错案例
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 问题，你也可以轻松解决。下次看到各种奇奇怪怪的报错，就用这些方法和提示试试吧！

Routine Load 导入问题处理指南