OLAP 无需事务？Apache Doris 如何让实时分析兼具事务保障-阿里云开发者社区

引言：Apache Doris 通过内置的轻量级强一致事务机制，解决了实时分析中数据重复与中间状态可见等挑战。支持 READ COMMITTED 隔离级别，通过 Label 机制确保数据不重不丢，并为复杂 ELT 提供原子性保障。Doris 打破了“OLAP 无需事务”的认知，是业界少数能同时实现实时、高性能与强一致性的分析引擎。

传统观念中，事务往往与 OLTP（在线事务处理）系统紧密关联，而 OLAP（在线分析处理）系统更注重查询性能和数据吞吐量。然而，随着企业数字化转型的深入和实时分析需求的爆发，这一观念正在被打破。现代实时分析系统，在追求“快”的同时，如何确保数据的“准”与“稳”，已成为架构设计的核心挑战。

在实际场景中，缺乏事务性保障的分析链路面临严峻的数据一致性挑战，比如：

数据重复及脏读：当 Kafka 等流式数据持续灌入时，出现网络抖动或任务失败后的重试，若无幂等机制保障，极易产生重复数据，污染下游分析结果。
中间状态可见性：在批量数据加载场景中，如果数据正在写入过程中就被查询读取，用户看到的将是不完整的中间状态。这种不一致的情况出现在金融、交易等场景，后果可能是灾难性的。
并发写入冲突：多数据管道同时向同一张表写入时，缺乏隔离机制会造成数据冲突与写入失败，影响整个数据链路的稳定性。
治理难度与成本高：复杂的 ELT 流程涉及多表操作，任一环节失败都可能导致数据仓库处于不一致的中间状态，回滚困难，治理成本高昂。

正是为了应对这些挑战，Apache Doris 将轻量级、强一致的事务能力深度融入其分析引擎，不仅确保了极速的查询体验，更让整个数据流转过程变得准确、完整、可靠。

两种架构下的事务保障机制

为满足多样化部署需求，Apache Doris 针对存算一体与存算分离两种架构，分别设计了不同的事务实现方案。本文将逐一介绍。

1. 存算一体：基于三阶段提交的分布式事务

在存算一体模式下，Doris 采用了经典的分布式事务协议来保障分布式事务的一致性。核心设计如下：

FE 节点作为全局事务的大脑，负责统一调度和管理整个集群的事务状态，FE 往往需要协调多个 Backend（BE）节点的事务操作，确保所有参与者达成一致。

Doris 在 FE 层实现了类似 Paxos 的共识算法。多个 FE 节点通过分布式一致性协议，确保事务决策的正确性和系统的高可用性。即使部分 FE 节点发生故障，系统仍能继续提供事务服务，避免了传统单点协调者的可靠性风险。数据使用多副本存储在 BE 节点，少数 BE 节点的故障也不会影响事务的推进。

2. 三阶段提交流程

在存算一体模式下，Doris 设计并开发了三阶段事务流程，确保分布式环境下的数据一致性：

第一阶段：事务准备（PREPARE）

写入操作首先在 Master FE 节点开启一个事务，此时事务状态处于 PREPARE 状态。事务信息通过 EditLog 在多个 FE 节点之间传递，EditLog 基于 BerkeleyDB Java Edition（BDBJE）实现，采用类似 Paxos 的共识算法确保多 FE 节点间的状态一致性。

第二阶段：数据写入与提交确认（COMMITTED）

数据首先写入到各个数据节点（BE），写入完成后，Master FE 将事务状态修改为 COMMITTED。需要注意的是，这里的 COMMITTED 状态与传统意义上的 commit 语义有所不同，它表示数据已成功写入但尚未对外可见。COMMITTED 状态同样通过 EditLog 在多个 FE 节点间传递。

第三阶段：发布与可见性（VISIBLE）

Master FE 的后台 Publish 任务会将 COMMITTED 状态的事务推进到 VISIBLE 状态。具体流程是向第一阶段写入数据的数据节点（BE）发起 Publish 操作。对于涉及的所有 Tablet，只要有一个副本 Publish 成功，事务就会进入 VISIBLE 状态，此时数据对查询完全可见，整个事务流程完成。

1.2 关键技术要点

状态持久化保障：事务的每个状态变更都会写入 EditLog 确保状态不丢失。EditLog 通过 BDBJE 采用类 Paxos 算法在多个 FE 之间达成一致，但这也引入了 I/O 和网络操作，因此事务频次会受到网络和 I/O 性能的影响。
事务可靠性承诺：一旦事务进入 COMMITTED 状态，就不会失败，这为上层应用提供了强一致性保障。
可见性超时处理：等待 VISIBLE 状态超时时会返回 OK，并标记 "visible later" 消息。用户可以通过以下参数调整超时时间：
- INSERT 操作：session variable insert_visible_timeout_ms
- StreamLoad 操作：be.conf 中 txn_commit_rpc_timeout_ms 的 1/2
高频导入优化：当遇到高频次导入瓶颈时，可以使用 Group Commit 机制来提升整体吞吐量。

2. 存算分离：基于 FoundationDB 的事务方案

在面向云原生的存算分离架构中，Doris 引入了独立的元数据存储服务，默认使用 FoundationDB（FDB）作为底层事务基础设施，提供了更加弹性、更低成本和更强的隔离性。

存算分离模式下事务实现与存算一体不同，技术实现上比存算一体更简单。

2.1元数据事务控制

在存算分离架构中，所有的元数据操作都通过 FoundationDB 的原生事务能力进行管理。FDB 作为分布式键值存储，提供了严格的 ACID 特性，能够原子性地控制元数据的可见性变更。

Doris 在 FDB 的事务基础上构建了上层的业务事务逻辑，利用 FDB 的事务特性保障元数据操作的一致性，在其上实现 Doris 特有的数据导入、查询隔离等业务逻辑。

2.2 事务提交过程

在元数据服务中开启一个事务，事务处于 PREPARE 状态。
向数据节点写入数据，数据节点会将数据写入到对象存储。
如果是 MOW（Merge-On-Write）表，会从元数据服务中申请表锁，计算 delete bitmap。
提交事务，提交成功后，数据对查询完全可见，不存在中间状态。

注意事项：

整个过程中会多次写入元数据服务，因此每次事务涉及 I/O 和网络操作的代价，代价和写入的 tablet 数目成正比，SelectDB 团队正在持续优化以降低 I/O 代价。

对于小规模写入操作，需注意 S3 的 PUT 操作费用成本，建议使用 Group Commit 机制优化性能和成本，SelectDB 团队正在持续优化以降低 S3 请求费用。

作为 Apache Doris 的核心贡献者，SelectDB 团队深度参与了存算分离架构的设计与落地。同时，基于 Doris 内核打造的企业级产品 SelectDB，完全具备 Doris 事务保障的能力，并在此基础上提供面向生产环境的企业级增强特性，让企业在享受极速实时分析的同时，获得金融级的数据一致性保障。

事务保障机制的设计

接下来，我们看看事务保障机制的设计实现。

1. READ COMMITTED 隔离级别

Doris 目前支持的唯一隔离级别是 READ COMMITTED。在此隔离级别下，语句只能看到在该语句开始执行之前已提交的数据。这确保了数据读取的一致性，避免了脏读问题。

具体实现上，Doris 中的数据可见性通过分区级别的 version 控制实现，确保事务的 READ COMMITTED 隔离性。多语句事务的原理与单语句事务类似，涉及的所有元数据操作均为原子性，且数据不会部分可见。

存算一体模式：在数据达到 VISIBLE 状态时，系统会持有表写锁更新事务涉及分区的 version。读取数据时，系统使用读锁获取分区的 version，从而实现 READ COMMITTED 隔离性。
存算分离模式：使用单个 FoundationDB 事务更新分区的 version，从而保证 READ COMMITTED 隔离性。

2. 显式与隐式事务

Doris 支持显式事务和隐式事务两种模式。显式事务需要用户主动启动、提交或回滚事务，而隐式事务则是在执行 SQL 语句时自动开启和提交。这种灵活的设计适应了不同应用场景的需求。

显式事务示例：

BEGIN;
INSERT INTO table1 VALUES (...);
UPDATE table2 SET ...;
COMMIT;

隐式事务：在 Doris 中，除了 Group Commit 外，每个导入语句在开始执行时会开启一个事务，语句执行完毕后自动提交事务，失败时自动回滚。

3. Label 机制确保数据不重不丢

Doris 中的事务或写入操作可以分配一个 Label，这个 Label 通常是用户定义的具有业务逻辑属性的字符串。Label 的主要目的是唯一标识一个事务或导入任务，确保具有相同 Label 的事务或导入只会成功执行一次。

这一机制的核心价值在于：

幂等性保障：重复执行相同 Label 的操作不会产生副作用
精确一次语义：结合上游数据源的至少一次保障，实现端到端的精确一次处理
业务可追溯性：通过 Label 可以清晰追踪每批数据的处理状态

4. 多语句事务与 StreamLoad 2PC

Doris 支持跨多个表的复杂事务操作，允许在一个事务内执行多个 INSERT INTO SELECT、UPDATE、DELETE 语句，满足原子性 ETL 流程的需求。
通过 StreamLoad 的两阶段提交（2PC）接口，完美对接 Apache Flink 等流处理框架，为流式写入提供金融级的可靠性与一致性保障。

# 第一阶段：准备提交
curl -H "two_phase_commit:true" -T data.txt http://fe_host/api/db/table/_stream_load

# 第二阶段：确认提交
curl -X PUT -H "txn_operation:commit" -H "txn_id:18036" http://fe_host/api/db/table/_stream_load_2pc

典型场景：让实时分析既快又准

1. 不重不丢实时事件流

假设你在构建一个实时点击流分析系统，目标是收集用户在网页上的点击事件并进行实时分析。系统需求如下：

数据延迟要求 10s 以内
页面报表每秒钟查询一次最新数据，生成实时用户行为分析报表。

如果没有事务机制，以下问题可能会出现：

网络波动导致一次导入失败后重试，出现重复数据；
某次导入正在进行，报表读到部分数据，出现脏报表；
多个导入任务并发写入同一个分区时互相干扰。

以下为基于 Apache Doris 实现高可靠实时数据流的实践案例，可供参考：

MiniMax 实时日志分析平台 ：人工智能企业 MiniMax 借助 SelectDB 构建了一个高吞吐、低延迟、成本优化、可横向扩展的实时日志分析平台，成功替代了之前性能受限且复杂冗长的 Loki 架构。
A/B 测试场景下的精准数据流：该实践在 A/B 测试中采用了 Apache Flink 的两步聚合策略，以及 Apache Doris 的聚合模型、物化视图和短索引，大幅提升数据计算速度与一致性。为保障端到端的数据完整性，还开发了结合 Doris 幂等写入与 Flink 两阶段提交机制的 Sink-to-Doris 工具，实现高效一致的数据写入流程。
金融实时反欺诈数据仓库：该案例展示了 Apache Doris 构建高性能的反欺诈实时数据仓库，通过其实时分析能力帮助金融机构快速识别风险并及时响应欺诈行为。文章强调，基于 Doris 的方案实现了快速可靠的金融级数据监控与分析支持。

2. 构建实时 ELT 数据处理流程

Apache Doris 的事务机制为复杂的 ELT（Extract, Transform, Load）流程提供了坚实的原子性保障。通过支持跨多表的 INSERT、UPDATE 和 DELETE 操作封装在单个事务中，它确保了数据在处理过程中的强一致性——要么全部成功，要么全部回滚。这种能力尤其适用于对实时性要求极高的场景，例如实时报表生成与实时数仓更新，使得数据在流转和转换时始终保持准确与可靠。

2. 构建实时 ELT 数据处理流程.png

以下真实案例体现了该机制在业务中的实际价值：

某头部支付机构：一个非银行支付服务提供商通过引入 Apache Doris，将数据写入速度提升了 2–5 倍，ELT 性能提升了 3–12 倍，查询执行速度提升了 10–15 倍，从而构建出一个实时、高性能的金融数据仓库体系。
抖音集团：通过以 Apache Doris 为核心的“存储实时数仓”架构，简化了复杂的多流 JOIN，通过秒级调度和 OLAP 引擎使实时数据开发变得如离线 SQL 一样高效，显著降低了开发与运维成本。

小结：实时与强一致兼得

当下，实时分析的核心诉求已从单纯的“快”演进为对准确性、可靠性与可运维性的全面要求。

Apache Doris 凭借内置的轻量级事务机制，为企业提供了坚实的数据一致性基石，不仅能够保证数据在复杂链路中的准确与完整，通过幂等导入杜绝重复，还能简化错误恢复、提升管道稳定性，并完整支持 ELT 多步操作。它彻底打破了“OLAP 无需事务”的固有认知，成为业界少数能同时驾驭实时性、高性能与强一致性的分析引擎。

OLAP 无需事务？Apache Doris 如何让实时分析兼具事务保障