HTAP 应该是一种需求而不是一款产品

HTAP（Hybrid Transaction and Analytical Process，混合事务和分析处理）自2014年明确提出以后成为了很多数据库厂商努力的方向。其实HATP并不新鲜，早年RDB刚兴起时本来就是用一个数据库同时做事务和分析，但随着数据规模不断变大再直接基于业务库做分析就会影响业务，这时数据仓库出现了，将业务数据导入数据仓库来专门应对分析需求，同时与业务库隔离，这样不仅可以更好地服务分析场景，又不会对业务系统产生影响，这是“合久必分”的阶段。但是由于数据仓库将历史数据与实时数据分开了，有时经常还会采用异构数据库（或大数据平台），如果要分析实时全量数据（T+0）就非常困难了，而T+0又是很多及时性业务必须的，这就造成了“数据仓库之殇”。为了解决这个问题，能不能把AP和TP在一个数据库内同时满足呢？于是HTAP再次登场了，这又到了“分久必合”的阶段。

但我们知道，AP和TP两个场景有显著不同，前者涉及的数据量很大，并且计算逻辑复杂，但并发量往往不大，没有数据一致性要求，甚至经常为了使用方便可以不满足范式；后者恰恰相反，数据量不大且数据处理逻辑简单，但并发量很大，有数据强一致性要求。从功能上讲，TP数据库本来就能执行SQL，也本来就具有一定的AP功能。当初之所以要把TP和AP分开，就是因为巨大数据量时，继续采用偏向TP的技术就不能高效地处理AP的需求（比如AP要求高性能需要使用列存，但TP为了写入更新便利需要使用行存），TP和AP的这些巨大差异就决定了这两个场景不能采用一个技术体系来同时满足，而这件事到现在并没有实质性地改变。

即使如此，还是有一些厂商尝试在同一引擎中同时满足TP和AP的需求，实现上有几种方式。一种是采用多副本的方式，其中某一个副本（可能使用列存）专门用来满足AP的需求；一种是采用行列混合存储，行存和列存