一笔支付正在处理。系统要放行这笔交易，风控模型得先看看这个账户最近的流水。但如果这些交易数据必须先从事务数据库搬到数据仓库，才能被分析，哪怕只耽搁一小会儿，判断结果的价值也会打折。

混合事务/分析处理（HTAP）就是为了把这两件事拉近。它让分析查询可以直接跑在还在更新的业务数据上，不必等批处理管道把数据搬进另一套分析系统。

打开网易新闻 查看精彩图片

两套负载，两种脾气

OLTP 扛的是高频、小颗粒的事务操作，比如创建订单、处理支付、更新账户，它要保证应用一直跑得动。OLAP 处理的是大数据集上的复杂查询，用来算指标、找模式、回答分析问题。两者天生不一样。

事务查询通常只读写少量完整的行。所以 OLTP 数据库靠行式存储、选择性索引、高效的并发控制，把延迟压在毫秒级，哪怕并发很高也得稳住。分析查询则常常要扫过几百万行、只取其中几列来算指标，于是 OLAP 用列式存储，因为列存压缩更好，大范围扫描和聚合时读的无关数据更少。OLAP 能容忍更长的延迟，用几秒的响应时间换更大的分析范围。

分开优化 OLTP 和 OLAP 本来很合理，但带出一个新问题：数据在两者之间搬运造成的延迟。业务数据通常得先从 OLTP 系统拷出来，进到数据仓库或其他分析库，才能被分析。事务和分析按不同的节奏跑、跑在不同的硬件上、对着不同的数据副本。这种把 OLTP 和 OLAP 分开的传统架构，等于给每个分析答案都内置了延迟。

随着对数据新鲜度的要求变高，数据团队开始自己拼系统来补这个缺口。变更数据捕获、流处理器、云数据仓库、云数据湖、实时查询层，成了今天解耦数据栈的积木。每块积木解决一个具体问题，但每多一跳，就多一份成本、多一份运维负担，也多一个数据一致性可能断掉的地方。

合在一起，不等于跑成一个样

把 OLTP 和 OLAP 拉近，不代表它们必须用同一种方式运行。HTAP 架构的差异，就在于怎么在保住各自负载所需特性的前提下，把两者结合起来。常见的有两条路。

一种是融合引擎，它省掉了同步独立查询引擎的麻烦，但必须防止分析操作干扰对延迟敏感的事务。另一种是组合式架构，它给每个负载更大的优化和隔离自由，但必须协调数据版本，还得让分析这条路径保持足够新鲜。

不管走哪条路，HTAP 的核心难题是同一个：让分析能足够快地拿到业务数据、快到有用，同时不牺牲事务负载的性能和可靠性。

一套 HTAP 架构会同时给事务和分析留出通路，并让业务数据以最小延迟可供分析。具体设计因系统而异，但通常包含事务处理、分析处理、面向不同负载的数据表示，以及一套让这些表示保持同步的机制。

事务这条路径处理应用频繁的读写，比如创建订单、更新账户、记录支付。这类负载通常只碰少量行，要求低延迟、高效并发控制和可靠的事务保证。HTAP 系统常用行式存储引擎、索引、缓存和预写日志来支撑这些操作。

对不少业务分析场景来说，HTAP 能减少甚至免掉 ETL 流程，砍掉团队要维护的数据副本数量，让业务系统和分析系统更接近同一个事实来源。在最集成的设计里，OLTP 和 OLAP 能力住在同一个系统里，而不是两个产品缝在一起。