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 数据库以立方体（cube）格式存储数据，这种格式将度量组织到各个维度中，并可针对重复查询预计算聚合数据。现代 OLAP 平台则使用反规范化结构和列式存储来执行同样的多维分析，而不是物理立方体，从而在模型发生变化时无需重建立方体即可保持聚合速度。

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

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

OLAP 与数据仓库

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

OLTP 与 OLAP 的关键区别

OLTP 针对少量记录上的频繁事务进行优化。OLAP 则针对支持复杂查询的大范围读取和聚合进行优化。这种分工决定了查询行为、延迟、数据存储和数据管理方式。

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

查询模式、延迟和并发性

诸如按 ID 获取客户之类的点查询仅触及数据库的一小块区域，这有助于 OLTP 系统快速返回面向应用程序的请求。

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

并发性也遵循同样的模式。OLTP 系统同时服务大量短暂事务，而分析引擎则将更多计算用于处理较少但更繁重的查询。

数据存储、压缩和数据量

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

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

列式布局还具有良好的压缩效果，因为相似的值放在一起。Apache Parquet 将这种布局与编码和压缩相结合；在 Databricks 上，它作为 Delta Lake 的基础，用于分析读取。

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

OLTP 与 OLAP 的数据模型

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

OLAP 围绕事实和维度来组织多维数据。星型模式将度量保存在与客户、产品或日期等维度相关联的中心事实表中，从而简化报表查询。

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