OLTP vs. OLAP：事务型数据库与分析型数据库如何选择

联机事务处理（OLTP）针对当前事务数据（如支付、订单和库存更新）处理高并发、低延迟的读写操作。联机分析处理（OLAP）处理复杂查询，这些查询会跨时间、产品、地点等维度扫描、连接并聚合大量历史数据。当工作负载依赖快速、可靠的数据库事务时，选择 OLTP。当工作负载依赖对当前和历史数据的分析时，选择 OLAP。

随着运营工作负载和分析工作负载日益靠近，OLTP 与 OLAP 的抉择所影响的已不只是报表。人工智能（AI）智能体说明了原因。智能体可能会将会话状态持久化到事务存储中，同时从分析系统查询历史上下文。这种设置使数据新鲜度、数据一致性、查询广度和数据移动都成为架构决策的一部分。

本文从查询模式、数据模型、数据存储和延迟等方面比较 OLTP 与 OLAP 系统，然后展示数据管道、混合处理和湖仓架构如何将它们连接起来，以便数据团队为工作负载选择更合适的方案。

内容提要

• OLTP（联机事务处理）适合针对单条记录的实时事务处理，例如网上银行和电子商务订单；而 OLAP 适合跨大量历史数据的分析查询。
• 分离的事务数据库和分析系统需要提取、转换、加载（ETL）或变更数据捕获（CDC）来保持同步，随着数据新鲜度要求提高，这会增加延迟和管道工作量。
• 在 OLAP 与 OLTP 的抉择中，架构选择应跟随工作负载。OLTP 偏好点写入和即时一致性；OLAP 偏好广泛的历史扫描。混合工作负载也使同步开销和分析延迟成为决策的一部分。

数据处理中 OLAP 与 OLTP 概述

OLAP 和 OLTP 系统通常在不同阶段处理相同的数据。OLTP 系统在业务事件发生时生成业务数据；OLAP 系统则聚合这些数据（通常来自多个 OLTP 数据源），以进行更广泛的分析。

以一笔电子商务订单为例。结账服务必须记录该订单并更新库存，同时不能拖慢面向客户的事务。这项工作属于 OLTP，因为它会更改当前运营记录。

之后，分析师可能会比较不同地区的销售数据，或考察几个季度的购买模式。这些 OLAP 查询会处理大量记录，并按日期或产品等维度对结果进行分组。洞察也可以回流：当 OLAP 系统揭示出某个地区反复出现缺货时，团队可能会更改 OLTP 系统中的补货规则。

传统架构会将这些运营记录移入单独的 OLAP 数据仓库。这种转移如何进行，决定了分析数据的新鲜度和管道的复杂性。大多数组织会并行运行 OLTP 和 OLAP，因此实际问题在于两者如何连接。

什么是联机事务处理（OLTP）？

联机事务处理（OLTP），有时称为在线事务处理，描述的是为在当前数据上运行大量短小、并发的数据事务而构建的数据处理系统。网上银行、机票预订、电子商务结账和零售库存更新都依赖 OLTP 数据库，因为每笔事务只涉及少量记录，且必须在毫秒内完成。对于需要高并发和严格数据完整性的应用，OLTP 是首选。

OLTP 数据库如何维护数据完整性

OLTP 数据库适用于需要快速完成小规模、频繁变更且不能让数据库处于无效状态的工作负载。一次支付或订单更新可能只涉及少量记录，但每次变更都必须可靠。

OLTP 数据库通过原子性、一致性、隔离性和持久性（ACID）合规来确保数据完整性。原子性可防止事务的一部分在另一部分失败时被提交。一致性使每次变更都符合为数据库定义的规则。隔离性控制多个操作同时访问相同记录时发生的情况，这正是 OLTP 数据库能够在多用户访问下不损坏记录的原因。持久性使已提交的变更即使在故障后也能持久保存。这些保证共同在重并发负载下维护数据完整性和事务完整性。

大多数 OLTP 系统运行在具有规范化表和行式存储的关系数据库上，这两者都适合写入密集型工作负载以及对完整记录的访问。PostgreSQL、MySQL、SQL Server 和 Oracle Database 是用于事务处理的常见关系数据库。OLTP 数据通常以 GB 计量，不过大型生产系统可能会远超这一规模。

在 Databricks 中，Lakebase 是一个完全托管的 Postgres 数据库，旨在支持事务型应用以及湖仓数据。

什么是联机分析处理（OLAP）？

OLAP（联机分析处理）描述的是为大规模分析数据而构建的系统。OLAP 系统优先考虑读操作而非写操作，并运行较少但更复杂的只读查询。财务报告、销售预测、客户行为分析和商业智能都依赖 OLAP，因为它们考察的是数月或数年的历史数据，而不是某一笔当前事务。

多维数据模型与 OLAP 分析

常见的 OLAP 模型将度量与维度分开。度量保存收入或成本等值；维度提供时间、产品或地理等上下文。这些多维数据模型让分析师无需逐一处理单笔事务，就能比较各地区的季度收入。

传统的多维 OLAP 数据库以数据立方体格式存储数据，它将度量按维度组织起来，并可为重复查询预计算聚合数据。现代 OLAP 平台使用非规范化结构和列式存储来执行相同的多维分析，而不是物理数据立方体，这样无需在模型每次变化时重建数据立方体，也能保持快速聚合。

OLAP 还支持数据挖掘、复杂数据分析以及为战略决策提供依据的复杂分析计算。数据分析师和数据科学家依赖它进行复杂分析，因为单个 OLAP 数据库查询可能会连接并汇总数十亿行数据。

Databricks SQL 通过用于查询湖仓数据的 SQL 仓库、仪表板和可复用业务指标来支持这些分析工作负载。Snowflake 是另一个例子，此外还有其他云数据仓库产品和分析引擎。

OLAP 与数据仓库

OLAP 与数据仓库密切相关。数据仓库充当集中式数据存储，从多个事务型数据库中收集业务数据，对其进行清理，并组织起来用于分析处理。OLAP 工作负载在数据仓库中运行；OLTP 数据库则是这些数据的来源。

OLTP 与 OLAP 之间的主要区别

OLTP 优化对少量记录的高频事务处理。OLAP 优化支持复杂查询的宽泛读取和聚合。这种分工决定了查询行为、延迟、数据存储和数据管理。

下表总结了 OLTP 与 OLAP 数据库之间的关键差异。

查询模式、延迟和并发

诸如按 ID 获取客户这样的点查找只触及数据库的一小部分，这有助于 OLTP 系统快速返回面向应用的请求。

OLAP 查询可能会先扫描数月的记录，然后再进行分组和聚合。这种更重的执行特征使得秒级或分钟级对许多分析查询来说是可以接受的，而大型批处理作业可能会运行数小时，具体取决于引擎和数据量。

并发也遵循同样的模式。OLTP 系统同时服务许多短暂事务，而分析引擎会为较少但更重的查询投入更多计算资源来处理数据。

数据存储、压缩和数据量

OLTP 系统通常使用行式存储，因为应用通常一次读取或更新一条记录的大部分内容。索引也有助于 OLTP 数据库快速定位单条记录，不过每增加一个索引都会给插入和更新增加工作量。

OLAP 系统通常使用列式存储，因为分析查询通常只需要许多记录中的一部分字段。使用 date、region 和 sales_amount 的收入报表可以跳过无关列，因此随着数据集增长，引擎读取的数据更少。

列式布局还能很好地压缩，因为相似的值放在一起。Apache Parquet 将这种布局与编码和压缩相结合；在 Databricks 上，它为 Delta Lake 的分析读取提供基础。

数据量会放大这种差异，但仅凭规模并不能定义 OLTP 或 OLAP。OLTP 系统关注活跃的运营记录，而 OLAP 平台保留多年的历史数据。在这种规模下，减少扫描数据与存储效率同样重要。

OLTP 和 OLAP 的数据模型

OLTP 倾向于规范化模式，这样一次更新只需在一个地方修改值，而不必维护多份副本。将相关数据拆分到不同表中可减少重复，并使频繁更新更易于管理，不过应用程序在检索相关记录时可能需要使用联接。

OLAP 围绕事实和维度来组织多维数据。星型模式将度量值保存在一个中央事实表中，并链接到客户、产品或日期等维度，从而简化报表查询。

雪花模式将维度模型进一步推进，把维度表拆分为相关的子维度。额外的规范化减少了重复，但查询可能需要更多联接才能获取相同的信息。

OLTP 与 OLAP 系统如何协同工作

独立的 OLTP 和 OLAP 系统需要一条路径，让运营变更能够到达分析系统。提取、转换、加载（ETL）流程将数据从 OLTP 系统传输到 OLAP 系统，并在加载前进行转换。提取、加载、转换（ELT）则先加载，再在目标端进行转换。两者通常都以批处理方式运行，适合可以接受一定分析延迟的工作负载。

变更数据捕获（CDC）更适合更新鲜的分析。它捕获行级变更，而不是反复复制整张表，从而减少数据移动，但管道仍需负责处理故障、模式变更和数据一致性。

混合事务/分析处理（HTAP）在一个系统或紧密集成的平台中同时支持两种工作负载。它可以减少复制，但分析查询仍会与延迟敏感的事务共享资源。

Databricks 的 Lake 事务/分析处理（LTAP）架构采用存储层方法。Lakebase 的存储层在将已提交变更物化到对象存储时，把面向行的 Postgres 数据转码为列式 Parquet，湖仓引擎可以直接读取。这消除了团队原本需要的 CDC 管道，无需再将 Lakebase 事务数据复制到单独的分析系统。

在 OLTP、OLAP 和混合架构之间做选择

当 OLTP 和 OLAP 工作负载都是一等需求时，架构选择取决于新鲜度、工作负载隔离和运维复杂性。

• 两层架构：将 OLTP 和 OLAP 保持分离，两者之间采用批量 ETL。当工作负载划分清晰且报表可以容忍数小时延迟时，这种方式可行。
• 流式架构：保留独立的引擎，但通过 CDC 和流处理持续移动变更。这适合需要秒级到分钟级新鲜度、又不直接查询运营数据库的分析场景，代价是更多的管道工作。
• HTAP 引擎：当分析需要近实时的运营数据，且引擎能够保护事务延迟时，在一个系统中运行两种工作负载。资源争用仍是主要权衡。
• 采用 LTAP 的湖仓：当 OLTP 和 OLAP 需要独立计算，但分析仍需要新鲜的事务数据且无需维护单独的分析副本时，可使用这种方式。Databricks 使用其 LTAP 架构实现这一模式，将事务保留在 Postgres 中，同时由湖仓引擎处理分析。评估这一模式的团队可以探索 Lakebase 进行事务处理，同时让分析留在湖仓上。

运营与迁移注意事项

将 OLTP 和 OLAP 一起运行会产生数据移动之外的操作工作。复制数据必须在两种环境中保持准确并受到治理，同时迁移测试需要反映生产负载。

数据完整性、治理和成本

• 验证复制数据： ETL 或 CDC 管道应在报告依赖这些更新之前捕获缺失或无效的更新。在处理过程中应用数据质量检查，使不良记录不会到达下游消费者。
• 保持治理一致： 复制数据仍然需要访问控制、分类、血缘和审计。Unity Catalog 为在 Databricks 上注册的数据集中管理这些数据管理控制。
• 考虑基础设施成本： 双系统需要为两侧的计算和存储付费，而复制会增加处理和传输开销。查询量、保留期和新鲜度要求会推高这些成本。
• 规划恢复： 事务系统通常需要在不良更改后进行细粒度恢复。Lakebase 支持时间点恢复，可从配置的历史窗口内的任意时刻创建新分支，同时保持原始分支不变。

在迁移前测试工作负载

迁移测试应反映生产流量。测量读写组合和并发性，然后在分析查询运行时跟踪第 99 百分位（p99）事务延迟。对于 OLAP，在写入持续进行时测量查询时长和吞吐量。在 Databricks 上，Lakebase 的查询性能监控和 Databricks SQL 的查询配置文件可以帮助验证这些测量结果。

也要测试集成路径。CDC 原型应在真实流量和故障条件下测量提交到分析的延迟。这可以在生产之前暴露索引、模式或同步瓶颈。

OLTP 与 OLAP 决策清单

将工作负载作为最终筛选条件。当写入和即时一致性占主导时选择 OLTP，当历史扫描占主导时选择 OLAP，当两者都是一等需求时选择混合架构。

下表将这些需求转化为快速决策检查。

如果两列都描述了工作负载，请考虑 CDC、HTAP 或 LTAP 等混合架构，而不是将其强行纳入单一的 OLTP 或 OLAP 系统。

对于 Databricks 工作负载，Lakebase 覆盖 OLTP，Databricks SQL 覆盖分析。分离的系统可以使用 Debezium 等 CDC 工具将变更向下游流式传输。

使用与工作负载相似的基准测试。事务处理性能委员会（TPC）基准测试提供了两个常见参考：TPC-C 用于 OLTP 事务，TPC-H 用于分析型决策支持查询。两者都是参考点，不能替代针对具体应用的测试。

常见问题

OLAP 与 OLTP 的典型用例有哪些？

OLTP 处理会更改当前记录的业务操作，例如支付处理、网上银行、订单管理、航空和酒店预订以及零售库存更新。OLAP 支持对随时间累积的信息进行考察的工作。常见示例包括商业智能仪表板、销售分析、财务预测、客户行为分析，以及跨不同维度比较大型历史数据集的其他查询。

什么是 OLTP 与 OLAP？

OLTP 和 OLAP 描述的是针对不同任务优化的数据库工作负载。在线事务处理针对当前运营数据执行大量小事务，具有低延迟和强一致性要求。在线分析处理则专为扫描、连接和聚合更大数据集的查询而设计，以支持报表、预测和其他形式的分析。

数据仓库是 OLTP 还是 OLAP？

数据仓库是 OLAP 系统。它将来自多个 OLTP 源的数据整合到一个集中式数据存储中，针对分析查询、历史保留和报表进行优化，而非高频写入。

OLTP 和 OLAP 可以协同工作吗？

可以。一种常见架构将 OLTP 和 OLAP 运行在独立系统中，然后通过 ETL 或 CDC 传输事务变更。HTAP 在同一系统内支持两种工作负载类型，而较新的湖仓一体方法将运营数据和分析数据拉得更近，无需依赖传统的双栈模型。正确的集成模式取决于所需的分析新鲜度，以及团队能够支持的管道或工作负载管理开销。

数据库中 OLTP 和 OLAP 有什么区别？

主要区别在于每种数据库优化处理的访问模式。OLTP 数据库倾向于针对当前运营记录进行短事务、频繁更新和聚焦查找。OLAP 数据库则优先考虑跨更大历史数据集的扫描和聚合。这些工作负载模式会影响模式设计、存储布局、并发行为以及每个系统预期的响应时间。