1、Catalogs、databases 和 tables
在 StarRocks 中,Catalogs(目录)、Databases(数据库) 和 Tables(表) 是构成数据组织架构的核心层级,从高到低依次形成“Catalog → Database → Table”的三级结构,用于高效管理和访问数据。以下是它们的详细简介:
1. Catalogs(目录)
定义:Catalog 是 StarRocks 中最高层级的命名空间,用于统一管理不同类型的数据源(如 StarRocks 本地数据、Hive 元数据、Iceberg 表、Delta Lake 表等),实现多源数据的集中访问和管理。
核心作用:
- 多源数据整合:通过不同类型的 Catalog 连接外部数据源(如 Hive Catalog、Iceberg Catalog)和本地数据(Internal Catalog),让用户可以像访问本地表一样查询外部数据,无需数据迁移。
- 隔离与权限控制:不同 Catalog 可对应不同的业务场景或数据源,便于权限隔离(如限制用户只能访问特定 Catalog)。
常见类型:
- Internal Catalog:StarRocks 内置的默认 Catalog,用于管理本地创建的数据库和表(如通过
CREATE DATABASE
CREATE TABLE
创建的对象)。 - External Catalog:连接外部数据源的 Catalog,例如:
- Hive Catalog:对接 Hive 元数据,访问 Hive 表;
- Iceberg Catalog:对接 Apache Iceberg 表;
- MySQL Catalog:对接 MySQL 数据库中的表。
使用示例:
访问 Hive Catalog 中 hive_db
数据库下的 hive_table
表:
SELECT * FROM hive_catalog.hive_db.hive_table;
2. Databases(数据库)
定义:Database 是 Catalog 下的二级命名空间,用于对表进行逻辑分组,通常按业务场景、数据类型或部门划分(如“用户行为库”“交易库”)。
核心作用:
- 逻辑隔离:将不同业务的表放在不同数据库中,避免表名冲突(如两个业务都有
user
表,可分别放在user_db
和trade_db
中)。 - 权限管理:可针对数据库设置权限(如只允许某用户查询
user_db
,不允许修改)。
特点:
- 每个 Database 隶属于某个 Catalog(默认属于 Internal Catalog)。
- 支持通过
CREATE DATABASE
创建,DROP DATABASE
删除,USE DATABASE
切换当前数据库。
使用示例:
创建一个隶属于 Internal Catalog 的数据库 sales_db
:
CREATE DATABASE sales_db;
USE sales_db; -- 切换到该数据库,后续操作可省略数据库名
3. Tables(表)
定义:Table 是 StarRocks 中存储和管理数据的基本单元,由行和列组成,对应实际的业务实体(如“用户表”“订单表”)。
核心特性:
- 多种表类型:
- Duplicate Key 表:默认表类型,允许数据重复,适合日志、行为等无需去重的场景;
- Unique Key 表:支持按主键去重,适合需要更新数据的场景(如用户信息表);
- Aggregate Key 表:自动按主键聚合数据(如求和、计数),适合分析场景(如指标汇总表);
- Primary Key 表:支持主键唯一且高效更新,适合实时同步业务库的场景。
- 分区与分桶:支持按时间、业务维度分区(Partition),并在分区内分桶(Bucket),提升查询效率。
- 列类型丰富:支持数值、字符串、日期、JSON、数组等多种数据类型,满足复杂业务需求。
使用示例:
在 sales_db
数据库中创建一个订单表 orders
:
CREATE TABLE sales_db.orders (
order_id INT,
user_id INT,
amount DECIMAL(10,2),
order_time DATETIME
)
DUPLICATE KEY (order_id)
PARTITION BY RANGE (order_time) (
PARTITION p2023 VALUES LESS THAN ('2024-01-01')
)
DISTRIBUTED BY HASH (order_id) BUCKETS 10;
三者关系总结
- 层级关系:
Catalog → Database → Table
,形成树形结构,通过“Catalog.数据库.表”的全称可唯一定位一个表。 - 作用分工:
- Catalog 解决“跨数据源访问”问题;
- Database 解决“表的逻辑分组”问题;
- Table 解决“数据存储与业务映射”问题。
这种层级结构让 StarRocks 既能高效管理本地数据,又能无缝对接外部数据源,适合复杂数据架构下的统一查询和分析。
2、表类型
✅ 各类表能力对比
https://docs.starrocks.io/zh/docs/table_design/table_types/table_capabilities/
✅ 表类型
-
主键表
1)优势
数据更新的同事高效查询
2)场景
1.实时对接事务型数据至 StarRocks
2.利用部分列更新轻松实现多流 JOIN3)工作原理
1.Delete+Insert 策略 实现实时更新 2.主键索引 + DelVector 精确定位最新版本数据,避免多版本合并 3.查询时可直接下推谓词和索引至底层数据
- 数据写入是通过 StarRocks 内部的 Loadjob 实现,包含一批数据变更操作(包括 Insert、Update、Delete)。
- 读取数据时,由于写入数据时各个数据文件中历史重复数据已经标记为删除,同一个主键值下仅需要读取最新的一条数据,无需在线 Merge 多个版本的数据文件来去重以找到最新的数据。
4)使用
CREATE TABLE orders2 ( order_id bigint NOT NULL, dt date NOT NULL, merchant_id int NOT NULL, user_id int NOT NULL, good_id int NOT NULL, good_name string NOT NULL, price int NOT NULL, cnt int NOT NULL, revenue int NOT NULL, state tinyint NOT NULL ) PRIMARY KEY (order_id,dt,merchant_id) PARTITION BY date_trunc('day', dt) DISTRIBUTED BY HASH (merchant_id) ORDER BY (dt,merchant_id) PROPERTIES ( "enable_persistent_index" = "true" );
5)主键
- 在建表语句中,主键列必须定义在其他列之前。
- 主键必须包含分区列和分桶列。
- 主键列支持以下数据类型:数值(包括整型和布尔)、日期和字符串。
- 默认设置下,单条主键值编码后的最大长度为 128 字节。
- 建表后不支持修改主键。
- 主键列的值不能更新,避免破坏数据一致性。
6)主键索引
7)排序键
-
明细表
1)场景
- 分析原始数据,例如原始日志、原始操作记录等。
- 查询方式灵活,不需要局限于预聚合的分析方式。
- 导入日志数据或者时序数据,主要特点是旧数据不会更新,只会追加新的数据。
2)使用
CREATE TABLE 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 "") ORDER BY (event_time, event_type);
-
聚合表
1)场景
- 帮助网站或应用程序提供商分析用户在特定网站或应用程序上的流量和停留时间,以及网站或应用程序的总访问次数。
- 帮助广告公司分析他们为客户提供的广告的总点击量、总浏览量和消费统计数据。
- 帮助电子商务公司分析其年度交易数据,以识别各个季度或月份内的地理畅销商品。
2)数据查询摄取特点
- 大多数查询是聚合查询,如 SUM、MAX 和 MIN。
- 不需要检索原始明细数据。
- 历史数据不经常更新。仅追加新数据。
3)原理
- 在数据摄取阶段,当数据以批次导入聚合表时,每批数据形成一个版本。在一个版本中,具有相同聚合键的数据将被聚合。
- 在后台压缩阶段,当在数据摄取时生成的多个数据版本的文件定期压缩成一个大文件时,StarRocks 会在大文件中聚合具有相同聚合键的数据。
- 在数据查询阶段,StarRocks 会在返回查询结果之前聚合所有数据版本中具有相同聚合键的数据。
4)使用
CREATE TABLE 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);
-
更新表
使用主键表替换 -
视图、同步物化视图、异步物化视图
当然,下面是 StarRocks 中 视图、同步物化视图、异步物化视图 的简明解释和对比:
✅ 1. 视图(View)
- 逻辑视图,不存储数据,只保存 SQL 查询逻辑。
- 每次查询都会重新执行原始 SQL。
- 不加速查询,仅用于简化复杂 SQL、统一查询口径。
📌 示例:
CREATE VIEW v_user_orders AS
SELECT user_id, COUNT(*) AS order_count
FROM orders
GROUP BY user_id;
✅ 2. 同步物化视图(同步 MV)
- 使用
REFRESH IMMEDIATE
创建。 - 数据写入原表时自动更新视图(强一致)。
- 查询可自动命中视图,显著加速聚合、Join 等操作。
- 适合 实时性要求高 的分析场景。
📌 示例:
CREATE MATERIALIZED VIEW mv_user_sum
BUILD IMMEDIATE REFRESH AUTO
AS
SELECT user_id, SUM(amount) FROM orders GROUP BY user_id;
✅ 3. 异步物化视图(异步 MV)
- 使用
REFRESH MANUAL
创建。 - 不自动更新,需手动或定时触发刷新。
- 查询也可自动命中,但数据可能有延迟。
- 适合 数据实时性要求不高 的批量分析场景。
📌 示例:
CREATE MATERIALIZED VIEW mv_user_sum
BUILD IMMEDIATE REFRESH MANUAL
AS
SELECT user_id, SUM(amount) FROM orders GROUP BY user_id;
-- 手动刷新
REFRESH MATERIALIZED VIEW mv_user_sum;
✅ 对比总结
类型 | 是否存储数据 | 是否自动更新 | 查询加速 | 实时性 | 典型用途 |
---|---|---|---|---|---|
视图 | ❌ 否 | ❌ 否 | ❌ 否 | 实时查询 | 简化 SQL、统一口径 |
同步物化视图 | ✅ 是 | ✅ 是 | ✅ 是 | 高 | 实时聚合、实时查询加速 |
异步物化视图 | ✅ 是 | ❌ 否(手动) | ✅ 是 | 中/低 | 批量分析、非实时场景 |
📌 总结:
- 实时分析 → 用同步物化视图
- 批处理分析 → 用异步物化视图
- 简化 SQL,无需加速 → 用普通视图
3、分区与分桶策略优化
✅ 分区策略优化
分区(Partition):按字段(如日期、地区)水平切分数据。
优化目标:
- 减少扫描数据量(分区裁剪)
- 简化生命周期管理(如 TTL 删除)
- 降低元数据压力(避免过多小分区)
优化建议:
- 按查询常用过滤字段分区(如
event_date
) - 控制分区数量(建议 < 10 万)
- 使用 RANGE 或 LIST 分区,必要时用多级分区
✅ 分桶策略优化
分桶(Bucket):分区内进一步哈希切分数据,分布到多个 tablet。
优化目标:
- 提高并发查询与写入性能
- 实现数据负载均衡
- 降低单个 tablet 大小,避免 compaction 问题
优化建议:
- 按高基数字段分桶(如
user_id
、order_id
) - 控制 tablet 总数(单 BE < 20 万 tablet)
- 避免过多分桶 + 副本数造成 tablet 爆炸
- 使用动态分桶(StarRocks 3.x 支持)
✅ 分区 + 分桶联合优化
项目 | 作用 | 建议 |
---|---|---|
分区字段选择 | 提升过滤效率、管理生命周期 | 优先选择时间、地区等常过滤字段 |
分桶字段选择 | 提升并发性能、数据均衡 | 使用高基数字段(如用户、订单 ID) |
分桶数量 | 控制 tablet 数、提升并发 | 根据数据量、节点数设置,避免过多或过少 |
多级分区 | 降低一级分区数量,提升管理效率 | 如:RANGE(时间) + LIST(地区) |
4、主键模型 vs 明细模型的使用场景
✅ 主键模型(Primary Key)
🔹 特点:
- 支持实时更新(Delete + Insert)
- 保证主键唯一性
- 自动构建主键索引 + DelVector
- 查询性能高,适合更新频繁场景
🔹 适用场景:
- 实时更新场景(如维表、用户画像)
- 数据唯一性要求高(如订单、设备状态)
- 数据量大但更新频繁(如日志、埋点)
✅ 明细模型(Duplicate Key)
🔹 特点:
- 不做主键去重,保留所有明细数据
- 不支持更新,只支持追加写入
- 查询时需聚合或过滤重复数据
🔹 适用场景:
- 明细数据存储(如日志、交易流水)
- 不需要更新的数据仓库场景
- 聚合分析类查询(如 GROUP BY)
✅ 对比总结
对比项 | 主键模型(Primary Key) | 明细模型(Duplicate Key) |
---|---|---|
数据唯一性 | 有(主键约束) | 无 |
是否支持更新 | ✅ 支持实时更新 | ❌ 不支持,仅支持追加 |
查询性能 | 高(索引 + DelVector 优化) | 中(需聚合/过滤重复) |
存储开销 | 稍高(维护索引) | 较低 |
典型场景 | 维表、状态表、实时更新数据 | 日志、交易明细、埋点数据 |
📌 总结:
- 需要更新/去重 → 用主键模型
- 保留所有明细/仅追加写入 → 用明细模型
5、物化视图设计与自动重写机制
在 StarRocks 中,**物化视图(Materialized View)** 是一种自动维护的预计算结果表,用于加速查询性能。它结合了 **自动重写机制**,可在不改写 SQL 的前提下自动命中视图,提升查询效率。
✅ 什么是物化视图?
- 是基于原始表的 SQL 查询结果
- 数据会定期或实时自动刷新
- 查询时可被自动重写使用,避免全表扫描和重复计算
✅ 典型用途
- 加速聚合查询(如
GROUP BY
) - 加速 TopN 查询(如
ORDER BY ... LIMIT
) - 加速多表 Join 查询
- 减少资源消耗,提升响应速度
✅ 自动重写机制
StarRocks 支持 查询自动重写为命中物化视图,无需用户手动指定。
自动重写触发条件:
- 查询逻辑与物化视图逻辑兼容(字段、过滤条件、聚合等)
- 查询使用的基础表与物化视图一致
- 查询粒度不低于物化视图(支持下推)
示例:
-- 原始表
CREATE TABLE orders (
order_id BIGINT,
user_id BIGINT,
order_date DATE,
amount DOUBLE
);
-- 创建物化视图
CREATE MATERIALIZED VIEW mv_user_day_amount
BUILD IMMEDIATE REFRESH AUTO
AS
SELECT user_id, order_date, SUM(amount) AS total_amount
FROM orders
GROUP BY user_id, order_date;
-- 查询时自动命中该视图
SELECT user_id, order_date, SUM(amount)
FROM orders
GROUP BY user_id, order_date;
✅ 设计建议
项目 | 建议 |
---|---|
刷新方式 | 实时更新用 IMMEDIATE ,批量更新用 MANUAL |
聚合字段选择 | 聚合字段应与查询常用字段一致,避免查询无法重写 |
命中率优化 | 保证列名、聚合函数、过滤条件一致,提高自动命中成功率 |
多视图组合 | 可为不同维度、时间粒度建多个视图,满足多场景加速需求 |
📌 总结:
StarRocks 的物化视图结合自动重写机制,可在后台自动命中加速查询,无需改写 SQL,大幅提升查询性能,是 OLAP 查询优化的重要利器。