背景

为了接入实时事件数据 ，记R接入需要借助于StarRocks的数据RoutineLoad能力，将kafka的延迟数据接入到StarRocks的表中 ，在routine load比较多的记R接入情况下，出现大量的数据数据延迟，最高延迟达到了16分钟
。延迟

其中
，记R接入在创建routine load的数据脚本里，设置了如下参数：

• desired_concurrent_number等于kafka的延迟分区数

• max_batch_interval等于20

官方答复

咨询了官方后，官方给出如下答复（https://forum.starrocks.com/t/topic/1675）。记R接入

routine load 消费的数据并行度取决于以下四个属性的最小值
，增大并行度可以增加消费速率 ：

1. desired_concurrent_number，延迟创建routine load任务时指定参数 ，记R接入默认3。数据
2. kafka的延迟分区数。
3. fe的配置 max_routine_load_task_concurrent_num = 5。
4. be数量。

其中
，参数max_routine_load_task_concurrent_num是指每个routine load作业最大并发执行的task数  。

解决方案

鉴于此，有三个方向值得一试。

• 首先得考虑kafka的分区数是否合理，如果kafka过多 ，可以考虑缩小分区数对齐be节点个数，或者用多个routine load来接收同一个kafka不同分区的数据；
• 其次 ，调整参数max_routine_load_batch_size ，增加每次routine load接入的数据量；
• 最后扩容BE节点个数，再次基础上再去调整上面的参数 。

辅助

楼下的日志是截取于BE日志文件里的一段内容，从中可以分析每次接收的数据量以及耗时
。

data_consumer_group.cpp:131] consumer group done: 41448fb1a0ca59ad-30e34dabfa7e47a0. consume time(ms)=3261, received rows=179190, received bytes=9855450, eos: 1, left_time: -261, left_bytes: 514432550, blocking get time(us): 3065086, blocking put time(us): 24855