StarRocks的四种数据模型

基本概念

数据模型

排序键

说明

• 3.0 版本之前，主键模型不支持分别定义主键和排序键。
• 排序键的更多说明，请参见排序键和前缀索引。

注意事项

• 在建表语句中，排序键必须定义在其他列之前。
• 在创建表时，您可以将一个或多个列定义为排序键。排序键在建表语句中的出现次序，为数据存储时多重排序的次序。
• 不支持排序键的数据类型为 BITMAP、HLL。
• 前缀索引的长度限制为 36 字节。如果排序键中全部列的值的长度加起来超过 36 字节，则前缀索引仅会保存限制范围内排序键的若干前缀列。
• 如果导入的数据存在重复的主键，则数据导入至数据模型，存储在 StarRocks 时，则会按照如下方式进行处理：
  • 明细模型：表中会存在主键重复的数据行，并且与导入的数据是完全对应的。您可以召回所导入的全部历史数据。
  • 聚合模型：表中不存在主键重复的数据行，主键满足唯一性约束。导入的数据中主键重复的数据行聚合为一行，即具有相同主键的指标列，会通过聚合函数进行聚合。您只能召回导入的全部历史数据的聚合结果，但是无法召回历史明细数据。
  • 主键模型和更新模型：表中不存在主键重复的数据行，主键满足唯一性约束。最新导入的数据行，替换掉其他主键重复的数据行。这两种模型可以视为聚合模型的特殊情况，相当于在聚合模型中，为表的指标列指定聚合函数为 REPLACE，REPLACE 函数返回主键相同的一组数据中的最新数据。

明细模型

适用场景

• 分析原始数据，例如原始日志、原始操作记录等。
• 查询方式灵活，不需要局限于预聚合的分析方式。
• 导入日志数据或者时序数据，主要特点是旧数据不会更新，只会追加新的数据。

创建表

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 子句指定分桶键，否则建表失败。分桶键的更多说明，请参见分桶。
• 自 2.5.7 版本起，StarRocks 支持在建表和新增分区时自动设置分桶数量 (BUCKETS)，您无需手动设置分桶数量。更多信息，请参见 确定分桶数量。

使用说明

• 排序键的相关说明：
  • 在建表语句中，排序键必须定义在其他列之前。
  • 排序键可以通过 DUPLICATE KEY 显式定义。本示例中排序键为 event_time 和 event_type。

    如果未指定，则默认选择表的前三列作为排序键。

  • 明细模型中的排序键可以为部分或全部维度列。
• 建表时，支持为指标列创建 BITMAP、Bloom Filter 等索引。

下一步

• 导入时，支持追加新数据，不支持修改历史数据。
• 如果导入两行完全相同的数据，则明细模型会将这两行数据视为两行，而不是一行。

聚合模型

适用场景

• 通过分析网站或 APP 的访问流量，统计用户的访问总时长、访问总次数。
• 广告厂商为广告主提供的广告点击总量、展示总量、消费统计等。
• 通过分析电商的全年交易数据，获得指定季度或者月份中，各类消费人群的爆款商品。

• 多为汇总类查询，比如 SUM、MAX、MIN等类型的查询。
• 不需要查询原始的明细数据。
• 旧数据更新不频繁，只会追加新的数据。

原理

1. 数据导入阶段：数据按批次导入至聚合模型时，每一个批次的数据形成一个版本。在一个版本中，同一排序键的数据会进行一次聚合。
2. 后台文件合并阶段 (Compaction) ：数据分批次多次导入至聚合模型中，会生成多个版本的文件，多个版本的文件定期合并成一个大版本文件时，同一排序键的数据会进行一次聚合。
3. 查询阶段：所有版本中同一排序键的数据进行聚合，然后返回查询结果。

创建表

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 子句指定分桶键。分桶键的更多说明，请参见分桶。
• 自 2.5.7 版本起，StarRocks 支持在建表和新增分区时自动设置分桶数量 (BUCKETS)，您无需手动设置分桶数量。更多信息，请参见 确定分桶数量。

使用说明

• 排序键的相关说明：
  • 在建表语句中，排序键必须定义在其他列之前。
  • 排序键可以通过 AGGREGATE KEY 显式定义。

    • 如果 AGGREGATE KEY 未包含全部维度列（除指标列之外的列），则建表会失败。
    • 如果不通过 AGGREGATE KEY 显示定义排序键，则默认除指标列之外的列均为排序键。

  • 排序键必须满足唯一性约束，必须包含全部维度列，并且列的值不会更新。
• 指标列：通过在列名后指定聚合函数，定义该列为指标列。一般为需要汇总统计的数据。
• 聚合函数：指标列使用的聚合函数。聚合模型支持的聚合函数，请参见 CREATE TABLE。
• 查询时，排序键在多版聚合之前就能进行过滤，而指标列的过滤在多版本聚合之后。因此建议将频繁使用的过滤字段作为排序键，在聚合前就能过滤数据，从而提升查询性能。
• 建表时，不支持为指标列创建 BITMAP、Bloom Filter 等索引。

下一步

导入时，仅支持全字段导入，即导入任务需要涵盖表的所有列，例如示例中的 site_id、date、city_code 和 pv 四个列。

更新模型

适用场景

原理

创建表

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 子句指定分桶键。分桶键的更多说明，请参见分桶。
• 自 2.5.7 版本起，StarRocks 支持在建表和新增分区时自动设置分桶数量 (BUCKETS)，您无需手动设置分桶数量。更多信息，请参见 确定分桶数量。

使用说明

• 主键的相关说明：
  • 在建表语句中，主键必须定义在其他列之前。
  • 主键通过 UNIQUE KEY 定义。
  • 主键必须满足唯一性约束，且列的值不会修改。
  • 设置合理的主键。
    • 查询时，主键在聚合之前就能进行过滤，而指标列的过滤通常在多版本聚合之后，因此建议将频繁使用的过滤字段作为主键，在聚合前就能过滤数据，从而提升查询性能。
    • 聚合过程中会比较所有主键，因此需要避免设置过多的主键，以免降低查询性能。如果某个列只是偶尔会作为查询中的过滤条件，则不建议放在主键中。
• 建表时，不支持为指标列创建 BITMAP、Bloom Filter 等索引。

下一步

• 导入数据时，仅支持全部更新，即导入任务需要指明所有列，例如示例中的 create_time、order_id、order_state 和 total_price 四个列。
• 在设计导入频率时，建议以满足业务对实时性的要求为准。查询更新模型的数据时，需要聚合多版本的数据，当版本过多时会导致查询性能降低。所以导入数据至更新模型时，应该适当降低导入频率，从而提升查询性能。如果业务对实时性的要求是分钟级别，那么每分钟导入一次更新数据即可，不需要秒级导入。

主键模型

说明 3.0 版本之前，主键模型不支持分别定义主键和排序键。

适用场景

• 实时对接事务型数据至 StarRocks。事务型数据库中，除了插入数据外，一般还会涉及较多更新和删除数据的操作，因此事务型数据库的数据同步至 StarRocks 时，建议使用主键模型。通过 Flink-CDC 等工具直接对接 TP 的 Binlog，实时同步增删改的数据至主键模型，可以简化数据同步流程，并且相对于 Merge-On-Read 策略的更新模型，查询性能能够提升 3~10 倍。
• 利用部分列更新轻松实现多流 JOIN。在用户画像等分析场景中，一般会采用大宽表方式来提升多维分析的性能，同时简化数据分析师的使用模型。而这种场景中的上游数据，往往可能来自于多个不同业务（比如来自购物消费业务、快递业务、银行业务等）或系统（比如计算用户不同标签属性的机器学习系统），主键模型的部分列更新功能就很好地满足这种需求，不同业务直接各自按需更新与业务相关的列即可，并且继续享受主键模型的实时同步增删改数据及高效的查询性能。

注意事项

• 如果开启持久化索引，主键模型大大降低了主键索引对内存的占用。因为导入时少部分主键索引存在内存中，大部分主键索引存在磁盘中。单条主键编码后的最大长度为 128 字节。
• 如果不开启持久化索引，主键模型适用于主键占用空间相对可控的场景，因为导入时将主键索引加载至内存中。单条主键编码后的最大长度和内存占用上限为 128 字节。 如下两个场景中，主键占用空间相对可控：
  • 数据有冷热特征，即最近几天的热数据才经常被修改，老的冷数据很少被修改。例如，MySQL订单表实时同步到 StarRocks 中提供分析查询。其中，数据按天分区，对订单的修改集中在最近几天新创建的订单，老的订单完成后就不再更新，因此导入时其主键索引就不会加载，也就不会占用内存，内存中仅会加载最近几天的索引。

    如图所示，数据按天分区，最新两个分区的数据更新比较频繁。

  • 大宽表（数百到数千列）。主键只占整个数据的很小一部分，其内存开销比较低。比如用户状态和画像表，虽然列非常多，但总的用户数不大（千万至亿级别），主键索引内存占用相对可控。

    如图所示，大宽表中主键只占一小部分，且数据行数不多。

原理

• StarRocks 收到对某记录的更新操作时，会通过主键索引找到该条记录的位置，并对其标记为删除，再插入一条新的记录。相当于把 Update 改写为 Delete+Insert。
• StarRocks 收到对某记录的删除操作时，会通过主键索引找到该条记录的位置，对其标记为删除。

创建表

• 例如，需要按天实时分析订单，则可以将时间 dt、订单编号 order_id 作为主键，其余列为指标列。建表语句如下：

create table orders (
    dt date NOT NULL,
    order_id bigint NOT NULL,
    user_id int NOT NULL,
    merchant_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 (dt, order_id)
PARTITION BY RANGE(`dt`) (
    PARTITION p20210820 VALUES [('2021-08-20'), ('2021-08-21')),
    PARTITION p20210821 VALUES [('2021-08-21'), ('2021-08-22')),
    PARTITION p20210929 VALUES [('2021-09-29'), ('2021-09-30')),
    PARTITION p20210930 VALUES [('2021-09-30'), ('2021-10-01'))
) DISTRIBUTED BY HASH(order_id)
PROPERTIES (
    "replication_num" = "3",
    "enable_persistent_index" = "true"
);

注意

• 建表时必须使用 DISTRIBUTED BY HASH 子句指定分桶键，否则建表失败。分桶键的更多说明，请参见分桶。
• 自 2.5.7 版本起，StarRocks 支持在建表和新增分区时自动设置分桶数量 (BUCKETS)，您无需手动设置分桶数量。更多信息，请参见 确定分桶数量。

• 例如，需要按地域、最近活跃时间实时分析用户情况，则可以将表示用户 ID 的 user_id 列作为主键，表示地域的 address 列和表示最近活跃时间的 last_active 列作为排序键。建表语句如下：

create table users (
    user_id bigint NOT NULL,
    name string NOT NULL,
    email string NULL,
    address string NULL,
    age tinyint NULL,
    sex tinyint NULL,
    last_active datetime,
    property0 tinyint NOT NULL,
    property1 tinyint NOT NULL,
    property2 tinyint NOT NULL,
    property3 tinyint NOT NULL
) PRIMARY KEY (user_id)
DISTRIBUTED BY HASH(user_id)
ORDER BY(`address`,`last_active`)
PROPERTIES (
    "replication_num" = "3",
    "enable_persistent_index" = "true"
);

使用说明

• 主键相关的说明：
  • 在建表语句中，主键必须定义在其他列之前。
  • 主键通过 PRIMARY KEY 定义。
  • 主键必须满足唯一性约束，且列的值不会修改。本示例中主键为 dt、order_id。
  • 主键支持以下数据类型：BOOLEAN、TINYINT、SMALLINT、INT、BIGINT、LARGEINT、DATE、DATETIME、VARCHAR/STRING。并且不允许为 NULL。
  • 分区列和分桶列必须在主键中。
• enable_persistent_index：是否持久化主键索引，同时使用磁盘和内存存储主键索引，避免主键索引占用过大内存空间。通常情况下，持久化主键索引后，主键索引所占内存为之前的 1/10。您可以在建表时，在PROPERTIES中配置该参数，取值范围为 true 或者 false（默认值）。

  • 自 2.3.0 版本起，StarRocks 支持配置该参数。
  • 如果磁盘为固态硬盘 SSD，则建议设置为 true。如果磁盘为机械硬盘 HDD，并且导入频率不高，则也可以设置为 true。
  • 建表后，如果您需要修改该参数，请参见 ALTER TABLE 修改表的属性 。

• 如果未开启持久化索引，导入时主键索引存在内存中，可能会导致占用内存较多。因此建议您遵循如下建议：
  • 合理设置主键的列数和长度。建议主键为占用内存空间较少的数据类型，例如 INT、BIGINT 等，暂时不建议为 VARCHAR。
  • 在建表前根据主键的数据类型和表的行数来预估主键索引占用内存空间，以避免出现内存溢出。以下示例说明主键索引占用内存空间的计算方式：
    • 假设存在主键模型，主键为dt、id，数据类型为 DATE（4 个字节）、BIGINT（8 个字节）。则主键占 12 个字节。
    • 假设该表的热数据有 1000 万行，存储为三个副本。
    • 则内存占用的计算方式：(12 + 9(每行固定开销) ) * 1000W * 3 * 1.5（哈希表平均额外开销) = 945 M
• 通过 ORDER BY 关键字指定排序键，可指定为任意列的排列组合。

  注意： 如果指定了排序键，就根据排序键构建前缀索引；如果没指定排序键，就根据主键构建前缀索引。

• 支持使用 ALTER TABLE 进行表结构变更，但是存在如下注意事项：
  • 不支持修改主键。
  • 对于排序键，支持通过 ALTER TABLE ... ORDER BY ... 重新指定排序键。不支持删除排序键，不支持修改排序键中列的数据类型。
  • 不支持调整列顺序。
• 自2.3 版本起，除了主键之外的列新增支持 BITMAP、HLL 数据类型。
• 创建表时，支持为除了主键之外的列创建 BITMAP、Bloom Filter 等索引。
• 自 2.4 版本起，支持基于主键模型的表创建异步物化视图。

下一步