ApacheDoris5.0实现CDC能力，支持DETAIL、MIN_DELTA与APPEND_ONLY三种变更读取模式

Apache Doris 5.0 正式引入原生变更数据捕获（CDC）能力，标志着其从传统实时数仓的“终点”角色，转向可作为高性能实时计算中间节点的新定位。这一变化的核心是 Changelog 机制——在数据写入时自动记录每一行的增删改操作，配合三种差异化读取模式（DETAIL、MIN_DELTA、APPEND_ONLY），为下游系统提供灵活、低延迟、高一致性的变更流。

过去，Doris 在典型实时链路中承担的是数据汇聚与查询服务角色：业务数据库经 Flink CDC 或 Stream Load 写入 Doris，再由 Doris 加工为宽表或指标供报表调用，链路至此终止。但随着实时分析需求深化，越来越多企业希望将 Doris 用于更复杂的中间计算场景：例如电商平台将多源商品数据统一合并后，需将最新价格实时同步至搜索引擎；财务系统在 Doris 中完成预算控制汇总后，需将结果推送给风控模块；数据团队则需将加工后的宽表同步至其他业务系统的数据湖。

在 Doris 5.0 之前，这类“Doris → 下游”的变更同步缺乏高效方案：

全量导出比对：延迟高、资源消耗大；
基于 update_time 字段增量拉取：无法感知删除操作；
将相同逻辑复刻到 Flink 重算：维护成本翻倍，且易出现结果不一致。

Doris 5.0 的 Changelog 机制直接在存储层解决上述问题。用户只需在建表时设置 changelog.enable = true，系统即在写入路径中自动捕获变更事件。对于主键表（Unique Key 模型），还可开启 changelog.need_historical_value，使每次更新同时携带旧值，从而完整还原 Flink 变更流中的 -U（撤回旧值）与 +U（插入新值）语义。

如图所示，以订单表为例，在 10:00–10:05 时间窗口内：

订单 1000 由“Shipped”变为“Delivered”；
订单 1001 新建并完成支付；
订单 1002 提交后被删除。

三种读取方式分别适配不同下游需求：

DETAIL 模式：返回全部原始变更事件（含 +I、-U、+U、-D），适用于审计追踪、风控回溯与订单状态流转分析；
MIN_DELTA 模式：合并同一主键的多次变更，仅输出最终净结果（如 1002 的插入与删除抵消后不出现），适合同步搜索索引、客服系统等对中间态无感的场景；
APPEND_ONLY 模式：仅返回新增行（+I），忽略更新与删除，适用于事件日志采集或流式埋点场景。

读取语法简洁统一：SELECT * FROM orders@incr('startTimestamp'='2026-11-11 10:00', 'endTimestamp'='2026-11-11 10:05', 'mode'='DETAIL')，用户可像查询普通表一样获取变更数据。

技术实现上，Doris 面临分布式环境下的三大挑战：如何保证 Changelog 与数据强一致、如何维持跨分片变更的全局时序、如何高效存储与访问高频变更。其解决方案如下：

首先，Changelog 与数据表共存于同一本地磁盘，采用“一对表”结构——每张数据表对应一张 Changlog 表，二者共享同一个导入事务（Import Transaction）。当批量写入发生时，数据与变更日志被原子写入，确保可见性一致。如图2所示，导入批次进入后，系统为每个表生成一份数据文件与一份变更日志文件，两者通过事务锁绑定，只有事务提交后才对查询可见。

其次，时序一致性依赖 Doris 的两阶段提交（2PC）与主 FE（Frontend）全局时间戳分配机制。所有写入请求由 Master FE 统一分配 TSO（Timestamp Oracle），按提交时间顺序组织。各 BE（Backend）节点上的多个表副本虽物理分散，但通过 TSO 排序，确保同一时间窗口内的变更在逻辑上无间隙、无重叠。如图3所示，Table A/p0 与 Table B/p0 的变更在 [10:00, 10:05] 窗口内按 commit-time 严格排序，下游消费时可精确划定切片边界。

在此基础上，Doris 5.0 构建了完整的变更处理生态：

库内加工层：IVM（Incremental View Maintenance）与 Table Stream 支持在 Doris 内部对变更流做关联、聚合与清洗，避免将逻辑外溢至 Flink；
下游对接层：Flink Doris Connector 基于 Changelog API 实现并行、断点续传、Exactly-Once 投递，确保变更可靠送达 Kafka、Hive 或其他目标系统。

实际业务中，某头部电商已基于该能力重构商品主数据链路：上游 ERP、CRM、库存系统各自写入 Doris 商品宽表，Doris 实时合并去重并计算最新价格与库存状态，再通过 MIN_DELTA 模式将净变化同步至 Elasticsearch。相比原方案（Flink 多路 Join + 全量快照比对），端到端延迟从分钟级降至秒级，运维复杂度降低 60%。

另一金融客户则利用 DETAIL 模式构建交易流水审计系统：所有账户余额变更均以完整轨迹留存，支持任意时间点的状态回放与差异比对，满足监管合规要求。

值得注意的是，Changelog 当前仅支持 Duplicate Key 与 Merge-on-Write 类型的主键表，Aggregate Key 和 Unique Key 的 Write-Ahead Log（WAL）模式暂未纳入。官方表示后续版本将扩展至更多模型，并增强压缩率与历史版本追溯能力。

Doris 5.0 的 CDC 能力并非简单复刻 MySQL binlog，而是在分布式列存架构下重新设计的轻量级、高吞吐变更捕获方案。它使 Doris 不再局限于“查得快”，而是真正具备“流得准、算得稳、传得实”的全链路实时处理能力。对于正构建统一实时数据平台的企业而言，这意味着可大幅简化架构、减少冗余计算，并提升数据一致性保障水平。