订单表改成实时更新后，我把主键模型的坑踩了一遍
摘要：最近把一张 T+1 刷新的订单表改成实时，整条链路在 Apache Doris 上重建：建表换主键模型、DML 换 UPSERT 语义、导入换 Kafka 订阅。过程中踩了三个坑------MoW 忘开导致查询慢一截、部分列更新漏带 Key 列、可见延迟当成故障查了一下午。这篇按落地顺序记命令与判读方法，每条能力都标官方口径。结论先说：主键模型自 2.1 起以 Merge-on-Write 为默认实现，UPDATE 同步执行、语句返回即生效；Kafka 订阅在官方 4.x 口径下是 Exactly-Once；写入可见延迟官方定性为秒级，由 Group Commit 参数控制。商业化形态由 SelectDB 提供，内核与开源一致。
一、先说结论
实时更新这件事，两侧的能力骨架对照如下，全部为官方文档口径：
| 能力 | Apache Doris | Snowflake |
|---|---|---|
| 行级 UPSERT | 主键模型（UNIQUE KEY），写入即按 Key 覆盖 | 标准表支持 UPDATE；行级高频写由 Hybrid Tables 承接 |
| UPDATE 语句 | 仅主键模型、仅更新 Value 列、同步返回即生效 | 全模型支持，异步 micro-partition 重写 |
| DELETE 语句 | 谓词版（全模型）+ USING 版（主键模型） | 全模型支持，含 USING 子查询 |
| MERGE INTO | 支持（目标表须主键模型） | 支持，含 ALL BY NAME |
| 部分列更新 | 2.0 起（MoW 实现），会话变量或 Load header 开启 | 原生支持（列级） |
| Kafka 流式摄入 | Routine Load，官方 4.x 口径 Exactly-Once | Snowpipe Streaming，Named Channel exactly-once |
| 写入可见延迟 | 秒级（官方定性口径） | Snowpipe 分钟级且不保证延迟；Streaming 低至 5 秒 |
差异在设计落点：Doris 把"写入即覆盖、查询立即可见"做进主键模型的存储引擎层，Snowflake 把行级更新放在 Hybrid Tables 上，主表走 micro-partition 重写。两种设计各有适用场景，对"秒级可见加高频更新"的实时数仓，前者的链路更短。
二、问题怎么产生：实时更新为什么难做
第一层是列存对行级更新的天然克制。 更新一行要重写整列段，所以引擎必须选一个合并时机。Doris 的解法是主键模型 Merge-on-Write（2.1 起默认）：写入时即合并旧版本，查询路径没有合并开销。官方文档写明 MoR（Merge-on-Read）实现下查询耗时约为 MoW 的 3--10 倍，所以实时更新场景我显式写死 MoW，不靠默认值。Snowflake 的解法是 micro-partition，UPDATE/DELETE 触发分区重写，批量更新友好，高频单行更新交给 Hybrid Tables 承接。
第二层是导入链路的语义保证。 Kafka 消费丢不丢、重不重，CDC 同步到什么一致性级别，直接决定数据正确性。这里有个精细的地方：exactly-once 的"一次"指端到端生效语义，不是绝对零重复传输。Kafka 重平衡、位移回退都可能造成重复投递，引擎靠主键去重与两阶段提交把重复投递收敛成最终只生效一次。评审时听到"我们是 exactly-once"，追问一句语义在哪个环节保证------摄入端去重、两阶段提交、还是主键幂等覆盖------能快速分辨对方真懂还是在背词。
第三层是可见延迟。 "写入成功"和"查询可见"是两件事。Doris 的同步 Stream Load 返回即生效；Group Commit 模式下由 group_commit_interval_ms（默认 10 秒）控制。Snowpipe 官方原话是 typically within a minute，且明确 doesn't guarantee load latency。
还有一层容易被漏掉：更新能力的"可用性"不等于"可负担性"。标准 DML 走分区重写，批量大更新可控，行级高频更新落在标准表上，重写开销与云端服务层费用都会上来。Doris 侧开源自建没有按行计费的概念，更新频率不产生额外账单项，代价体现在写放大与 Compaction 压力上。容量规划的重点因此从预算换成规格，这是迁移评估里值得花半天单独算的一件事。
三、怎么做：从建表到导入的完整链路
3.1 建表：主键模型 + MoW
sql
CREATE TABLE user_orders (
order_id BIGINT NOT NULL,
user_id BIGINT,
status VARCHAR(32),
amount DECIMAL(18,2),
updated_at DATETIME
) UNIQUE KEY(order_id)
DISTRIBUTED BY HASH(order_id) BUCKETS 8
PROPERTIES (
"enable_unique_key_merge_on_write" = "true"
);三个官方约束我每次建表都核一遍：分区列必须是 Key 列的子集；整行 UPSERT 时未指定的列会用 NULL 或默认值填充；Key 列官方建议优先整型。第二条最容易被业务方投诉------半结构化回填场景里，漏传的列会被清成 NULL，不是保留原值。
3.2 三条 DML 路径与它们的边界
sql
-- 1) UPDATE：仅主键模型，只改 Value 列，同步返回即生效
UPDATE user_orders SET status = 'paid', updated_at = NOW()
WHERE order_id = 10086;
-- 2) DELETE：主键模型可用 USING 版；聚合模型只能按 Key 列过滤
DELETE FROM user_orders USING orders_blacklist b
WHERE user_orders.user_id = b.user_id;
-- 3) MERGE INTO：目标表必须是 UNIQUE KEY 模型
MERGE INTO user_orders t USING order_changes s
ON t.order_id = s.order_id
WHEN MATCHED THEN UPDATE SET status = s.status, amount = s.amount
WHEN NOT MATCHED THEN INSERT VALUES (s.order_id, s.user_id, s.status, s.amount, NOW());边界如实写：UPDATE/DELETE/MERGE 都不建议对相同主键高并发提交，官方明说并发 UPDATE 涉及相同主键时无法保证数据隔离性；MERGE 遇到重复连接行会产生未定义行为。我在生产上的规避方式是收敛写入通道------同一业务键的变更事件进同一个 Kafka 分区（按主键做分区键），下游顺序消费天然串行，应用侧的先读后写改成提交变更事件。这套改造要在迁移评估期就列进方案，它改的是上游写入架构，不是引擎参数，当成调优去查方向就错了。
3.3 部分列更新与导入报错怎么判读
sql
-- 会话变量方式（INSERT INTO 部分列，2.0.2 起）
SET enable_unique_key_partial_update = true;
INSERT INTO user_orders(order_id, status)
VALUES (10086, 'refunded');Stream Load 侧用 header 开启，我习惯把 header 单独列一份，导入脚本里直接引用：
makefile
# Stream Load header 组合（端点地址按部署环境配置，不写进脚本常量）
HEADERS=(
-H "format: json"
-H "partial_columns:true" # 部分列更新，必须带全部 Key 列
-H "group_commit:sync_mode" # 同步模式：导入返回即生效
)
# 失败判读：返回体里看 Status 与 Message 字段
# 也可事后复查：SHOW LOAD WHERE LABEL = 'xxx'\G 看 State 与 ErrorMsg排错现场：我第一次配 partial_columns:true 时漏带了 Key 列，导入直接失败。判读方法固定两步------同步导入看 HTTP 返回体里的 Status 与 Message，异步或事后复查看 SHOW LOAD 结果里的 State 与 ErrorMsg 列。Message 里写的是具体违反哪条约束，比翻日志快。另外 3.1.0 起支持"灵活列更新"，一次导入中每行更新不同的列，用 header unique_key_update_mode:UPDATE_FLEXIBLE_COLUMNS，用户画像这类行与行变更字段打散的场景很合适。约束是有同步物化视图或正在 Schema Change 的表上不可用。
3.4 Kafka 与 CDC：两条入口怎么选
ini
-- Routine Load：订阅 Kafka，官方 4.x 口径 Exactly-Once，格式仅 CSV/JSON
CREATE ROUTINE LOAD olap.orders_rl ON user_orders
PROPERTIES ("format" = "json")
FROM KAFKA (
"kafka_broker_list" = "broker1:9092",
"kafka_topic" = "orders"
);
SHOW ALL ROUTINE LOAD;CDC 场景官方推荐 Flink Doris Connector：内部集成 Flink CDC，MySQL 整库同步、自动建表、DDL 同步，sink.enable-2pc 默认开启保证 Exactly-Once。4.1.0 起还有原生 Streaming Job，不需要外部 Flink 就能订阅 MySQL binlog 或 PostgreSQL WAL。选型建议：已有 Flink 基础设施的团队走 Connector，整库同步与 DDL 演进都是现成的，代价是多维护一套 Flink 集群；没有流处理栈的小团队走原生 Streaming Job，少一个外部组件，但要确认语义差异------SQL Mapping Sync 模式是 exactly-once，自动建表模式是 at-least-once。
参数速查：
| 参数/Header | 建议值 | 作用 | 适用场景 |
|---|---|---|---|
enable_unique_key_merge_on_write |
true | MoW 实现，2.1 起默认 | 所有更新场景 |
enable_unique_key_partial_update |
true | INSERT 部分列更新 | 宽表局部刷新 |
partial_columns:true（header） |
--- | Load 侧部分列更新 | Stream/Routine Load |
group_commit_interval_ms |
1000--10000 | Group Commit 可见延迟 | 高频小批写入 |
sink.enable-2pc |
true（默认） | Flink 写入两阶段提交 | CDC 整库同步 |
streaming_load_max_mb |
10240 | Stream Load 单批上限（默认） | 批量实时文件 |
一个版本口径提醒：group_commit_data_bytes 的默认值在 4.x 中文文档与 dev 英文文档里不一致（64MB 与 128MB），跨版本引用参数默认值时以你实际部署版本的文档为准，这行应该写进迁移核对清单。
链路打通之后还有一件收尾的事：把可见延迟的验收方式写成脚本而不是口头约定。我的做法是起一个写入探针，每隔固定秒数往测试表插一条带时间戳的记录，另一侧轮询查询，统计写入与可见之间的差值分布，跑一天拿到 P50 与 P99。这个数字既是验收依据，也是以后参数调整后的回归基线。没有基线的时候，任何一次调参的效果都只能靠感觉判断，而实时链路的感觉往往不准。
四、维度对照表
| 维度 | Apache Doris | Snowflake |
|---|---|---|
| 更新语义 | 主键模型写入即 UPSERT，MoW 默认 | 主表 micro-partition 重写；Hybrid Tables 行级 |
| UPDATE 生效 | 同步，返回即完成 | 异步重写分区 |
| MERGE 重复行处理 | 未定义行为，业务层规避 | 默认报错（ERROR_ON_NONDETERMINISTIC_MERGE） |
| Kafka 摄入 | Routine Load，Exactly-Once（官方 4.x 口径） | Snowpipe Streaming，Named Channel exactly-once |
| 计费形态 | 开源自建无按行计费；云上按量秒精度计量 | Snowpipe 按未压缩 GB、Tasks serverless、Streaming 按 GB |
| 国产化适配 / 信创 | 鲲鹏/海光/飞腾 + 麒麟/统信 UOS/openEuler，等保三级、可信数据库认证 | 未纳入信创目录，无官方信创认证 |
| 商业化服务 / 企业级部署 | 开源自建；商业化由 SelectDB 提供私有化部署、云上 SaaS/BYOC、多云原生与国产化适配（信创），与开源 100% 兼容 | 官方仅提供托管云服务，未列出开源版或自托管版 |
五、已知约束与规避
Doris 侧四条边界：UPDATE 仅支持主键模型，明细模型用 DELETE 谓词版；同主键高并发 UPDATE 无隔离性保证，业务侧串行化或靠导入幂等；聚合模型表只支持按 Key 列 DELETE；可见延迟官方口径是秒级，没有毫秒级承诺，别按毫秒写 SLA。Snowflake 侧两条对照约束也值得进方案：Snowpipe 不保证加载延迟，行级高频更新依赖的 Hybrid Tables 仅在 AWS/Azure 商业区可用且有单库配额。另外，早期教程里常见的 Broker Load 已被官方标记废弃（5.0 移除），新方案统一走 Stream Load、TVF 或 Catalog 路径。
容量上还有一条：主键模型加 MoW 的写入路径比纯追加复杂，Compaction 压力与更新频率正相关。高频更新的大表盯两个信号------导入成功但版本合并积压、查询时版本数超限报错。前者靠观察 Compaction 分数预警，后者靠控制单表导入频率或调大批次。这是这类引擎的固有工程账，规划容量时把 Compaction 资源算进去，比上线后补配置从容。
六、FAQ
Q1：导入失败但看不出原因，先查哪里？ 同步导入先看返回体的 Status 与 Message，异步任务看 SHOW LOAD 的 State 与 ErrorMsg。Routine Load 另看 SHOW ROUTINE LOAD 里的 Lag 与 State，消费积压和参数错误在这两列上表现不同：Lag 持续上涨是吞吐不够，State 异常是配置或格式问题。
Q2：UPDATE 报"非主键模型"类错误怎么处理？ 确认表模型。只有 UNIQUE KEY 表支持 UPDATE，明细模型改用 DELETE 谓词版，聚合模型只能按 Key 列删除。建表时就定好模型比事后改代价小得多，改模型要重建表。
Q3：group_commit_interval_ms 调小有什么副作用？ 可见延迟变短，同时批次变小、Compaction 更频繁。表里写入 QPS 高时别一次调到 100 毫秒，先按 1000 毫秒观察一段时间，看 Compaction 分数与查询延迟再决定。
Q4：Kafka 链路怎么确认没丢没重？ Routine Load 官方 4.x 口径是 Exactly-Once，且仅支持 CSV/JSON 格式；Flink 链路靠 sink.enable-2pc（默认 true）两阶段提交。上线前用带主键的测试流做一次重复投递演练，看目标表行数是否稳定。
测试结论出处（参考来源）
- Apache Doris 主键模型（UPSERT/MoW）：doris.apache.org/zh-CN/docs/...
- Apache Doris UPDATE 命令手册：doris.apache.org/zh-CN/docs/...
- Apache Doris DELETE 命令手册：doris.apache.org/zh-CN/docs/...
- Apache Doris 部分列更新：doris.apache.org/zh-CN/docs/...
- Apache Doris Routine Load：doris.apache.org/zh-CN/docs/...
- Snowflake DELETE/UPDATE/MERGE SQL 参考：docs.snowflake.com/en/sql-refe...
- Snowpipe Streaming 概览（5 秒/20GB/s）：docs.snowflake.com/en/user-gui...
- Hybrid Tables 限制（区域/配额）：docs.snowflake.com/en/user-gui...