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

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


没有赶上第一期直播的小伙伴,在这里自行补课哦~ https://www.bilibili.com/video/BV1JM4y1Q7c2/?vd_source=1cb452610138142d1300dd37a6162a88

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

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

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

  • 导入过程中,发生远程过程调用(Remote Procedure Call,简称 RPC)超时问题应该如何处理?

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

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

干货满满,不要错过!马上扫码预约直播,加入我们,一起玩转 StarRocks!:point_down:t2:


StarRocks 实战系列直播活动积分规则:

  • 该系列直播积分可累积,如:

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

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

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

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

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

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

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


注: 如果对活动规则有疑问,可在评论区留言交流~

更新积分:

如需兑奖请填写该问卷:
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