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

StarRocks -- 基础概念(数据模型及分区分桶)

news 2025/12/19 3:49:30

1. 数据模型

StarRocks提供四种数据模型： Duplicate Key, Aggregate Key, Unique Key, Primary Key

1.1 Duplicate Key

适用场景：

分析原始数据，如原始日志和原始操作记录。
可以使用多种方法查询数据，不受预聚合方法的限制。
加载日志数据或时序数据。新数据以追加模式写入，现有数据不更新。
注意：
默认情况下，如果没有指定排序键列，StarRocks将使用前三列作为排序键【sort key】列
可以在表创建时创建索引，如BITMAP索引和Bloomfilter索引。
如果加载了两条相同的记录，将它们保留为两条记录，而不是一条
只能向表中追加数据。不能修改表中的现有数据。

1.2 Aggregate Key

此模型有助于减少查询需要处理的数据量，从而加快查询速度。
适用场景：

数据统计和分析场景
使用时有如下特点：
大多数查询是聚合查询，例如SUM、COUNT和MAX。
不需要检索原始的详细数据。
历史数据不经常更新。只追加新数据。
聚合时机：
ingestion 阶段：当数据批量加载到表中时，每个批量包含一个数据版本。生成数据版本后，StarRocks将在数据版本中具有相同排序键的数据进行聚合。
compaction 阶段：将数据摄取时生成的多个数据版本的文件定期压缩成一个大文件时，StarRocks会在大文件中聚合具有相同排序键的数据。
query 阶段：在返回查询结果之前聚合所有数据版本中具有相同排序键的数据。
注意：
如果AGGREGATE KEY关键字不包括所有维度列，则无法创建表。
如果没有使用AGGREGATE key关键字显式地定义排序键列，将选择除度量列之外的所有列作为排序键列
在运行查询时，排序键列在多个数据版本聚合之前被过滤，而度量列在多个数据版本聚合之后被过滤。
创建表时，不能在表的度量列上创建BITMAP索引或Bloom Filter索引
将数据加载到使用聚合键模型的表中时，只能更新表的所有列

1.3 Unique Key

使用场景：

需要频繁实时更新数据的业务场景，如在电子商务场景中，每天可以下数亿个订单，订单状态经常变化
注意:
主键必须创建在执行唯一约束且不能更改名称的列上
- 在运行查询时，主键列在多个数据版本聚合之前被过滤，而度量列在多个数据版本聚合之后被过滤
- 在聚合过程中，StarRocks比较所有主键列。这很耗时，而且可能会降低查询性能。因此，不要定义大量的主键列
创建表时，不能在表的指标列上创建BITMAP索引或Bloom Filter索引。
不支持实体化视图。
将数据加载到使用唯一键模型的表中时，只能更新表的所有列

1.4 Primary Key

与Unique Key模型不同，Primary Key模型在查询期间不需要聚合操作，并支持谓词和索引的下推。因此，Primary Key模型可以提供较高的查询性能，尽管实时和频繁的数据更新。
Duplicate Key模型采用MoR策略。MoR简化了数据写入，但需要在线聚合多个数据版本。此外，Merge操作符不支持下推谓词和索引。结果，查询性能下降。
Primary Key模型采用删除+插入策略，确保每条记录都有唯一的主键。这样，主键模型就不需要合并操作。详情如下:

对记录进行更新操作时，它通过搜索主键索引来定位该记录，将该记录标记为已删除，并插入一条新记录。换句话说，StarRocks将更新操作转换为删除操作加上插入操作。
对记录进行删除操作时，它通过搜索主键索引来定位记录，并将记录标记为已删除
适用场景：
数据需要经常实时更新
- 实时流数据从交易处理系统到StarRocks，这简化了数据同步，并提供比使用唯一键模型的MoR (Merge on Read)表高3到10倍的查询性能
- 通过对单个列执行更新操作来连接多个流：这些场景中的上游数据可能来自各种应用程序，如购物app、物流app和银行app，或者来自机器学习系统。主键模型非常适合这些场景，因为它支持对单个列的更新。每个应用程序或系统只能更新在自己的服务范围内保存数据的列
主键占用的内存【memory occupied by the primary key 】是可控的
- 当将数据加载到表中时，StarRocks将主键索引加载到内存中。因此Primary Key模型需要比其他三个数据模型更大的内存容量。StarRocks将组成主键的字段的总长度限制为编码后的127字节
- 表包含快速变化的数据和缓慢变化的数据。快速变化的数据经常在最近几天更新，而缓慢变化的数据很少更新，如订单表，按天分区，在运行数据加载作业时，主键索引不会加载到内存中，只有最近更新的订单的索引项才会加载到内存中。
- 表是一个由数百或数千列组成的平面表。主键只包含表数据的一小部分，并且只消耗少量内存。如user status or profile table，表的列太多，但只有几千万到几亿条
  注意：
必须在强制执行唯一约束的列上创建主键，并且不能更改主键列的名称。
主键列可以是以下任何数据类型:BOOLEAN、TINYINT、SMALLINT、INT、BIGINT、LARGEINT、STRING、VARCHAR、DATE和DATETIME。但是，主键列不能定义为NULL。
分区列和桶列必须参与主键。
the memory occupied by the primary key index 的计算公式： (主键长度+9) x 记录数量 x 副本数 x 1.5 = 占用内存大小
- 9是每行不可变的开销，1.5是每个哈希表的平均额外开销
enable_persistent_index:主键索引可以持久化到磁盘并存储在内存中，以避免占用太多内存。
从2.3.0版本开始， indicator column现在支持BITMAP、HLL数据类型。
创建表时，不能在表的 metric columns 上创建BITMAP索引或Bloom Filter索引。
从2.4.0版本开始，可以基于主键表创建异步物化视图

2. 分区分桶

在这里插入图片描述

2.1 分区：

StarRocks中的分区是在建表时通过PARTITION BY RANGE()语句设置，用于分区的列也被称之为分区键，当前分区键仅支持日期类型和整数类型（支持一列或多列）。
在分区时，可以设置分区的存储策略，包括副本数量、热数据或冷数据的存储策略、存储介质等。
StarRocks允许在集群中使用多个存储介质。例如，将最新数据保存在SSD硬盘上，可以提高查询性能;将历史数据保存在SATA硬盘上，可以降低存储成本。
StarRocks的分区粒度视数据量而定，单个分区原始数据量建议维持在100G以内。

2.2 分桶：

对每个分区的数据，StarRocks还会再进行Hash分桶。我们在建表时通过DISTRIBUTED BY HASH()语句来设置分桶，用于分桶的列也被称之为分桶键。分桶键可以是一列或多列。
分桶是将一个分区划分为多个更易于管理的部分即tablet，tablet是使用和分配的最小存储单元
bucket列中具有相同哈希值的数据被分布到同一tablet中
StarRocks为每个tablet创建多个副本(默认为三个)，以防止数据丢失。这些副本由单独的本地存储引擎管理。创建表时必须指定bucket列。
分桶数的设置通常也建议以数据量为参考，从经验来看，每个分桶的原始数据建议不要超过5个G，考虑到压缩比，也即每个分桶的大小建议在100M-1G之间。
分桶的目的我们一直在说是为了将数据打散，所以分桶键就需要选择高基数的列（去重后数据量最大的列）。分桶后的数据如果出现严重的数据倾斜，就可能导致系统局部的性能瓶颈，所以我们也可以视情况使用两个或三个列作为分桶键，尽量的将数据均匀分布。我们可以show语句查看表中的数据分布情况：

mysql> show tablet from tablename;

若不好估算数据量，我们也可以将分桶数设为：分桶数=“BE个数BE节点CPU核数”或者“BE个数BE节点CPU核数/2”，这样一般也不会有什么问题。这里需要注意的是，已创建分区的分桶数不能修改（有其他方式能实现，但比较麻烦），所以前期设定合适的分桶数非常重要。

2.3 动态分区

在StarRocks中，必须先有分区，才能将对应的数据导入进来，不然导入就会报错（提示there is a row couldn’t find a partition）。比如使用日期作为分区，那就需要先创建每天的分区，再进行数据导入。在日常业务中，除了每日会新增数据，我们还会对旧的历史数据进行清理。动态分区就是StarRocks用来实现新分区自动创建以及过期分区自动删除的方式。
动态分区由后台常驻进程调度，默认调度周期为10分钟一次，由FE配置文件中的dynamic_partition_check_interval_seconds参数控制（单位是秒，配置文件中默认没有该配置），所以并不是创建动态分区表后所有分区就立刻被创建，我们还需要等待不超过10分钟让后台调度生效。
动态分区参数在properties中配置：
- dynamic_partition.enable：是否开启动态分区特性，可指定为TRUE或FALSE。如果该参数等号后不填写值，则默认代表TRUE。
- dynamic_partition.time_unit：动态分区调度的粒度，可指定为DAY/WEEK/MONTH。不同分区粒度下动态分区自动创建分区的名称后缀不同，指定为DAY时，分区名后缀为yyyyMMdd，例如table07中的20211009。指定为WEEK时，分区名后缀为yyyy_ww，例如2021_40代表2021年第40周。指定为MONTH时，动态创建的分区名后缀格式为yyyyMM，例如202110。这里注意，我们创建静态分区时，分区命名也建议和动态分区自动创建的规则保持一致。
- dynamic_partition.start：动态分区的开始时间。以当天为基准，根据该参数向过去推算数个粒度的时间，超过该时间范围的分区将会被删除。如果不填写，则默认为Integer.MIN_VALUE即-2147483648。
- dynamic_partition.end：动态分区的结束时间。以当天为基准，会根据该参数提前创建数个粒度的分区范围。
- dynamic_partition.prefix：动态分区自动创建的分区名前缀。
- dynamic_partition.buckets：动态创建的分区所对应的分桶数量。
  以上属性在建表完成后也可以进行修改，例如关闭动态分区属性：

ALTER TABLE table07 SET("dynamic_partition.enable"="false");

查看分区

SHOW PARTITIONS FROM table07;

当分区键为日期类型的时候，需要指定INTERVAL关键字来表示日期间隔，目前日期仅支持day、week、month、year，分区的命名规则同动态分区一样。例如：

PARTITION BY RANGE (event_day) (START ("2019-01-01") END ("2021-01-01") EVERY (INTERVAL 1 YEAR),START ("2021-01-01") END ("2021-05-01") EVERY (INTERVAL 1 MONTH),START ("2021-05-01") END ("2021-05-04") EVERY (INTERVAL 1 DAY)
)## 等价于
PARTITION p2019 VALUES [('2019-01-01'), ('2020-01-01')),
PARTITION p2020 VALUES [('2020-01-01'), ('2021-01-01')),
PARTITION p202101 VALUES [('2021-01-01'), ('2021-02-01')),
PARTITION p202102 VALUES [('2021-02-01'), ('2021-03-01')),
PARTITION p202103 VALUES [('2021-03-01'), ('2021-04-01')),
PARTITION p202104 VALUES [('2021-04-01'), ('2021-05-01')),
PARTITION p20210501 VALUES [('2021-05-01'), ('2021-05-02')),
PARTITION p20210502 VALUES [('2021-05-02'), ('2021-05-03')),
PARTITION p20210503 VALUES [('2021-05-03'), ('2021-05-04'))

当分区键为整数类型时，我们可以直接使用数字进行分区，这里注意分区值需要使用引号引用，而EVERY则不用引号，例如：

PARTITION BY RANGE (datekey) (START ("1") END ("5") EVERY (1)
)## 等价于
PARTITION p1 VALUES [("1"), ("2")),
PARTITION p2 VALUES [("2"), ("3")),
PARTITION p3 VALUES [("3"), ("4")),
PARTITION p4 VALUES [("4"), ("5"))

2.4 分区分桶修改

在建表完成后，我们也可以手动增加分区。

如果没有指定分桶方式，则自动使用建表时的分桶方式。
如果指定分桶方式，则使用新的分桶方式创建（这里当前只能修改分桶数，不能修改分桶方式或分桶列）。
动态分区表的分区不能直接增删改，若要操作，需要先关闭其动态分区属性。