什么是 HTAP？混合事务/分析处理简明指南

设想一个处理购买交易的支付系统。在批准交易之前，欺诈模型可能需要根据账户的近期活动对其进行评估。但如果这些交易数据必须先从事务数据库移动到数据仓库进行分析，那么即使是很短的延迟也会使结果变得不那么有用。

混合事务/分析处理（HTAP）将事务处理与分析处理拉得更近，以解决这一问题。HTAP 数据库让你可以在运营数据仍然是最新的时候对其运行分析查询，而无需等待批处理数据管道将其移入单独的分析系统。

在本指南中，你将了解 HTAP 的工作原理、所涉及的架构权衡，以及它在现代数据架构中的定位。你还将看到不同的 HTAP 系统如何处理事务和分析工作负载，HTAP 与湖事务/分析处理（LTAP）相比如何，以及在评估和采用任一方法时需要考虑哪些因素。

TL;DR

• HTAP 将事务处理和分析处理拉得更近，使应用能够对最新的交易数据运行分析。
• 不同的 HTAP 架构在性能、隔离性、数据一致性和新鲜度方面涉及不同的权衡。
• 根据你的工作负载选择架构。LTAP 在事务计算和分析计算之间提供了更大的分离，同时两者操作的是同一份数据。

什么是 HTAP？

HTAP 代表混合事务/分析处理。Gartner 于 2014 年创造了这一术语，用来描述将在线事务处理（OLTP）和在线分析处理（OLAP）整合到同一个集成数据库系统中的架构。Gartner 最初对混合事务/分析处理的构想认为，将两者结合将创造巨大的业务创新机会，因为决策可以基于最新的交易，而不是昨天的提取数据。OLTP 处理大量小型、频繁的事务操作，以维持应用运行，例如创建订单、处理支付或更新账户。OLAP 对大型数据集处理复杂查询，以计算指标、识别模式并回答分析性问题。

HTAP 将这些工作负载拉得更近，使分析查询能够访问当前的运营数据，而不必完全依赖单独的批处理 ETL 管道。对于许多运营分析用例，HTAP 系统可以减少或消除对 ETL 流程的需求，减少团队维护的数据副本数量，并更接近为运营和分析系统提供单一事实来源。在最集成的设计中，OLTP 和 OLAP 能力存在于单个系统中，而不是拼接在一起的两个产品中。

将 OLTP 和 OLAP 工作负载拉得更近，并不意味着它们必须以完全相同的方式运行。因此，HTAP 架构在如何结合 OLTP 和 OLAP 能力、同时保留每种工作负载所需特性方面存在差异。两种常见方法是：

• 融合式 HTAP：通过单个数据库引擎运行事务和分析工作负载。这些工作负载可能使用不同的索引、存储格式或执行路径，但它们共享同一个数据库的很大一部分。
• 组合式 HTAP：在集成架构中使用独立的事务引擎和分析引擎。这些引擎可以共享存储层，或通过复制传播变更，同时针对各自的工作负载保持优化。

融合式引擎避免了同步独立查询引擎的需要，但它必须防止分析操作干扰对延迟敏感的事务。组合式架构为优化和隔离每种工作负载提供了更大的自由度，但它必须协调数据版本，并保持分析路径足够新鲜。

在这两种情况下，HTAP 的核心挑战是相同的：以足够快的速度提供对运营数据的分析访问，使其有用，同时不损害事务工作负载的性能和可靠性。

为什么 OLTP 和 OLAP 会变成独立的系统

OLTP 和 OLAP 具有不同的访问模式。事务查询通常读取或更新少量完整行。因此，OLTP 数据库依赖基于行的存储、选择性索引、高效的并发控制以及可预测的延迟，通常以毫秒为单位衡量。大多数事务数据库都是关系数据库，经过调优以在重并发下仍保持低延迟。

相比之下，分析查询通常会扫描数百万行中的部分列，以计算指标或识别模式。OLAP 数据库使用列式存储，因为列存储在大型扫描和聚合期间可提高压缩率并减少读取的不必要数据量。OLAP 系统可以容忍复杂查询的较长延迟，用数秒的响应时间换取分析更多数据的能力。

因此，分别优化 OLTP 和 OLAP 系统在实践上是合理的，但它引入了一个新问题：它们之间数据移动造成的延迟。运营数据通常必须先从 OLTP 系统复制到数据仓库或其他分析数据库，然后才能进行分析。事务和分析处理按不同的时间表、在不同的硬件上、针对不同的数据副本运行。以这种方式将 OLTP 和 OLAP 系统分离的传统架构，使每个分析答案都内置了延迟。

随着对更新鲜数据的需求增长，数据团队开始组装自己的定制系统来弥合差距。变更数据捕获馈送、流处理器、云数据仓库、云数据湖和实时查询层成为当今解耦数据栈的构建块。每个组件都解决了特定问题，但每增加一跳都会增加成本、运营工作量，以及另一个可能破坏数据一致性的地方。

HTAP 解决了这种延迟，同时保留了针对特定工作负载优化的性能优势。

HTAP 架构如何工作

HTAP 架构为事务和分析工作负载提供路径，同时使运营数据以最小延迟可供分析。具体设计因系统而异，但该架构通常包括事务处理、分析处理、针对工作负载的数据表示，以及使这些表示保持同步的机制，如下所示。

事务处理

事务路径处理频繁的应用读写，例如创建订单、更新账户或记录支付。这些事务型工作负载通常只操作少量行，并且需要低延迟、高效的并发控制以及可靠的事务保证。

HTAP 系统通常使用行式存储引擎、索引、缓存和预写日志，旨在高效且持久地服务这些操作型访问模式。

分析处理

分析路径处理分析型查询，这些查询会扫描、过滤、连接和聚合大量数据。列式表示通常被采用，因为分析型查询往往需要跨多行获取列的子集，而正是它们使得在操作型数据上实现快速 OLAP 查询成为可能。

根据 HTAP 设计的不同，分析处理可能与事务运行在同一个数据库引擎中，也可能运行在独立的分析计算资源上。将计算路径分离可以让每种工作负载使用针对其访问模式优化的执行资源，因此系统可以在不拖慢 OLTP 系统的情况下增加分析能力。许多 HTAP 系统还使用智能查询优化，由优化器决定查询应从行存储、列存储还是两者中读取数据。

存储与数据表示

HTAP 系统可能维护同一数据的多种表示形式。行式存储引擎可以服务事务型访问，而列式存储引擎则支持分析型扫描和聚合。

这些表示形式可能存在于同一个数据库系统中，也可能跨越独立的事务和分析组件。一些架构还将计算与存储解耦，并使用对象存储以及缓存、日志或其他服务。

同步与新鲜度

当事务型和分析型处理使用不同的存储引擎或组件时，已提交的变更需要一条从事务侧到分析侧的路径。系统可以使用变更数据捕获（CDC）、预写日志复制、共享日志或共享存储等机制来传播这些变更。

其结果是形成一个分析视图，能够纳入最近提交的事务，而无需传统的定期将整个数据集提取到独立分析系统的过程。这些变更多快可见取决于架构及其一致性保证。

HTAP 数据库的挑战

将事务型和分析型工作负载拉得更近，会在数据存储和处理方式上引入权衡。这些成本出现在哪里取决于架构，但 HTAP 数据库都面临同一个核心问题：同时针对 OLTP 和 OLAP 工作负载进行优化。有四个常见挑战。

写放大

在频繁事务写入的同时维护分析数据会产生额外工作。由于许多 HTAP 系统以两种格式存储数据，更新可能生成增量，或需要刷新和压缩，从而增加计算、I/O 和存储使用量，即使这些工作不落在事务路径上。

资源争用

当 OLTP 工作负载和 OLAP 工作负载共享资源时，大型分析查询可能将事务延迟从毫秒级推高到秒级。独立计算提供更强的隔离，但你仍需考虑存储、网络和协调服务等共享瓶颈。

一致性与新鲜度

事务处理路径与分析处理路径可能不会以相同的速度推进。你需要决定已提交的更改必须多快可供分析使用，以及工作负载需要什么样的数据一致性保证。更高的新鲜度通常需要两条路径之间更紧密的协调，而每一种 HTAP 架构都是在管理同步与隔离之间的某种张力，而非消除它。

运维复杂性

支持混合工作负载可能意味着要管理多种数据表示、执行路径、资源策略和同步机制。查询优化器还必须在两种存储格式之间选择良好的执行计划。在监控、扩展、故障排查和恢复系统时，你需要考虑到这种复杂性。

评估 HTAP 解决方案：检查清单

在评估 HTAP 解决方案时，应在反映生产环境的条件下同时测试事务处理和分析处理工作负载。衡量在两种工作负载并发运行时，事务延迟、分析性能和数据新鲜度是否仍处于你的要求范围内。

尽可能使用接近生产环境的数据、查询模式、数据量和并发度。纳入突发写入、倾斜数据、流量峰值和高要求的分析查询，以便了解系统在实际将面对的条件下如何表现。

真实世界的 HTAP 数据库与实现

在 TiDB、AlloyDB 和 Databricks Lakebase 等系统中，你可以看到 HTAP 系统分离事务处理和分析处理工作负载的不同方式。每种系统在事务处理、分析处理以及两者之间的数据路径上采取了不同的方法。

TiDB：分离行引擎与列引擎

TiDB 展示了一种组合式 HTAP 架构。2020 年，PingCAP 发表了一篇 VLDB 论文，将 TiDB 描述为基于 Raft 的 HTAP 数据库，其解耦架构为混合工作负载集成了行存储和列存储。事务处理工作负载使用 TiKV，一种基于行的存储引擎，而 TiFlash 维护列式表示以用于分析查询。TiDB 的优化器可以将查询路由到 TiKV、TiFlash 或两者，两条路径运行在独立节点上以实现更好的工作负载隔离。

TiFlash 通过 Raft 日志异步接收副本，但会检查自身是否已达到查询所需的数据版本，以提供快照隔离。在评估这种方法时，要考虑在持续事务写入期间复制延迟如何影响分析延迟和吞吐量。

AlloyDB：一个数据库，兼具列式路径

AlloyDB 采用了更为融合的方案。它通过一个透明的内存列式引擎来运行，加速扫描、连接和聚合等分析操作。该引擎可以在主实例或只读池实例上运行，以实现更高的工作负载隔离。Google 表示，AlloyDB 的分析查询速度比标准 PostgreSQL 快达 100 倍。

在评估这种方法时，请考虑你的工作负载中有多少可以使用列式路径。不受支持的操作或列式引擎中不可用的数据可能会回退到面向行的路径，而频繁更新可能需要刷新列式数据。使用具有代表性的查询和更新模式来测试列式覆盖率和性能。

Lakebase 和 LTAP：在共享数据层之上分离计算

Lakebase 与 LTAP 进一步拉开了事务型与分析型工作负载之间的距离。它并非通过同一个数据库引擎来同时服务两者，而是让它们的计算保持独立，同时通过共享数据层将它们连接起来。Postgres 计算可以保持针对低延迟事务进行优化，而分析计算则处理相同的运营数据，无需将分析工作负载放在主数据库上。

这种分离还允许两侧独立扩展。事务容量可以跟随应用流量，而分析容量可以跟随查询需求，无需让一种工作负载为另一种工作负载预置资源。对于实时读取，分析计算从对象存储中的列式副本读取大部分数据，仅从 Postgres 获取当前日志位置，并从 pageserver 合并任何非常新的更改，以提供事务一致性的视图，而不会将分析工作负载放在主 Postgres 实例上。

现代数据架构中的 HTAP：何时才是正确选择？

HTAP 不止一次被宣传为下一个重大数据库架构。在实践中，当你的分析价值取决于对新鲜运营数据的访问时，它就是一个很好的选择。首先问问你的工作负载能容忍多少延迟。如果数据在从事务系统移动到单独的分析系统时变得不那么有用，那么减少这种延迟可能就足以证明采用 HTAP 架构是合理的。

随着 AI 代理和实时个性化等新兴工作负载需要同时获取当前状态和历史上下文，这个问题变得更加重要。这也是为什么讨论已经从紧耦合的数据仓库转向基于开放格式构建的模块化数据湖，在那里事务型和分析型系统可以共享数据，而不必强制每个工作负载都进入一个引擎。

常见用例包括：

根据你需要的新鲜度和工作负载隔离程度来选择架构。当事务型和分析型工作负载能够安全地共享同一运行环境时，融合式 HTAP 可以很好地发挥作用。当同步仍能使分析数据对你的工作负载保持足够新鲜时，组合式 HTAP 可提供更强的计算隔离。

何时将 OLTP 和 OLAP 分开

当你的分析工作负载能够容忍一定延迟时，将 OLTP 和 OLAP 分开。历史分析、模型训练、高级分析和监管报告通常可以保留在专用的 OLAP 数据库或云数据仓库中，尤其是当你需要通过更强的工作负载隔离来保护事务延迟和可用性时。

还要考虑你现有的架构。如果你的 CDC 或 ETL 数据处理已经满足你对新鲜度、性能、可靠性和成本的要求，那么迁移到 HTAP 可能会带来迁移风险和运维复杂性，而收益却不够充分。当减少数据延迟能够解决特定的应用或业务问题时，HTAP 才最有价值。

HTAP 迁移与采用手册

一旦你验证了 HTAP 架构能够满足你的工作负载要求，就应逐步采用它。在每个阶段设定明确的成功标准，并确保在未达到这些标准时能够回到现有路径。

一个实用的迁移顺序是：

1. 梳理你的工作负载和依赖关系：识别所涉及的应用程序、查询、管道和下游消费者。将事务型和分析型工作负载与那些真正需要两者兼顾的工作负载区分开来。
2. 设定你的护栏：为事务延迟、分析性能、新鲜度、正确性、可用性和成本定义可接受的阈值。提前决定什么情况会导致你暂停或回滚。
3. 从分析读取开始：在可能的情况下，并行运行现有和新的分析路径。在新路径影响应用行为之前，比较结果、新鲜度和性能。
4. 逐步切换流量：分阶段迁移合适的工作负载，同时监控新路径及其对事务性能的影响。
5. 测试故障与恢复：验证当同步落后、组件故障或流量回退到先前路径时会发生什么。在生产环境依赖这些流程之前先对其进行测试。
6. 仅在需要时迁移写入：如果采用 HTAP 会改变你的记录系统，请先验证持久性、模式演进、下游依赖关系和回滚行为。

利用这次迁移来审视你的模式、索引和访问模式。HTAP 可以改变你存储和查询数据的方式，但它无法弥补不适合你工作负载的数据模型。

总结

HTAP 可以缩小事务与分析之间的差距，但正确的架构取决于你的工作负载。从你的应用所需的事务延迟、分析性能、新鲜度、一致性和隔离性出发，然后在具有代表性的混合负载下共同测试这些要求。

如果事务型和分析型计算需要独立扩展，同时又要通过共享数据层保持连接，Databricks Lakebase 为湖仓及其下方的数据湖提供了兼容 Postgres 的事务型基础。探索 Lakebase，了解 Databricks 如何实现 LTAP，并评估它在哪些方面满足你的工作负载需求。

常见问题

什么是 HTAP？

HTAP 代表混合事务/分析处理（Hybrid Transactional/Analytical Processing）。它是一种将在线事务处理（OLTP）和在线分析处理（OLAP）结合在一起的数据库架构，使应用程序能够在运营数据仍然实时时对其进行分析。

什么是 HTAP 数据库？

HTAP 数据库同时支持事务型和分析型工作负载。融合式系统通过单一数据库引擎处理两者，而组合式系统则使用独立的事务型和分析型引擎，通过共享存储、复制或其他同步机制连接。

数据库中的 HTAP 是什么？

在数据库中，HTAP 减少了运营系统与分析系统之间的传统分离。它让分析查询能够访问更新鲜的事务数据，而不必完全依赖先通过单独的批处理 ETL 管道移动这些数据。

OLTP 和 OLAP 有什么区别？

OLTP 数据库使用行式存储和低延迟访问来处理大量小型事务。OLAP 数据库使用列式存储对大型数据集运行复杂查询，接受更长的延迟以换取高效的扫描和聚合。

什么是 LTAP？

LTAP 代表湖事务/分析处理（Lake Transactional/Analytical Processing）。它在湖中的统一存储层上，以单一治理模型同时服务事务型和分析型工作负载，消除了团队传统上为保持独立系统同步而维护的 CDC 和复制管道。这使每个工作负载都能在共同的数据基础上独立优化和扩展。