HTAP是什么？技术路线图看懂事务与分析混合负载怎么选

大家好，我是数据库小学妹👋我踩过的坑，你别再踩。

上个月帮一家智能制造客户看架构。订单库是MySQL，报表走数仓，中间挂了一堆同步脚本。车间提了个需求：大屏要实时看产能、盯异常工单，还要顺带算良率趋势。数仓说当天给数，车间说等不了。两边扯到我这里，问得很直接：“能不能一套库，交易照跑，分析也实时？”

这句话我近两年听了太多遍。这篇就把HTAP讲透：它是什么、为什么喊了十年才普及、技术路线怎么分、到底什么时候该上。文章有点长，看完你能自己拿主意。

一、先给定义：HTAP到底是什么

HTAP（Hybrid Transactional/Analytical Processing，混合事务与分析处理），是让OLTP事务与OLAP分析在同一套数据库上运行、共用一份数据底座、不需要ETL搬数据的架构。

翻译成大白话就是：以前一个系统管下单，一个系统管报表，中间靠半夜跑批把数据搬过去；HTAP做的事，是让白天产生的交易数据，下一秒就能被分析查询读到，且全程只有一套系统。

顺着这个思路，得先弄明白一件事：交易和分析，为什么原本要分开。

二、交易和分析，天生是两种脾气的活

OLTP和OLAP长得就不像，放一起对比你感受下。

传统做法是把它们拆成两套系统：OLTP库管生产，OLAP库管分析，中间用ETL同步。这套架构成熟，但痛点也很实在。一是慢，ETL一天跑一次，报表看到的永远是昨天的数据；二是乱，两套库数据口径偶尔对不上，业务和数仓互相甩锅；三是贵，两套硬件、两套监控、两拨人，成本翻着倍走。

HTAP要解决的就是这三件事。但它不是没有代价。

三、为什么喊了十年，HTAP这两年才热起来

很多人以为HTAP是新词。其实Gartner提出这个概念已经超过十年了。它最近才被频繁提起，是因为实现它真的难。回头看，HTAP的演进是被两件事推着走的：内存太贵，分布式太复杂。

第一波，内存计算时代。代表是SAP HANA这类，把数据全塞进内存，靠内存快跑混合负载。快是真快，但内存太贵了。Gartner 2014年提出HTAP时，设想的正是这条路。可内存价格打不下来，这套方案只有预算充足的头部企业用得起。

第二波，分布式原生时代。内存贵的问题解决不了，行业换了个思路：不用内存硬扛，用分布式集群来扛。TiDB、SingleStore这类产品把行存列存揉进一套分布式引擎，用多台机器分担负载。这波让HTAP真正走向生产，但代价是架构复杂，运维门槛不低。

第三波，模块化HTAP时代。分布式还不够省心，行业又往前走了一步：不把OLTP和OLAP硬塞进同一个执行引擎，而是把事务层和分析层“拼”起来，靠底座打通。Snowflake、Google AlloyDB走的是这条路。业内叫它模块化HTAP，本质是承认两套引擎各有所长，用一套统一的存储层把它们串起来。

三波走下来，核心难点一直没变：负载隔离和数据新鲜度之间，太难两全。分析查询又大又重，跑起来会抢交易的资源；可要保证数据新鲜，又不能让两边隔得太远。这俩诉求天生打架，谁做HTAP都得过这关。

四、五种技术路线，一张表看清

理解了难点，再看市面上五花八门的HTAP方案，本质就五条路：

前四种是想把"两套变一套"，最后一种是"承认两套存在，把中间的路修直"。没有哪条路绝对正确，关键看你到底要什么。我给客户做评估时，常把第五条也摆上台面。有些团队缺的根本不是一套新库，就是想让数据实时过去而已。

行列混合存储，为什么是主流

五种路线里，行列混合存储是被最多产品采用的一条。原因不复杂：交易爱行存，分析爱列存，那就都存。数据写一份进引擎，行存管点查更新，列存管大查询，查询优化器根据SQL特征自动选路。用户无感知，两边都爽。

难点在于"一份数据、两种格式"的一致性。写进行存的数据，必须尽快同步到列存，还不能拖垮交易。这里的技术含量，全在同步机制和资源调度上。

五、别被"一套全搞定"忽悠，先看懂三个权衡

我接触过的团队，十个里有八个是冲着"省一套系统"来的。但HTAP不是魔法，它有三组绕不开的权衡，选型前必须想清楚。

权衡一：数据新鲜度和负载隔离，只能各让一步。 要让分析立刻读到最新交易，就得让两条负载靠得近、共享资源，结果是分析大查询可能拖慢交易；要做强隔离保证交易稳，数据同步就得有延迟，新鲜度打折。所谓成熟HTAP，本质是把这个度调到业务能接受。

权衡二：一份数据两种格式，写放大躲不掉。 行存一份、列存一份，写入成本天然比单格式高。对写多读少的系统，这个代价要仔细算。

权衡三：OLTP的语义天花板。 分布式HTAP想同时保证跨节点事务和高效分析，事务能力一般比不过专做OLTP的库。真到银行核心转账那种极苛刻场景，很多架构还是选择拆开。

被问得多了，我自己就一个判断：边界模糊、两头都要实时的，上HTAP划算；一头特别重、另一头等得起的，别硬凑。

六、案例复盘：制造业客户，我为什么这么选

回到开头那个智能制造客户。评估时我列了三种走法。

方案A，上全套分布式HTAP。业务量没到那个规模，团队也只有三个人管库，我怕他们hold不住，先否了。

方案B，维持两套库，只把同步换成日志级CDC。能解决"实时看板"，但系统还是两套，架构没简化。

方案C，也是最后选的：交易主库落在金仓（KingbaseES）上，保证OLTP的稳；实时分析要求高的那几张核心表，交给金仓分布式HTAP数据库软件集群V3的行列混合能力，交易写行存、分析读列存，应用不用改连接，也不用自己写同步。少数重查询继续走原来的数仓。客户正好是国产化改造背景，这条路同时把"信创"和"实时分析"两个KPI都交了。

当时我一度纠结"要不要为了HTAP重构表结构"，后来原厂的技术一句话点醒了我：别一上来就动业务表，先找出"高频写+要被实时读"的那几张核心表，做小范围列存试点，跑通了再扩。 金仓在能源、金融的核心系统里有不少公开落地案例，走的基本都是这个节奏：集中式、分布式不是二选一，而是一套架构按负载选路。这也是它家常说的"集中分布一体"。

项目上线后，车间大屏从"看昨天的数"变成"看现在的数"，同步脚本也拆掉了一大半。回头想，客户要的不是某个炫酷的HTAP名词，是"交易别慢、报表别等、人别太累"。

七、决策框架：五个问题定去留

经常被问"该不该上HTAP"时，我一般不会直接给答案，而是让对方先答以下五个问题。

落到第五问，国产里做HTAP的其实不多，能过国家级安全可靠测评的更少。据中国信息安全测评中心2024年公告，金仓HTAP集群V3和KES V9一起通过了《安全可靠测评》。选型时把这类硬指标放进清单，比听销售讲故事靠谱得多。

八、避坑清单

在这方面我也是踩过不少的坑，总结一下最想叮嘱大家的有这三条：

把"能跑分析SQL"当成HTAP，是我见过最贵的误会。单跑一条聚合，是个库都快。真混合负载是交易和分析并发着打，两种流量一起压，才能看出分析会不会把交易拖垮。厂商演示和榜单都别太当真，让他们在你们自己的数据上跑一遍再说。

第二个坑是手痒，一上来就重构表结构。真不用。先挑几张高频写、又要被实时读的核心表做列存试点，跑通了再扩，代价小得多。我见过有人为了上HTAP把全库表结构重设计了一遍，上线前又全部回滚。

再就是写放大，最容易被忽略，等业务跑起来才发现。我见过一个系统，上线前列存副本没细算，订单高峰期写入毛刺变明显，最后把一批低频表的列存副本撤了才缓过来。写多读少的系统，这笔账一定要上项目前算清楚。

九、决定上不上HTAP前，先看看这三个疑问

HTAP到底能不能替代数据仓库？

不能简单画等号。轻中度的实时分析、运营看板、风控查询，HTAP够用，还能省掉一套系统。但PB级大宽表、复杂建模、跨年历史回溯这类重活，专业数仓仍然更合适。不少团队的终局是"HTAP管实时、数仓管深析"，两套并存、各管一段。

国产数据库真的能做HTAP吗？

能做，但要看硬指标。金仓HTAP集群V3通过了中国信息安全测评中心的安全可靠测评，KES V9这类融合数据库也把OLTP、OLAP、HTAP、时序场景收进一套架构，能源、金融核心系统里也有公开落地。我的建议是把"是否过安可""有没有同行业案例"写进选型表，再拿自己的数据压测一轮。

什么情况千万别上HTAP？

交易要求极致强一致、分析又等得起T+1、团队没人会运维分布式，这几条里只要占了两条，就别硬上了。

写在最后

HTAP这个词被炒了很多年，有人把它当万能药，有人说是噱头。我的看法居中：它不是银弹，但在"交易与分析实时兼得"这个真实需求上，是当下最顺的路。 如果你也在判断要不要上，其实就看三件事：数据要不要实时、团队养不养得起两套系统、分析重不重。想清楚再动，比跟风强。

如果你正好在国产化改造，想顺带解决实时分析，金仓这类融合数据库值得放进候选。它一套架构收下交易、分析和时序，集中分布一体、按负载选路，少养一套系统，自主可控和实时分析两个KPI能一起交。还是那句话，别听我一面之词，拿你们自己的核心表和真实流量跑一轮压测，过了再拍板。

你们项目里遇到过"交易和分析要兼得"的场景吗？最后怎么解的？评论区聊聊，咱们互相避坑。

我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见 👋