2/22 19:00 直播 | StarRocks 实战系列 Ep.2—导入优化＆问题排查（转发、打卡还可以获得积分奖品！）

2月8日第一期 “部署&导入” 篇开播后，我们收到了社区小伙伴们的众多好评，为了不辜负大家的学习热情，社区决定将后面3期的内容一并放出，大家可以提前预留好时间，与我们一起直播打卡。

image1125×3300 396 KB

经过第一期的学习，相信大家对不同导入方式，以及实际业务场景具体选择哪种导入已经心中有数，但实际操作中：

• 每种导入方式，在大规模数据量的导入情况下，怎样合理去配置参数和针对性地调优？

• 发生数据质量错误 “ETL_QUALITY_UNSATISFIED; msg:quality not good enough to cancel” 应该如何处理？

• 导入过程中，发生远程过程调用（Remote Procedure Call，简称 RPC）超时问题应该如何处理？

• 等等一系列导入中会遇到的问题。

2月22日（下周三）19:00-20:00，“StarRocks 实战系列第二期–导入优化&问题排查”开播，镜舟科技技术支持工程师 Eddie，将在线为大家梳理不同导入方式的优化方案，将常见的导入问题一网打尽。

干货满满，不要错过！马上扫码预约直播，加入我们，一起玩转 StarRocks！

image1125×2898 334 KB

image953×199 98.6 KB

• 【重要】积分记录、中奖名单、直播 QA 和回放等，请至论坛查看： 2/22 19:00 直播 | StarRocks 实战系列 Ep.2—导入优化＆问题排查（转发、打卡还可以获得积分奖品！）

• 转发朋友圈截图及直播间观看截图均在本次活动问卷中进行填写 （问卷填写截止时间为： 2023年2月23日21:00 前，过期将不可再填写） 活动问卷请填写：https://tl-tx.dustess.com/aTpuvg9W5W

• 该系列直播积分可累积，如：

  • 打卡“部署&导入”篇， 完成上述所有奖励行为事件，获得 40 积分

  • 打卡本次直播，完成上述所有奖励行为事件，获得 40 积分，加上累积的 40 积分，此时总和为 80 积分

  • 依此类推，当累计积分达到50分及以上，即可参与积分兑奖

• 可以选择立即兑换相应奖品，或者等完成上述全部打卡后，根据自己的积分总和在积分商城选择想要的奖品进行兑换，未兑换完的积分将在本系列直播结束后（2023年3月底）自动清零。

• 成功打卡 全部直播 的小伙伴，将会额外获得 StarRocks 社区纪念徽章。

• 兑换奖品时请填写：https://tl-tx.dustess.com/4kTjGagl6W

StarRocks 实战系列直播奖品及兑换方式

image1125×3030 686 KB

更新积分：

image1550×610 72.6 KB

如需兑奖请填写该问卷：
https://tl-tx.dustess.com/4kTjGagl6W

1. 蒲月：我之前导入的时候，会报错，RPC超时的问题，这个应该如何处理

A：您可以检查下 BE 配置文件 be.conf 中 write_buffer_size 参数的设置。这个参数是用来控制 BE 上内存块的大小的，默认阈值为 100 MB。阈值过大的话，可能就会导致远程过程调用 RPC超时

2. liujie：routing load 怎么调优？怎么降低磁盘io

A：可以从多个方面进行调优，当routine load出现性能问题时，可以考虑从如下几个维度来进行参数调优。

1） 任务调度周期

max_batch_interval

通过缩短任务调度周期加速数据消费。但是，更小的任务调度周期可能会带来更多的CPU资源消耗。

需要注意的是，任务调度周期最小值为5s。

2）任务并行度

max_routine_load_task_concurrent_num

desired_concurrent_number

在partition数量和BE数量较多时，可以通过设置较大的该参数来加速任务执行。但是，更大的并行度可能会带来更多的CPU资源消耗。

单个 routine load 任务会根据kafka topic partition数、BE数等被拆分为若干个子任务，分发至多个BE执行。这里的任务并行度，实际上是指单个routine load拆分成的子任务个数。

任务并行度取决于 Job 配置 desired_concurrent_num、可用 BE 数、 FE 配置、topic partition数和 max_routine_load_task_concurrent_num 的最小值，具体的计算方式如下：

concurrent_num = Min(partition_num, desired_concurrent_num, alive_be_num, Config.max_routine_load_task_concurrent_num)

因此，在调整该参数时需要综合考虑BE数量和partition数量。

3）任务批量大小

routine_load_task_consume_second

通过增大单次读取持续时间加速数据消费。

max_routine_load_batch_size

通过增大单次读取的数据量加速数据消费。

I0325 20:27:50.410579 15259 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

可以根据如上的日志来判定当前的批量参数设置是否过小。正常情况下，该日志的 left_bytes 字段应该 >= 0，表示一次读取的数据量还未超过 max_routine_load_batch_size上限 。否则，说明 max_routine_load_batch_size 过小。

3. 猫咪卡在臭豆：我总遇到 too many tablet versions，怎么处理？

A：这种一般是因为导入频率太快了，数据没能及时合并 ，从而导致版本数超过支持的最大未合并版本数。默认支持的最大未合并版本数为 1000的。可以通过 ：增大单次导入的数据量，降低导入频率来解决 ，或者说您的集群资源很好 那就可以修改下be中的几个compaction加速合并的配置项 具体的可以去论坛上搜搜下 be.conf 中修改以下配置，通过调整合并策略实现加快合并的目的：

修改完成后，需要观察内存和 I/O，确保内存和 I/O 正常。

4. liujie：insert into select 能忽略错误执行吗？

A：insert into select是同步执行的任务 ，任务出错后会直接返回状态和错误信息，失败的任务需要排查修改错误点后才能进行重试，所以不能忽略，排查手段参考：[问题排查]导入失败相关

5. 高雪熠：insert into from 外表这种导入方式和broker load性能相比有什么差距吗？还是性能是基本相当的

A：基本相当 只是导入方式的选择区别

6. 金双贤：导入支持做资源隔离吗？

A：当前仅支持计算部分

7. #000FF#： 我上次 Broker Load 导入作业没报错，但为什么却查询不到数据呢？

A：Broker Load 是一种异步的导入方式，就是按照前面讲的吗创建导入作业的语句没报错，不代表导入作业成功了。可以通过 SHOW LOAD 语句来查看导入作业的结果状态和 errmsg 信息，然后修改导入作业的参数配置后，再重试导入作业。

8. Mike： 使用 Routine Load 消费 Kafka 写入 StarRocks 是怎么样保证一致性语义的呀 能讲一下这块吗 ？

A：Routine Load 是能够保证 Exactly-once 语义的 ，主要的点在于一个导入任务是一个单独的事务，如果该事务在执行过程中出现错误，则事务会中止，FE 不会更新该导入任务相关分区的消费进度。并且 FE 在下一次调度任务执行队列中的导入任务时，从上次保存的分区消费位点发起消费请求，如此可以保证 Exactly once 语义。

最佳提问：问题1、2、3，请以下同学看到消息填写该兑奖问卷：https://wj.qq.com/s2/11664612/bb2c/

StarRocks导入优化完稿.pdf (2.8 MB)
回放地址：
https://www.bilibili.com/video/BV1o24y1b7Am/?vd_source=1cb452610138142d1300dd37a6162a88