“

"老王，我们系统的订单状态更新又出问题了！"刚到公司，就听到运维老李焦急的声音。

十万订单并发更新，系统CPU直接飙升到90%，查询响应时间暴增到秒级，客服电话被投诉打爆... 

这样的场景是否似曾相识？数据更新，这个看似平常的操作，却像个调皮的精灵，总在关键时刻给我们制造惊喜。有时它温顺得像只小猫，轻轻一点就能完成；有时却化身为咆哮的猛兽，吞噬着系统资源，让整个数据平台瑟瑟发抖。 

如何驯服这个"数据更新"的野兽？今天，让我们一起揭开高性能数据更新的神秘面纱，看看Doris数据专家们是如何用优雅的设计，解决这个困扰着无数工程师的世纪难题。

Doris让数据实时更新不再是难事

在数据分析场景中，数据的实时性和准确性至关重要。某互联网公司的数据团队负责人小张最近就遇到了一个棘手的问题：广告投放系统每天都会产生海量的数据更新，原有的批处理方案已经无法满足业务对数据实时性的要求。

经过技术选型，小张选择了Apache Doris作为解决方案。Doris提供了丰富的数据更新功能，能够完美应对各种数据更新场景。

Doris提供了两种核心的数据模型来支持不同的更新需求：主键模型和聚合模型。

主键模型针对那些需要保证记录唯一性的场景。小张在处理用户画像数据时就用到了这个模型。用户的标签信息需要随时更新，同时还要保证每个用户只有一条最新记录。

主键模型又提供了两种实现方式：MoW(Merge-on-Write)和MoR(Merge-on-Read)。MoW就像是一个细心的图书管理员，在新书上架时就把重复的旧书清理掉；而MoR则像是一个懒惰的管理员，等到有人来借书时才去整理书架。

聚合模型则适用于需要进行数据累加、平均等操作的场景。在统计广告点击数据时，小张就采用了这个模型。每次有新的点击记录，系统都会自动将其与历史数据进行聚合计算。高性能更新实现

高性能更新实现

性能问题一直是小张最关心的。通过实测发现，MoW方式在查询时性能出色，可以达到MoR方式的5-10倍。这是因为MoW在写入时就完成了数据的合并，读取时无需额外处理。

为了应对不同规模的更新需求，Doris提供了两种更新方式：

1. UPDATE语句适合小规模、临时性的数据修改。
2. 基于导入的批量更新则适合大规模数据的更新。

小张在处理少量用户标签修正时使用UPDATE语句，而在处理每日百万级的广告数据更新时则采用部分列批量更新方式。系统会自动采用UPSERT语义，确保数据的一致性。

如下示例轻松开启 Merge-on-Write 部分列更新：

-- 建表时需要指定如下 property（Doris2.1后默认mow），以开启 Merge-on-Write 实现
enable_unique_key_merge_on_write = true

-- 如果使用的是 Stream Load/Broker Load/Routine Load，在导入时添加如下 header
partial_columns:true
-- 同时在columns中指定要导入的列（必须包含所有 key 列，不然无法更新），后续会推出更灵活的方式

智能并发控制机制

在处理高并发数据更新时，小张遇到了一个新问题：多个业务系统同时对同一批数据进行更新，如何保证数据的准确性？

Doris的并发控制机制完美解决了这个问题。默认情况下，系统不允许对同一张表同时进行多个Update操作，这就像是给数据上了一把安全锁。

更妙的是，Doris还为Unique模型提供了Sequence列机制，通过为每条记录赋予一个序列号，来确保数据更新的顺序。这让小张想到了视频网站的弹幕系统，每条弹幕都有一个时间戳，确保按照正确的顺序显示。

灵活的列更新策略

在实际业务中，小张发现并不是每次都需要更新所有字段。比如用户画像数据，有时候只需要更新用户的某个标签。

Doris从2.0版本开始，在MoW实现中支持了部分列更新能力。这就像是修改Excel表格，可以只更新某个单元格，而不影响其他数据。

聚合模型通过REPLACE_IF_NOT_NULL聚合函数也实现了类似的效果。这种机制特别适合增量更新场景，新数据只会覆盖旧数据中的非空值。

最后，小张的团队在实践中总结出了一套最佳实践（Doris官方对比图表）：

小结

数据更新看似简单，实则暗藏玄机。Doris通过精心设计的更新机制，平衡了性能与易用性，好似一位经验丰富的交通指挥员，让数据流动有序又高效。

有趣的是，在写这篇文章时，我想到了功夫熊猫里那句名言："意外总会发生，我们要做的就是找到应对之道。" Doris的数据更新功能就是应对数据变化的最佳之道。

下期，我们将一起探讨Doris其它更有趣有用有价值的内容，敬请期待！