SR版本2.4.0
场景: stream load消费kafka中message，每个message中100条数据，将100条数据发送一次stream load。每次http时间在50ms左右，然后再进行下一次消费。
机器: 3台 16core * 64G be 独享机器
测试案列： 消费kafka中3000批次数据(共30W条) 同样的数据即写了kudu 又写了SR
消费完成后 kudu数据为30W条，但是SR的数据只有20多万条，试过明细模型 、更新模型 、 主键模型均存在丢失数据的情况，
测试过程中保证消费offset准确 以及stream load请求次数准确且返回状态值均为200
但是如果只消费10W数据的话， 共测试四次数据均没有丢失，
配置: be配置参数：
这是导入完成后马上查询的结果吗，超高频导入的话在ap库可能会有写入延迟的现象。过一会查询结果对的上不？
等一会查询数据还是一样的
可以复现吗，我们远程会议看下？腾讯会议
可以复现的，目前社区的景丹哥们在处理，但是腾讯会议不了，我们这边是在沙盒模式下 上不了在线会议 
，方便加个微信不 我把群里沟通聊天记录发你看下
你方便把30w数据每次写入的数据量弄大点试下么，比如一次写入10w行数据写3次，看看写入后是不是30w,你这里的频次这么高应该是有部分数据写入失败了，版本太多引起的，可以在日志里搜下这个看下grep ‘too many tablet versions’ /data/xxx/starrocks/be/log/be.WARNING ，如果有对应的日志内容就是上面说的那个问题了，可以参考这个帖子https://forum.mirrorship.cn/t/topic/1578
kafka的数据有size限制， 另外目前建表的分桶数是3个，我之前分区弄了15个就出现了版本过多的问题
你上面的这个帖子我看过不一样的情况，http stream load请求返回statuscode = 200，
另外同时消费五张十万的数据 也没丢失数据情况
感觉有可能是超过表的cache，然后在做compaction或者flash的时候，这时候再有数据进来就可能丢失了
跟cache没关系，就是你导入的频次太高了，ap库数据合并的代价是很高的，我们推荐单表的写入间隔再5s以上，你这种50ms写一次，1s能写20多次，很快就达到单表version 1000的限制了，超过1000版本的时候，再写数据就会抛错，statuscode = 200不一定代表着success，调整下你的导入频次把，按照帖子里的建议
但是10W条数据，1000次连续请求，哪怕是在五张表同时操作的场景下也没丢失数据，另外十万条数据消费完隔两分钟再消费 数据也没丢。我们目前是想把kudu存储转移到sr上面来，目前kudu也是这么写的，频次调低的话生产上消费就跟不上，
难道是因为10W条刚好1000个version？ 我等下吃完饭来试试11W数据看看
kafka的数据可以用routineload直接消费，参考官网文档routineload部分内容，不要用streamload 100条数据写一次这种方式去导入。
目前快20条业务线，差不多两千张表，rountin load建不了这么多任务 
目前base_compaction_check_interval_seconds = 60
应该还是和那个version有关系，写13W数据就丢失了9500， 是不是可以调整check间隔短点？
routineload背后也是streamload方式吧，为啥不可以直接用streamload 100条这样的频率导入呢
有可能和任务配置里面kakfa消费调度周期有关系，一般也不建议设置的太短了，如果一秒钟提交的太多了，估计也有version问题，丢失数据
version太多，为啥会导致数据丢失呢，这种最不能容忍的就是数据丢失，可以失败但不能丢
估计是做http stream load 返回的response对象，里面状态值200有问题，后面估计失败了，也返回了个200
