Doris开发

# Doris开发

1. DDL
	1. 在 Doris 中，建表时必须选择**数据模型**，这决定了数据的存储、更新和聚合方式。
	2. **三种模型：**

| 模型 | 描述 | 对应 MySQL 场景 |
| --- | --- | --- |
| Duplicate (明细模型) | 存什么样查什么样，不做聚合。 | 普通的日志表、流水表。 |
| Unique (主键模型) | Key 相同则覆盖（Upsert）。 | 业务库同步过来的有主键的表。 |
| Aggregate (聚合模型) | Key 相同则按 Value 进行聚合（Sum/Max/Min）。 | 预计算报表、指标统计。 |

* 1. **示例1**：CREATE TABLE \-DUPLICATE模型 (类似 MySQL，需指定分桶)
		1. CREATE TABLE user\_log ( user\_id BIGINT, visit\_date DATE, city VARCHAR(20\), age INT)
		2. DUPLICATE KEY(user\_id, visit\_date) \-\- DUPLICATE指定模型类型。KEY（）指定user\_id，visit\_date为排序键，类似索引
		3. DISTRIBUTED BY HASH(user\_id) BUCKETS 10
		4. PROPERTIES ("replication\_num" \= "1");
	2. **示例2**：CREATE TABLE\- UNIQUE模型 (实现 MySQL 的 Replace/Update 语义)
		1. CREATE TABLE user\_info ( user\_id BIGINT, username VARCHAR(50\), last\_login DATETIME)
		2. UNIQUE KEY(user\_id)\-\-\-\- UNIQUE指定模型类型。KEY（）指定user\_id为排序键，类似索引
		3. DISTRIBUTED BY HASH(user\_id) BUCKETS 10
		4. PROPERTIES ("replication\_num" \= "3");

![](/media/202603/20260331135445269234.png)

* + 1. 执行报错，
		2. 报错原因分析：架构分析

![](/media/202603/20260331135445278146.png)

* + - 1. fe:frontend 前端节点：SQL解析
			2. ms:meta service 元数据服务：存放元数据（如库表结构、分区信息等）
			3. be:backend后端节点：数据存储（数据存放到be/storage），PROPERTIES ("replication\_num" \= "3")设置数据副本数，如果不显式设置，Doris 会使用默认副本数（通常为 3，来源于FE 配置 default\_replication\_num）。但在单 BE 环境下，默认值 3 会导致建表失败，因为无法满足副本放置要求。如下图，执行报错。示例2报错即为该原因导致。

![](/media/202603/20260331135445288908.png)

![](/media/202603/20260331135445298241.png)

* + 1. 调整数据副本数为1：
		2. CREATE TABLE user\_info ( user\_id BIGINT, username VARCHAR(50\), last\_login DATETIME)
		3. UNIQUE KEY(user\_id)\-\-\-\- UNIQUE指定模型类型。KEY（）指定user\_id为排序键，类似索引
		4. DISTRIBUTED BY HASH(user\_id) BUCKETS 10
		5. PROPERTIES ("replication\_num" \= "1");

![](/media/202603/20260331135445306539.png)

* + 1. PROPERTIES ("replication\_num" \= "1")数据副本数显示设置为1后执行成功。
	1. **示例3**：CREATE TABLE \- AGGREGATE模型 (实现 MySQL 的 GROUP BY分组的SUM, REPLACE, MAX, MIN聚合函数语义）
		1. CREATE TABLE user\_stats (
		2. user\_id BIGINT,
		3. visit\_date DATE,
		4. city VARCHAR(20\), \-\- 以上是 Key (维度)
		5. visit\_count BIGINT SUM DEFAULT "0", \-\- 自动求和
		6. last\_visit\_time DATETIME REPLACE DEFAULT CURRENT\_TIMESTAMP, \-\- 记录最后一次出现的值
		7. max\_stay\_duration INT MAX DEFAULT "0", \-\- 记录最大值
		8. min\_stay\_duration INT MIN DEFAULT "99999" \-\- 记录最小值
		9. )
		10. AGGREGATE KEY(user\_id, visit\_date, city) \-\-AGGREGATE定义模型类型，KEY 定义哪些列是维度
		11. DISTRIBUTED BY HASH(user\_id) BUCKETS 5
		12. PROPERTIES ("replication\_num" \= "1");

![](/media/202603/20260331135445316341.png)

* 1. **示例4**：ALTER TABLE \- 增加字段
		1. ALTER TABLE user\_log ADD COLUMN new\_col INT;

![](/media/202603/20260331135445328249.png)

* 1. **示例5**：ALTER TABLE \- 删除字段
		1. ALTER TABLE user\_log DROP COLUMN new\_col;

![](/media/202603/20260331135445336510.png)

* 1. **示例6**：ALTER TABLE \- 修改表属性
		1. 修改副本数 (Replication Num)
		2. ALTER TABLE test\_db.user\_stats SET ("replication\_num" \= "3");

![](/media/202603/20260331135445344369.png)

* + 1. 修改表注释
		2. ALTER TABLE test\_db.user\_stats MODIFY COMMENT "用户访问统计报表";

![](/media/202603/20260331135445352851.png)

* 1. **示例7**：ALTER TABLE \- 修改表字段
		1. 修改字段类型或长度
		2. ALTER TABLE user\_stats
		3. MODIFY COLUMN city VARCHAR(50\);

![](/media/202603/20260331135445362474.png)

* + 1. 调整字段顺序 (Reorder Columns)
		2. ALTER TABLE user\_stats
		3. ORDER BY (user\_id, city, visit\_date, visit\_count, last\_visit\_time, max\_stay\_duration, min\_stay\_duration);

![](/media/202603/20260331135445370575.png)

* + 1. select \* from user\_stats

![](/media/202603/20260331135445378624.png)

* + 1. ALTER TABLE user\_stats
		2. ORDER BY (user\_id, visit\_date,city, visit\_count, last\_visit\_time, max\_stay\_duration, min\_stay\_duration);
		3. select \* from user\_stats

![](/media/202603/20260331135445386876.png)

* 1. TIPS
		1. **分桶 (Bucketing)**：Doris 强制要求 DISTRIBUTED BY，这决定了数据如何分布在 BE 节点上。
		2. **排序键 (Short Key Index)**：DUPLICATE/UNIQUE/AGGREGATE KEY 里的列不仅是逻辑定义，还是物理存储的排序依据，查询时前缀过滤非常快，类似索引。
		3. **数据副本数（replication num）**:PROPERTIES ("replication\_num" \= "3")指定数据副本数，以确定表的分区（tablet）在不同的be节点的副本数，默认为3。多个 BE 可以同时响应查询请求以提升并发能力。
		4. **Aggregate模型**：Key 列必须在 Value 列之前。
		5. **建表属性（如分桶，数据副本数等）**：这些属性作用于分区，即分区创建之后，分区就会有自己的属性，修改表属性只对未来创建的分区生效，对已经创建好的分区不生效。
1. DML
	1. Doris 采用类似 **LSM\-Tree（Log\-Structured Merge\-Tree）** 的存储结构。当不断执行 INSERT、UPDATE、DELETE 或批量导入时，数据不是直接覆盖旧文件，而是**增量写入新文件**（ Doris 称 **Rowset**）。这样做的优点是写入速度快（顺序写），但缺点是**小文件过多，空间占用大。**
	2. **Compaction** 是由 BE 节点的后台线程自动执行的核心的**后台数据合并机制**。
	3. Doris 的 Compaction 分为两种主要类型，协同工作：

| 类型 | 触发时机 | 合并范围 | 目的 |
| --- | --- | --- | --- |
| Cumulative Compaction | 频繁触发 | 合并最近生成的多个小文件 | 快速减少小文件数量，防止积压 |
| Base Compaction | 周期触发 | 将 Cumulative 合并后的文件与历史基表文件合并 | 彻底消除冗余，形成稳定的大文件 |

* 1. **示例1**：INSERT 插入操作（DUPLICATE模型）
		1. INSERT INTO user\_log VALUES
		2. (1, '2023\-10\-01', 'Beijing', 20\),
		3. (2, '2023\-10\-01', 'Shanghai', 25\),
		4. (3, '2023\-10\-01', 'shenzhen', 21\),
		5. (4, '2023\-10\-01', 'guangzhou', 22\),
		6. (5, '2023\-10\-01', 'chengdu', 23\),
		7. (6, '2023\-10\-01', 'hangzhou', 24\),
		8. (7, '2023\-10\-01', 'chongqin', 25\),
		9. (7, '2023\-10\-01', 'wuhan', 26\),
		10. (5, '2023\-10\-01', 'chengdu', 27\),
		11. (3, '2023\-10\-01', 'Shanghai', 29\);

![](/media/202603/20260331135445398221.png)

* + 1. select \* from user\_log

![](/media/202603/20260331135445406298.png)

* 1. **示例2**：INSERT 插入操作（UNIQUE模型）
		1. insert into user\_info VALUES
		2. (1,'wanger',CURRENT\_DATE),
		3. (2,'zhangsan',CURRENT\_DATE),
		4. (3,'lisi',CURRENT\_DATE),
		5. (4,'wangwu',CURRENT\_DATE),
		6. (5,'zhouliu',CURRENT\_DATE),
		7. (6,'wuqi',CURRENT\_DATE),
		8. (1,'xuda',CURRENT\_DATE),
		9. (2,'wangxiaoer',CURRENT\_DATE),
		10. (3,'lijiu',CURRENT\_DATE);

![](/media/202603/20260331135445415785.png)

* + 1. select \* from user\_info

![](/media/202603/20260331135445424579.png)

* + 1. user\_info表主键为1,2,3 的username前面插入的值'wanger','zhangsan','lisi'分别被后面插入语句值覆盖为'xuda','wangxiaoer','lijiu'
	1. **示例3**：INSERT 插入操作（AGGREGATE模型）
		1. INSERT INTO user\_stats VALUES
		2. (1, '2023\-10\-01', 'Beijing', 1,NOW(),5,5\),
		3. (2, '2023\-11\-01', 'shanghai', 1,NOW(),6,6\),
		4. (3, '2023\-12\-01', 'guangzhou', 1,NOW(),7,7\),
		5. (4, '2023\-01\-01', 'chengdu', 1,NOW(),8,8\),
		6. (1, '2023\-10\-01', 'Beijing', 1,NOW(),9,9\),
		7. (2, '2023\-10\-01', 'wuhan', 1,NOW(),1,1\),
		8. (3, '2023\-10\-01', 'Redwood City', 1,NOW(),2,2\),
		9. (4, '2023\-10\-01', 'chengdu', 1,NOW(),3,3\),
		10. (1, '2023\-10\-01', 'San Jose', 1,NOW(),4,4\),
		11. (2, '2023\-10\-01', 'shanghai', 1,NOW(),11,11\),
		12. (3, '2023\-10\-01', 'Beijing', 1,NOW(),11,11\);

![](/media/202603/20260331135445435437.png)

* + 1. select \* from user\_stats

![](/media/202603/20260331135445444341.png)

* + 1. 以上，只有(1, '2023\-10\-01', 'Beijing', 1,NOW(),5,5\),(1, '2023\-10\-01', 'Beijing', 1,NOW(),9,9\)两条发生聚合生成条目：（1 2023\-10\-01 Beijing 2 2026\-03\-05 15:18:53 9 5）。即user\_id,visit\_date,city三者值皆相同发生聚合（对比GROUP BY user\_id,visit\_date,city）
		2. 再插入，尝试多次发生聚合
		3. INSERT INTO user\_stats VALUES
		4. (1, '2023\-10\-01', 'Beijing', 1,NOW(),1,1\),
		5. (2, '2023\-11\-01', 'shanghai', 1,NOW(),2,2\),
		6. (3, '2023\-12\-01', 'guangzhou', 1,NOW(),8,8\),
		7. (4, '2023\-01\-01', 'chengdu', 1,NOW(),9,9\),
		8. (1, '2023\-10\-01', 'Beijing', 1,NOW(),19,19\),
		9. (2, '2023\-10\-01', 'wuhan', 1,NOW(),14,14\),
		10. (3, '2023\-10\-01', 'Redwood City', 1,NOW(),1,1\),
		11. (4, '2023\-10\-01', 'chengdu', 1,NOW(),2,2\),
		12. (1, '2023\-10\-01', 'San Jose', 1,NOW(),5,5\),
		13. (2, '2023\-10\-01', 'shanghai', 1,NOW(),10,10\),
		14. (3, '2023\-10\-01', 'Beijing', 1,NOW(),13,13\);

![](/media/202603/20260331135445453399.png)

* + 1. select \* from user\_stats

![](/media/202603/20260331135445463201.png)

* + 1. 多次发生聚合
	1. **示例4**：更新操作 UPDATE（必须基于 Unique 模型）
		1. Doris 的 UPDATE 实际上是先标记删除旧行，再插入新行。
		2. SELECT \* FROM user\_info; \-\-\-\-user\_info是UNIQUE模型

![](/media/202603/20260331135445472117.png)

* + 1. UPDATE user\_info SET username\='老徐' WHERE user\_id \=1;

![](/media/202603/20260331135445481837.png)

* + 1. SELECT \* FROM user\_info;

![](/media/202603/20260331135445494197.png)

* + 1. SELECT \* FROM user\_log; \-\-\-\-\-user\_log是DUPLICATE模型

![](/media/202603/20260331135445502531.png)

* + 1. UPDATE user\_log SET city\='chengdu' WHERE user\_id \=1;

![](/media/202603/20260331135445513866.png)

* + 1. 执行报错，提示：Only unique table could be updated.
		2. SELECT \* FROM user\_stats; \-\-\-\-\-user\_stats是AGGREGATE模型

![](/media/202603/20260331135445524090.png)

* + 1. UPDATE user\_stats SET city\='Beijing' WHERE user\_id \=1;

![](/media/202603/20260331135445532352.png)

* + 1. 执行报错，提示：Only unique table could be updated.
		2. 在 AGGREGATE/UNIQUE 模型中，**通常不需要使用 UPDATE 语句**。
		3. 如果你想更新 last\_visit\_time，你只需要 INSERT 一条 Key 相同的新数据，Value 列会自动根据 REPLACE 函数覆盖旧值。
	1. **示例5**：删除操作 DELETE
		1. Doris 的 DELETE 提交后，数据并不会立即从磁盘消失，而是被打上标记，在后台 Compaction 时物理删除。
		2. 如果你要删除整个分区，使用 ALTER TABLE t DROP PARTITION p1，这比 DELETE 快得多，且不消耗 CPU。
		3. **UNIQUE模型**
		4. SELECT \* FROM user\_info;

![](/media/202603/20260331135445541893.png)

* + 1. DELETE FROM user\_info WHERE user\_id \= 1;

![](/media/202603/20260331135445552454.png)

* + 1. SELECT \* FROM user\_info;

![](/media/202603/20260331135445560526.png)

* + 1. **DUPLICATE模型**
		2. SELECT \* FROM user\_log;

![](/media/202603/20260331135445569489.png)

* + 1. DELETE FROM user\_log WHERE user\_id \= 1;

![](/media/202603/20260331135445577844.png)

* + 1. SELECT \* FROM user\_log;

![](/media/202603/20260331135445586536.png)

* + 1. **APPREGATE模型**
		2. SELECT \* FROM user\_stats;

![](/media/202603/20260331135445615671.png)

* + 1. DELETE FROM user\_stats WHERE user\_id \= 1;

![](/media/202603/20260331135445624656.png)

* + 1. SELECT \* FROM user\_stats;

![](/media/202603/20260331135445634113.png)

* + 1. 实际上，在APPREGATE模型中，如果你执行 DELETE FROM user\_stats WHERE user\_id \= 1，Doris 会生成一条标记记录，在查询时过滤掉该 Key 的所有聚合结果。
	1. **示例6**：查询操作 SELECT（Doris的最强技）
		1. Doris 的 SELECT 语法与 MySQL 几乎一致，但处理大量数据的能力却强太多太多太多太多...
		2. SELECT \* FROM user\_log;

![](/media/202603/20260331135445643981.png)

* + 1. SELECT
		2. city,
		3. COUNT(DISTINCT user\_id),
		4. SUM(age)
		5. FROM user\_log
		6. GROUP BY city
		7. ORDER BY 2 DESC;

![](/media/202603/20260331135445657740.png)