通过上一篇博客(【大数据】初步认识StarRocks),我们对StarRocks有了一个简单的认识,这边博客呢,我们主要来学习下StarRocks的四种数据模型:明细模型 (Duplicate Key Model)、聚合模型 (Aggregate Key Model)、更新模型 (Unique Key Model) 和主键模型 (Primary Key Model)。这四种数据模型能够支持多种数据分析场景,例如日志分析、数据汇总分析、实时分析等。
补:数据模型描述数据的结构、特性、关系和约束的概念模型,常见的数据模型有层次模型、网络模型和关系模型。
一、明细模型
明细表是默认创建的表类型。如果在建表时未指定任何 key,默认创建的是明细表。
创建表时,支持定义排序键。如果查询的过滤条件包含排序键,则 StarRocks 能够快速地过滤数据,提高查询效率。明细表适用于日志数据分析等场景,支持追加新数据,不支持修改历史数据。
适用场景
- 分析原始数据,例如原始日志、原始操作记录等。
- 查询方式灵活,不需要局限于预聚合的分析方式。
- 导入日志数据或者时序数据,主要特点是旧数据不会更新,只会追加新的数据。
建表语法
CREATE TABLE IF NOT EXISTS detail (
event_time DATETIME NOT NULL COMMENT "datetime of event",
event_type INT NOT NULL COMMENT "type of event",
user_id INT COMMENT "id of user",
device_code INT COMMENT "device code",
channel INT COMMENT ""
)
DUPLICATE KEY(event_time, event_type)
DISTRIBUTED BY HASH(user_id)
PROPERTIES (
"replication_num" = "3"
);
注意:
-
建表时必须使用 DISTRIBUTED BY HASH 子句指定分桶键,否则建表失败
-
排序键:
- 在建表语句中,排序键必须定义在其他列之前。
- 排序键可以通过 DUPLICATE KEY 显式定义。本示例中排序键为 event_time 和 event_type。
如果未指定,则默认选择表的前三列作为排序键。 - 明细表中的排序键可以为部分或全部维度列。
二、聚合模型
建表时,支持定义排序键和指标列,并为指标列指定聚合函数。当多条数据具有相同的排序键时,指标列会进行聚合。在分析统计和汇总数据时,聚合表能够减少查询时所需要处理的数据,提升查询效率。
适用场景
聚合数据分析
- 多为汇总类查询,比如 SUM、MAX、MIN等类型的查询。
- 不需要查询原始的明细数据。
- 旧数据更新不频繁,只会追加新的数据。
例如:
- 通过分析网站或 APP 的访问流量,统计用户的访问总时长、访问总次数。
- 广告厂商为广告主提供的广告点击总量、展示总量、消费统计等。
- 通过分析电商的全年交易数据,获得指定季度或者月份中,各类消费人群的爆款商品。
建表语法
CREATE TABLE IF NOT EXISTS example_db.aggregate_tbl (
site_id LARGEINT NOT NULL COMMENT "id of site",
date DATE NOT NULL COMMENT "time of event",
city_code VARCHAR(20) COMMENT "city_code of user",
pv BIGINT SUM DEFAULT "0" COMMENT "total page views"
)
AGGREGATE KEY(site_id, date, city_code)
DISTRIBUTED BY HASH(site_id)
PROPERTIES (
"replication_num" = "3"
);
注意:
-
建表时必须使用 DISTRIBUTED BY HASH 子句指定分桶键
-
排序键
在建表语句中,排序键必须定义在其他列之前。
排序键可以通过 AGGREGATE KEY 显式定义。
排序键必须满足唯一性约束,必须包含全部维度列,并且列的值不会更新。 -
指标列:通过在列名后指定聚合函数,定义该列为指标列。一般为需要汇总统计的数据。
-
聚合函数:指标列使用的聚合函数。聚合表支持的聚合函数,请参见 CREATE TABLE。
-
查询时,排序键在多版聚合之前就能进行过滤,而指标列的过滤在多版本聚合之后。因此建议将频繁使用的过滤字段作为排序键,在聚合前就能过滤数据,从而提升查询性能。
-
建表时,不支持为指标列创建 BITMAP、Bloom Filter 等索引。
三、更新模型
建表时,支持定义主键和指标列,查询时返回主键相同的一组数据中的最新数据,更新表简化了数据导入流程,能够更好地支撑实时和频繁更新的场景。
适用场景
实时和频繁更新的业务场景,例如分析电商订单。在电商场景中,订单的状态经常会发生变化,每天的订单更新量可突破上亿。
建表语法
CREATE TABLE IF NOT EXISTS orders (
create_time DATE NOT NULL COMMENT "create time of an order",
order_id BIGINT NOT NULL COMMENT "id of an order",
order_state INT COMMENT "state of an order",
total_price BIGINT COMMENT "price of an order"
)
UNIQUE KEY(create_time, order_id)
DISTRIBUTED BY HASH(order_id)
PROPERTIES (
"replication_num" = "3"
);
注意:
- 建表时必须使用 DISTRIBUTED BY HASH 子句指定分桶键
- 主键:
- 在建表语句中,主键必须定义在其他列之前。
- 主键通过 UNIQUE KEY 定义。
- 主键必须满足唯一性约束,且列的值不会修改。
- 设置合理的主键。
- 建表时,不支持为指标列创建 BITMAP、Bloom Filter 等索引。
四、主键模型
主键表中的主键具有唯一非空约束,用于唯一标识数据行。如果新数据的主键值与表中原数据的主键值相同,则存在唯一约束冲突,此时新数据会替代原数据。主要优势在于支撑实时数据更新的同时,也能保证高效的复杂即席查询性能。
应用场景
- 实时对接事务型数据至 StarRocks。
- 利用部分列更新轻松实现多流 JOIN
建表语法
CREATE TABLE orders1 (
order_id bigint NOT NULL,
dt date NOT NULL,
user_id INT NOT NULL,
good_id INT NOT NULL,
cnt int NOT NULL,
revenue int NOT NULL
)
PRIMARY KEY (order_id)
DISTRIBUTED BY HASH (order_id)
;
注意:
- 在建表语句中,主键列必须定义在其他列之前。
- 主键必须包含分区列和分桶列。
- 主键列支持以下数据类型:数值(包括整型和布尔)、日期和字符串。
- 单条主键值编码后的最大长度为 128 字节。
- 建表后不支持修改主键。
- 主键列的值不能更新,避免破坏数据一致性。
每种数据模型都有其特定的应用场景和优缺点,用户可以根据自己的业务需求选择合适的数据模型来构建表。在建表时,需要指定数据模型,以便StarRocks能够按照排序键对数据进行排序、处理和存储