四、数据模型
Doris 的数据模型主要分为 3 类：Aggregate、Uniq、Duplicate。
Aggregate 模型
表中的列按照是否设置了AggregationType，分为Key（维度列）和Value（指标列）。没有设置 AggregationType的称为Key，设置了AggregationType的称为Value。
当我们导入数据时，对于Key列相同的行会聚合成一行，而Value列会按照设置的AggregationType 进行聚合。AggregationType目前有以下四种聚合方式：
- SUM：求和，多行的Value进行累加；
- REPLACE：替代，下一批数据中的Value会替换之前导入过的行中的Value。
- REPLACE_IF_NOT_NULL：当遇到null值则不更新；
- MAX：保留最大值；
- MIN：保留最小值。
数据的聚合，在Doris中有如下三个阶段发生：
- 1、每一批次数据导入的ETL阶段。该阶段会在每一批次导入的数据内部进行聚合；
- 2、底层BE进行数据Compaction的阶段。该阶段，BE会对已导入的不同批次的数据进行进一步的聚合；
- 3、数据查询阶段。在数据查询时，对于查询涉及到的数据，会进行对应的聚合。
数据在不同时间，可能聚合的程度不一致。比如一批数据刚导入时，可能还未与之前已存在的数据进行聚合。但是对于用户而言，用户只能查询到聚合后的数据。即不同的聚合程度对于用户查询而言是透明的。用户需始终认为数据以最终的完成的聚合程度存在，而不应假设某些聚合还未发生。
示例1：导入数据聚合
建表：
CREATE TABLE IF NOT EXISTS test.example_site_visit
(
`user_id` LARGEINT NOT NULL COMMENT "用户 id",
`date` DATE NOT NULL COMMENT "数据灌入日期时间",
`city` VARCHAR(20) COMMENT "用户所在城市",
`age` SMALLINT COMMENT "用户年龄",
`sex` TINYINT COMMENT "用户性别",
`last_visit_date` DATETIME REPLACE DEFAULT "1970-01-01 00:00:00" COMMENT "用户最后一次访问时间",
`last_visit_date_not_null` DATETIME REPLACE_IF_NOT_NULL DEFAULT
"1970-01-01 00:00:00" COMMENT "用户最后一次访问时间",
`cost` BIGINT SUM DEFAULT "0" COMMENT "用户总消费",
`max_dwell_time` INT MAX DEFAULT "0" COMMENT "用户最大停留时间",
`min_dwell_time` INT MIN DEFAULT "99999" COMMENT "用户最小停留时间"
)
AGGREGATE KEY(`user_id`, `date`, `city`, `age`, `sex`)
DISTRIBUTED BY HASH(`user_id`) BUCKETS 10
PROPERTIES
(
"replication_num" = "1",
"storage_medium" = "SSD"
);
插入数据：
insert into test.example_site_visit values\
(10000,'2017-10-01','北京',20,0,'2017-10-01 06:00:00','2017-10-01 06:00:00',20,10,10),\
(10000,'2017-10-01','北京',20,0,'2017-10-01 07:00:00','2017-10-01 07:00:00',15,2,2),\
(10001,'2017-10-01','北京',30,1,'2017-10-01 17:05:45','2017-10-01 07:00:00',2,22,22),\
(10002,'2017-10-02','上海',20,1,'2017-10-02 12:59:12',null,200,5,5),\
(10003,'2017-10-02','广州',32,0,'2017-10-02 11:20:00','2017-10-02 11:20:00',30,11,11),\
(10004,'2017-10-01','深圳',35,0,'2017-10-01 10:00:15','2017-10-01 10:00:15',100,3,3),\
(10004,'2017-10-03','深圳',35,0,'2017-10-03 10:20:22','2017-10-03 10:20:22',11,6,6);
注意：Insert into 单条数据这种操作在 Doris 里只能演示不能在生产使用，会引发写阻塞。
查看表：
mysql> select * from test.example_site_visit;
+---------+------------+--------+------+------+---------------------+--------------------------+------+----------------+----------------+
| user_id | date | city | age | sex | last_visit_date | last_visit_date_not_null | cost | max_dwell_time | min_dwell_time |
+---------+------------+--------+------+------+---------------------+--------------------------+------+----------------+----------------+
| 10002 | 2017-10-02 | 上海 | 20 | 1 | 2017-10-02 12:59:12 | NULL | 200 | 5 | 5 |
| 10001 | 2017-10-01 | 北京 | 30 | 1 | 2017-10-01 17:05:45 | 2017-10-01 07:00:00 | 2 | 22 | 22 |
| 10004 | 2017-10-01 | 深圳 | 35 | 0 | 2017-10-01 10:00:15 | 2017-10-01 10:00:15 | 100 | 3 | 3 |
| 10004 | 2017-10-03 | 深圳 | 35 | 0 | 2017-10-03 10:20:22 | 2017-10-03 10:20:22 | 11 | 6 | 6 |
| 10000 | 2017-10-01 | 北京 | 20 | 0 | 2017-10-01 07:00:00 | 2017-10-01 07:00:00 | 35 | 10 | 2 |
| 10003 | 2017-10-02 | 广州 | 32 | 0 | 2017-10-02 11:20:00 | 2017-10-02 11:20:00 | 30 | 11 | 11 |
+---------+------------+--------+------+------+---------------------+--------------------------+------+----------------+----------------+
6 rows in set (0.05 sec)
可以看到，用户10000只剩下了一行聚合后的数据。而其余用户的数据和原始数据保持一致。经过聚合，Doris中最终只会存储聚合后的数据。换句话说，即明细数据会丢失，用户不能够再查询到聚合前的明细数据了。
示例2：保留明细数据
建表：
CREATE TABLE IF NOT EXISTS test.example_site_visit2
(
`user_id` LARGEINT NOT NULL COMMENT "用户 id",
`date` DATE NOT NULL COMMENT "数据灌入日期时间",
`timestamp` DATETIME COMMENT "数据灌入时间，精确到秒",
`city` VARCHAR(20) COMMENT "用户所在城市",
`age` SMALLINT COMMENT "用户年龄",
`sex` TINYINT COMMENT "用户性别",
`last_visit_date` DATETIME REPLACE DEFAULT "1970-01-01 00:00:00" COMMENT "用户最后一次访问时间",
`cost` BIGINT SUM DEFAULT "0" COMMENT "用户总消费",
`max_dwell_time` INT MAX DEFAULT "0" COMMENT "用户最大停留时间",
`min_dwell_time` INT MIN DEFAULT "99999" COMMENT "用户最小停留时间"
)
AGGREGATE KEY(`user_id`, `date`, `timestamp`, `city`, `age`, `sex`)
DISTRIBUTED BY HASH(`user_id`) BUCKETS 10
PROPERTIES
(
"replication_num" = "1",
"storage_medium" = "SSD"
);
插入数据：
insert into test.example_site_visit2 values(10000,'2017-10-01','2017-10-01 08:00:05','北京',20,0,'2017-10-01 06:00:00',20,10,10),\
(10000,'2017-10-01','2017-10-01 09:00:05','北京',20,0,'2017-10-01 07:00:00',15,2,2),\
(10001,'2017-10-01','2017-10-01 18:12:10','北京',30,1,'2017-10-01 17:05:45',2,22,22),\
(10002,'2017-10-02','2017-10-02 13:10:00','上海',20,1,'2017-10-02 12:59:12',200,5,5),\
(10003,'2017-10-02','2017-10-02 13:15:00','广州',32,0,'2017-10-02 11:20:00',30,11,11),\
(10004,'2017-10-01','2017-10-01 12:12:48','深圳',35,0,'2017-10-01 10:00:15',100,3,3),\
(10004,'2017-10-03','2017-10-03 12:38:20','深圳',35,0,'2017-10-03 10:20:22',11,6,6);
查看数据：
mysql> select * from test.example_site_visit2;
+---------+------------+---------------------+--------+------+------+---------------------+------+----------------+----------------+
| user_id | date | timestamp | city | age | sex | last_visit_date | cost | max_dwell_time | min_dwell_time |
+---------+------------+---------------------+--------+------+------+---------------------+------+----------------+----------------+
| 10002 | 2017-10-02 | 2017-10-02 13:10:00 | 上海 | 20 | 1 | 2017-10-02 12:59:12 | 200 | 5 | 5 |
| 10001 | 2017-10-01 | 2017-10-01 18:12:10 | 北京 | 30 | 1 | 2017-10-01 17:05:45 | 2 | 22 | 22 |
| 10000 | 2017-10-01 | 2017-10-01 08:00:05 | 北京 | 20 | 0 | 2017-10-01 06:00:00 | 20 | 10 | 10 |
| 10000 | 2017-10-01 | 2017-10-01 09:00:05 | 北京 | 20 | 0 | 2017-10-01 07:00:00 | 15 | 2 | 2 |
| 10004 | 2017-10-01 | 2017-10-01 12:12:48 | 深圳 | 35 | 0 | 2017-10-01 10:00:15 | 100 | 3 | 3 |
| 10004 | 2017-10-03 | 2017-10-03 12:38:20 | 深圳 | 35 | 0 | 2017-10-03 10:20:22 | 11 | 6 | 6 |
| 10003 | 2017-10-02 | 2017-10-02 13:15:00 | 广州 | 32 | 0 | 2017-10-02 11:20:00 | 30 | 11 | 11 |
+---------+------------+---------------------+--------+------+------+---------------------+------+----------------+----------------+
7 rows in set (0.01 sec)
可以发现，存储的数据和导入数据完全一样，没有发生任何聚合。这是因为，这批数据中，因为加入了timestamp列，所有行的Key都不完全相同。也就是说，只要保证导入的数据中，每一行的 Key都不完全相同，那么即使在聚合模型下，Doris也可以保存完整的明细数据。
示例3：导入数据与已有数据聚合
往示例1中继续插入数据：
insert into test.example_site_visit values(10004,'2017-10-03','深圳',35,0,'2017-10-03 11:22:00',null,44,19,19),\
(10005,'2017-10-03','长沙',29,1,'2017-10-03 18:11:02','2017-10-03 18:11:02',3,1,1);
查看数据：
mysql> select * from test.example_site_visit;
+---------+------------+--------+------+------+---------------------+--------------------------+------+----------------+----------------+
| user_id | date | city | age | sex | last_visit_date | last_visit_date_not_null | cost | max_dwell_time | min_dwell_time |
+---------+------------+--------+------+------+---------------------+--------------------------+------+----------------+----------------+
| 10002 | 2017-10-02 | 上海 | 20 | 1 | 2017-10-02 12:59:12 | NULL | 200 | 5 | 5 |
| 10001 | 2017-10-01 | 北京 | 30 | 1 | 2017-10-01 17:05:45 | 2017-10-01 07:00:00 | 2 | 22 | 22 |
| 10000 | 2017-10-01 | 北京 | 20 | 0 | 2017-10-01 07:00:00 | 2017-10-01 07:00:00 | 35 | 10 | 2 |
| 10005 | 2017-10-03 | 长沙 | 29 | 1 | 2017-10-03 18:11:02 | 2017-10-03 18:11:02 | 3 | 1 | 1 |
| 10004 | 2017-10-01 | 深圳 | 35 | 0 | 2017-10-01 10:00:15 | 2017-10-01 10:00:15 | 100 | 3 | 3 |
| 10004 | 2017-10-03 | 深圳 | 35 | 0 | 2017-10-03 11:22:00 | 2017-10-03 10:20:22 | 55 | 19 | 6 |
| 10003 | 2017-10-02 | 广州 | 32 | 0 | 2017-10-02 11:20:00 | 2017-10-02 11:20:00 | 30 | 11 | 11 |
+---------+------------+--------+------+------+---------------------+--------------------------+------+----------------+----------------+
7 rows in set (0.01 sec)
可以看到，用户10004的已有数据和新导入的数据发生了聚合，同时新增了10005用户的数据。
Uniq模型
在某些多维分析场景下，用户更关注的是如何保证Key的唯一性，即如何获得Primary Key唯一性约束。因此，我们引入了Uniq的数据模型。该模型本质上是聚合模型的一个特例，也是一种简化的表结构表示方式。
建表：
CREATE TABLE IF NOT EXISTS test.user
(
`user_id` LARGEINT NOT NULL COMMENT "用户 id",
`username` VARCHAR(50) NOT NULL COMMENT "用户昵称",
`city` VARCHAR(20) COMMENT "用户所在城市",
`age` SMALLINT COMMENT "用户年龄",
`sex` TINYINT COMMENT "用户性别",
`phone` LARGEINT COMMENT "用户电话",
`address` VARCHAR(500) COMMENT "用户地址",
`register_time` DATETIME COMMENT "用户注册时间"
)
UNIQUE KEY(`user_id`, `username`)
DISTRIBUTED BY HASH(`user_id`) BUCKETS 10
PROPERTIES
(
"replication_num" = "1",
"storage_medium" = "SSD"
);
插入数据：
insert into test.user values\
(10000,'wuyanzu',' 北京',18,0,12345678910,' 北京朝阳区 ','2017-10-01 07:00:00'),\
(10000,'wuyanzu',' 北京',19,0,12345678910,' 北京朝阳区 ','2017-10-01 07:00:00'),\
(10000,'zhangsan','北京',20,0,12345678910,'北京海淀区','2017-11-15 06:10:20');
查看数据：
mysql> select * from test.user;
+---------+----------+---------+------+------+-------------+-------------------+---------------------+
| user_id | username | city | age | sex | phone | address | register_time |
+---------+----------+---------+------+------+-------------+-------------------+---------------------+
| 10000 | wuyanzu | 北京 | 19 | 0 | 12345678910 | 北京朝阳区 | 2017-10-01 07:00:00 |
| 10000 | zhangsan | 北京 | 20 | 0 | 12345678910 | 北京海淀区 | 2017-11-15 06:10:20 |
+---------+----------+---------+------+------+-------------+-------------------+---------------------+
2 rows in set (0.03 sec)
Uniq 模型完全可以用聚合模型中的REPLACE方式替代，其内部的实现方式和数据存储方式也完全一样。
Duplicate模型
在某些多维分析场景下，数据既没有主键，也没有聚合需求。Duplicate数据模型可以满足这类需求。数据完全按照导入文件中的数据进行存储，不会有任何聚合。即使两行数据完全相同，也都会保留。而在建表语句中指定的DUPLICATE KEY，只是用来指明底层数据按照哪些列进行排序。
建表：
CREATE TABLE IF NOT EXISTS test.example_log
(
`timestamp` DATETIME NOT NULL COMMENT "日志时间",
`type` INT NOT NULL COMMENT "日志类型",
`error_code` INT COMMENT "错误码",
`error_msg` VARCHAR(1024) COMMENT "错误详细信息",
`op_id` BIGINT COMMENT "负责人 id",
`op_time` DATETIME COMMENT "处理时间"
)
DUPLICATE KEY(`timestamp`, `type`)
DISTRIBUTED BY HASH(`timestamp`) BUCKETS 10
PROPERTIES
(
"replication_num" = "1",
"storage_medium" = "SSD"
);
插入数据：
insert into test.example_log values\
('2017-10-01 08:00:05',1,404,'not found page', 101, '2017-10-01 08:00:05'),\
('2017-10-01 08:00:05',1,404,'not found page', 101, '2017-10-01 08:00:05'),\
('2017-10-01 08:00:05',2,404,'not found page', 101, '2017-10-01 08:00:06'),\
('2017-10-01 08:00:06',2,404,'not found page', 101, '2017-10-01 08:00:07');
查看表：
mysql> select * from test.example_log;
+---------------------+------+------------+----------------+-------+---------------------+
| timestamp | type | error_code | error_msg | op_id | op_time |
+---------------------+------+------------+----------------+-------+---------------------+
| 2017-10-01 08:00:05 | 1 | 404 | not found page | 101 | 2017-10-01 08:00:05 |
| 2017-10-01 08:00:05 | 1 | 404 | not found page | 101 | 2017-10-01 08:00:05 |
| 2017-10-01 08:00:05 | 2 | 404 | not found page | 101 | 2017-10-01 08:00:06 |
| 2017-10-01 08:00:06 | 2 | 404 | not found page | 101 | 2017-10-01 08:00:07 |
+---------------------+------+------------+----------------+-------+---------------------+
4 rows in set (0.01 sec)
数据模型的选择建议
因为数据模型在建表时就已经确定，且无法修改。所以，选择一个合适的数据模型非常重要。
- 1、Aggregate模型可以通过预聚合，极大地降低聚合查询时所需扫描的数据量和查询的计算量，非常适合有固定模式的报表类查询场景。但是该模型对count(*) 查询很不友好。同时因为固定了Value列上的聚合方式，在进行其他类型的聚合查询时，需要考虑语意正确性；
- 2、Uniq模型针对需要唯一主键约束的场景，可以保证主键唯一性约束。但是无法利用ROLLUP等预聚合带来的查询优势（因为本质是REPLACE，没有SUM这种聚合方式）；
- 3、Duplicate适合任意维度的Ad-hoc查询。虽然同样无法利用预聚合的特性，但是不受聚合模型的约束，可以发挥列存模型的优势（只读取相关列，而不需要读取所有Key列）。
聚合模型的局限性
这里我们针对Aggregate模型（包括Uniq模型），来介绍下聚合模型的局限性。在聚合模型中，模型对外展现的，是最终聚合后的数据。也就是说，任何还未聚合的数据（比如说两个不同导入批次的数据），必须通过某种方式，以保证对外展示的一致性。我们举例说明。
假设表结构如下：
假设存储引擎中有如下两个已经导入完成的批次的数据：
可以看到，用户10001分属在两个导入批次中的数据还没有聚合。但是为了保证用户只能查询到如下最终聚合后的数据：
首先，可以在在查询引擎中加入聚合算子，以保证数据对外的一致性。
另外，在聚合列（Value）上，执行与聚合类型不一致的聚合类查询时，要注意语意。比如我们在如上示例中执行如下查询：
SELECT MIN(cost) FROM table;
得到的结果是5，而不是1。
同时，这种一致性保证在某些查询中，会极大的降低查询效率。我们以最基本的count(*) 查询为例：
SELECT COUNT(*) FROM table;
在其他数据库中，这类查询都会很快的返回结果。因为在实现上，我们可以通过如“导入时对行进行计数，保存count的统计信息”，或者在查询时“仅扫描某一列数据，获得 count值”的方式，只需很小的开销，即可获得查询结果。但是在Doris的聚合模型中，这种查询的开销非常大。
上面的例子，select count(*) from table; 的正确结果应该为4。但如果我们只扫描user_id这一列，如果加上查询时聚合，最终得到的结果是3（10001, 10002, 10003）。而如果不加查询时聚合，则得到的结果是5（两批次一共5行数据）。可见这两个结果都是不对的。
为了得到正确的结果，我们必须同时读取user_id和date这两列的数据，再加上查询时聚合，才能返回4这个正确的结果。也就是说，在count(*) 查询中，Doris必须扫描所有的AGGREGATE KEY 列（这里就是user_id和date），并且聚合后，才能得到语意正确的结果。
当聚合列非常多时，count()查询需要扫描大量的数据。因此，当业务上有频繁的count() 查询时，我们建议用户通过增加一个值恒为1 、聚合类型为SUM的列来模拟 count(*)。如刚才的例子中的表结构，我们修改如下：
增加一个count列，并且导入数据中，该列值恒为1。则select count() from table; 的结果等价于 select sum(count) from table;。而后者的查询效率将远高于前者。不过这种方式也有使用限制，就是用户需要自行保证，不会重复导入AGGREGATE KEY列都相同的行。否则，select sum(count) from table; 只能表述原始导入的行数，而不是select count() from table; 的语义。
另一种方式，就是将如上的count列的聚合类型改为REPLACE，且依然值恒为1。那么select sum(count) from table;和select count(*) from table;的结果将是一致的。并且这种方式，没有导入重复行的限制。
动态分区
动态分区是在Doris 0.12版本中引入的新功能。旨在对表级别的分区实现生命周期管理（TTL），减少用户的使用负担。目前实现了动态添加分区及动态删除分区的功能，动态分区只支持Range分区。
原理
在某些使用场景下，用户会将表按照天进行分区划分，每天定时执行例行任务，这时需要使用方手动管理分区，否则可能由于使用方没有创建分区导致数据导入失败，这给使用方带来了额外的维护成本。
通过动态分区功能，用户可以在建表时设定动态分区的规则。FE会启动一个后台线程，根据用户指定的规则创建或删除分区。用户也可以在运行时对现有规则进行变更。
使用方式
动态分区的规则可以在建表时指定，或者在运行时进行修改。当前仅支持对单分区列的分区表设定动态分区规则。
- 1、建表时指定：
CREATE TABLE tbl1
(...)
PROPERTIES
(
"dynamic_partition.prop1" = "value1",
"dynamic_partition.prop2" = "value2",
...
);
- 2、运行时修改：
ALTER TABLE tbl1 SET
(
"dynamic_partition.prop1" = "value1",
"dynamic_partition.prop2" = "value2",
...
);
规则参数
主要参数
动态分区的规则参数都以 dynamic_partition. 为前缀：
创建历史分区的参数
- 1、dynamic_partition.create_history_partition：默认为false。当置为true时，Doris 会自动创建所有分区，当期望创建的分区个数大于max_dynamic_partition_num值时，操作将被禁止。当不指定 start属性时，该参数不生效；
*２、dynamic_partition.history_partition_num：当create_history_partition为true时，该参数用于指定创建历史分区数量。默认值为-1， 即未设置； - 3、dynamic_partition.hot_partition_num：指定最新的多少个分区为热分区。对于热分区，系统会自动设置其 storage_medium 参数为SSD，并且设置storage_cooldown_time；
- 4、hot_partition_num：往前n天和未来所有分区。我们举例说明。假设今天是2021-05-20，按天分区，动态分区的属性设置为：hot_partition_num=2, end=3, start=-3。则系统会自动创建以下分区，并且设置 storage_medium和storage_cooldown_time参数：
p20210517：["2021-05-17", "2021-05-18") storage_medium=HDD storage_cooldown_time=9999-12-31 23:59:59
p20210518：["2021-05-18", "2021-05-19") storage_medium=HDD storage_cooldown_time=9999-12-31 23:59:59
p20210519：["2021-05-19", "2021-05-20") storage_medium=SSD storage_cooldown_time=2021-05-21 00:00:00
p20210520：["2021-05-20", "2021-05-21") storage_medium=SSD storage_cooldown_time=2021-05-22 00:00:00
p20210521：["2021-05-21", "2021-05-22") storage_medium=SSD storage_cooldown_time=2021-05-23 00:00:00
p20210522：["2021-05-22", "2021-05-23") storage_medium=SSD storage_cooldown_time=2021-05-24 00:00:00
p20210523：["2021-05-23", "2021-05-24") storage_medium=SSD storage_cooldown_time=2021-05-25 00:00:00
- 5、dynamic_partition.reserved_history_periods：需要保留的历史分区的时间范围。
- 1、当 dynamic_partition.time_unit设置为"DAY/WEEK/MONTH" 时，需要以[yyyy-MM-dd,yyyy-MM-dd],[…,…] 格式进行设置；
- 2、当dynamic_partition.time_unit 设置为"HOUR" 时，需要以[yyyy-MM-dd HH:mm:ss,yyyy-MM-dd HH:mm:ss],[…,…]的格式来进行设置；
- 3、如果不设置，默认为 “NULL”。
我们举例说明。假设今天是2021-09-06，按天分类，动态分区的属性设置为：
time_unit="DAY/WEEK/MONTH", \
end=3, \
start=-3, \
reserved_history_periods="[2020-06-01,2020-06-20],[2020-10-31,2020-11-15]"
则系统会自动保留：
["2020-06-01","2020-06-20"],
["2020-10-31","2020-11-15"]
或者
time_unit="HOUR", \
end=3, \
start=-3, \
reserved_history_periods="[2020-06-01 00:00:00,2020-06-01 03:00:00]"
则系统会自动保留：
["2020-06-01 00:00:00","2020-06-01 03:00:00"]
这两个时间段的分区。其中，reserved_history_periods的每一个[…,…]是一对设置项，两者需要同时被设置，且第一个时间不能大于第二个时间。
创建历史分区规则
假设需要创建的历史分区数量为expect_create_partition_num，根据不同的设置具体数量如下：
-
1、create_history_partition = true：
dynamic_partition.history_partition_num未设置，即 -1，则expect_create_partition_num = end - start;
dynamic_partition.history_partition_num已设置，则expect_create_partition_num = end - max(start, -histoty_partition_num); -
2、create_history_partition = false：
不会创建历史分区，expect_create_partition_num = end - 0; -
3、当expect_create_partition_num > max_dynamic_partition_num（默认500）：
禁止创建过多分区。
创建历史分区举例
假设今天是2021-05-20，按天分区，动态分区的属性设置为：create_history_partition=true,end=3, start=-3, history_partition_num=1，则系统会自动创建以下分区（4个，且历史分区只有1个）：
p20210519
p20210520
p20210521
p20210522
p20210523
history_partition_num=5，其余属性不变，则系统会自动创建以下分区（6个，历史分区3个）：
p20210517
p20210518
p20210519
p20210520
p20210521
p20210522
p20210523
history_partition_num=-1 即不设置历史分区数量，其余属性不变，则系统会自动创建以下分区（6个，历史分区3个）：
p20210517
p20210518
p20210519
p20210520
p20210521
p20210522
p20210523
注意事项
动态分区使用过程中，如果因为一些意外情况导致dynamic_partition.start和dynamic_partition.end之间的某些分区丢失，那么当前时间与dynamic_partition.end之间的丢失分区会被重新创建，dynamic_partition.start与当前时间之间的丢失分区不会重新创建。
示例
创建表，分区列time类型为DATE，创建一个动态分区规则。按天分区，只保留最近7天的分区，并且预先创建未来3天的分区：
create table student_dynamic_partition1
(
id int,
time date,
name varchar(50),
age int
)
duplicate key(id,time)
PARTITION BY RANGE(time)()
DISTRIBUTED BY HASH(id) buckets 10
PROPERTIES(
"dynamic_partition.enable" = "true",
"dynamic_partition.time_unit" = "DAY",
"dynamic_partition.start" = "-7",
"dynamic_partition.end" = "3",
"dynamic_partition.prefix" = "p",
"dynamic_partition.buckets" = "10",
"replication_num" = "1",
"storage_medium" = "SSD"
);
查看动态分区调度情况：
mysql> SHOW DYNAMIC PARTITION TABLES;
+----------------------------+--------+----------+-------+------+--------+---------+----------------+-------------------------+---------+---------------------+---------------------+--------+------------------------+----------------------+------------------------+
| TableName | Enable | TimeUnit | Start | End | Prefix | Buckets | ReplicationNum | ReplicaAllocation | StartOf | LastUpdateTime | LastSchedulerTime | State | LastCreatePartitionMsg | LastDropPartitionMsg | ReservedHistoryPeriods |
+----------------------------+--------+----------+-------+------+--------+---------+----------------+-------------------------+---------+---------------------+---------------------+--------+------------------------+----------------------+------------------------+
| student_dynamic_partition1 | true | DAY | -7 | 3 | p | 10 | 1 | tag.location.default: 1 | NULL | 2022-05-14 16:17:24 | 2022-05-14 16:17:24 | NORMAL | NULL | NULL | NULL |
+----------------------------+--------+----------+-------+------+--------+---------+----------------+-------------------------+---------+---------------------+---------------------+--------+------------------------+----------------------+------------------------+
1 row in set (0.02 sec)
其中：
- 1、LastUpdateTime: 最后一次修改动态分区属性的时间；
- 2、LastSchedulerTime: 最后一次执行动态分区调度的时间；
- 3、State: 最后一次执行动态分区调度的状态；
- 4、LastCreatePartitionMsg: 最后一次执行动态添加分区调度的错误信息；
- 5、LastDropPartitionMsg: 最后一次执行动态删除分区调度的错误信息
查看表的分区：
mysql> SHOW PARTITIONS FROM student_dynamic_partition1;
+-------------+---------------+----------------+---------------------+--------------------+--------+--------------+----------------------------------------------------------------------------+-----------------+---------+----------------+---------------+---------------------+--------------------------+----------+------------+-------------------------+
| PartitionId | PartitionName | VisibleVersion | VisibleVersionTime | VisibleVersionHash | State | PartitionKey | Range | DistributionKey | Buckets | ReplicationNum | StorageMedium | CooldownTime | LastConsistencyCheckTime | DataSize | IsInMemory | ReplicaAllocation |
+-------------+---------------+----------------+---------------------+--------------------+--------+--------------+----------------------------------------------------------------------------+-----------------+---------+----------------+---------------+---------------------+--------------------------+----------+------------+-------------------------+
| 10365 | p20220514 | 1 | 2022-05-14 16:17:24 | 0 | NORMAL | time | [types: [DATE]; keys: [2022-05-14]; ..types: [DATE]; keys: [2022-05-15]; ) | id | 10 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0.000 | false | tag.location.default: 1 |
| 10386 | p20220515 | 1 | 2022-05-14 16:17:24 | 0 | NORMAL | time | [types: [DATE]; keys: [2022-05-15]; ..types: [DATE]; keys: [2022-05-16]; ) | id | 10 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0.000 | false | tag.location.default: 1 |
| 10407 | p20220516 | 1 | 2022-05-14 16:17:24 | 0 | NORMAL | time | [types: [DATE]; keys: [2022-05-16]; ..types: [DATE]; keys: [2022-05-17]; ) | id | 10 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0.000 | false | tag.location.default: 1 |
| 10428 | p20220517 | 1 | 2022-05-14 16:17:24 | 0 | NORMAL | time | [types: [DATE]; keys: [2022-05-17]; ..types: [DATE]; keys: [2022-05-18]; ) | id | 10 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0.000 | false | tag.location.default: 1 |
+-------------+---------------+----------------+---------------------+--------------------+--------+--------------+----------------------------------------------------------------------------+-----------------+---------+----------------+---------------+---------------------+--------------------------+----------+------------+-------------------------+
4 rows in set (0.00 sec)
插入测试数据，注意要把时间改成分区里的时间：
mysql> insert into student_dynamic_partition1 values(1,'2022-05-15 11:00:00','name1',18);
Query OK, 1 row affected (0.06 sec)
{'label':'insert_3c4b08c175d14cb9-998c4b5bcd732a28', 'status':'VISIBLE', 'txnId':'9'}
mysql> insert into student_dynamic_partition1 values(1,'2022-05-14 11:00:00','name1',18);
Query OK, 1 row affected (0.03 sec)
{'label':'insert_40a2af42900f4741-a127684ca5700fb6', 'status':'VISIBLE', 'txnId':'10'}
mysql> insert into student_dynamic_partition1 values(1,'2022-05-16 11:00:00','name1',18);
Query OK, 1 row affected (0.07 sec)
{'label':'insert_6f9ed7c84c624de3-ae13f44bb7dab360', 'status':'VISIBLE', 'txnId':'11'}
设置创建历史分区：
ALTER TABLE student_dynamic_partition1 SET ("dynamic_partition.create_history_partition" = "true");
查看分区情况：
mysql> SHOW PARTITIONS FROM student_dynamic_partition1;
+-------------+---------------+----------------+---------------------+---------------------+--------+--------------+----------------------------------------------------------------------------+-----------------+---------+----------------+---------------+---------------------+--------------------------+----------+------------+-------------------------+
| PartitionId | PartitionName | VisibleVersion | VisibleVersionTime | VisibleVersionHash | State | PartitionKey | Range | DistributionKey | Buckets | ReplicationNum | StorageMedium | CooldownTime | LastConsistencyCheckTime | DataSize | IsInMemory | ReplicaAllocation |
+-------------+---------------+----------------+---------------------+---------------------+--------+--------------+----------------------------------------------------------------------------+-----------------+---------+----------------+---------------+---------------------+--------------------------+----------+------------+-------------------------+
| 10452 | p20220507 | 1 | 2022-05-14 16:19:57 | 0 | NORMAL | time | [types: [DATE]; keys: [2022-05-07]; ..types: [DATE]; keys: [2022-05-08]; ) | id | 10 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0.000 | false | tag.location.default: 1 |
| 10473 | p20220508 | 1 | 2022-05-14 16:19:57 | 0 | NORMAL | time | [types: [DATE]; keys: [2022-05-08]; ..types: [DATE]; keys: [2022-05-09]; ) | id | 10 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0.000 | false | tag.location.default: 1 |
| 10494 | p20220509 | 1 | 2022-05-14 16:19:57 | 0 | NORMAL | time | [types: [DATE]; keys: [2022-05-09]; ..types: [DATE]; keys: [2022-05-10]; ) | id | 10 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0.000 | false | tag.location.default: 1 |
| 10515 | p20220510 | 1 | 2022-05-14 16:19:57 | 0 | NORMAL | time | [types: [DATE]; keys: [2022-05-10]; ..types: [DATE]; keys: [2022-05-11]; ) | id | 10 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0.000 | false | tag.location.default: 1 |
| 10536 | p20220511 | 1 | 2022-05-14 16:19:57 | 0 | NORMAL | time | [types: [DATE]; keys: [2022-05-11]; ..types: [DATE]; keys: [2022-05-12]; ) | id | 10 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0.000 | false | tag.location.default: 1 |
| 10557 | p20220512 | 1 | 2022-05-14 16:19:57 | 0 | NORMAL | time | [types: [DATE]; keys: [2022-05-12]; ..types: [DATE]; keys: [2022-05-13]; ) | id | 10 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0.000 | false | tag.location.default: 1 |
| 10578 | p20220513 | 1 | 2022-05-14 16:19:57 | 0 | NORMAL | time | [types: [DATE]; keys: [2022-05-13]; ..types: [DATE]; keys: [2022-05-14]; ) | id | 10 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0.000 | false | tag.location.default: 1 |
| 10365 | p20220514 | 2 | 2022-05-14 16:18:55 | 929516207550812448 | NORMAL | time | [types: [DATE]; keys: [2022-05-14]; ..types: [DATE]; keys: [2022-05-15]; ) | id | 10 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0.000 | false | tag.location.default: 1 |
| 10386 | p20220515 | 2 | 2022-05-14 16:18:42 | 7997457037777189294 | NORMAL | time | [types: [DATE]; keys: [2022-05-15]; ..types: [DATE]; keys: [2022-05-16]; ) | id | 10 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0.000 | false | tag.location.default: 1 |
| 10407 | p20220516 | 2 | 2022-05-14 16:18:58 | 7092394304145677063 | NORMAL | time | [types: [DATE]; keys: [2022-05-16]; ..types: [DATE]; keys: [2022-05-17]; ) | id | 10 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0.000 | false | tag.location.default: 1 |
| 10428 | p20220517 | 1 | 2022-05-14 16:17:24 | 0 | NORMAL | time | [types: [DATE]; keys: [2022-05-17]; ..types: [DATE]; keys: [2022-05-18]; ) | id | 10 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0.000 | false | tag.location.default: 1 |
+-------------+---------------+----------------+---------------------+---------------------+--------+--------------+----------------------------------------------------------------------------+-----------------+---------+----------------+---------------+---------------------+--------------------------+----------+------------+-------------------------+
11 rows in set (0.00 sec)
动态分区表与手动分区表相互转换：
对于一个表来说，动态分区和手动分区可以自由转换，但二者不能同时存在，有且只有一种状态。
- 1、手动分区转换为动态分区：
如果一个表在创建时未指定动态分区，可以通过ALTER TABLE在运行时修改动态分区相关属性来转化为动态分区，具体示例可以通过HELP ALTER TABLE查看。
注意：如果已设定dynamic_partition.start，分区范围在动态分区起始偏移之前的历史分区将会被删除。 - 2、动态分区转换为手动分区：
关闭动态分区功能后，Doris 将不再自动管理分区，需要用户手动通过 ALTER TABLE的方式创建或删除分区。
ALTER TABLE tbl_name SET ("dynamic_partition.enable" = "false")
六、Rollup
ROLLUP在多维分析中是“上卷”的意思，即将数据按某种指定的粒度进行进一步聚合。
基本概念
在Doris中，我们将用户通过建表语句创建出来的表称为Base表（Base Table）。Base表中保存着按用户建表语句指定的方式存储的基础数据。
在Base表之上，我们可以创建任意多个ROLLUP表。这些ROLLUP的数据是基于Base表产生的，并且在物理上是独立存储的。
ROLLUP表的基本作用，在于在Base表的基础上，获得更粗粒度的聚合数据。
Aggregate和Uniq模型中的Rollup
因为Uniq只是Aggregate模型的一个特例，所以这里我们不加以区别。
示例1：以example_site_visit2表为例
- 1、查看表的结构信息
mysql> desc example_site_visit2 all;
+---------------------+---------------+-----------------+-------------+------+-------+---------------------+---------+---------+
| IndexName | IndexKeysType | Field | Type | Null | Key | Default | Extra | Visible |
+---------------------+---------------+-----------------+-------------+------+-------+---------------------+---------+---------+
| example_site_visit2 | AGG_KEYS | user_id | LARGEINT | No | true | NULL | | true |
| | | date | DATE | No | true | NULL | | true |
| | | timestamp | DATETIME | Yes | true | NULL | | true |
| | | city | VARCHAR(20) | Yes | true | NULL | | true |
| | | age | SMALLINT | Yes | true | NULL | | true |
| | | sex | TINYINT | Yes | true | NULL | | true |
| | | last_visit_date | DATETIME | Yes | false | 1970-01-01 00:00:00 | REPLACE | true |
| | | cost | BIGINT | Yes | false | 0 | SUM | true |
| | | max_dwell_time | INT | Yes | false | 0 | MAX | true |
| | | min_dwell_time | INT | Yes | false | 99999 | MIN | true |
+---------------------+---------------+-----------------+-------------+------+-------+---------------------+---------+---------+
10 rows in set (0.00 sec)
- 2、比如需要查看某个用户的总消费，那么可以建立一个只有user_id和cost的rollup：
alter table example_site_visit2 add rollup rollup_cost_userid(user_id,cost);
- 3、查看表的结构信息：
mysql> desc example_site_visit2 all;
+---------------------+---------------+-----------------+-------------+------+-------+---------------------+---------+---------+
| IndexName | IndexKeysType | Field | Type | Null | Key | Default | Extra | Visible |
+---------------------+---------------+-----------------+-------------+------+-------+---------------------+---------+---------+
| example_site_visit2 | AGG_KEYS | user_id | LARGEINT | No | true | NULL | | true |
| | | date | DATE | No | true | NULL | | true |
| | | timestamp | DATETIME | Yes | true | NULL | | true |
| | | city | VARCHAR(20) | Yes | true | NULL | | true |
| | | age | SMALLINT | Yes | true | NULL | | true |
| | | sex | TINYINT | Yes | true | NULL | | true |
| | | last_visit_date | DATETIME | Yes | false | 1970-01-01 00:00:00 | REPLACE | true |
| | | cost | BIGINT | Yes | false | 0 | SUM | true |
| | | max_dwell_time | INT | Yes | false | 0 | MAX | true |
| | | min_dwell_time | INT | Yes | false | 99999 | MIN | true |
| | | | | | | | | |
| rollup_cost_userid | AGG_KEYS | user_id | LARGEINT | No | true | NULL | | true |
| | | cost | BIGINT | Yes | false | 0 | SUM | true |
+---------------------+---------------+-----------------+-------------+------+-------+---------------------+---------+---------+
13 rows in set (0.00 sec)
- 4、然后可以通过 explain 查看执行计划，是否使用到了 rollup：
mysql> explain SELECT user_id, sum(cost) FROM example_site_visit2 GROUP BY user_id;
+---------------------------------------------------------------------------------------+
| Explain String |
+---------------------------------------------------------------------------------------+
| PLAN FRAGMENT 0 |
| OUTPUT EXPRS:<slot 2> `user_id` | <slot 3> sum(`cost`) |
| PARTITION: UNPARTITIONED |
| |
| RESULT SINK |
| |
| 2:EXCHANGE |
| |
| PLAN FRAGMENT 1 |
| OUTPUT EXPRS: |
| PARTITION: HASH_PARTITIONED: `default_cluster:test`.`example_site_visit2`.`user_id` |
| |
| STREAM DATA SINK |
| EXCHANGE ID: 02 |
| UNPARTITIONED |
| |
| 1:AGGREGATE (update finalize) |
| | output: sum(`cost`) |
| | group by: `user_id` |
| | cardinality=-1 |
| | |
| 0:OlapScanNode |
| TABLE: example_site_visit2 |
| PREAGGREGATION: ON |
| partitions=1/1 |
| rollup: rollup_cost_userid |
| tabletRatio=10/10 |
| tabletList=10601,10603,10605,10607,10609,10611,10613,10615,10617,10619 |
| cardinality=0 |
| avgRowSize=24.0 |
| numNodes=1 |
+---------------------------------------------------------------------------------------+
31 rows in set (0.01 sec)
Doris会自动命中这个ROLLUP表，从而只需扫描极少的数据量，即可完成这次聚合查询。
- 5、通过命令查看完成状态：
mysql> SHOW ALTER TABLE ROLLUP;
+-------+---------------------+---------------------+---------------------+---------------------+--------------------+----------+---------------+----------+------+----------+---------+
| JobId | TableName | CreateTime | FinishTime | BaseIndexName | RollupIndexName | RollupId | TransactionId | State | Msg | Progress | Timeout |
+-------+---------------------+---------------------+---------------------+---------------------+--------------------+----------+---------------+----------+------+----------+---------+
| 10599 | example_site_visit2 | 2022-05-14 16:25:23 | 2022-05-14 16:25:44 | example_site_visit2 | rollup_cost_userid | 10600 | 12 | FINISHED | | NULL | 86400 |
+-------+---------------------+---------------------+---------------------+---------------------+--------------------+----------+---------------+----------+------+----------+---------+
1 row in set (0.01 sec)
示例 2：获得不同城市，不同年龄段用户的总消费、最长和最短页面驻留时间
- 1、创建 ROLLUP
alter table example_site_visit2 add rollup rollup_city_age_cost_maxd_mind(city,age,cost,max_dwell_time,min_dwell_time);
- 2、查看 rollup 使用
mysql> explain SELECT city, age, sum(cost), max(max_dwell_time), min(min_dwell_time) FROM example_site_visit2 GROUP BY city, age;
+-----------------------------------------------------------------------------------------------------------------------------------------+
| Explain String |
+-----------------------------------------------------------------------------------------------------------------------------------------+
| PLAN FRAGMENT 0 |
| OUTPUT EXPRS:<slot 5> `city` | <slot 6> `age` | <slot 7> sum(`cost`) | <slot 8> max(`max_dwell_time`) | <slot 9> min(`min_dwell_time`) |
| PARTITION: UNPARTITIONED |
| |
| RESULT SINK |
| |
| 4:EXCHANGE |
| |
| PLAN FRAGMENT 1 |
| OUTPUT EXPRS: |
| PARTITION: HASH_PARTITIONED: <slot 5> `city`, <slot 6> `age` |
| |
| STREAM DATA SINK |
| EXCHANGE ID: 04 |
| UNPARTITIONED |
| |
| 3:AGGREGATE (merge finalize) |
| | output: sum(<slot 7> sum(`cost`)), max(<slot 8> max(`max_dwell_time`)), min(<slot 9> min(`min_dwell_time`)) |
| | group by: <slot 5> `city`, <slot 6> `age` |
| | cardinality=-1 |
| | |
| 2:EXCHANGE |
| |
| PLAN FRAGMENT 2 |
| OUTPUT EXPRS: |
| PARTITION: HASH_PARTITIONED: `default_cluster:test`.`example_site_visit2`.`user_id` |
| |
| STREAM DATA SINK |
| EXCHANGE ID: 02 |
| HASH_PARTITIONED: <slot 5> `city`, <slot 6> `age` |
| |
| 1:AGGREGATE (update serialize) |
| | STREAMING |
| | output: sum(`cost`), max(`max_dwell_time`), min(`min_dwell_time`) |
| | group by: `city`, `age` |
| | cardinality=-1 |
| | |
| 0:OlapScanNode |
| TABLE: example_site_visit2 |
| PREAGGREGATION: ON |
| partitions=1/1 |
| rollup: example_site_visit2 |
| tabletRatio=10/10 |
| tabletList=10255,10257,10259,10261,10263,10265,10267,10269,10271,10273 |
| cardinality=6 |
| avgRowSize=1358.0 |
| numNodes=1 |
+-----------------------------------------------------------------------------------------------------------------------------------------+
47 rows in set (0.00 sec)
mysql> explain SELECT city, sum(cost), max(max_dwell_time), min(min_dwell_time) FROM example_site_visit2 GROUP BY city;
+------------------------------------------------------------------------------------------------------------------------+
| Explain String |
+------------------------------------------------------------------------------------------------------------------------+
| PLAN FRAGMENT 0 |
| OUTPUT EXPRS:<slot 4> `city` | <slot 5> sum(`cost`) | <slot 6> max(`max_dwell_time`) | <slot 7> min(`min_dwell_time`) |
| PARTITION: UNPARTITIONED |
| |
| RESULT SINK |
| |
| 4:EXCHANGE |
| |
| PLAN FRAGMENT 1 |
| OUTPUT EXPRS: |
| PARTITION: HASH_PARTITIONED: <slot 4> `city` |
| |
| STREAM DATA SINK |
| EXCHANGE ID: 04 |
| UNPARTITIONED |
| |
| 3:AGGREGATE (merge finalize) |
| | output: sum(<slot 5> sum(`cost`)), max(<slot 6> max(`max_dwell_time`)), min(<slot 7> min(`min_dwell_time`)) |
| | group by: <slot 4> `city` |
| | cardinality=-1 |
| | |
| 2:EXCHANGE |
| |
| PLAN FRAGMENT 2 |
| OUTPUT EXPRS: |
| PARTITION: HASH_PARTITIONED: `default_cluster:test`.`example_site_visit2`.`user_id` |
| |
| STREAM DATA SINK |
| EXCHANGE ID: 02 |
| HASH_PARTITIONED: <slot 4> `city` |
| |
| 1:AGGREGATE (update serialize) |
| | STREAMING |
| | output: sum(`cost`), max(`max_dwell_time`), min(`min_dwell_time`) |
| | group by: `city` |
| | cardinality=-1 |
| | |
| 0:OlapScanNode |
| TABLE: example_site_visit2 |
| PREAGGREGATION: ON |
| partitions=1/1 |
| rollup: rollup_city_age_cost_maxd_mind |
| tabletRatio=10/10 |
| tabletList=10623,10625,10627,10629,10631,10633,10635,10637,10639,10641 |
| cardinality=0 |
| avgRowSize=32.0 |
| numNodes=1 |
+------------------------------------------------------------------------------------------------------------------------+
47 rows in set (0.00 sec)
mysql> explain SELECT city, age, sum(cost), min(min_dwell_time) FROM example_site_visit2 GROUP BY city, age;
+--------------------------------------------------------------------------------------------------------+
| Explain String |
+--------------------------------------------------------------------------------------------------------+
| PLAN FRAGMENT 0 |
| OUTPUT EXPRS:<slot 4> `city` | <slot 5> `age` | <slot 6> sum(`cost`) | <slot 7> min(`min_dwell_time`) |
| PARTITION: UNPARTITIONED |
| |
| RESULT SINK |
| |
| 4:EXCHANGE |
| |
| PLAN FRAGMENT 1 |
| OUTPUT EXPRS: |
| PARTITION: HASH_PARTITIONED: <slot 4> `city`, <slot 5> `age` |
| |
| STREAM DATA SINK |
| EXCHANGE ID: 04 |
| UNPARTITIONED |
| |
| 3:AGGREGATE (merge finalize) |
| | output: sum(<slot 6> sum(`cost`)), min(<slot 7> min(`min_dwell_time`)) |
| | group by: <slot 4> `city`, <slot 5> `age` |
| | cardinality=-1 |
| | |
| 2:EXCHANGE |
| |
| PLAN FRAGMENT 2 |
| OUTPUT EXPRS: |
| PARTITION: HASH_PARTITIONED: `default_cluster:test`.`example_site_visit2`.`user_id` |
| |
| STREAM DATA SINK |
| EXCHANGE ID: 02 |
| HASH_PARTITIONED: <slot 4> `city`, <slot 5> `age` |
| |
| 1:AGGREGATE (update serialize) |
| | STREAMING |
| | output: sum(`cost`), min(`min_dwell_time`) |
| | group by: `city`, `age` |
| | cardinality=-1 |
| | |
| 0:OlapScanNode |
| TABLE: example_site_visit2 |
| PREAGGREGATION: ON |
| partitions=1/1 |
| rollup: rollup_city_age_cost_maxd_mind |
| tabletRatio=10/10 |
| tabletList=10623,10625,10627,10629,10631,10633,10635,10637,10639,10641 |
| cardinality=0 |
| avgRowSize=30.0 |
| numNodes=1 |
+--------------------------------------------------------------------------------------------------------+
47 rows in set (0.01 sec)
- 3、通过命令查看完成状态
mysql> SHOW ALTER TABLE ROLLUP;
+-------+---------------------+---------------------+---------------------+---------------------+--------------------------------+----------+---------------+----------+------+----------+---------+
| JobId | TableName | CreateTime | FinishTime | BaseIndexName | RollupIndexName | RollupId | TransactionId | State | Msg | Progress | Timeout |
+-------+---------------------+---------------------+---------------------+---------------------+--------------------------------+----------+---------------+----------+------+----------+---------+
| 10599 | example_site_visit2 | 2022-05-14 16:25:23 | 2022-05-14 16:25:44 | example_site_visit2 | rollup_cost_userid | 10600 | 12 | FINISHED | | NULL | 86400 |
| 10621 | example_site_visit2 | 2022-05-14 16:27:54 | 2022-05-14 16:28:24 | example_site_visit2 | rollup_city_age_cost_maxd_mind | 10622 | 13 | FINISHED | | NULL | 86400 |
+-------+---------------------+---------------------+---------------------+---------------------+--------------------------------+----------+---------------+----------+------+----------+---------+
2 rows in set (0.00 sec)
七、Duplicate模型中的Rollup
因为Duplicate模型没有聚合的语意，所以该模型中的ROLLUP，已经失去了“上卷”这一层含义。而仅仅是作为调整列顺序，以命中前缀索引的作用。下面详细介绍前缀索引，以及如何使用ROLLUP改变前缀索引，以获得更好的查询效率。
前缀索引
不同于传统的数据库设计，Doris不支持在任意列上创建索引。Doris这类MPP架构的OLAP数据库，通常都是通过提高并发来处理大量数据的。
本质上，Doris的数据存储在类似SSTable（Sorted String Table）的数据结构中。该结构是一种有序的数据结构，可以按照指定的列进行排序存储。在这种数据结构上，以排序列作为条件进行查找，会非常的高效。
在Aggregate、Uniq 和 Duplicate三种数据模型中，底层的数据存储是按照各自建表语句中，AGGREGATE KEY、UNIQ KEY和DUPLICATE KEY中指定的列进行排序存储的。而前缀索引，即在排序的基础上，实现的一种根据给定前缀列，快速查询数据的索引方式。
我们将一行数据的前36个字节作为这行数据的前缀索引。当遇到VARCHAR类型时，前缀索引会直接截断。举例说明：
-
1、以下表结构的前缀索引为 user_id(8 Bytes) + age(4 Bytes) + message(prefix 20 Bytes)。
-
2、以下表结构的前缀索引为user_name(20 Bytes)。即使没有达到 36 个字节，因为遇到VARCHAR，所以直接截断，不再往后继续。
-
3、当我们的查询条件，是前缀索引的前缀时，可以极大的加快查询速度。比如在第一个例子中，我们执行如下查询：
SELECT * FROM table WHERE user_id=1829239 and age=20；
该查询的效率会远高于如下查询：
SELECT * FROM table WHERE age=20；
所以在建表时，正确的选择列顺序，能够极大地提高查询效率。
Rollup调整前缀索引
因为建表时已经指定了列顺序，所以一个表只有一种前缀索引。这对于使用其他不能命中前缀索引的列作为条件进行的查询来说，效率上可能无法满足需求。因此，我们可以通过创建ROLLUP来人为的调整列顺序。
举例说明，Base表结构如下：
我们可以在此基础上创建一个ROLLUP表：
可以看到，ROLLUP和Base表的列完全一样，只是将user_id 和age的顺序调换了。那么当我们进行如下查询时：
SELECT * FROM table where age=20 and message LIKE "%error%";
会优先选择ROLLUP表，因为ROLLUP的前缀索引匹配度更高。
几点说明
- 1、ROLLUP最根本的作用是提高某些查询的查询效率（无论是通过聚合来减少数据量，还是修改列顺序以匹配前缀索引）。因此ROLLUP的含义已经超出了“上卷”的范围。这也是为什么在源代码中，将其命名为Materialized Index（物化索引）的原因；
- 2、ROLLUP是附属于Base表的，可以看做是Base表的一种辅助数据结构。用户可以在Base表的基础上，创建或删除ROLLUP，但是不能在查询中显式的指定查询某ROLLUP。是否命中 ROLLUP完全由Doris系统自动决定；
- 3、ROLLUP的数据是独立物理存储的。因此，创建的ROLLUP越多，占用的磁盘空间也就越大。同时对导入速度也会有影响（导入的ETL阶段会自动产生所有ROLLUP的数据），但是不会降低查询效率（只会更好）；
- 4、ROLLUP的数据更新与Base表是完全同步的。用户无需关心这个问题；
- 5、ROLLUP中列的聚合方式，与Base表完全相同。在创建ROLLUP无需指定，也不能修改；
- 6、查询能否命中ROLLUP的一个必要条件（非充分条件）是，查询所涉及的所有列（包括select list和where中的查询条件列等）都存在于该ROLLUP的列中。否则，查询只能命中Base表；
７、某些类型的查询（如 count()）在任何条件下，都无法命中ROLLUP。具体参见前文聚合模型的局限性一节； - 8、可以通过EXPLAIN your_sql;命令获得查询执行计划，在执行计划中，查看是否命中ROLLUP；
*９、可以通过DESC tbl_name ALL;语句显示Base表和所有已创建完成的ROLLUP。
参考：
https://blog.csdn.net/qq_37475168/article/details/125570856
网友评论