阿里云StarRocks使用感受：优点与挑战

头像墨翼飞鸿   创建 于 2024年11月20日1204

"数据是企业的新石油，而大数据是新的竞争力量。" - 克莱夫·汉弗莱

​ 在这篇文章中，我将分享我们使用StarRocks的心路历程，包括它带给我们的便利，以及我们在使用过程中遇到的一些困扰和问题。

为什么选择StarRocks？

​ 我们的业务大部分都是阿里云产品，而在接入StarRocks之前，我们也使用过ClickHouse。然而，我们这次并没有选择ClickHouse，而是选择了StarRocks。这是基于以下几个考虑：

  1. CDC同步：我们需要将业务库数据同步到PolarDB进行分析。
  2. 事务问题：我们需要处理大表的join问题和并发问题。
  3. 生态问题：我们需要考虑到生态问题。

基于以上的背景以及公司的实际情况，我们最终确定了新的StarRocks集群。我们使用的组件包括阿里云的Flink实时计算全托管和EMR-StarRocks（3.2.4版本）。

使用中的问题

在使用StarRocks的过程中，我们遇到了一些问题，下面详细介绍。

问题1：基于实时计算Flink使用CTAS&CDAS功能同步MySQL数据至StarRocks

​ 根据阿里云帮助中心的描述，我们可以使用CTAS&CDAS功能同步MySQL数据至StarRocks。然而，在实际使用过程中，我们发现当业务库新增字段时，StarRocks中也会新增，但是当新增字段的列产生数据时就会报错，大概就是列的数量不一致。

​ 这个问题在我24年7月已经反馈，但至今尚未解决。我猜测这个问题的原因可能是：代码会校验写入的数据字段数量和StarRocks表的字段数量，而且会保存在state中。但是当同步表新的字段到StarRocks后，新的数据来了之后，第一次sink时候，再次校验字段数量时候，state中的信息没更新，旧的列数量对比最新的导致不一致而引起的。

​ 这个问题对我们的业务影响巨大，出现此问题之后无法从之前的状态中恢复Flink任务，只能重新同步相关表，遇到大表在资源有限时往往恢复起来长达几小时。为了解决这个问题，我们团队将所有的Flink CDC任务换成了create source table，create sink table，从source insert到sink的方式。这样就不支持表结构变更了。后续我们完善了上线发布流程，相关数据库操作需经过数据部门审批或抄送，避免业务库增加字段，而StarRocks表丢失情况。
1711.png

​ 我们在一个CDC的任务中原本同步了2个表，现在增加一个到3个表，代码更新后从停止前的一个检查点恢复时，阿里云控制台的状态兼容性检测是“完全兼容”。但是启动后原本的两个表也变成全量同步了，Flink控制台中的checkpoint id还在继续累加（无状态启动时checkpoint id是初始化从1开始的），从checkpoint id也能看到是从状态恢复的也印证了此错误。

​ 我们都知道此情况是属于Flink的状态部分兼容变更，即：原来的2个表使用状态中offset恢复，新加的表无状态启动。当然此问题是偶发性时间，再过去的很长一段时间只发生过一次。

问题3：E-MapReduce更改StarRocks集群FE节点的JVM内存不生效而更改BE节点的JVM内存又生效问题

​ 我们的StarRocks集群开始是比较低的入门版配置，随着使用的范围越来越广，乞丐版难以支持的时候就会升配。在过往中使用云厂商的一些服务时，只需要在控制台配置，重启或是热更新即可生效。然而，E-MapReduce更改StarRocks集群FE节点的JVM内存会颠覆你的认知。

​ 我们升配了FE节点的内存，当你以为美滋滋终于稳妥了，然而数据分析师还是会反馈QuickBI中查询显示gc xxxx。某一天当我在FE节点 jsp -v | grep pid 天塌了，设置的内存竟然没生效，最终需要更改FE的启动脚本的JVM参数才会生效，这些操作在阿里云产品文档上完全没有体现，有没有背刺的感觉？有使用同款产品的小伙伴们注意了，遇到类似的情况赶紧排查下。

问题4：关于StarRocks设置query_timeout不生效问题

​ 目前我们StarRocks主要供QuickBI查询使用，StarRocks中设置全局超时时间是为了避免页面刷新过久带来的不友好问题，同时时间越长理论上占用StarRocks资源越多，我们想通过设置这些参数来反推优化大查询，推动StarRocks中中间层的建设。此参数设置后，我们发现QuickBI的查询还是超过限制没经过一系列排查，发现QuickBI的数据连接池设置了一个session级别的query_timeout会覆盖StarRocks中全局的设置，而且这个参数QuickBI还没地方能改，QuickBI的数据源配置就光秃秃的IP和端口，我们都知道数据源的连接池可配置的参数很多，连接池大小，空闲时间，超时时间等等。

问题5：StarRocks物化视图表权限丢失问题

​ 当使用原子更换功能时物化视图表的权限丢失。起初我们是对每个物化视图单独授权给用户的，当使用 ALTER MATERIALIZED VIEW aSWAP WITH b后 a表的授权就会丢失了，此问题已经和StarRocks社区的相关负责人沟通过确定是一个bug，也反馈了，不过目前还没修复，解决办法就是不对单个物化视图授权。[Bug] Issue #50480

问题6：StarRocks中get database read lock timeout问题导致FE节点卡顿

​ 此问题是过往中使用StarRocks遇到的最大问题，直接会导致导致整个集群处于假死状态，FE所有节点卡住数分钟，重启FE节点后恢复或是等待卡顿结束后自行恢复。StarRocks社区技术专家在论坛中指出这是历史遗留问题，问了保证元数据的一致性， stream load并发导入时会在db层级加锁，因为锁的粒度大所以很容易形成lock contention，即使不同的导入导的是不同的 table；目前只能通过调下fe.confjdbc_meta_default_cache_enable=true,jdbc_meta_default_cache_expire_sec=60000来缓解，并不能彻底解决；同时根据个人使用经验，如果是CDC导入的任务比较多，建议增加checkpoint的间隔时间，以此来避免频繁导入而引起的lock timeout问题。

1916.png
1916.png

问题7：FE节点重启物化视图调度失败问题

​ 我们经历过几次的集群升级，已经上述[6]的问题，因此会涉及到FE节点的重起问题，我们注意到重启后，部分物化视图处于非激活状态，失败原因是 schema xxx 大概就是元数据问题。此时这部分物化视图有时候不会自动恢复调度，StarRocks本身也没有相关预警，通常业务受损后才会感知到，建议用户自己实现相关的监控功能，以及重新拉起相关物化视图，具体方法：① ALTER MATERIALIZED VIEW mv ACTIVE;手动激活 ②REFRESH MATERIALIZED VIEW mv;手动刷新一次 ③若物化视图人处以 inactive状态，则通过SHOW MATERIALIZED VIEWS FROM db;看到text列的原始建表语句，重新创建物化视图。

问题8：StarRocks默认参数的修改

​ 我们建议开启资源组配置，将不同的账号纳入不同资源组，防止测试开发环境的大sql占用过多资源，而生产用户无足够资源。同时，我们也建议启用查询队列，StarRocks会在并发查询数量或资源使用率达到一定阈值时自动对查询进行排队，从而避免过载加剧。此外，我们还建议设置单个用户最大连接数，有助于在并发场景瞬时的大量连接导致卡顿问题。

sql 复制代码 
CREATE RESOURCE GROUP group_mvTO (    
    query_type in ('select','insert')
)WITH (   
    "cpu_core_limit" = "4",   
    "mem_limit" = "80%",  
    "concurrency_limit" = "10",  #查询触发 FE 实行查询队列的 并发度阈值   
    "spill_mem_limit_threshold"="80%",   
    "max_cpu_cores"="8",     #查询触发 FE 实行查询队列的 CPU 核数阈值  
    "big_query_cpu_second_limit" = "8",     #大查询在be节点上使用的cpu上
    "big_query_mem_limit"="1024*1024*1024*5",  #大查询在be节点上使用的mem上限
    "big_query_scan_rows_limit"="1000000",         #大查询在be节点上扫描行上限    
    "spill_mem_limit_threshold"="60%",      #当前资源组触发落盘的内存占用阈值    
    "type" = "normal");
sql 复制代码 
#为 SELECT 查询启用查询队列
SET GLOBAL enable_query_queue_select = true;
#设置资源队列最大长度
set GLOBAL query_queue_max_queued_queries=100;
#启用资源粒度查询队列
set GLOBAL enable_group_level_query_queue =true;
#查询队列中等待的时长 
set GLOBAL query_queue_pending_timeout_second=3;
#查询队列的并发
set GLOBAL query_queue_concurrency_limit=30;
# 查询队列使用使用法制触发中间结果落盘
set GLOBAL query_queue_mem_used_pct_limit=0.6;
#队列中查询数量的上限。当达到此阈值时，新增查询将被拒绝执行。仅在设置为大于 0 后生效。
set GLOBAL query_queue_max_queued_queries=1024;
#队列中单个查询的最大超时时间。当达到此阈值时，该查询将被拒绝执行。单位：秒。
set GLOBAL query_queue_pending_timeout_second=300;
sql 复制代码 
# v3.3一下版本
SET PROPERTY FOR 'st_rsync' 'max_user_connections' = '30';
# v3.3以上版本
ALTER USER 'st_rsync' SET PROPERTIES ('session.query_timeout' = '10');

结语

​ 尽管我们在使用StarRocks的过程中遇到了一些问题，但是我们依然认为StarRocks是一款优秀的OLAP数据库。它具有强大的实时分析能力，可以帮助我们快速获取业务数据，提升业务效率。同时，我们也相信StarRocks的团队会不断改进产品，解决我们在使用过程中遇到的问题。我们期待StarRocks的未来发展，也期待我们的业务能够在StarRocks的帮助下更上一层楼。