Doris删除之术：五大神技让你的数据管理秀起来

一臻数据

发布于 2024-12-24 16:16:49

16000

代码可运行

运行总次数：0

代码可运行

“作为21世纪的数据工程师,你是否遇到过这样的烦恼:删除了几条数据,查询性能却直线下降;想要重写某个分区的数据,却要忍受服务暂停之痛;CDC同步删除数据时总是步履维艰... 别担心,Apache Doris早已为你准备好了一套数据删除的五大神技。从简单的DELETE语句到优雅的原子替换,从高效的批量删除到灵活的临时分区,总有一款适合你的场景。今天,就让我们一起打开Doris的工具箱,看看这些删除功能如何帮你轻松掌控数据,让数据管理变得优雅而高效。

Doris数据删除功能概述

大数据的世界中,数据删除看似简单,实则暗藏玄机。作为一款高性能的分析型数据库,Apache Doris提供了多种灵活的数据删除方案,让数据管理更加得心应手：

Delete条件精准删除
基于隐藏字段进行批量删除
简单粗暴的TRUNCATE清空
表原子替换瞬切
分区级别的原子替换

DELETE语句,精准定位数据删除

不知道你是否遇到过这样的场景:某个订单被误操作,需要删除对应的数据;或者某些过期数据需要清理,但只想删除特定条件的记录。这时候,DELETE语句就派上用场了。

DELETE语句是Doris提供的最基础也是最灵活的数据删除方式。通过WHERE子句的条件表达式,我们可以精确定位需要删除的数据。

DELETE语句支持单一条件删除:

DELETE FROM orders WHERE order_id = 10086;

也支持多个条件的组合删除:

DELETE FROM orders WHERE create_date < '2024-11-14' 
AND status = 'CANCELLED';

在分区表上,我们可以通过PARTITION关键字指定要操作的分区:

DELETE FROM orders PARTITION(p202312) 
WHERE order_amount < 100;

对于UNIQUE KEY模型的表,Doris还提供了Using子句的删除方式。这种方式允许我们利用其他表的数据作为删除条件:

DELETE FROM orders USING refund_list
WHERE orders.order_id = refund_list.order_id;

DELETE语句虽然灵活,但也有一些使用注意事项:

使用表模型 Aggregate 时，只能指定 Key 列上的条件。
当选定的 Key 列不存在于某个 Rollup 中时，无法进行 Delete。
条件之间只能是“与”的关系。若希望达成“或”的关系，需要将条件分写在两个 DELETE 语句中；
如果为分区表，需要指定分区，如果不指定，Doris 会从条件中推断出分区。两种情况下，Doris 无法从条件中推断出分区：1) 条件中不包含分区列；2) 分区列的 op 为 not in。当分区表未指定分区，或者无法从条件中推断分区的时候，需要设置会话变量 delete_without_partition 为 true，此时 Delete 会应用到所有分区。
delete语句可能会降低执行后一段时间内的查询效率。影响程度取决于语句中指定的删除条件的数量。指定的条件越多，影响越大。

为什么会对查询性能产生影响呢?这是因为DELETE在Doris中是通过记录删除条件来实现的。每次DELETE都会生成一个标记删除的数据版本,查询时需要过滤这些已删除的数据。

这种机制让DELETE操作能够快速完成,但随着删除操作的增多,查询时需要处理的条件也会增加,从而影响查询性能。

那么如何应对这种情况呢?这就要说到Doris提供的其他删除方案了。接下来一起探讨批量删除和TRUNCATE操作...

批量删除:另辟蹊径的Delete实现

前面说到DELETE语句会影响查询性能的问题。那么面对大规模数据删除需求时,有没有更好的方案?答案就是批量删除。

Doris的批量删除别出心裁,它基于导入机制实现,通过一个隐藏字段__DORIS_DELETE_SIGN__来标记数据是否删除。这种设计让批量删除既保持了高性能,又不会像DELETE语句那样影响查询。

以Stream Load为例,我们可以这样执行批量删除:

curl --location-trusted -u root: \
-H "column_separator:," \
-H "columns: id,name,score" \
-H "merge_type: DELETE" \
-T delete_data.csv \
http://doris_host:8030/api/test_db/test_table/_stream_load

数据文件中只需包含要删除记录的Key列值即可。这种方式特别适合从上游系统同步删除操作的场景,比如:

通过CDC工具同步MySQL的删除操作
批量清理过期数据
删除不合格的历史数据

TRUNCATE:一键清空的利器

相比DELETE和批量删除,TRUNCATE则是一个更加简单粗暴的方案 - 直接清空表或分区的所有数据。它的优势在于:

操作原子性,要么全部成功,要么全部失败
不影响查询性能
执行速度快,不受数据量影响
释放存储空间

清空整表数据:

TRUNCATE TABLE orders;

清空指定分区:

TRUNCATE TABLE orders PARTITION(p202312, p202311);

使用TRUNCATE需要注意:

操作不可恢复,需要谨慎使用
执行时表状态必须为NORMAL
可能会导致正在进行的导入任务失败

接下来让我们继续探讨表原子替换和临时分区这两个更高级的数据删除方案...

表原子替换,无缝切换的艺术

表原子替换提供了一种优雅的数据重写方案。它通过一个原子操作,将两张表的数据瞬间切换。这个过程中查询请求不会中断,用户无感知。

基本语法很简单:

ALTER TABLE table1 REPLACE WITH TABLE table2
[PROPERTIES('swap' = 'true')];

其中swap参数很有意思:

当swap=true时,两张表的数据互换
当swap=false时,table2的数据替换table1,然后table2被删除

一个经典应用场景是数据重写:

-- 1.创建新表
CREATE TABLE orders_new LIKE orders;

-- 2.数据重写导入
INSERT INTO orders_new 
SELECT * FROM orders WHERE status != 'INVALID';

-- 3.原子替换
ALTER TABLE orders REPLACE WITH TABLE orders_new;

临时分区,分区级别的原子替换

临时分区则是表原子替换理念在分区级别的延伸。它让我们能够:

创建一个临时分区用于数据重写
数据准备就绪后原子替换正式分区
过程对查询透明,保证数据一致性

使用临时分区的典型场景:

分区数据重写

-- 创建临时分区
ALTER TABLE orders ADD TEMPORARY PARTITION tp_202312
VALUES LESS THAN ('2024-01-01');

-- 数据重写
INSERT INTO orders TEMPORARY PARTITION(tp_202312)
SELECT * FROM orders PARTITION(p202312) WHERE ...;

-- 分区替换
ALTER TABLE orders REPLACE PARTITION (p202312) 
WITH TEMPORARY PARTITION (tp_202312);

修改分桶数

-- 创建新的分桶数的临时分区
ALTER TABLE orders ADD TEMPORARY PARTITION tp_202312
VALUES LESS THAN ('2024-01-01')
DISTRIBUTED BY HASH(order_id) BUCKETS 48;

-- 数据迁移并替换

合并小分区

-- 创建一个大分区的临时分区
ALTER TABLE orders ADD TEMPORARY PARTITION tp_2023
VALUES LESS THAN ('2024-01-01');

-- 导入多个小分区的数据
INSERT INTO orders TEMPORARY PARTITION(tp_2023)
SELECT * FROM orders PARTITION(p202310,p202311,p202312);

-- 替换分区
ALTER TABLE orders REPLACE PARTITION(p202310,p202311,p202312)
WITH TEMPORARY PARTITION(tp_2023);