Doris 的数据模型主要分为 3 类：Aggregate 、Uniq 、Duplicate
表中的列按照是否设置了 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) 数据查询阶段。在数据查询时， 对于查询涉及到的数据， 会进行对应的聚合。
数据在不同时间，可能聚合的程度不一致。比如一批数据刚导入时，可能还未与之前已 存在的数据进行聚合。但是对于用户而言，用户只能查询到聚合后的数据。即不同的聚合程 度对于用户查询而言是透明的。用户需始终认为数据以最终的完成的聚合程度存在，而不应 假设某些聚合还未发生。(可参阅聚合模型的局限性一节获得更多详情。)
3.5.1.1 示例一：导入数据聚合
1)建表
CREATE TABLE IF NOT EXISTS test_db.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;
2）插入数据
insert into test_db.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 里只能演示不能在生产使用， 会引发写阻 塞。
3)查看表
select * from test_db.example_site_visit;
可以看到，用户 10000 只剩下了一行聚合后的数据。而其余用户的数据和原始数据保 持一致。经过聚合，Doris 中最终只会存储聚合后的数据。换句话说， 即明细数据会丢失， 用户不能够再查询到聚合前的明细数据了。
1)建表
CREATE TABLE IF NOT EXISTS test_db.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;
2)插入数据
insert into test_db.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);
3)查看表
select * from test_db.example_site_visit2;
存储的数据，和导入数据完全一样， 没有发生任何聚合。这是因为，这批数据中， 因为 加入了 timestamp 列，所有行的 Key 都不完全相同。也就是说，只要保证导入的数据中，
每一行的 Key 都不完全相同，那么即使在聚合模型下，Doris 也可以保存完整的明细数据。
1)往实例一中继续插入数据
insert into test_db.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);
2)查看表
select * from test_db.example_site_visit;
可以看到，用户 10004 的已有数据和新导入的数据发生了聚合。同时新增了 10005 用 户的数据。
3.5.2 Uniq 模型
在某些多维分析场景下，用户更关注的是如何保证 Key 的唯一性，即如何获得 Primary Key 唯一性约束。因此，我们引入了 Uniq 的数据模型。该模型本质上是聚合模型的一个特 例，也是一种简化的表结构表示方式。
1)建表
CREATE TABLE IF NOT EXISTS test_db.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;
2)插入数据
insert into test_db.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');
3)查询表
select * from test_db.user;
Uniq 模型完全可以用聚合模型中的 REPLACE 方式替代。其内部的实现方式和数据存 储方式也完全一样。
3.5.3 Duplicate 模型
在某些多维分析场景下，数据既没有主键，也没有聚合需求。 Duplicate 数据模型可以 满足这类需求。数据完全按照导入文件中的数据进行存储，不会有任何聚合。即使两行数据 完全相同， 也都会保留。 而在建表语句中指定的 DUPLICATE KEY，只是用来指明底层数 据按照那些列进行排序。
1)建表
CREATE TABLE IF NOT EXISTS test_db.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;
2)插入数据
insert into test_db.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');
3)查看表
select * from test_db.example_log;
因为数据模型在建表时就已经确定， 且无法修改。所以， 选择一个合适的数据模型非常 重要。
(1) Aggregate 模型可以通过预聚合，极大地降低聚合查询时所需扫描的数据量和查询 的计算量，非常适合有固定模式的报表类查询场景。但是该模型对 count(*) 查询很不友好。 同时因为固定了 Value 列上的聚合方式， 在进行其他类型的聚合查询时，需要考虑语意正确 性。
(2) Uniq 模型针对需要唯一主键约束的场景， 可以保证主键唯一性约束。但是无法利 用 ROLLUP 等预聚合带来的查询优势(因为本质是REPLACE，没有 SUM 这种聚合方式)。
(3) Duplicate 适合任意维度的 Ad-hoc 查询。虽然同样无法利用预聚合的特性，但是不 受聚合模型的约束，可以发挥列存模型的优势(只读取相关列，而不需要读取所有 Key 列)
3.5.5 聚合模型的局限性
这里我们针对 Aggregate 模型(包括 Uniq 模型)， 来介绍下聚合模型的局限性。
在聚合模型中， 模型对外展现的，是最终聚合后的数据。也就是说，任何还未聚合的数 据(比如说两个不同导入批次的数据) ，必须通过某种方式， 以保证对外展示的一致性。我 们举例说明。
假设表结构如下：
| ColumnName | Type | AggregationType | Comment |
|---|---|---|---|
| user_id | LARGEINT | 用户 id | |
| date | DATE | 数据灌入日期 | |
| cost | BIGINT | SUM | 用户总消费 |
假设存储引擎中有如下两个已经导入完成的批次的数据：
batch 1
| user_id | date | cost |
|---|---|---|
| 10001 | 2017- 11-20 | 50 |
| 10002 | 2017- 11-21 | 39 |
batch 2
| user_id | date | cost |
|---|---|---|
| 10001 | 2017- 11-20 | 1 |
| 10001 | 2017- 11-21 | 5 |
| 10003 | 2017- 11-22 | 22 |
可以看到，用户 10001 分属在两个导入批次中的数据还没有聚合。但是为了保证用户
只能查询到如下最终聚合后的数据：
| user_id | date | cost |
|---|---|---|
| 10001 | 2017- 11-20 | 51 |
| 10001 | 2017- 11-21 | 5 |
| 10002 | 2017- 11-21 | 39 |
| 10003 | 2017- 11-22 | 22 |
在查询引擎中加入了聚合算子， 来保证数据对外的一致性。
另外， 在聚合列(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(*)。如刚才的例子中的表结构，我们修改如下：
| ColumnName | Type | AggregateType | Comment |
|---|---|---|---|
| user_id | BIGINT | 用户 id | |
| date | DATE | 数据灌入日期 | |
| cost | BIGINT | SUM | 用户总消费 |
| count | BIGINT | 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; 的结果将是一致的。并且这种 方式， 没有导入重复行的限制。
📢博客主页：https://manor.blog.csdn.net
📢欢迎点赞 👍 收藏 ?留言 📝 如有错误敬请指正！
📢本文由 Maynor 原创，首发于 CSDN博客🙉
📢不能老盯着手机屏幕，要不时地抬起头，看看老板的位置?
📢专栏持续更新,欢迎订阅：https://blog.csdn.net/xianyu120/category_12401955.html
本文由mdnice多平台发布