适用范围与阅读目标
本文面向 Apache Doris 3.x 内表的建模评审与运维交接，帮助把部署形态、业务主键和查询口径放到一起检查。既有表应以实际 SHOW CREATE TABLE 和精确补丁版本为准，不能根据新版本默认值推断历史表配置。示例仅供只读检查，库表与日期均须替换；本文尚未在业务环境验证，验证等级保持 PENDING。
先准备三类材料：真实组件清单、订单或事件的生命周期，以及三条代表性查询。明确业务需要原始事件、当前状态还是汇总指标，再选择模型。技术选型记录应写明允许的重复、乱序和修订行为，而不是只记录吞吐量。
FE、BE 与存储边界
在存算一体部署中，FE 负责连接、元数据与查询规划等协调工作，BE 承担数据存储和计算。排障时要区分 FE 的连接或规划压力、BE 的执行压力，以及底层磁盘与网络异常。仅凭 SQL 端口可连接，不能推断整个集群的数据服务健康。
Doris 存算分离仍使用 BE 名称，但增加 Meta Service，并依赖 FoundationDB 管理相应元数据，业务数据使用 S3 或 HDFS 等共享存储。运维清单因此需要包含 MS、FDB 和远端存储，而不仅是 FE、BE。不要把 StarRocks 的 CN 命名直接套入 Doris 资产表。组件差异见 Doris 存算分离部署准备。
三种模型决定保留什么
- Duplicate Key：原始日志与行为事件。 相同 Key 再次写入仍保留重复行，Key 主要参与排序。
- Unique Key：订单当前状态与维表修订。 同一 Key 保留一条有效记录，需要同时定义业务版本规则。
- Aggregate Key：固定维度累计指标。 Value 列按照声明的聚合函数合并，不能随意改变统计口径。
例如同一业务键先后出现金额 30 和 40：Duplicate 可能保留两条事件；Unique 表示状态替换；SUM 聚合表示累计 70。三者没有统一的“正确行数”。若 40 是修订后的总额，把它导入 SUM 列会改变业务含义。模型建表后不能直接互换，通常需要新表重建与数据核对，详见 表设计最佳实践。
核查现有表而不是猜默认值
假设已确认 analytics.orders_current 是待评审的内表：
SELECT VERSION();
SHOW CREATE TABLE analytics.orders_current;
DESC analytics.orders_current;保存完整 DDL，再标出模型、Key 列、分区列、分桶表达式与属性。对于 Unique 表，重点确认 enable_unique_key_merge_on_write 的实际设置，以及是否配置 function_column.sequence_col。返回成功只说明能够读取定义；不能证明数据已经按该定义正确接入。
给每个主键字段补上业务解释。例如 (tenant_id, order_id) 是否才能唯一标识订单，订单编号是否会跨租户复用，分区日期是否随更新变化。缺少租户字段可能发生跨租户覆盖；为了分区而把可变日期放进 Key，又可能把同一订单变成多个键。先解决身份定义，再讨论查询速度。
Unique 的去重与乱序是两件事
Merge-on-Write 在写入阶段处理新旧记录的有效性，降低读取时合并的工作；它并不自动理解“业务最后修改时间”。相同 Key 的并发或乱序输入，需要独立的版本规则。Doris 的 Sequence 列允许由业务指定比较值，使较大版本能够替换较小版本；该机制适用于 Unique 模型，见 主键模型的更新并发控制。
评审时用两个虚拟输入解释预期：订单 90001 的版本 12 是已支付，迟到的版本 11 是待支付。启用且正确映射 Sequence 后，版本 11 不应覆盖 12。版本相等但内容不同仍需要上游解决冲突，不能把毫秒时间戳天然当成全局唯一顺序。删除事件、部分列更新和新键插入还要分别验证，避免把一次整行更新的结果推广到所有写入方式。
分区、分桶与排序各管一层
分区帮助控制日期范围与生命周期；分桶决定分区内数据分布及执行并行度；Key 和排序布局影响数据组织。时间条件准确并不保证分桶均匀，高基数字段也可能由于少数超大租户出现热点。
用已确认存在的日期字段检查一条代表查询的计划：
EXPLAIN
SELECT order_id, status, amount
FROM analytics.orders_current
WHERE order_date >= '2026-09-01'
AND order_date < '2026-09-02'
AND tenant_id = 42
LIMIT 20;检查扫描节点中的 partitions、tablets 和过滤条件。partitions=1/90 只说明计划选中一个分区；它不代表只读取一行，也不证明数据均衡。LIMIT 限制返回数量，不能充当扫描字节预算。字段解释依据 Doris EXPLAIN。
用小样本建立模型验收矩阵
在隔离环境准备明确的事件序列，至少涵盖新键、重复批次、旧版本迟到、同版本冲突、删除以及恢复后的重放。本篇不执行写入；需要由验证负责人保存输入文件、摘要、label 与期望结果。对同一键读取时限定租户和日期：
SELECT tenant_id, order_id, status, amount, source_version
FROM analytics.orders_current
WHERE order_date = '2026-09-01'
AND tenant_id = 42 AND order_id = 90001
LIMIT 10;输出应与事件序列对应，而不是仅检查有无重复。Aggregate 表还需证明聚合前后的金额与次数口径，Duplicate 表则需区分预期重复事件和传输重放。Unique 表的一条结果不能证明历史输入从未丢失。
常见误区与设计取舍
把所有表都改为 Unique 会丢失需要保留的状态历史；把所有字段都放进 Key 又会让任何属性变化都生成新键，失去状态替换的效果。把 REPLACE 看成有业务时间排序也会误判乱序结果。应先保留可重放的原始来源，再构建服务查询的状态表或汇总表。
频繁小批写入会增加版本与合并压力，不能仅通过增加桶数解决。更大的并行度同时带来元数据、文件和调度成本。容量评估需同时包含当前有效数据、历史版本、合并空间和峰值导入，存算分离还应单列缓存容量和远端读取成本。
验收、停止与回退边界
交付物包括版本与模式、表 DDL、业务键契约、代表查询计划、重放样本及预期结果。通过标准是相同输入在约定顺序规则下得到正确结果，查询范围可解释，且更新高峰下仍满足业务新鲜度与资源预算。所有未实测项目标为待验证。
若出现跨租户覆盖、旧事件反写新状态、输入来源无法重放，停止推广新模型。模型迁移应保留旧表和原始事件，先双读对账再切读；新表接收额外写入后，回退需要补齐这些增量，不能只改回表名。继续阅读 Doris 导入事务诊断 与 Doris 查询调优。