cover_image

StarRocks 的表设计规范与监控体系

陈康佳 微盟技术中心 2023年10月13日 10:10
‍‍‍

前言概述

StarRocks 是一款高性能分析型数据仓库,使用向量化、MPP 架构、CBO、智能物化视图、可实时更新的列式存储引擎等技术实现多维、实时、高并发的数据分析。StarRocks 既支持从各类实时和离线的数据源高效导入数据,也支持直接分析数据湖上各种格式的数据。StarRocks 兼容 MySQL 协议,可使用 MySQL 客户端和常用 BI 工具对接。同时 StarRocks 具备水平扩展,高可用、高可靠、易运维等特性。广泛应用于实时数仓、OLAP 报表、数据湖分析等场景。

StarRocks表概述

建表是使用 StarRocks 非常重要的一环,规范的表设计在一些场景下甚至使查询性能提升数倍,StarRocks表设计涉及知识点主要包含数据模型选择、分区分桶、排序键、前缀索引以及字段类型。
StarRocks表使用列式存储,采用分区分桶机制进行数据管理。一张表可以被划分成多个分区,一个分区内的数据可以根据一列或者多列进行分桶,将数据切分成多个 Tablet。Tablet 是 StarRocks 中最小的数据管理单元。每个 Tablet 都会以多副本 (replica) 的形式存储在不同的 BE 节点中。
如图表按照日期划分为 4 个分区,第一个分区进一步切分成 4 个 Tablet。每个 Tablet 使用 3 副本进行备份,分布在 3 个不同的 BE 节点上。
图片

一、StarRocks表设计

现有的场景中,主要使用比较多的两种表模型是更新模型和主键模型。二者在同维度列相同的数据处理上是一致的,不同的是相对于更新模型,主键模型在查询时不需要执行聚合操作,并且支持谓词下推和索引使用,能够在支持实时和频繁更新等场景的同时,提供高效查询。
下面内容主要是对更新模型与主键模型都适用的分区分桶规范,以及主键模型需要而外注意一些场景。

1.1 字段类型

定义恰当数据字段类型对StarRocks查询的优化是非常重要的,从查询效率的角度考虑,我们可以遵循两条原则:
1、如果数据没有Null,可以指定Not Null属性;
2、尽量使用数字列代替字符串列。

1.2 分区分桶

StarRocks采用Range-Hash的组合数据分布方式,也就是我们一直在提的分区(Range)分桶(Hash)方式。
图片

1.2.1 分区规范

1、分区键选择:当前分区键仅支持日期类型和整数类型,为了让分区能够更有效的裁剪数据,我们一般也是选取时间列作为分区键。
2、分区粒度选择:StarRocks 的分区粒度视数据量而定,单个分区原始数据量建议维持在100G以内。

1.2.2 分桶规范

1、分桶键选择:分桶的目的我们一直在说是为了将数据打散,所以分桶键就需要选择高基数的列(去重后数据量最大的列)。分桶后的数据如果出现严重的数据倾斜,就可能导致系统局部的性能瓶颈,所以我们也可以视情况使用两个或三个列作为分桶键,尽量的将数据均匀分布。我们可以show语句查看表中的数据分布情况:
2、分桶数:分桶数的设置需要适中,如果分桶过少,查询时查询并行度上不来(CPU多核优势体现不出来)。而如果分桶过多,会导致元数据压力比较大,数据导入导出时也会受到一些影响。
3、分桶数的设置通常也建议以数据量为参考,从经验来看,每个分桶的原始数据建议不要超过5个G,考虑到压缩比,也即每个分桶的大小建议在100M-1G之间。
4、若不好估算数据量,我们也可以将分桶数设为:分桶数=“BE个数BE节点CPU核数”或者“BE个数BE节点CPU核数/2”,这样一般也不会有什么问题。这里需要注意的是,已创建分区的分桶数不能修改(有其他方式能实现,但比较麻烦),所以前期设定合适的分桶数非常重要。

1.3 主键表

相较更新模型,主键模型(Primary Key)可以更好地支持实时/频繁更新的功能。该类型的表要求有唯一的主键,支持对表中的行按主键进行更新和删除操作。
该模型适合需要对数据进行实时更新的场景,特别适合 MySQL 或其他数据库同步到 StarRocks 的场景。虽然原有的 Unique 模型也可以实现对数据的更新,但Merge-on-Read 的策略大大限制了查询性能。Primary模型更好地解决了行级别的更新操作,配合 Flink-connector-StarRocks 可以完成 MySQL 数据库的同步。
需要注意的是:由于存储引擎会为主键建立索引,而在导入数据时会把主键索引加载在内存中,所以主键模型对内存的要求比较高,还不适合主键特别多的场景。目前比较适合的两个场景是:
1、 数据有冷热特征,即最近几天的热数据才经常被修改,老的冷数据很少被修改。典型的例子如 MySQL 订单表实时同步到 StarRocks 中提供分析查询。其中,数据按天分区,对订单的修改集中在最近几天新创建的订单,老的订单完成后就不再更新,因此导入时其主键索引就不会加载,也就不会占用内存,内存中仅会加载最近几天的索引。
图片
2、大宽表(数百到数千列)。主键只占整个数据的很小一部分,其内存开销比较低。比如用户状态和画像表,虽然列非常多,但总的用户数不大(千万至亿级别),主键索引内存占用相对可控。
图片
如图所示,大宽表中排序键只占一小部分,且数据行数不多。

1.4 实际案例

案例一:Update内存超了,导致主键表导入失败

1、背景
收到研发反馈,说有多个主键表导入报错,任务返回如下。
Caused by: java.io.IOException: com.starrocks.connector.flink.manager.StarRocksStreamLoadFailedException: Failed to flush data to StarRocks, Error response: 

{"Status":"Fail","BeginTxnTimeMs":0,"Message":"close index channel failed, load_id=bc4eb485-f99b-1f20-ffd9-e7e7e22925ab","NumberUnselectedRows":0,"CommitAndPublishTimeMs":0,"Label":"2434c3d7-9cef-45b0-b057-482b9a0032cd","LoadBytes":1056,"StreamLoadPutTimeMs":1,"NumberTotalRows":0,"WriteDataTimeMs":14,"TxnId":1355616,"LoadTimeMs":15,"ReadDataTimeMs":0,"NumberLoadedRows":0,"NumberFilteredRows":0}
2、报错
通过 Label ID 去 BE 日志里面过滤,找到相关的报错:
图片
3、相关监控
图片
图片
4、原因
默认 BE 的 Update 内存设置是27G,实际使用中发现这部分内存使用超了,导致任务报错。
该值已经很大了,排查后发现是使用姿势的问题,有几张表设计的不合理。
图片
图片
该主键表没有分区,在写入的时候会把整张表都加载到内存中,导致 BE 内存暴涨,超出 Update 限制。
5、处理
表优化:
发现该业务其实并不需要用主键模型只需要更新模型就能满足需求。于是把主键模型改为了更新模型。
6、补充与总结
1、相较更新模型,主键模型(Primary Key)可以更好地支持实时/频繁更新的功能。如果表写入是离线任务,或者更新频率很低则不需要使用主键模型,因为主键模型相对于更新模型有更大的内存消耗。
2、主键表把主键加载到内存中的最小维度是分区,所以主键表如果有冷热数据的概念,可以根据时间增加分区键,减小写入时主键部分消耗的内存。(默认主键表在写入的时候会表写入对应分区主键加载到内存中,如10分钟没有写入需求才会把这部分内存释放)

案例二:主键内存超了,导致导入失败

1、背景
研发反馈主键表导入失败。
图片

2、报错
根据对应的表和 Label 排查,发现是主键长度超限制了。
图片
建表语句,看主键列特别多。
CREATE TABLE xxxx (
       pid
BIGINT ( 20 ) NOT NULL DEFAULT '0' COMMENT '企业ID',
       task_id
VARCHAR ( 64 ) NOT NULL DEFAULT '' COMMENT '任务ID t_task表ID',
       userwid
VARCHAR ( 64 ) NOT NULL DEFAULT '' COMMENT '用户 t_task表creator_wid',
       username
VARCHAR ( 150 ) NOT NULL DEFAULT '' COMMENT '用户姓名',
       sales_talk_id
VARCHAR ( 64 ) NOT NULL DEFAULT '' COMMENT '线路ID, t_task表sales_talk_id',
       gap
VARCHAR ( 50 ) NOT NULL DEFAULT '' COMMENT '通话间隔 yyyy-MM-dd:HH',
       gap_time
VARCHAR ( 50 ) NOT NULL DEFAULT '' COMMENT '通时间隔 1-10秒,10-60秒, 1-3分 , 3分以上',
       count
BIGINT ( 20 ) NOT NULL DEFAULT '0' COMMENT '数量',
       create_time datetime
NOT NULL  COMMENT '创建时间',
       update_time datetime
NOT NULL  COMMENT '更新时间') PRIMARY KEY(pid, task_id, userwid,username, sales_talk_id, gap, gap_time) COMMENT  '概览-通话时长'DISTRIBUTED by HASH(pid) BUCKETS 8;
3、原因
主键列过多导致主键长度超限制,与研发沟通后,去掉了一列主键后写入成功。
4、补充
主键模型中,主键编码后,占用内存空间上限为 127 字节。该值目前不支持修改。为了保证正常写入主键表在设计的时候,主键列应该尽量少,主键列的长度尽量短。

案例三:主键表内存优化

1、治理前现状
数据团队集群总共有主键表50张左右,集群8台 BE 节点,平均每台 BE 有大概7.5G 的被主键长期消耗(常驻),当前集群机器分配给 BE 服务也就只有50G,严重影响了离线写入与查询的性能。
2、治理方式
1、不需要实时更新的主键表都改用更新模型。
2、写入有冷热概念的表,全部增加分区键。
3、检查所有主键表的数据生命周期,删除多余数据。
3、治理结果
主键表优化,BE 内存释放大概48G(常驻),BE 有更多内存用于写入和查询。
图片

案例四:tablet 数量治理

1、治理前现状
数据团队集群 Tablet数120w,整个集群的数据量才3T,平均每个Tablet大小才2.6M,远低于官方推荐的100M-1G,有大量的tablet大小只有几KB。Tablet 过多导致元数据过大,FE内存紧张。
2、治理方式
以单个分区大小在 100G 以内,单个 Tablet 数据分配在100M-1G为标准,对表的分区分桶做重新规划,具体方式是:
a. 把天级别分区改为月级别分区
b. 对于分桶过多,数据量不大的表,减少分桶数量
3、治理结果
优化三批汇总,Tablet 数量由140W 降低到13W。降低了元数据大小
图片
FE 内存峰值由 18.6G 下降为 4.5G,减少了FE内存的浪费。
1.5 建表案例
业务背景:
需要新建一张订单表,表信息如下:
1、 字段。
bos_id bigint(20) NOT NULL COMMENT "组织架构树id",
vid bigint(20) NOT NULL COMMENT "节点id",
path varchar(65533) NULL COMMENT "父节点路径",
prod_id bigint(20) NOT NULL COMMENT "产品id",
prod_inst_id bigint(20) NOT NULL COMMENT "产品实例id",
st tinyint(4) NOT NULL COMMENT "数据统计类型0:全部, 1:自身, 2:全部子节点",
consign_type tinyint(4) NOT NULL COMMENT "交付单状态0:待发单;1:发单;2确认收货",
order_no bigint(20) NOT NULL COMMENT "订单号",
dd date NOT NULL COMMENT "日期",
merchant_id bigint(20) NOT NULL COMMENT "商户id",
vid_type bigint(20) NOT NULL COMMENT "节点类型",
consign_vid bigint(20) NULL COMMENT "处理vid",
create_time datetime NOT NULL COMMENT "创建时间"
2、数据量:年数据量预估在20亿左右。
3、SIZE:年数据量是10G左右,23年之前有存量数据1G。
4、常用过滤条件:dd,bos_id,path,prod_id。
5、QPS:10。
建表分析:
1、 2023年之前存量数据较少,使用频率低,可以建为一个分区。
2、 增量数据稳定10G每年,并有时间维度做分区,采用月分区,平均分区大小在0.83G。
3、 在保证每个 Tablet  数据量在100M-1G之间的同时,增加读写的并发,将分桶设置为6,平均 Tablet 大小是138M。
建表语句:
CREATE TABLE table1 (
dd date NOT NULL COMMENT "日期",
bos_id bigint(20) NOT NULL COMMENT "组织架构树id",
vid bigint(20) NOT NULL COMMENT "节点id",
path varchar(65533) NULL COMMENT "父节点路径",
prod_id bigint(20) NOT NULL COMMENT "产品id",
prod_inst_id bigint(20) NOT NULL COMMENT "产品实例id",
st tinyint(4) NOT NULL COMMENT "数据统计类型0:全部, 1:自身, 2:全部子节点",
consign_type tinyint(4) NOT NULL COMMENT "交付单状态0:待发单;1:发单;2确认收货",
order_no bigint(20) NOT NULL COMMENT "订单号",
merchant_id bigint(20) NOT NULL COMMENT "商户id",
vid_type bigint(20) NOT NULL COMMENT "节点类型",
consign_vid bigint(20) NULL COMMENT "处理vid",
create_time datetime NOT NULL COMMENT "创建时间"
) ENGINE=OLAP
UNIQUE KEY(ddbos_idvidpathprod_idprod_inst_idstconsign_typeorder_no)
COMMENT "履约分析_待发货待发单待备货"
PARTITION BY RANGE(dd)
(PARTITION p2022 VALUES [('1970-01-01'), ('2023-01-01')),
PARTITION p2023 VALUES [('2023-01-01'), ('2024-02-01')),
PARTITION p202401 VALUES [('2023-02-01'), ('2024-03-01')))
DISTRIBUTED BY HASH(bos_idorder_no) BUCKETS 6
PROPERTIES (
"replication_num" = "3",
"dynamic_partition.enable" = "true",
"dynamic_partition.time_unit" = "MONTH",
"dynamic_partition.time_zone" = "Asia/Shanghai",
"dynamic_partition.start" = "-2147483648",
"dynamic_partition.end" = "1",
"dynamic_partition.prefix" = "p",
"dynamic_partition.buckets" = "6",
"dynamic_partition.start_day_of_month" = "1",
"in_memory" = "false",
"storage_format" = "DEFAULT"
);

二、StarRocks监控

本节内容包含监控架构、监控页面使用、监控项的解释以及对应值的合理范围(其中部分性能指标有原理及排查思路的扩展)。

监控架构

在监控告警的选择上,我们选择在官方推荐的 Prometheus+Grafana 的方案基础上,接入 AlertManager+ 自定义的 API 做告警。
Prometheus 通过 Pull 方式访问 FE 或 BE 的 Metric 接口,然后将监控数据存入时序数据库。监控展示选取的是通过 Grafana 配置 Prometheus 为数据源。
图片

StarRocks 慢查询

通过 FileBeat 把 FE 本地的慢查询保存到 ES 中,再接入大数据平台可以过滤查询慢SQL,自定义 API 方式实现周慢查询邮件,相关监控通过 Kibana 实现。
图片

2.1 监控使用

根据需求,选择需要查看的集群,FE,BE节点。
图片

2.2 监控分类

对于关键指标会标记。

2.2.1 Overview

主要是用来同时展示所有StarRocks 集群的运行状态,一般作为StarRocks日常巡检的一部分。
图片
监控项解释
1、Cluster Number:starrocks 集群总数
2、Frontends Status:fe节点状态(1为alive,0为dead)
3、Backends status:be节点状态(1为alive,0为dead)
4、Cluster FE JVM Heap Stat:fe内存使用情况(所有fe节点的平均值)
5、Cluster BE CPU Idle:be节点cpu使用情况(所有be节点的平均值)
6、Cluster BE Mem Stat:be节点内存使用情况(所有be节点的平均值)
7、Cluster QPS Stat:集群qps
8、Capacity used percentage:集群存储使用百分百
9、Disk State:be节点磁盘的状态(1为正常,0为异常)

2.2.2 Cluster Overview

主要是所选择集群的基础指标,观察所选集群的基础状态。
图片
1、FE Node:FE节点的总数
2、FE Alive:alive状态 FE节点数
3、BE Node:BE节点的总数
4、BE Alive:alive状态 BE节点数
5、Total Capacity:集群整体的存储
6、Used Capacity:已使用的存储
7、Max Replayed journal id:当前最新的journal id
8、Scheduling Tablets:集群中正在调度(被复制)的tablet数量(tablet缺失,不一致,unhealthy,balance 都会触发tablet 的复制),一般情况下,该值超过50需要检查一下集群的负载。

2.2.3 Query Statistic

集群查询相关的指标:
图片
1、 RPS:每个FE的每秒请求数。请求包括发送到FE的所有请求。
2、 QPS:每个FE的每秒查询数。查询仅包括 Select 请求。
3、 99th Latency:每个FE 的 99th个查询延迟情况。
4、 Query Percentile:左 Y 轴表示每个FE的 95th 到 99th 查询延迟的情况。右侧 Y 轴表示每 1 分钟的查询率。
5、 Query Error:左 Y 轴表示累计错误查询次数。右侧 Y 轴表示每 1 分钟的错误查询率。通常,错误查询率应为 0。
6、 Connections:每个FE的连接数量
7、Slow Query:慢查询的数量(累计值)

2.2.4 Jobs

写入任务的相关指标:
图片
1、Broker Load Job:每个负载状态下的Broker Load 作业数量的统计。
2、Insert Load Job:由 Insert Stmt 生成的每个 Load State 中的负载作业数量的统计。
3、Report queue size:Master FE 中报告的队列大小
4、Schema Change Job:正在运行的Schema 更改作业的数量。
5、Broker load tendency:Broker Load 作业趋势报告
6、Insert Load tendency:Insert Stmt 生成的 Load 作业趋势报告
7、Load submit:显示已提交的 Load 作业和 Load 作业完成的计数器。
8、Rollup Job:正在运行Rollup 构建作业数量

2.2.5 Transaction

图片
1、Txn Begin/Success on FE:事务开始/完成的数量,及速率,可以侧面衡量集群的写入频率
2、Txn Failed/Reject on FE:事务失败/拒绝的速率,可以侧面衡量集群写入失败的情况
3、Publish Task on BE:发布任务请求总数和错误率。(注意每个节点取得是错误的概率,集群正常情况下这个应该为0)
4、Txn Requset on BE:在 BE 上显示 txn 请求这里包括:begin,exec,commit,rollback四种请求的统计信息
5、Txn Load Bytes/Rows rate:事务写入速度,左 Y 轴表示 txn 的总接收字节数。右侧 Y 轴表示 txn 的Row 加载率。

2.2.6 FE JVM

FE 服务的内存,线程相关指标:
图片
1、JVM Heap:FE 服务堆内存使用(2.0.2 版本 FE 内部有内存架构有问题,有统计不全的情况,该值不是极为准确,可以作为 FE 负载变化的参考)
2、JVM Non Heap:非堆内存的使用
3、JVM Direct Buffer:指定 FE 的 JVM 直接缓冲区使用情况。左 Y 轴显示已用/容量直接缓冲区大小。
4、JVM Threads:集群FE JVM线程数。用来参考FE的负载情况
5、JVM Young:指定 FE 的 JVM 年轻代使用情况。
6、JVM Old:指定 FE 的 JVM 老年代使用情况。
7、JVM Young GC:指定 FE 的 JVM 年轻 GC 统计信息(总数和平均时间)。
8、JVM Old GC:指定 FE 的 JVM 完整 GC 统计信息(总数和平均时间)。

2.2.7 BE

BE服务的基础,集群层面的指标:
图片
1、BE CPU Idle:BE 的 CPU 空闲状态。低表示 CPU 忙。说明CPU的利用率越高
2、BE Mem:这里是监控集群中每个BE的内存使用情况
3、Net send/receive bytes:每个BE节点的网络发送(左 Y)/接收(右 Y)字节速率,除了“IO”
4、Disk Usage:BE节点的storage的大小(注意这个只是/data/starrocks/storage目录的大小,实际机器上面可能会比这个大,有log或者系统使用的磁盘)
5、Tablet Distribution:每个 BE 节点上的 Tablet 分布情况,原则上分布式均衡的,如果差别特别大,就需要去分析原因。(该值不宜过大,太大会消耗FE,以及BE的内存,我们做过相关压测一个 Tablet 大概消耗FE 5KB的内存,并且改值随着整体 Tablet 总量增加而增加。默认一张表的 Tablet 数=分区数分桶数3副本)
图片
1、BE FD count:BE的文件描述符( File Descriptor)使用情况。左 Y 轴显示使用的 FD 数量。右侧 Y 轴显示软限制打开文件数。(可以理解为文件句柄)
2、BE thread num:BE的线程数(用来衡量be的并发情况,当前16core机器在400左右为正常值)
3、BE tablet_writer_count:be节点上面正在做写入的tablet 数量(用来衡量be写入负载)
4、Disk written bytes:be节点上磁盘的写速度。
5、Disk bytes_read:be节点上磁盘的读速度。
6、Disk IO util:每个 BE 节点上磁盘的 IO util 指标,数值越高表示IO越繁忙。
图片
1、BE Compaction Base:BE的Base Compaction压缩速率。左Y轴显示be节点压缩速率,右Y轴显示的整个集群累计做base compaction的大小。
2、BE Compaction Cumulate:BE的Base Cumulate压缩速率。左Y轴显示be节点压缩速率,右Y轴显示的整个集群累计做Cumulate compaction的大小。
图片
1、BE Scan Bytes:BE扫描效率,这表示处理查询时的读取率。(该值可以结合qps一起参考集群的查询压力)
2、BE Scan Rows:BE扫描行的效率,这表示处理查询时的读取率。
3、Tablet Meta Write:左Y 轴显示了tablet header 的写入速率。右侧 Y 轴显示每次写入操作的持续时间。
4、Tablet Meta Read:左Y 轴显示了tablet header 的读取速率。右侧 Y 轴显示每次读操作的持续时间。

2.2.8 BE tasks

BE 服务任务级别的监控指标:
图片
1、Tablets Report failed:BE Tablet 汇报给FE的失败率。(正常值是0,如果该值异常,考虑排查FE BE通信,或者FE BE负载是否有问题)
2、Delete failed:BE 做删除操作的失败率。(一般不会出现失败,如果删除失败检查一下磁盘是否正常)
3、Finish task report failed:BE向FE汇报的失败率。(正常值是0,如果该值异常,考虑排查FE BE通信,或者FE BE负载是否有问题)
4、Tablets Report:BE向FE做全量Tablet汇报的频率(正常的值是在0.67左右,如果该值减少,需要排查一下BE节点的负载情况)
5、Delete task:BE做删除操作的频率。(用来监控集群删除数据的频率,一般情况是0,如果该值比较大,需要排查集群是否在做 删表,删库操作)
6、Finish task report:BE节点运行Task的频率(可以用来衡量BE的繁忙程度和并发)

图片


1、Base Compaction failed:Base compaction失败率(BE做大合并的失败率,正常是0,如果该值异常,需要检查Be compaction内存,以及BE的IO是否正常。)
2、Cumulative Compaction failed:Cumulative Compaction(BE做小合并的失败率,正常是0,如果该值异常,需要检查Be compaction内存,以及BE的IO是否正常。)
3、Clone failed:tablet clone的失败率(Tabelt 做副本修复或者均衡的时候会clone,该值异常检查一下BE的IO)
4、Base Compaction task:Be做base compaction的频率。(用来反应当前集群的compaction大压力,如果Tablet 不及时做compaction,会影响读写性能,可以调整base compaction的并发来调整)
5、Cumulative Compaction task:BE做cumulative compaction的频率。(用来反应当前集群的小compaction压力,如果Tablet 不及时做compaction,会影响读写性能,可以调整cumulative compaction的并发来调整)
6、Clone task:BE节点Tablet 做复制的频率(这个可以结合 scheduler tablet监控一起来判断集群的Tablet复制的情况)
图片
1、Create tablet:新建Tablet 频率(一般新建表,新建分区,写数据会伴随着tablet数的增加,改值可以用来衡量集群的写入频率)
2、Single Tablet Report:tablet的汇报频率(左侧 Y 轴表示指定任务的失败率。通常,它应该是 0。右侧 Y 轴表示所有 Backends 中指定任务的总数。)
3、Create tablet failed:新建Tablet 失败率(一般新建表,新建分区,写数据会伴随着tablet数的增加,该值正常是0,如果该值异常要检查一下集群是否有建表,建分区失败的情况)

2.2.9 BE Mem

BE 服务内存分配使用情况:图片
1、BE used Mem:BE服务使用的总内存(当前BE节点配置的内存基本都为机器内存的80%,如果使用内存超了需要,排查内存具体消耗在哪里,具体优化或者分析是否需要扩容)
2、BE query Mem:查询部分消耗的内存。(对于64G内存的机器,当前该值的限制是40G,该内存需要结合QPS,慢查询一起治理优化)
3、BE load Mem:导入任务消耗的内存。(对于64G内存的机器,当前该值的限制是13G,如果该值大,需要连接集群Show Load;查看当前的导入任务,建议超过10G大小的数据,不要再业务高峰期操作)
4、BE meta Mem:BE消耗元数据总内存。(在查询和导入的时候,BE会把相关的Tablet元数据加载到内存中,这部分内存目前没有命令可以主动释放,需要重启节点才能释放)
图片
1、BE compaction Mem:BE服务做compaction使用的内存。(对于64G的机器,当前该值的限制是14G,建议超过10G大小的数据,不要再业务高峰期操作,否则做compaction会很消耗内存,影响集群的查询)
2、BE column_pool Mem:column pool 内存池,用于加速存储层数据读取的 Column Cache。(在做查询的时候,会把部分缓存保留在内存中,该内存没有命令主动释放,只能重启节点才能释放)
3、BE page cache Mem:BE 存储层 Page 缓存。(当前集群都没有开启Page cache)
4、BE CPU per core cache Mem:CPU per core 缓存,用于加速小块内存申请的 Cache。
图片
1、BE Consistency Mem:集群做Tablet 一致性校验的时候消耗的内存(集群会周期性的自动触发做一致性校验,有不一致的之后会伴随着Tablet 的复制,改情况为正常情况)
2、BE Primary Key Mem:主键索引消耗的内存。(对于64G的机器,该值的限制是26G,默认主键表在写入的时候,会把目标分区的主键索引都加载到内存中,如果该值过大,可以联系运维,访问BE 8040端口查看主键内存消耗的集群情况,找到对应的表做对应治理)
3、 BE Tablet Clone Mem:Tablet 复制时消耗的内存(如果该值过大,需要排查集群tablet的健康情况,一般会伴随大量的Tablet Scheduler)

总结

在 StarRocks 中,服务建表和监控是数据分析和查询引擎的关键环节。建表是构建数据基础的第一步,需要精心规划和管理,以确保数据的高效存储和查询。同时,监控则是保障系统稳定性和性能的守护者,通过实时的性能分析和故障检测,及时发现并解决潜在问题,确保系统持续运行。如果有相关问题,欢迎小伙伴和我讨论。

活动推荐
时间:10月19日(周四)19:30-21:30
主题:微盟技术沙龙 -数字化时代下的SaaS SCRM系统实战
直播:微盟技术中心视频号,51CTO视频号,开源中国视频号
报名方式:点击阅读原文或下图

图片

‍‍‍

运维 · 目录
上一篇Elasticsearch 慢查询自动化巡检实践
继续滑动看下一个
微盟技术中心
向上滑动看下一个