starrocks kafka routineLoad在生产中的应用

💬 StarRocks 用户问答
#1

我司最近在应用starrocks作为主要的OLAP引擎，主要数据源为kafka，日常工作中我们会有非常多的topic，这些topic都需要实时接入starrocks，在starrocks中为上层应用提供分析等需求，目前我们通过flink sql + kafka的方式将数据实时写到sr，但是随着topic越来越多，flink任务越来越多，flink资源也有限，所以我们考虑的是从kafka接入数据是一个轻量级的任务，可不可以用其他方式来代替flink，将flink资源解放出来，flink专注做计算；所以这里想到了starrocks自带的kafka routine load方式，但是我有几个疑问：
1、目前我们线上集群规模较小，3FE+3BE的方式，这种配置，线上最多能支撑多少个routine load任务？
2、目前starrocks好像没有内置命令或者api可以查询和监控routine load任务的资源消耗情况，比如一个任务消耗多少个cpu或者多少内存？
3、如果这种方式在生产上可行的话，任务过多会不会影响starrocks的使用，比如查询这些，或者会不会导致集群宕机？

补充说明：fe配置：4c 16g；be配置：8c 32g

#2

我理解跟任务数量没有特别大大关系，还是要评估下tps。您方便提供下集群目前导入的tps么？集群有没有做什么集群监控之类的可以看下。

#3

目前我们的监控比较简单，通过普罗米修斯监控的，平时也没怎么注意去看，但是有一点，就是我们的数据量非常的大，我抽取了3张大表来统计了下，平均每张表的数据量大概在4000万左右/天，这样的大表我们可能有7-8张，另外还有百万级的表/天，有20-30张左右。

#4

导入时效性如何呢？有没有大宽表之类的？

#5

时效最好是实时，目前走的是flink sql，接kafka，平时5-10秒刷一次盘；另外，大宽表倒是没有，都是数据直接消费kafka，然后直接落到starrocks ods层中，一般就10-20个字段左右

#6

对了，还有个问题请教下，就是有没有什么方式可以监控到每个kafka routine load任务消耗的内存和cpu呢？还是说我只能去监控整合be的内存情况，这一点也是很重要的，便于及时发现问题

#7

基于任务粒度的监控目前还是没有的。

大致统计了下

4000万 8张 30张 按照 500万来算

tps约为 6000

如果 按照导入占用 集群20%的资源来看，目前是扛不住的。

另外咱们磁盘是什么呢？ HDD SSD？

#8

磁盘是一般的HDD磁盘，另外，大表我刚又咨询了下，没有8张，可能就3-4张，目前我们是线上集群（aws上），后续我们会在本地机房再搭建一套starrocks，节点数可能超过3个，来把压力分担到我们本地机房中去，这样的话，还能抗住？

#9

每台机器大致存在多少块盘呢？

#10

目前一每台机器，暂时就一个磁盘，因为是线上的机器，所以磁盘没配多大

#11

这个可能会存在io瓶颈，咱们目前io_util还有iops是多少呢？

#12

ok，这个我下去看看，除了磁盘io瓶颈以外，cpu和内存和starrocks集群这块，您认为问题大不大？

#13

也会存在的，只是目前io可能会是一个卡点。

可以参考下我们官网的配置推荐。

#14

嗯，目前我们的配置好像比这个要低一点点，不过是可以升配的，如果配置升上去了，问题是不是不会很大？

#15

刚咨询了运维，iops是3000这个值

#16

io_util呢？

#17

截屏2022-11-24 下午2.51.06
截屏2022-11-24 下午2.51.061140×794 105 KB

这个配置

#18

SSD可以测试下。理论上没有问题。建议最好把时延都调整为10s。

#19

好的，谢谢了，对了，多问一句，您是怎么根据我提供的数据计算的资源这些够不够呢？

#20

我理解。导入是非常占用io资源的，ssd的承载量是非常高的。io不会是瓶颈的话，就要看cpu了。starrocks会对每块磁盘默认使用进程来做compaction。磁盘数量过多的话，就会cpu很高。8c配置1到2块盘是比较合理的。目前这个配置理论上是可以tps 压到6000左右的。

京ICP备2022026421号-1