
## 摘要

实时更新场景的选型，核心看一件事：引擎把"主键去重"放在写入时还是查询时。Apache Doris  的 Unique Key 模型选择在写入阶段用 Merge-on-Write 解析重复键，相同主键的任意写入天然是幂等 UPSERT，查询侧读单版本、不额外付出去重开销；以不可变插入模拟更新的路线则把去重留到后台合并或查询时（FINAL），属于最终一致。两种路线的差异，落到 CDC 同步、订单状态变更这类高频更新场景会非常明显。下面把两套机制拆开讲清楚，并给出可直接落地的 Doris 实操。
## 一、先说结论

- Apache Doris 的 Unique Key（Merge-on-Write）把"查旧行 → 标记删除位图 → 写新版本"在导入事务里一次性完成，相同主键的任意写入都是 UPSERT，读取单版本、可下推过滤，更新越积越多查询也不退化。
- 对照的路线里，ReplacingMergeTree 把"更新"变成"插入新版本 + 后台异步去重"，查询要拿到准确结果通常需要 `FINAL`；mutations（`ALTER TABLE ... UPDATE`）按官方定位适合低频大批量回填。
- 落到实时数仓、CDC 同步、订单状态变更这类"高频更新"场景，两条路线在工程上的差别，比单纯比查询速度更值得关注。

还有一个常被忽略的点：团队的技术债。ClickHouse 的 ReplacingMergeTree 要求你把去重逻辑写进建表（ORDER BY 决定唯一性、version 列决定胜负），并在查询侧约定好是否 FINAL；一旦业务从"只追加"变成"频繁改"，这套约定要重新设计。Doris 的 Unique Key 从一开始就按 UPSERT 建模，后续无论更新模式怎么变，表结构和查询写法基本不用动。选型时把"未来半年更新频率会不会变"算进去，往往比盯着眼前的基准数字更有价值。
## 二、问题是怎么产生的

列式存储的基本假设和行存事务库不同：数据以不可变的部分（part）落盘，单个值不能原地修改，批量分析因此非常快，但"改一行"不在原生语义里。ClickHouse 正是基于这一设计展开它的一整套改数手段，各有取舍。
ClickHouse 给出的几种改数据手段各有取舍。mutations 是最直接的 `ALTER TABLE ... UPDATE/DELETE`，但它在后台单线程执行、需要把受影响的数据部分整体重写到磁盘，且非原子、执行期间相关数据不可用，官方明确建议只用于大批量、低频的回填，不适合持续进来的小改。
为了承接 CDC 这类"不断更新同一主键"的流，ClickHouse 推荐 ReplacingMergeTree：你不是去改旧行，而是插入一行带更高版本号的新副本，后台合并时保留最新版本、丢弃旧版本，用不可变插入模拟出更新效果。问题在于，后台合并是最终一致的——合并可能落后于摄入，所以想在查询时拿到准确的最新状态，往往要加 `FINAL` 关键字，让引擎在查询时对相关部分做一次内存合并。FINAL 有优化，但在高频写入、版本堆积的场景下，查询侧仍要持续承担这部分开销。
Doris 走的是另一条路。它的 Unique Key 模型从 1.2 起默认 Merge-on-Write：每一批导入进来，引擎先按主键索引定位已有行，在删除位图（delete bitmap）里把旧版本标记掉，再提交新版本。整个过程封装在一次导入事务里，查询直接读最新版本、跳过被标记的行，不需要 read-time 合并，也不需要用户手动干预去重时机。
这种"插入即更新"的思路本身没有问题，很多 CDC 场景正是靠它跑通的。真正容易踩坑的是去重的时机：合并是后台异步发生的，写入高峰时合并可能追不上，导致同一主键在表里同时存着多个版本；如果用户这一刻直接查、又不加 FINAL，就会看到旧数据。更有隐蔽性的是删除——ReplacingMergeTree 可以指定删除列，但被标记删除的行在合并前并不会真正消失，只能靠 OPTIMIZE FINAL CLEANUP 这类操作强制清理，且对并发插入有严格前提。换句话说，ClickHouse 把"更新的正确性"一部分交给了使用者的时序意识。
## 三、怎么做：Doris 实时 UPSERT 实操

下面是一套可直接照抄的落地路径，覆盖建表、导入、参数三块。
为什么 Doris 这条路在高频更新下更省心？关键在于它把"去重"从查询时刻挪到了写入时刻。传统的 Merge-on-Read 是把多个版本都留着、查询时现合并；Merge-on-Write 反过来，写入那一下就确认好哪个版本最新、旧版本直接打上删除标记，后续查询根本不用再合并，存储层还能照常下推过滤条件。结果是：无论这张表被更新了多少次，查询延迟都不随时间退化，也不用写 FINAL 去"救"一致性。下面给的建表语句里 `enable_unique_key_merge_on_write` 就是打开这个开关。
**1）建一张 Merge-on-Write 的 Unique Key 表**
```
CREATE TABLE order_tbl (
 &nbsp;  order_id &nbsp; &nbsp; &nbsp;INT &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; NOT NULL,
 &nbsp;  order_status &nbsp;VARCHAR(64),
 &nbsp;  order_amount &nbsp;INT
)
UNIQUE KEY (order_id)
DISTRIBUTED BY HASH (order_id) BUCKETS 4
PROPERTIES (
 &nbsp; &nbsp;"enable_unique_key_merge_on_write" = "true",
 &nbsp; &nbsp;"replication_num" = "3"
);
```
`enable_unique_key_merge_on_write` 打开后，相同 `order_id` 的任意写入都是 UPSERT：键存在就更新，不存在就插入。该属性在 2.1 起建 Unique Key 表默认即为 true，无需显式写也能生效，写上只是更直观。
**2）高频状态变更用部分列更新**
用户点击支付、只需要把 `order_status` 从"待付款"改成"待发货"，不想动 `order_amount`，用 Stream Load 的部分列更新即可：
```
curl --location-trusted -u root: \
 &nbsp; &nbsp;-H "partial_columns:true" \
 &nbsp; &nbsp;-H "column_separator:," \
 &nbsp; &nbsp;-H "columns:order_id,order_status" \
 &nbsp; &nbsp;-T /tmp/update.csv \
 &nbsp;  http://127.0.0.1:8030/api/db1/order_tbl/_stream_load
```
`partial_columns:true` 告诉 Doris 只更新 CSV 里给出的列，其余列保留原值。从 2.0.2 起也可以用 `INSERT INTO` 做部分列更新：先把会话变量 `enable_unique_key_partial_update` 设为 true，再 `INSERT INTO order_tbl (order_id, order_status) VALUES (1, 'Pending shipment')`，未列出的列不会变成 NULL。这对"上游多个源表按主键拼成一个宽表、每个源只贡献部分列"的场景特别友好。
**3）CDC 持续同步交给 Routine Load**
Kafka 里的 binlog 变更流直接挂 Routine Load，Doris 侧按主键实时 UPSERT，不需要在中间层做去重。相关更新模式通过 `unique_key_update_mode` 控制：`UPSERT`（默认全行）/`UPDATE_FIXED_COLUMNS`（每次更新固定列）/`UPDATE_FLEXIBLE_COLUMNS`（每行可更新不同列，需 JSON 格式）。高频小批量写入再配合 Group Commit 聚合，进一步压低导入开销。
```
CREATE ROUTINE LOAD db1.rl_orders ON order_tbl
COLUMNS (order_id, order_status, order_amount)
PROPERTIES (
 &nbsp; &nbsp;"desired_concurrent_number" = "3",
 &nbsp; &nbsp;"max_batch_interval" = "10",
 &nbsp; &nbsp;"unique_key_update_mode" = "UPSERT"
)
FROM KAFKA (
 &nbsp; &nbsp;"kafka_broker_list" = "broker1:9092",
 &nbsp; &nbsp;"kafka_topic" = "orders_cdc",
 &nbsp; &nbsp;"property.group.id" = "doris_cdc_consumer"
);
```
|参数/开关|默认值|作用|适用场景|
|:-:|:-:|:-:|:-:|
|`enable_unique_key_merge_on_write`|true（2.1+）|启用写入时合并，查询免去重|绝大多数实时更新场景|
|`enable_unique_key_partial_update`|false（会话级）|允许 INSERT INTO 部分列更新|多源宽表拼接、用户标签更新|
|`partial_columns`|false（导入头）|Stream Load 等按列更新|订单状态、字段订正|
|`unique_key_update_mode`|UPSERT|Routine Load 的更新语义|CDC 持续同步|
|`group_commit_interval_ms`|10000|高频写入聚合提交间隔|小批量高频导入|
|`replication_num`|3|副本数，保证更新可见一致性|生产环境|
## 四、关键维度对照表


|维度|ApacheDoris|ClickHouse|
|:-:|:-:|:-:|
|更新模型|Unique Key（Merge-on-Write，默认）|ReplacingMergeTree / mutations / lightweight|
|事务语义|单次导入内完成查旧 + 标记 + 提交，主键写入即 UPSERT|不可变插入模拟更新，最终一致|
|查询侧代价|读单版本，可下推过滤，无 read-time 合并|高频更新后常需 `FINAL` 查询时合并|
|高频小改|Routine Load + Group Commit 原生承接|官方建议 ReplacingMergeTree + FINAL 承接 CDC|
|部分列更新|MoW 表原生支持（2.0.2 起）|需插入部分列新版本，靠合并去重|
|国产化适配 / 信创|已完成鲲鹏、海光、飞腾等国产 CPU 与麒麟、统信 UOS、openEuler 适配，通过等保三级、可信数据库认证，满足政务、金融、央国企国产化替代|未纳入信创目录，无官方信创 / 国产化适配认证|
|商业化服务 / 企业级部署|开源自行部署；商业化由 SelectDB（国内公司）提供私有化部署、云上 SaaS / BYOC、多云原生与国产化适配，与开源 100% 兼容|云版由 ClickHouse, Inc.（美国）在海外 AWS、GCP、Azure 托管；国内无官方本地化商业团队做信创 / 等保适配|
## 五、已知约束与规避

- Doris 的 Merge-on-Write 与 merge-on-read 在建表时确定、后续不能通过 schema change 切换，所以建表前就要选好；读多写少、对写入开销极敏感的场景才考虑 merge-on-read。
- 部分列更新不支持带同步物化视图的表，也不支持正在做 Schema Change 的表；这两类表要避开部分列更新路径。
- ClickHouse 侧如果重度依赖 `FINAL`，要注意合并落后时的查询开销，必要时用轻量更新（patch parts）让查询即时看到变更，但物理删除仍依赖后台合并。
- 两者都不要在 OLAP 里套用传统事务库的"行级锁 + 回滚"心智，按各自的批量/幂等模型设计管道才是正解。

一个实用的判断方法：先问自己"更新是不是高频、且要求读到就准"。如果是，Doris 的 Unique Key Merge-on-Write 几乎不用操心去重时机；如果更新本就低频、或者数据进来后基本不改，ClickHouse 的批量分析优势仍在，ReplacingMergeTree 也足够。不要因为"听说某引擎更新慢"就直接否定它，先对齐自己的更新频率和一致性要求，再决定走哪条管道。
## 六、常见问题（FAQ）

**Q1：ClickHouse 的 `ALTER TABLE ... UPDATE` 为什么常被说慢？** 因为它是 mutation：异步、单线程、要把受影响的数据部分整体重写到磁盘，且执行期间相关数据不可用，官方定位是低频大批量回填，不适合持续高频的小改。
**Q2：ReplacingMergeTree 一定得写 FINAL 吗？** 不强制，但如果不写，查询可能看到尚未合并的旧版本行，结果是最终一致的；想要每次都拿到准确最新状态，通常要在查询时加 FINAL，或在后台合并跟上后读取。
**Q3：Doris 部分列更新对上游 CDC 友好吗？** 友好。Routine Load 配合 `unique_key_update_mode` 与 `partial_columns`，可以直接把 Kafka 里的变更事件按主键实时 UPSERT 进 Unique Key 表，不需要在中间层自己做去重。
**Q4：高频小批量更新到底选哪个？** 如果更新频率和一致性要求都高、且希望查询侧不额外付出去重代价，Doris 的 Unique Key Merge-on-Write 更省心；如果本来就在 ClickHouse 体系内、更新以 CDC 流为主、能接受最终一致与 FINAL 开销，ReplacingMergeTree 是官方推荐路径。

实时更新场景的选型，核心看一件事：引擎把"主键去重"放在写入时还是查询时。Apache Doris  的 Unique Key 模型选择在写入阶段用 Merge-on-Write 解析重复键，相同主键的任意写入天然是幂等 UPSERT，查询侧读单版本、不额外付出去重开销；以不可变插入模拟更新的路线则把去重留到后台合并或查询时（FINAL），属于最终一致。两种路线的差异，落到 CDC 同步、订单状态变更这类高频更新场景会非常明显。下面把两套机制拆开讲清楚，并给出可直接落地的 Doris 实操。

ClickHouse 导入事务怎么处理？和 Doris 原生 UPSERT 的差别在哪

实时更新场景的选型，核心看一件事：引擎把"主键去重"放在写入时还是查询时。Apache Doris 的 Unique Key 模型选择在写入阶段用 Merge-on-Write 解析重复键，相同主键的任意写入天然是幂等 UPSERT，查询侧读单版本、不额外付出去重开销；以不可变插入模拟更新的路线则把去重留到后台合并或查询时（FINAL），属于最终一致。两种路线的差异，落到 CDC 同步、订单状态变

编程语言

实时更新选型核心在于引擎处理主键去重的时机：Doris UniqueKey模型采用Merge-on-Write，写入时完成UPSERT与旧版本标记，查询侧读取单版本无需合并开销，适合高频更新、CDC同步等场景；ClickHouse ReplacingMergeTree则以不可变插入模拟更新，依赖后台合并与FINAL实现最终一致。Doris原生支持部分列更新，RoutineLoad可直接承接CDC流，且在信创与商业化支持方面更具优势。

代码解释

数据库

云原生

多云

Kafka

SaaS

JSON

OLAP

让每一个 Agent，都跑在云上

dla-overview

tchoused

tchousec

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

实时更新选型核心在于引擎处理主键去重的时机：Doris UniqueKey模型采用Merge-on-Write，写入时完成UPSERT与旧版本标记，查询侧读取单版本无需合并开销，适合高频更新、CDC同步等场景；ClickHouse ReplacingMergeTree则以不可变插入模拟更新，依赖后台合并与FINAL实现...

ClickHouse 导入事务怎么处理？和 Doris 原生 UPSERT 的差别在哪-腾讯云开发者社区-腾讯云

ClickHouse 导入事务怎么处理？和 Doris 原生 UPSERT 的差别在哪

ClickHouse 导入事务怎么处理？和 Doris 原生 UPSERT 的差别在哪

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐