StarRocks笔记 | 安静时刻

好记性不如烂笔头

什么是StarRocks

StarRocks 是新一代极速全场景MPP数据库。StarRocks 的愿景是能够让用户的数据分析变得更加简单和敏捷。用户无需经过复杂的预处理，就可以用 StarRocks 来支持多种数据分析场景的极速分析。

StarRocks适用哪些场景

StarRocks 可以满足企业级用户的多种分析需求，包括 OLAP 多维分析、定制报表、实时数据分析和 Ad-hoc 数据分析等。

StarRocks三种数据模型

StarRocks根据数据摄入时候的映射关系，分为了三种数据关系，分别是明细、聚合、以及更新数据关系，三种数据关系在StarRocks中分别对应着不同的数据模型:

明细表对应明细模型（Duplicate Key）

聚合表对应聚合模型（Aggregate Key）

更新表对应更新模型（Unique Key）和主键模型（Primary Key）

明细模型（Duplicate Key）

需要保留原始的数据（例如原始日志，原始操作记录等）来进行分析；
查询方式灵活, 不局限于预先定义的分析方式, 传统的预聚合方式难以命中;
数据更新不频繁。导入数据的来源一般为日志数据或者是时序数据, 以追加写为主要特点, 数据产生后就不会发生太多变化。

注意：明细模型不会根据设置的主键覆盖数据，导入完全相同的两行数据也会认为是不同的两行插入进来，比如我们日志中经常出现含义相同的信息，但是我们一般不会希望存在覆盖的情况。

聚合模型（Aggregate Key）

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

注意：

1.只要是指定聚合函数的字段即视为指标列，表即视为聚合表，聚合表中不带聚合函数的列即为维度列

2.建表语句中维度列必须在指标列前面

3.聚合模型是根据按照相同的指标列进行聚合，多条数据具有相同的维度列的时候，会按照聚合函数将指标列数据进行聚合，这样可以减少数据量

4.触发数据聚合有三种方式 :

(1)数据导入时，数据落盘前的聚合

(2) 数据落盘后，后台的多版本异步聚合

(3)数据查询时，多版本多路归并聚合

更新模型(Unique Key & Primary Key)

Unique Key 官网讲解

Primary Key官网讲解

注意:

即 Unique 模型完全可以用聚合模型中的 REPLACE 方式替代。

Primary Key模型是starrocks全新设计模型，主键模型的表要求有唯一的主键，支持对表中的行按主键进行更新和删除操作。相较更新模型，主键模型可以更好地支持实时和频繁更新等场景。

StarRocks表设计

StarRocks和其他OLAP数据库存储设计类似，采用的列式存储，可以提高数据查询效率，每一列的数据类型一致，这样可以提高数据的压缩率，

StarRocks的数据列可以分为两种，分别是维度列以及指标列，维度列用于分组和排序，指标列通过聚合函数在维度列基础上进行SUM，COUNT，BITMAP_UNION等操作。

前缀索引

Doris 不支持在任意列上创建索引，本质上，Doris 的数据存储在类似 SSTable（Sorted String Table）的数据结构中。该结构是一种有序的数据结构，可以按照指定的列进行排序存储。在这种数据结构上，以排序列作为条件进行查找，会非常的高效。

比如我们建立的前缀索引为(user_id,age,message)，那么下面第一种查询要比第二种快得多

# 命中索引
SELECT * FROM table WHERE user_id=1829239 and age=20；
# 没有命中索引
SELECT * FROM table WHERE age=20；

下面我们看一下索引文件的结构

每个部分的描述与详细功能：

short key index表:

稀疏索引和行号之间的对应关系，首先表中数据会按照排序键进行排序，然后每1024行会构成一个逻辑块，并且获得一个shortkey index，这个key是由排序键进行拼接而成，不会超过36个字节，我们在查询的时候首先会根据要查询的排序键值来确定所属的数据块的行号，这个行号就是数据在第多少行。

Per-column cardinal index:

列式存储，列与列之间是独立存储，所以每列都会有一个自己的行号和块号的对应关系，划分块是通过每块大概是64kb来进行划分，根据前面找到的行号找到对应的数据块地址

Per-column data blocks:

表中每一列数据按64KB分块存储，根据前面找到的数据块地址就可以找到对应的块内容了。

注意:

这种使用范围查找的需要有前提条件，就是查询时, 如果指定了维度列的等值条件或者范围条件, 并且这些条件中维度列可构成表维度列的前缀, 则可以利用数据的有序性

使用索引范围查找的条件:

（1）维度列的等值或者范围条件，像 in (…) 这种是不能索引

（2）条件中的维度列可以构成前缀

Eg: 对于表table1: (event_day, siteid, citycode, username)➜(pv); 当查询条件为event_day > 2020-09-18 and siteid = 2, 则可以使用范围查找; 如果指定条件为citycode = 4 and username in [“Andy”, “Boby”, “Christian”, “StarRocks”], 则无法使用范围查找，或者查询条件是 where code = 4这种也是不能适用范围查找，没有命中。

RollUp以及物化视图

Rollup

Rollup 可以理解为 Table 的一个物化索引结构。物化是因为其数据在物理上独立存储，而索引的意思是，Rollup可以调整列顺序以增加前缀索引的命中率，也可以减少key列以增加数据的聚合度。

数据上Rollup意味着在多维分析中“上卷操作”，上卷意味着在数据立方体上进行一个维度的合并，与之对应的还有“钻取”操作(Drill-down)，钻取意味着在某些维度上进一步打开扩展维度，详细可以参考这里

Aggregate Key & Roll up

Rollup在聚合模型上可以发挥很好地作用，基于Base表创建Rollup可以获得更好的聚合数据效果以及调整key顺序，可以提高Rollup命中率

Unique Key & Roll up

更新模型中的Unique Key相当于聚合模型中聚合函数被固定为Replace，所以每次在Unique上创建Rollup的时候必须选中所有的维度列，即在Unique Key模型上创建Rollup只能调整维度key的顺序，可以获得更高的Rollup命中率，但是因为Rollup数据是需要独立存储的，这样的话数据是否直接全部被存储了两遍？还需要后面验证下。

Duplicate Key & Roll up

Duplicate Key模型和Unique Key模型类似，同样因为 Duplicate 模型没有聚合的语意。所以该模型中的 ROLLUP，已经失去了“上卷”这一层含义。而仅仅是作为调整列顺序，以命中前缀索引的作用。我们将在前缀索引详细介绍前缀索引，以及如何使用ROLLUP改变前缀索引，以获得更好的查询效率。

物化视图

说到物化视图就一定要和Rollup做一个区分，物化视图相当于Rollup的一个超集，和物化视图相比Rollup 具有一定的局限性：

1.Rollup不能做明细模型的聚合，只能起到更改前缀索引顺序来加快查询速度，因为明细模型Duplicate Key表本身就没有聚合的含义

2.Rollup的聚合函数必须和Base table保持一致，物化视图的聚合函数可以和base表不同

3.物化视图是不支持Unique Key模型，因为物化视图实际上是预聚合进行计算，比如sum，count，聚合完毕之后我们就丢失了明细信息，这时候如果你去更新明细信息，物化视图就没法知道该如何做出改变，比如两条明细数据分别是1、5，我们建立物化视图求和，这时候这个值是6，然后我们更新数据，将1更改成2，但是rollup手里只有一个6，他知道其中一个值被变成2了，但是仅此而已，所以物化视图是不支持更新模型。

更新策略

为保证物化视图表和 Base 表的数据一致性, Doris 会将导入，删除等对 base 表的操作都同步到物化视图表中。并且通过增量更新的方式来提升更新效率。通过事务方式来保证原子性。

比如如果用户通过 INSERT 命令插入数据到 base 表中，则这条数据会同步插入到物化视图中。当 base 表和物化视图表均写入成功后，INSERT 命令才会成功返回。