国产开源优秀新一代MPP数据库StarRocks入门之旅-数仓新利器(中)

表设计

列式存储

国产开源优秀新一代MPP数据库StarRocks入门之旅-数仓新利器(中)_第1张图片

  • StarRocks的表和关系型数据相同, 由行和列构成. 每行数据对应用户一条记录, 每列数据有相同数据类型. 所有数据行的列数相同, 可以动态增删列. StarRocks中, 一张表的列可以分为维度列(也成为key列)和指标列(value列), 维度列用于分组和排序, 指标列可通过聚合函数SUM, COUNT, MIN, MAX, REPLACE, HLL_UNION, BITMAP_UNION等累加起来. 因此, StarRocks的表也可以认为是多维的key到多维指标的映射。
  • 在StarRocks中, 表中数据按列存储, 物理上, 一列数据会经过分块编码压缩等操作, 然后持久化于非易失设备, 但在逻辑上, 一列数据可以看成由相同类型的元素构成的数组. 一行数据的所有列在各自的列数组中保持对齐, 即拥有相同的数组下标, 该下标称之为序号或者行号. 该序号是隐式, 不需要存储的, 表中的所有行按照维度列, 做多重排序, 排序后的位置就是该行的行号。
  • 查询时, 如果指定了维度列的等值条件或者范围条件, 并且这些条件中维度列可构成表维度列的前缀, 则可以利用数据的有序性, 使用range-scan快速锁定目标行. 例如: 对于表table1: (event_day, siteid, citycode, username)➜(pv); 当查询条件为event_day > 2020-09-18 and siteid = 2, 则可以使用范围查找; 如果指定条件为citycode = 4 and username in [“Andy”, “Boby”, “Christian”, “StarRocks”], 则无法使用范围查找。

稀疏索引

国产开源优秀新一代MPP数据库StarRocks入门之旅-数仓新利器(中)_第2张图片

shortkey索引为稀疏索引,表中数据组织有主要由三部分构成:

  • shortkey index表: 表中数据每1024行, 构成一个逻辑block. 每个逻辑block在shortkey index表中存储一项索引, 内容为表的维度列的前缀, 并且不超过36字节. shortkey index为稀疏索引, 用数据行的维度列的前缀查找索引表, 可以确定该行数据所在逻辑块的起始行号。
  • Per-column data block: 表中每一列数据按64KB分块存储, 数据块作为一个单位单独编码压缩, 也作为IO单位, 整体写回设备或者读出。
  • Per-column cardinal index: 表中的每列数据有各自的行号索引表, 列的数据块和行号索引项一一对应, 索引项由数据块的起始行号和数据块的位置和长度信息构成, 用数据行的行号查找行号索引表, 可以获取包含该行号的数据块所在位置, 读取目标数据块后, 可以进一步查找数据。

由此可见, 查找维度列的前缀的查找过程为: 先查找shortkey index, 获得逻辑块的起始行号, 查找维度列的行号索引, 获得目标列的数据块, 读取数据块, 然后解压解码, 从数据块中找到维度列前缀对应的数据项。

加速数据处理

  • 预先聚合: StarRocks支持聚合模型, 维度列取值相同数据行可合并一行, 合并后数据行的维度列取值不变, 指标列的取值为这些数据行的聚合结果, 用户需要给指标列指定聚合函数. 通过预先聚合, 可以加速聚合操作。
  • 分区分桶: 事实上StarRocks的表被划分成tablet, 每个tablet多副本冗余存储在BE上, BE和tablet的数量可以根据计算资源和数据规模而弹性伸缩. 查询时, 多台BE可并行地查找tablet快速获取数据. 此外, tablet的副本可复制和迁移, 增强了数据的可靠性, 避免了数据倾斜. 总之, 分区分桶保证了数据访问的高效性和稳定性。
  • RollUp表索引: shortkey index可加速数据查找, 然后shortkey index依赖维度列排列次序. 如果使用非前缀的维度列构造查找谓词, 则无法使用shortkey index. 用户可以为数据表创建若干RollUp表索引, RollUp表索引的数据组织和存储和数据表相同, 但RollUp表拥有自身的shortkey index. 用户创建RollUp表索引时, 可选择聚合的粒度, 列的数量, 维度列的次序; 使频繁使用的查询条件能够命中相应的RollUp表索引。
  • 列级别的索引技术: Bloomfilter可快速判断数据块中不含所查找值, ZoneMap通过数据范围快速过滤待查找值, Bitmap索引可快速计算出枚举类型的列满足一定条件的行。

数据模型

基本介绍

目前,StarRocks根据摄入数据和实际存储数据之间的映射关系, 其中明细表对应明细模型(Duplicate Key),聚合表对应聚合模型(Aggregate Key),更新表对应更新模型(Unique Key)和主键模型(Primary Key)。StarRocks表的维度列的取值构成数据表的排序键, StarRocks的排序键对比传统的主键具有:

  • 数据表所有维度列构成排序键, 所以后文中提及的排序列, key列本质上都是维度列。
  • 排序键可重复, 不必满足唯一性约束。
  • 数据表的每一列, 以排序键的顺序, 聚簇存储。
  • 排序键使用稀疏索引。

对于摄入(ingest)的主键重复的多行数据, 填充于(populate)数据表中时, 按照三种处理方式划分:

  • 明细模型: 表中存在主键重复的数据行, 和摄入数据行一一对应, 用户可以召回所摄入的全部历史数据。
  • 聚合模型: 表中不存在主键重复的数据行, 摄入的主键重复的数据行合并为一行, 这些数据行的指标列通过聚合函数合并, 用户可以召回所摄入的全部历史数据的累积结果, 但无法召回全部历史数据。
  • 更新模型&主键模型: 聚合模型的特殊情形, 主键满足唯一性约束, 最近导入的数据行, 替换掉其他主键重复的数据行。相当于在聚合模型中, 为数据表的指标列指定的聚合函数为REPLACE, REPLACE函数返回一组数据中的最新数据。

需要注意:

  • 建表语句, 排序列的定义必须出现在指标列定义之前。
  • 排序列在建表语句中的出现次序为数据行的多重排序的次序。
  • 排序键的稀疏索引(Shortkey Index)会选择排序键的若干前缀列。

明细模型

  • 适用场景:StarRocks建表的默认模型是明细模型(Duplicate Key)。一般用明细模型来处理的场景有如下特点:
    • 需要保留原始的数据(例如原始日志,原始操作记录等)来进行分析;
    • 查询方式灵活, 不局限于预先定义的分析方式, 传统的预聚合方式难以命中;
    • 数据更新不频繁。导入数据的来源一般为日志数据或者是时序数据, 以追加写为主要特点, 数据产生后就不会发生太多变化。
  • 原理
    • 用户可以指定数据表的排序列, 没有明确指定的情况下, 那么StarRocks会为表选择默认的几个列作为排序列。这样,在查询中,有相关排序列的过滤条件时,StarRocks能够快速地过滤数据,降低整个查询的时延。
    • 注意:在向StarRocks明细模型表中导入完全相同的两行数据时,StarRocks会认为是两行数据。
  • 使用
    • 充分利用排序列,在建表时将经常在查询中用于过滤的列放在表的前面,这样能够提升查询速度。
    • 明细模型中, 可以指定部分的维度列为排序键; 而聚合模型和更新模型中, 排序键只能是全体维度列。

创建测试数据库和明细表,其中DUPLICATE KEY(event_time, event_type)说明采用明细模型, 并且指定了排序键, 并且排序列的定义在其他列定义之前。

CREATE DATABASE test_db;
USE test_db;
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 of ",
    channel INT COMMENT ""
)
DUPLICATE KEY(event_time, event_type)
DISTRIBUTED BY HASH(user_id) BUCKETS 8;

INSERT INTO detail VALUES('2022-05-13 20:00:00.00',1,1000,1,1);
INSERT INTO detail VALUES('2022-05-13 20:00:00.00',2,1000,1,1);
INSERT INTO detail VALUES('2022-05-13 20:00:00.00',1,1000,1,1);

国产开源优秀新一代MPP数据库StarRocks入门之旅-数仓新利器(中)_第3张图片

聚合模型

  • 适用场景:在数据分析领域,有很多需要对数据进行统计和汇总操作的场景,就需要使用聚合模型(Aggregate Key)。
    • 比如:
      • 分析网站或APP访问流量,统计用户的访问总时长、访问总次数;
      • 广告厂商为广告主提供的广告点击总量、展示总量、消费统计等;
      • 分析电商的全年的交易数据, 获得某指定季度或者月份的, 各人口分类(geographic)的爆款商品。
    • 适合采用聚合模型来分析的场景具有如下特点:
      • 业务方进行的查询为汇总类查询,比如sum、count、max等类型的查询;
      • 不需要召回原始的明细数据;
      • 老数据不会被频繁更新,只会追加新数据。
  • 原理
    • StarRocks会将指标列按照相同维度列进行聚合。当多条数据具有相同的维度时,StarRocks会把指标进行聚合。从而能够减少查询时所需要的处理的数据量,进而提升查询的效率。
  • 使用
    • 聚合表中数据会分批次多次导入,每次导入会形成一个版本。相同排序键的数据行聚合有三种触发方式:
      • 数据导入时,数据落盘前的聚合;
      • 数据落盘后,后台的多版本异步聚合;
      • 数据查询时,多版本多路归并聚合。
    • 数据查询时,指标列采用先聚合后过滤的方式,把没必有做指标的列存储为维度列。
    • 聚合模型所支持的聚合函数列表请参考 [Create Table 语句说明](https://docs.starrocks.com/zh-cn/main/sql-reference/sql-statements/data-definition/CREATE TABLE)。

在建表时, 只要给指标列的定义指明聚合函数, 就会启用聚合模型; 用户可以使用AGGREGATE KEY显式地定义排序键。如下表site_id, date, city_code为排序键,pv为指标列, 使用聚合函数SUM。

CREATE TABLE IF NOT EXISTS 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"
)
DISTRIBUTED BY HASH(site_id) BUCKETS 8;

国产开源优秀新一代MPP数据库StarRocks入门之旅-数仓新利器(中)_第4张图片

更新模型

  • 适用场景
    • 有些分析场景之下,数据会更新, StarRocks采用更新模型来满足这种需求。比如在电商场景中,定单的状态经常会发生变化,每天的订单更新量可突破上亿。在这种量级的更新场景下进行实时数据分析,如果在明细模型下通过delete+insert的方式,是无法满足频繁更新需求的; 因此, 用户需要使用更新模型来满足数据分析需求。如用户需要更加实时/频繁的更新功能,建议使用主键模型。
    • 适合更新模型的场景特点
      • 已经写入的数据有大量的更新需求;
      • 需要进行实时数据分析。
  • 原理
    • 更新模型中, 排序键满足唯一性约束, 成为主键。
    • StarRocks存储内部会给每一个批次导入数据分配一个版本号, 同一主键的数据可能有多个版本, 查询时最大(最新)版本的数据胜出。通过这种机制,StarRocks可以支持对于频繁更新数据的分析。
  • 使用
    • 导入数据时需要将所有字段补全才能够完成更新操作,即下述例子中的create_time、order_id、order_state和total_price四个字段都需必须存在。
    • 对于更新模型的数据读取,需要在查询时完成多版本合并,当版本过多时会导致查询性能降低。所以在向更新模型导入数据时,应该适当降低导入频率,从而提升查询性能。建议在设计导入频率时以满足业务对实时性的要求为准。如果业务对实时性的要求是分钟级别,那么每分钟导入一次更新数据即可,不需要秒级导入。
    • 在查询时,对于value字段的过滤通常在多版本合并之后。将经常过滤字段且不会被修改的字段放在主键上, 能够在合并之前就将数据过滤掉,从而提升查询性能。
    • 因为合并过程需要将所有主键字段进行比较,所以应该避免放置过多的主键字段,以免降低查询性能。如果某个字段只是偶尔会作为查询中的过滤条件存在,不需要放在主键中。

在电商订单分析场景中,经常根据订单状态进行的统计分析。因为订单状态经常改变,而create_time和order_id不会改变,并且经常会在查询中作为过滤条件。所以可以将 create_time和order_id 两个列作为这个表的主键(即,在建表时用UNIQUE KEY关键字定义),其中create_time, order_id为排序列, 其定义在其他列定义之前出现;order_state和total_price为指标列, 其聚合类型为REPLACE。这样既能够满足订单状态的更新需求,又能够在查询中进行快速过滤。

CREATE TABLE IF NOT EXISTS order_detail (
    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) BUCKETS 8;

INSERT INTO order_detail VALUES('2022-05-12 20:00:00.00',1001,1,30);
INSERT INTO order_detail VALUES('2022-05-12 20:00:00.00',1002,1,40);
INSERT INTO order_detail VALUES('2022-05-13 20:00:00.00',1001,1,50);
INSERT INTO order_detail VALUES('2022-05-12 20:00:00.00',1001,2,60);

国产开源优秀新一代MPP数据库StarRocks入门之旅-数仓新利器(中)_第5张图片

主键模型

  • 适用场景:主键模型的表要求有唯一的主键,支持对表中的行按主键进行更新和删除操作。相较更新模型,主键模型可以更好地支持实时和频繁更新等场景。
    • 实时对接 TP 数据至 StarRocks
    • 利用部分列更新轻松实现多流 JOIN
    • 由于存储引擎会为主键建立索引,而在导入数据时会把主键索引加载在内存中,所以主键模型对内存的要求比较高,还不适合主键特别多的场景目前primary主键存储在内存中,为防止滥用造成内存占满,限制主键字段长度全部加起来编码后不能超过127字节
      • 数据有冷热特征,即最近几天的热数据才经常被修改,老的冷数据很少被修改。
      • 大宽表(数百到数千列);主键只占整个数据的很小一部分,其内存开销比较低。比如用户状态/画像表,虽然列非常多,但总的用户数不大(千万-亿级别),主键索引内存占用相对可控。
  • 原理:主键模型是由StarRocks全新设计开发的存储引擎支持的,其元数据组织、读取、写入方式和原有的表模型完全不同。
    • 主键模型通过主键约束,保证同一个主键下仅存在一条记录,这样就完全避免了Merge操作。具体实现步骤:
      • StarRocks收到对某记录的更新操作时,会通过主键索引找到该条记录的位置,并对其标记为删除,再插入一条新的记录。相当于把Update改写为Delete+Insert。
      • StarRocks收到对某记录的删除操作时,会通过主键索引找到该条记录的位置,对其标记为删除。这样在查询时不影响谓词下推和索引的使用, 保证了查询的高效执行。
    • 可见,相比更新模型,主键模型通过牺牲微小的写入性能和内存占用,极大提升了查询性能。

在建表时通过PRIMARY KEY指定最前的若干列为主键,即可启用主键模型,与更新模型结果一致,当user_id发生冲突时会覆盖。

create table users (
    user_id bigint NOT NULL,
    name string NOT NULL,
    email string NULL,
    address string NULL,
    age tinyint NULL
) PRIMARY KEY (user_id)
DISTRIBUTED BY HASH(user_id) BUCKETS 4
PROPERTIES("replication_num" = "3");

排序键

  • 原理:StarRocks中为加速查询,在内部组织并存储数据时,会把表中数据按照指定的列进行排序,这部分用于排序的列(可以是一个或多个列),可以称之为Sort Key。明细模型中Sort Key就是指定的用于排序的列(即 DUPLICATE KEY 指定的列),聚合模型中Sort Key列就是用于聚合的列(即 AGGREGATE KEY 指定的列),更新模型中Sort Key就是指定的满足唯一性约束的列(即 UNIQUE KEY 指定的列)。
  • 注意
    • 排序列的定义必须出现在建表语句中其他列的定义之前。
    • 排序列的顺序是由create table语句中的列顺序决定的。
    • 排序键类似mysql最左前缀原则,满足则可以加速查询。
    • 当Sort Key列数非常多时,会占用大量内存, 为了避免这种情况, 对shortkey index索引项做了限制。如shortkey 列数不超过3、字节数不超过36字节。

物化视图

  • 使用场景:在实际的业务场景中,通常存在两种场景并存的分析需求:对固定维度的聚合分析 和 对原始明细数据任意维度的分析。
  • 限制
    • 分区列必须存在于创建物化视图的group by聚合列中
    • 目前只支持对单表进行构建物化视图,不支持多表JOIN
    • 聚合类型表(Aggregation),不支持对key列执行聚合算子操作,仅支持对value列进行聚合,且聚合算子类型不能改变。
    • 物化视图中至少包含一个KEY列
    • 不支持表达式计算
    • 不支持指定物化视图查询
    • 不支持 Order By
CREATE MATERIALIZED VIEW materialized_detail_stat
AS SELECT user_id, MAX(event_type),COUNT(device_code),SUM(channel)
FROM detail
GROUP BY user_id;

explain select sum(channel) from detail;

国产开源优秀新一代MPP数据库StarRocks入门之旅-数仓新利器(中)_第6张图片

Bitmap 索引

StarRocks 支持基于Bitmap索引,对于有Filter的查询有明显的加速效果。

  • 原理
    • Bitmap是元素为bit的, 取值为0、1两种情形的, 可对某一位bit进行置位(set)和清零(clear)操作的数组。Bitmap的使用场景有:
      • 用一个long型表示32位学生的性别,0表示女生,1表示男生。
      • 用Bitmap表示一组数据中是否存在null值,0表示元素不为null,1表示为null。
      • 一组数据的取值为(Q1, Q2, Q3, Q4),表示季度,用Bitmap表示这组数据中取值为Q4的元素,1表示取值为Q4的元素, 0表示其他取值的元素。
    • Bitmap只能表示取值为两种情形的列数组, 当列的取值为多种取值情形枚举类型时, 例如季度(Q1, Q2, Q3, Q4), 系统平台(Linux, Windows, FreeBSD, MacOS), 则无法用一个Bitmap编码; 此时可以为每个取值各自建立一个Bitmap的来表示这组数据; 同时为实际枚举取值建立词典

国产开源优秀新一代MPP数据库StarRocks入门之旅-数仓新利器(中)_第7张图片

  • 适用场景
    • 非前缀过滤。
    • 多列过滤Filter。
  • 使用注意
    • 对于明细模型,所有列都可以建Bitmap 索引;对于聚合模型,只有Key列可以建Bitmap 索引。
    • Bitmap索引, 应该在取值为枚举型, 取值大量重复, 较低基数, 并且用作等值条件查询或者可转化为等值条件查询的列上创建。
    • 不支持对Float、Double、Decimal 类型的列建Bitmap 索引。
    • 如果要查看某个查询是否命中了Bitmap索引,可以通过查询的Profile信息查看。
CREATE TABLE IF NOT EXISTS user_info (
    user_id INT,
    sex INT,
    age INT
)
DUPLICATE KEY(user_id)
DISTRIBUTED BY HASH(user_id) BUCKETS 8;

INSERT INTO user_info VALUES(1001,1,18);
INSERT INTO user_info VALUES(1002,1,21);
INSERT INTO user_info VALUES(1003,0,19);
INSERT INTO user_info VALUES(1004,1,20);

SHOW INDEX FROM user_info;

国产开源优秀新一代MPP数据库StarRocks入门之旅-数仓新利器(中)_第8张图片

国产开源优秀新一代MPP数据库StarRocks入门之旅-数仓新利器(中)_第9张图片

Bloomfilter 索引

  • 原理
    • Bloom Filter(布隆过滤器)是用于判断某个元素是否在一个集合中的数据结构,优点是空间效率和时间效率都比较高,缺点是有一定的误判率。
    • StarRocks建表时, 可通过PROPERTIES{“bloom_filter_columns”=“c1,c2,c3”}指定需要建BloomFilter索引的列,查询时, BloomFilter可快速判断某个列中是否存在某个值。如果Bloom Filter判定该列中不存在指定的值,就不需要读取数据文件;如果是全1情形,此时需要读取数据块确认目标值是否存在。另外,Bloom Filter索引无法确定具体是哪一行数据具有该指定的值。
  • 适用场景
    • 首先BloomFilter也适用于非前缀过滤。
    • 查询会根据该列高频过滤,而且查询条件大多是in和=。
    • 不同于Bitmap, BloomFilter适用于高基数列。
  • 使用注意
    • 不支持对Tinyint、Float、Double、Decimal 类型的列建Bloom Filter索引。
    • Bloom Filter索引只对in和=过滤查询有加速效果。
    • 如果要查看某个查询是否命中了Bloom Filter索引,可以通过查询的Profile信息查看(TODO:加上查看Profile的链接)。
CREATE TABLE IF NOT EXISTS article (
    id INT,
    type INT,
    level INT,
    title VARCHAR(100)
)
DUPLICATE KEY(id)
DISTRIBUTED BY HASH(id) BUCKETS 8
PROPERTIES("bloom_filter_columns"="type,level");

SHOW CREATE TABLE article;

ALTER TABLE article SET ("bloom_filter_columns" = "");

国产开源优秀新一代MPP数据库StarRocks入门之旅-数仓新利器(中)_第10张图片
**本人博客网站 **IT小神 www.itxiaoshen.com

你可能感兴趣的:(数据库,大数据,分布式,数据库,大数据)