当前位置：首页 > news >正文

StarRocks笔记

news 2025/10/25 13:48:19

StarRocks 是新一代极速统一的云原生MPP数据库。StarRocks 的愿景是能够让用户的数据分析变得更加简单和敏捷。用户无需经过复杂的预处理，就可以用 StarRocks 来支持多种数据分析场景的极速分析。

特性

极速

MPP执行引擎：性能随机器数量线性扩展，shuffle分布式
Pipeline调度引擎：自适应并行度，提升易用性；减少线程创建、切换成本；支持时间片调度，资源隔离
向量化执行：列式存储降低存储成本，列裁剪提升查询IO；利用SIMD指令最大限度提升单核性能

统一

SQL语法统一
- 内部查询遵循SQL-92标准，也支持部分新标准功能（如窗口函数、GroupingSets）；兼容MySQL协议
- 联邦查询支持使用统一的StarRocks语法访问MySQL、Oracle等db，Hive、Iceberg、Paimon等datalake，也支持trino方言
分析场景统一：支持四种表模型；
- 用户画像：Bitmap集合计算、精准去重、前缀索引、多表关联、Bitmap_to_array列转行
- 经营报表、订单实时分析：导入即生效，秒级延迟；向量化查询、兼容MySQL协议，兼容性好；数据模型灵活（雪花、星型、大宽表、预聚合）
- 多维分析：现代化物化视图对固定维度的报表非常友好
- 高并发业务：分区机制（高效过滤）、分桶机制（避免热点）、tablet（数据逻辑单元，灵活支持并行计算）
集群管理统一：支持配置资源组来合理控制CPU、IO、内存资源，实现多租户资源隔离，熔断大查询，不同业务可工作在同一集群

架构

1. 存算一体

FE（CatalogManager、QueryOptimizer）、BE（本地存储，execution engine、storage engine）

角色

FE：基于Java开发，主要负责集群元数据管理、接收和返回客户端请求、查询计划生成等。
- Leader：提供元数据读写服务，由Follower动态选举产生。Leader接收写入请求更新元数据，通过BDBJE（Berkeley DB Java Edition完成元数据操作日志的持久化、日志同步、FE高可用等，key为连续整型，value为操作日志）同步到Follower、Observer，半数以上Follower同步成功后才算元数据写入成功
- Follower：提供元数据的读服务，回放Leader的同步日志异步同步元数据；半数以上存活时进行Leader选举
- Observer：可选。用于扩展集群读的能力，不参与Leader选举
- 元数据，每个FE都有一份完整的元数据，在内存中，定期写checkpoint后的完整元数据到磁盘image，bde是元数据的journal
  - 数据信息：db、表schema、分片信息等
  - 作业信息：导入、clone、schema change作业
  - 用户及权限信息
  - 集群及节点信息

BE：基于C++开发，负责实际执行FE下发的执行计划，执行SQL计算任务；维护本地数据的持久化存储
- 存储引擎：数据以Tablet分片（根据分区、分桶键打散成一个个tablet）、Segment V2格式进行分布式地多副本存储；列式压缩（列存、LZ4压缩）、生成索引（short key index、ordinal索引、zone map索引）
- 执行引擎：通过MPP多机并行机制充分利用多机多核资源；执行时优先处理本地数据，避免过多的数据传输，如聚合时先local-group，shuffle后再第二阶段聚合
BROKER：可选，基于Java开发。独立的无状态服务，封装了文件系统接口。sr通过Broker读写远端存储如hdfs、s3、oss等的文件和目录，仅作为数据通路占用内存很少；也可用于数据备份与恢复；也可用于存算分离，在多hdfs集群或多kerberos用户场景相比CN更方便

优点

无外部依赖
极简架构：FE、BE
集群高度扩展：横向扩展
服务高可用：FE内部采用主从复制BDBJE架构，BE内部采用多副本策略保证数据安全

2. 存算分离

角色

FE：集成了StarManager支持存算分离架构
CN：无状态计算节点。执行FE下发的执行计划，查询耗时增加；cache远端的hdfs、兼容s3协议的对象存储数据
对象存储：使用StarRocks自有的文件格式，也可通过外部Catalog直接查询数据湖格式

优点

- 弹性：根据负载情况灵活弹性伸缩计算节点；无状态，扩缩容时数据不用迁移
- 成本：计算和存储可根据各自使用情况灵活扩缩容；存储由硬盘多副本变为s3单副本
- 隔离：读写分离；multi-warehouse
- 灾备：s3对象存储可提供11个9的数据可靠性；shared-data架构支持部署跨可用区、跨云的无状态计算节点
- 生态：数据在云存储，更易用

不适用场景

不具备对象存储或hdfs
高频写入，如写入间隔小于10s，写入并发高
对查询性能有比较严格的要求

湖仓融合解决方案

存储层次

对象	定义	对排序键的重要性
Partition	表的粗粒度逻辑切片（例如，日期或 tenant_id）。	启用计划时分区裁剪并隔离生命周期操作（TTL，批量导入）。
Tablet	分区内的哈希/随机桶，独立复制到后端节点。	其行按排序键物理排序的单元；所有分区内裁剪从这里开始。
MemTable	内存写缓冲区（约 96 MB），在刷新到磁盘前按声明的键排序。	确保每个磁盘上的 Segment 已经排序——无需后续外部排序。
Rowset	由刷新、流式导入或 Compaction 周期生成的一个或多个 Segment 的不可变捆绑。	append设计使 StarRocks 可以同时导入，而读者保持无锁。
Segment	Rowset 内部的自包含列式文件（约 512 MB），携带数据页面和裁剪索引。	Segment 级别的区域映射和前缀索引依赖于 MemTable 阶段建立的顺序。

每个 Segment 都是自描述的。从上到下，您会发现：

列数据页面 64 KB 块编码（字典、RLE、Delta）并压缩（默认 LZ4）。
序号索引将行序号映射到页面偏移量，以便引擎可以直接跳转到页面 n。
区域映射索引每个页面和整个 Segment 的最小值、最大值和是否有空值——裁剪的第一道防线。
短键（前缀）索引每 ~1 K 行的排序键前 36 字节的稀疏二分搜索表——支持毫秒级点/范围查找。
页脚和魔术数字每个索引的偏移量和完整性校验和；让 StarRocks 仅内存映射尾部以发现其余部分。

因为页面已经按键排序，这些索引虽然小但非常有效。

读取路径

1. 分区裁剪（计划时）如果 WHERE 子句限制了分区键（例如 dt BETWEEN '2025‑05‑01' AND '2025‑05‑07'），优化器仅打开匹配的分区目录。
2. Tablet 裁剪（计划时）当等式过滤器包含哈希分布列时，StarRocks 计算目标 tablet ID 并仅调度这些 Tablets。
3. 前缀索引查找在前导排序列上的稀疏短键索引定位到确切的 segment 或页面。
4. 区域映射裁剪每个 Segment 和 64 KB 页面的最小/最大元数据丢弃不符合谓词窗口的块。
5. 向量化扫描和延迟物化存活的列页面顺序流经 CPU 缓存；仅物化引用的行和列，保持内存紧凑。

因为数据在每次刷新时按键顺序提交，每个读取时裁剪层在前一层的基础上累积，提供对数十亿行表的亚秒级扫描。

内存

FE内存主要由元数据占用，大约一千万个tablet占用20G内存。还有一部分SQL Session的SQL处理过程对内存的占用

BE内存：

标识	Metric 名称	说明	BE 相关配置
process	starrocks_be_process_mem_bytes	BE 进程实际使用的内存（不包含预留的空闲内存）。	mem_limit
query_pool	starrocks_be_query_mem_bytes	BE 查询层使用总内存。
load	starrocks_be_load_mem_bytes	导入使用的总内存。	load_process_max_memory_limit_bytes, load_process_max_memory_limit_percent
table_meta	starrocks_be_tablet_meta_mem_bytes	元数据总内存。
compaction	starrocks_be_compaction_mem_bytes	版本合并总内存。	compaction_max_memory_limit, compaction_max_memory_limit_percent
column_pool	starrocks_be_column_pool_mem_bytes	column pool 内存池，用于加速存储层数据读取的 Column Cache。
page_cache	starrocks_be_storage_page_cache_mem_bytes	BE 存储层 page 缓存。	disable_storage_page_cache, storage_page_cache_limit
jit_cache	starrocks_be_jit_cache_mem_bytes	BE jit 编译函数的缓存。	jit_lru_cache_size
chunk_allocator	starrocks_be_chunk_allocator_mem_bytes	CPU per core 缓存，用于加速小块内存申请的 Cache。	chunk_reserved_bytes_limit
consistency	starrocks_be_consistency_mem_bytes	定期一致性校验使用的内存。	consistency_max_memory_limit_percent, consistency_max_memory_limit
schema_change	starrocks_be_schema_change_mem_bytes	Schema Change 任务使用的总内存。	memory_limitation_per_thread_for_schema_change
clone	starrocks_be_clone_mem_bytes	Tablet Clone 任务使用的总内存。
update	starrocks_be_update_mem_bytes	主键表使用的总内存。

建表

数据模型

	主键表 (Primary Key table)	明细表 (Duplicate Key table)	聚合表 (Aggregate table)	更新表 (Unique Key table)
导入数据时实现 INSERT	支持。在导入任务中配置 __op=0 实现 INSERT 。内部实现时，StarRocks 将 INSERT 和 UPDATE 操作均视为 UPSERT 操作。	支持	支持（同聚合键值的数据行会聚合）	支持（同唯一键值的数据行会更新）
导入数据时实现 UPDATE		不支持	支持（使用 Replace 聚合函数实现）	支持（更新表本身就可以视为使用 Replace 聚合函数的聚合表）
导入数据时实现 DELETE	支持。在导入任务中配置 __op=1 实现 DELETE 。	不支持	不支持	不支持
导入数据列值的完整性	默认必须导入全部列值。如果开启部分列更新 partial_update ，或者列具有默认值，则无需导入全部列值。	默认必须导入全部列值。如果列具有默认值，则无需导入全部列值。	默认必须导入全部列值。不过，聚合表可以通过指定 Value 列的聚合函数为 REPLACE_IF_NOT_NULL 实现部分列更新，具体使用方式，请参见 aggr_type 。并且如果列具有默认值，也无需导入全部列值。	默认必须导入全部列值。如果列具有默认值，则无需导入全部列值。
DML INSERT	支持
DML UPDATE	Key 列作为过滤条件：支持 Value 列作为过滤条件：支持	不支持
DML DELETE	Key 列作为过滤条件：支持 Value 列作为过滤条件：支持	Key 列作为过滤条件：支持 Value 列作为过滤条件：支持。注意，仅支持基于 Key 或 Value 列本身的简单过滤条件，如 =、，不支持复杂条件，如函数、子查询。	Key 列作为过滤条件：支持。注意，仅支持基于 Key 列本身的简单过滤条件，如 =、，不支持复杂条件，如函数、子查询。 Value 列作为过滤条件：不支持

明细模型（Duplicate Key）

适用于大数据量追加写入的场景，不支持更新，不建议删除。对于两条相同数据，仍视为两条

聚合模型（Aggregate Key）

key列相同的数据会根据value列设置的聚合函数进行聚合，表内最终只存储聚合后的结果数据

支持的聚合函数

SUM、MAX、MIN、REPLACE
REPLACE_IF_NOT_NULL：当且仅当新导入数据非空时发生替换
HLL_UNION_AGG、HLL_UNION：仅用于HLL列
BITMAP_UNION：仅用于BITMAP列

更新模型(Unique Key)

Unique Key 官网讲解

upsert方式写入更新，是聚合模型value列增均为REPLACE的一个特例。采用MOR读时合并模式实现更新，对写入更友好，查询性能较明细模型差，每次写入会产生一个隐式版本号，对外只可见同key版本最大的数据，且历史版本不可召回，会在后台compaction时删除。不支持Update

create table unique1(date DATE not null, value bigint) UNIQUE KEY(date) distributed by hash(date) buckets 8; insert into unique1 values ('20250630',10); insert into unique1 values ('20250630',20); insert into unique1 values ('20250630',null); MySQL [test]> select * from unique1; +------------+-------+ | date | value | +------------+-------+ | 2025-06-30 | NULL | +------------+-------+

主键模型（Primary Key）

Primary Key官网讲解

starrocks全新设计模型，主键模型的表要求有唯一的主键，支持对表中的行按主键进行更新和删除操作。相较更新模型，主键模型可以更好地支持实时和频繁更新等场景。

采用Delete And Insert模式实现更新，查询性能较更新模型提升3～5倍以上。

支持部分更新、条件更新，有效解决数据乱序问题
支持Delete、Update语法

enable_persistent_index：持久化主键索引，默认true，启用后同时使用磁盘和内存存储主键索引，避免索引占用过大内存

列类型

数据类型

数字：Bigint、int、Largeint、Smallint、Tinyint、Boolean、Decimal、Double、Float
字符串：Char、varchar（最多1mb，单位是字节数，而非mysql的字符数）、string、binary/varbinary
日期：date、datetime（精度支持至微秒）
半结构化：json（最多16mb）、array（最多14层嵌套）、map（最多14层嵌套）、struct
其他：HLL（只能用于聚合模型，用于非精确去重计数，无法看到原始值，只能用hll_union_agg）、Bitmap（用于非明细模型，支持指标列为Bitmap类型）

属性：

自增列：AUTO_INCREMENT
默认值：DEFAULT '10'、DEFAULT current_timestamp、DEFAULT uuid()、DEFAULT uuid_numeric()

分区

PARTITION分区（支持range、list或表达式分区）：一般选时间、枚举字段。数据导入和备份恢复的最小逻辑单位

1.range分区：左闭右开无重复，分区不建数不入。手动创建

- PARTITION BY RANGE(event_day) (PARTITION part1 VALUES LESS THAN('2025-05-01'))
- 动态分区：增加'dynamic_partition.enable'='true'配置属性后，后台常驻线程默认每10分钟对分区调度一次，删除历史维度m个粒度前的分区，创建未来维度n个粒度的新分区

2.list分区：适用于处理非连续值的列。手动创建

- PARTITION BY LIST(city) (PARTITION part1 VALUES IN ('HK', 'SH'))

3.表达式分区：日期函数、列表达式。数据导入时会自动创建分区，v3.0+

（1）日期函数，适用于连续相同粒度的日期范围

PARTITION BY date_trunc('day',event_day) 适用于按天查询

PARTITION BY date_trunc('month', event_day) 适用于按月查询

PARTITION BY time_slice(event_day, INTERVAL 7 day) 适用于按周查询

partition_live_number 保留的分区数，分区数包含当天，默认根据dynamic_partition_check_interval_seconds 10分钟调度检查后清理，v3.0+引入

（2）列表达式

PARTITION BY (dt, city) 适用于经常按日期范围和特定城市查询

4.动态分区（不推荐，应使用表达式分区）

动态分区由后台常驻进程调度，默认调度周期为10分钟一次，由FE配置文件中的dynamic_partition_check_interval_seconds参数控制（单位是秒）

分桶

DISTRIBUTED分桶（支持hash、随机分桶）：一般选高基数、查询条件字段，且必须是主键的子集。桶过多会导致内存占用上升，过少会影响查询性能。已支持自动设置桶数。并发读写，避免热点问题

DISTRIBUTED BY HASH (k1[,k2 ...]) [BUCKETS num]

DISTRIBUTED BY RANDOM BUCKETS

表属性

replication_num 副本数
partition_live_number 保留的分区数，分区数包含当天，默认根据dynamic_partition_check_interval_seconds 10分钟调度检查后清理，3.0+引入

自动降冷

1.在be.conf显式指定存储类型：storage_root_path=/data1,medium:HDD;/data2,medium:SSD

2.指定分区的存储介质和到期时间

支持在建表时以表级别指定，也支持建表后修改、新增分区时以分区级别指定

alter table t1 add partition part1 values less than ('2025-06-30') ( 'storage_medium'='SSD', 'storage_cooldown_ttl'='1 MONTH' -- 1个月后将数据从ssd转到hdd )

Colocation join

是分布式系统实现 Join 数据分布的策略之一，能够减少数据多节点分布时 Join 操作引起的数据移动和网络传输，提高查询性能

需要在建表时为其指定一个 Colocation Group（CG），同一 CG 内的表需遵循相同的 Colocation Group Schema（CGS），即表对应的分桶副本具有一致的分桶键、副本数量和副本放置方式。如此可以保证同一 CG 内，所有表的数据分布在相同一组 BE 节点上。当 Join 列为分桶键时，计算节点只需做本地 Join，从而减少数据在节点间的传输耗时，提高查询性能。因此，Colocate Join，相对于其他 Join，例如 Shuffle Join 和 Broadcast Join，可以有效避免数据网络传输开销，提高查询性能。

当 Group 中最后一张表彻底删除后（彻底删除是指从回收站中删除。通常，一张表通过 DROP TABLE 命令被删除后，会在回收站默认停留一天的时间后，再被彻底删除），该 Group 也会被自动删除。

索引

StarRocks底层存储引擎提供了多种索引类型，分别是前缀索引（ShortKey Index）、Ordinal索引、ZoneMap索引、Bitmap索引、Bloom Filter索引、N-Gram bloom filter索引(v3.3)和全文倒排索引(v3.3)

自动创建：

ShortKey Index前缀索引：采用稀疏索引结构。在数据写入的过程中, StarRocks在排序键的基础上根据前缀列,每1024行生成一个索引项,在索引中存放索引项数据和对应数据偏移。前缀索引使用的列数不超过3,字节数不超过36字节，遇varchar截断。查询时利用二分查找

Ordinal Index : 可以理解为一级索引,其他索引查找数据时，都要通过Ordinal Index查找数据Page的位置。StarRocks底层采用列存的方式来存储数据,每一列数据会被分为多个Data Page。数据写入时, StarRocks会为每一个Data Page生成一条Ordinal索引项,在索引中保存Data Page在Segment文件中的offset、 Data Page的大小以及Data Page的起始行号。Ordinal Index索引能够将按列存储数据按行对齐,提供了通过行号来查找Column Data Page数据页的物理地址的能力。Ordinal index也采用稀疏索引结构,就像是一本书的目录,记录了每个章节对应的页码。
ZoneMap索引: StarRocks会自动为Segment文件中的一列数据添加ZoneMap索引,同时会为列中的每一个Data Page添加ZoneMap索引。ZoneMap索引项中记录了每一列或列中每一个Data Page的最大值(max value)、最小值(minvalue)、是否有null值(has null)以及是否有非null值(has not null)的信息。

手动创建：

Bitmap索引：适用于较高基数列的查询和多个低基数列的组合查询，支持日期、数值、字符串、HLL。适用于优化等值=查询、[not] in范围查询、> >= <
Bloom Filter索引：用于快速判断某个数据文件中是否不存在某值，只对in、=有加速效果
N-gram bloom filter索引（v3.3）：特殊的bf索引，用于加速like、ngram_search、ngram_search_case_insensitive，只适用于字符串
全文倒排索引（v3.3）：将文本中的每个单词分词，为每个词建立一个索引、记录该单词与其所在数据文件行号的映射关系。全文检索时，借助全文倒排索引，sr可以根据查询条件，找到包含关键词的索引项，然后快速找到关键词所在数据文件行号，大幅减少扫描行数

索引命中：查看sql profile中的ShortKeyFilterRows、BitmapIndexFilterRows、BloomFilterFilterRows等字段

索引使用顺序：ShortKey -> Bitmap -> BloomFIlter -> Zonemap -> Ordinal

资源组

配置

配置名称	描述	取值范围	默认值
cpu_weight	该资源组在一个 BE 节点上调度 CPU 的权重。该值指定了该资源组的任务可用的 CPU 时间的相对份额。在 v3.3.5 以前，该配置名称为 cpu_core_limit	(0,avg_be_cpu_cores] (大于 0 时生效)	0
exclusive_cpu_cores	该资源组的 CPU 硬隔离参数。v3.3.5+支持。在 v3.3.5 之前，StarRocks 支持设置 type 为 short_query 类型的资源组。目前，该参数已经被废弃，由 exclusive_cpu_cores 所代替专属：为该资源组留 exclusive_cpu_cores 个 CPU Core，其余资源组不可以使用，即使这些 CPU 处于空闲状态。限额：该资源组只能使用这 exclusive_cpu_cores 个 CPU Core。即使其他资源组有空闲的 CPU 资源，该资源组也不能使用。	(0,min_be_cpu_cores - 1] (大于 0 时生效)	0
mem_limit	该资源组在当前 BE 节点可使用于查询的内存的比例。	(0, 1] (必填项)	-
spill_mem_limit_threshold	该资源组触发落盘的内存占用阈值。v3.1.7+支持	(0, 1]	1.0
concurrency_limit	该资源组中并发查询数的上限。v3.1.4+默认未开启查询队列的情况下，超过后会自动失败，开启后会排队	整数 (大于 0 才生效)	0
max_cpu_cores	资源组在单个 BE 节点中使用的 CPU 核数上限。仅在设置为大于 0 后生效。自 v3.1.4 起支持	[0, avg_be_cpu_cores]，其中 avg_be_cpu_cores 表示所有 BE 的 CPU 核数的平均值	0
big_query_cpu_second_limit	该资源组的大查询任务在每个 BE 上可以使用 CPU 的时间上限。	整数 (大于 0 才生效)	0
big_query_scan_rows_limit	该资源组的大查询任务在每个 BE 上可以扫描的行数上限。	整数 (大于 0 才生效)	0
big_query_mem_limit	该资源组的大查询任务在每个 BE 上可以使用的内存上限。	整数 (大于 0 才生效)	0

系统定义资源组

每个 StarRocks 示例中有两个系统定义资源组：default_wg 和 default_mv_wg。您可以通过 ALTER RESOURCE GROUP 来修改系统定义资源组的配置，但不能为其定义分类器，也不能删除系统定义资源组。

1.default_wg

如果普通查询受资源组管理，但是没有匹配到分类器，系统将默认为其分配 default_wg。该资源组的默认资源配置如下：

cpu_weight：BE 的 CPU 核数。
mem_limit：100%。
concurrency_limit：0。
big_query_cpu_second_limit：0。
big_query_scan_rows_limit：0。
big_query_mem_limit：0。
spill_mem_limit_threshold: 1.0。

2.default_mv_wg

如果创建异步物化视图时没有通过 resource_group 属性指定资源组，该物化视图刷新时，系统将默认为其分配 default_mv_wg。该资源组的默认资源配置如下：

cpu_weight：1。
mem_limit：80%。
concurrency_limit: 0。
spill_mem_limit_threshold: 80%。

分类器

您可以为每个资源组关联一个或多个分类器。系统将会根据所有分类器中设置的条件，为每个查询任务选择一个匹配度最高的分类器，并根据生效的分类器所属的资源组为该查询任务分配资源。

分类器可以包含以下条件：

user：用户名。
role：用户所属的 Role。
query_type: 查询类型，目前支持 SELECT 与 INSERT (2.5及以后)。当 query_type 为 insert 的资源组有 INSERT INTO 或 Broker Load 导入任务正在运行时，当前 BE 节点会为其预留相应的计算资源。
source_ip：发起查询的 IP 地址，类型为 CIDR。
db：查询所访问的 Database，可以为 , 分割的字符串。
plan_cpu_cost_range：系统估计的查询 CPU 开销范围。格式为 (DOUBLE, DOUBLE]。默认为 NULL，表示没有该限制。fe.audit.log 的 PlanCpuCost 列为系统估计的该查询的 CPU 开销。自 v3.1.4 版本起，StarRocks 支持该参数。
plan_mem_cost_range：系统估计的查询内存开销范围。格式为 (DOUBLE, DOUBLE]。默认为 NULL，表示没有该限制。fe.audit.log 的 PlanMemCost 列为系统估计的该查询的内存开销。自 v3.1.4 版本起，StarRocks 支持该参数。

查询队列

默认关闭查询队列。可以通过设置相应的全局会话变量（Global session variable）来为 INSERT 导入、SELECT 查询和统计信息查询启用全局或资源组粒度的查询队列

BE粒度的资源阈值

可以通过以下全局会话变量设置单be粒度的触发查询队列的阈值：

变量	默认值	描述
query_queue_concurrency_limit	0	单个 BE 节点中并发查询上限。仅在设置为大于0后生效。设置为0表示没有限制。
query_queue_mem_used_pct_limit	0	单个 BE 节点中内存使用百分比上限。仅在设置为大于0后生效。设置为0表示没有限制。取值范围：[0, 1]
query_queue_cpu_used_permille_limit	0	单个 BE 节点中 CPU 使用千分比上限（即 CPU 使用率 * 1000）仅在设置为大于0后生效。设置为0表示没有限制。取值范围：[0,1000]

资源组粒度的资源阈值

从 v3.1.4 开始，可以在创建资源组时为其设置各自的并发查询上限 concurrency_limit 和 CPU 核数上限 max_cpu_cores。当发起一个查询时，如果任意一项资源占用超过了全局粒度或资源组粒度的资源阈值，那么查询会进行排队，直到所有资源都没有超过阈值，再执行该查询。

属性	默认值	描述
concurrency_limit	0	该资源组在单个 BE 节点中并发查询上限。仅在设置为大于0后生效。
max_cpu_cores	0	该资源组在单个 BE 节点中使用的 CPU 核数上限。仅在设置为大于0后生效。取值范围：[0,avg_be_cpu_cores]，其中avg_be_cpu_cores表示所有 BE 的 CPU 核数的平均值。

可以通过 SHOW USAGE RESOURECE GROUPS 来查看每个资源组在每个 BE 上的资源使用信息

配置查询队列

可以通过以下全局会话变量设置查询队列的容量和队列中查询的最大超时时间：

变量	默认值	描述
query_queue_max_queued_queries	1024	队列中查询数量的上限。当达到此阈值时，新增查询将被拒绝执行。仅在设置为大于0后生效。
query_queue_pending_timeout_second	300	队列中单个查询的最大超时时间。当达到此阈值时，该查询将被拒绝执行。单位：秒。

导入与导出

离线导入StreamLoad

StreamLoad是最核心的导入方法，基于http协议的同步导入，实现从本地文件系统或流式数据湖导入数据

重定向：FE 8030 -> BE 8040，对所涉及的节点都要网络可达
事务：每次导入都是一个事务，整批要么成功要么失败，没有中间状态
过半原则：导入涉及的tablet所在的BE超过半数存活，才生成导入执行计划

场景：

1. 导入本地数据文件，支持csv、json格式，支持UTF-8编码。采用curl命令

数据可包含__op字段，0代表upsert操作，1代表delete操作

2. 导入批量的离线数据。采用java等语法在导入时实现基于StreamLoad的逻辑导入，如DataX、Kettle、Seatunnel等

3. 导入实时产生的数据流。采用RoutineLoad、Flink等提交一个导入作业，持续生成一系列导入任务，每个任务先在内存攒微批，然后基于StreamLoad导入

离线导入BrokerLoad

基于SQL的异步导入方式，从hdfs、外部存储、本地磁盘导入几十到数百G的大数据量。支持csv、parquet、orc、json。能一次导入多个文件，事务性的，不会部分成功或失败。2.5+，可不借助Broker而直接通过BE

无broker模式（with broker且不支持配置）：架构更简洁，性能、稳定性更优、推荐使用。需要将core-site.xml、hdfs-site.xml放到sr的fe/conf、be/conf，修改conf配置，但限制一个sr集群仅能使用一个kerberos用户或仅能与一套hdfs集群通信

有broker模式（with broker broker_local）：需要单独部署broker组件，配置文件放到broker节点，不同的broker可使用不同的kerberos用户或连到不同hdfs集群。而且也支持导入broker本节点的数据文件

查看导入作业的结果：

show load where label='x'
select * from information_schema.loads
curl --location-trusted -u root:root 'http://FE_leader:8030/api/starrocks/_load_info?label=x'

取消导入：cancel load where label='x'

properties:

"partial_update"="true" 部分更新

离线导入SparkLoad

通过外部的spark资源实现对导入数据的预处理，提高sr大数据量的导入性能、节省计算资源，主要用于初次导入大量数据。与BrokerLoad类似，但BrokerLoad使用sr自身资源，SparkLoad使用外部spark资源。

SparkLoad在对数据etl后还会使用spark资源对要导入的数据进行分区、排序、聚合等，方便BE直接写入文件，有效降低导入过程中sr集群的资源使用

限制：

不支持主键模型表
需要依赖外部spark资源

实时导入RoutineLoad

基于SQL方式常驻订阅kafka消息，近实时导入。创建一个导入作业后，会常驻运行生成一系列的并行导入任务，通过StreamLoad方式不丢、不重地攒微批订阅kafka消息：任务调度->内存攒批->StreamLoad写入->任务上报->等待再次调度

支持从kafka消费csv、json、avro格式的数据，支持无认证、ssl认证、sasl认证访问kafka

命令：

show routine load for x;
show routine load task where jobname='x';
pause routine load for x;
alter routine load for x properties ('desired_concurrent_number'='2');
resume routine load for x;
stop routine load for x; 终止导入作业，终止后无法恢复，默认3天后清理

实时导入FlinkConnector

通过缓存数据攒批后基于StreamLoad写入

物化视图

	单表聚合	多表关联	查询改写	刷新策略	基表
异步物化视图	是	是	是	异步刷新手动刷新	支持多表构建。基表可以来自：Default CatalogExternal Catalog（v2.5）已有异步物化视图（v2.5）已有视图（v3.1）
同步物化视图	仅部分聚合函数	否	是	导入同步刷新	仅支持基于 Default Catalog 的单表构建

同步物化视图

本质是一个特殊的单表查询加速索引

所有对于基表的数据变更都会自动同步更新到物化视图中。无需手动调用刷新命令，即可实现自动同步刷新物化视图。同步物化视图的管理成本和更新成本都比较低，适合实时场景下单表聚合查询的透明加速

仅能基于 Default Catalog 中的单个基表创建部分聚合函数

无法指定mv的列别名，即使指定后也会被自动生成的列名代替

CREATE MATERIALIZED VIEW store_amt AS
SELECT store_id, SUM(sale_amt)
FROM sales_records
GROUP BY store_id;-- 直接查询同步物化视图，请勿省略 Hint 中的括号[]
SELECT * FROM store_amt [_SYNC_MV_];-- 查看特定表的表结构及其同步物化视图
DESC <tbl_name> ALL

异步物化视图

本质是一个物理表

异步物化视图支持多表关联以及更加丰富的聚合算子。异步物化视图可以通过手动调用、定时任务或自动触发的方式刷新，并且支持刷新部分分区，可以大幅降低刷新成本。除此之外，异步物化视图支持多种查询改写场景，实现自动、透明查询加速。

刷新粒度：partition_refresh_number属性控制单次刷新最多刷新的分区数量，若超过则分批从远至今刷，默认1

物化范围：partition_ttl_number（v3.1.5-）或 partition_ttl（推荐用于 v3.1.5=+）属性控制。partition_ttl_number 用于指定要保留的最新分区的数量，partition_ttl 用于指定要保留的物化视图数据的时间范围。在每次刷新过程中，StarRocks 会按时间顺序排列分区，并且仅保留符合 TTL 要求的分区。

刷新策略：自动刷新 (REFRESH ASYNC) 的物化视图在基表数据发生变化时会自动刷新；定时刷新 (REFRESH ASYNC [START ()] EVERY (INTERVAL )) 的物化视图将按照定义的间隔定时刷新；手动刷新 (REFRESH MANUAL) 的物化视图只能通过手动执行 REFRESH MATERIALIZED VIEW 语句进行刷新