HTAP（Hybrid Transaction / Analytical Processing，混合事务分析处理）在2014 年被首次提出并赋予明确的定义：即同时支持 OLTP 和 OLAP 场景，需要创新的计算存储框架，在一份数据上保证事务的同时支持实时分析，省去费时的 ETL 过程。随着全球进入数字化时代，数字化技术渗透到各行各业，同时产生海量数据，数据的存储和应用成为企业决策的重要依据，业务场景的变化也掀起了一股 HTAP 浪潮。
那么到底什么才是真正的 HTAP，它对于使用者和开发者到底意味着什么？
了解过 OceanBase 的体系架构的同学应该都知道，OceanBase 自从 2015 年在蚂蚁内部 1.0 之后整体的技术架构就采用了 MPP 的架构，一直保留到了今天。拥有可以理论上无限横向扩展的能力，这也是很多数仓数据库选择的架构类似于 GreenPlum，同时当时蚂蚁内部需要进行蚂蚁核心链路的联机交易 Oracle 替换工作，SQL 特点是典型的点查，点读，小事务，高并发场景，所以我们做了大量的 TP 场景的优化，包括优化器，事务等，满足 Mission Critical 场景的业务诉求，底层采用LSM存储引擎具备完整的 ACID 事务属性。
2019 年开始，在 OceanBase 的 MPP 架构下很自然的我们开始面向复杂查询场景开始在 SQL 引擎执行器部分引入分布式执行框架可以利用MPP框架的计算伸缩性进行 DML,Query 的提速，存储部分引入了数据库编码技术，在数据刷脏的时候按行存储按列编码，在一份数据上实现对业务透明的行列混合存储。同时在 2020 年 OceanBase 的 3.X 上基于现代硬件的 SIMD 指令向量化的能力优化，实现了 TPC-H 打榜第一的成绩。
相比于纯 TP 或者纯 AP，HTAP 是 niche market，有真实的业务场景与诉求，最近有个比较火的名词：实时数仓，上游的联机交易采用了MySQL，业务需要实时根据 TP 的落地数据进行 C 端快速反馈，比如实时风控，交易历史明细查询，欺诈监测，千人千面等等，传统的数仓 ETL 链路长，延迟大，很难满足业务快速多变的诉求。
现在流行的解决方案还是把 TP 的数据通过日志解析工具拖出一份到汇聚库，在汇聚库进行负责查询，对于业务需要多份数据且要包装容灾，成本居高不下，这种场景就特别适合 HTAP，减少 IT 投入的同时降低后期运维成本。
HTAP 数据库需要能处理高并发海量写入场景的同时，又能准实时的处理一些复杂查询场景，譬如多表关联，批量导入导出等场景， OceanBase 天生三副本 Paxos 协议实现无损容灾，在实际业务场景需要能识别出联机交易场景的 SQL，与复杂查询场景的 SQL，利用OceanBase的多副本采用Hint的方式进行 SQL 分发减少 TP/AP 的资源争抢，一些对于事务有强一致诉求的场景，可以采用 OceanBase 的 Rrsource Manager 能力，进行 SQL 打标，在主副本上进行资源隔离，确保负责查询对于核心场景的抖动影响。
原本 TP/AP 分开采用 ETL 进行数据传输的架构上，DBA 需要花费大量精力维护链路的稳定性与时效性，切换至 HTAP 数据库后，DBA 无需再花费精力进行链路维护，DBA 从原先的 Database Administrator 切换至Database architect，深入参与到业务的架构设计中，根据业务逻辑识别出最适合的业务架构与 HTAP 数据库的结合。
举个例子携程的 DBA 基于 OceanBase 的开源版本，在深刻理解业务逻辑的基础上，改造了 OBProxy，通过独立部署不同的 proxy 实现业务无需业务代码侵入访问不同的 proxy 实现 TP/AP 的分离，这就是很典型的例子。
集中式的 HTAP 类似 Oracle SQLServer，本身设计就是面临混合负载场景。可以把 HTAP 分为 small htap 或者 big htap，最大的区别还是横向扩展能力，集中式数据库在遇到性能瓶颈的时候主要的解决方案还是 scale up，分布式数据库譬如 OceanBase 采用的是 Scale Out 方式。
集中式架构的 HTAP 和分布式架构的 HTAP 最大的区别是集中数据库的 scale up 是有上限的，譬如 CPU 规格，譬如 IO 的吞吐与 IOPS 能力，所以小型规模业务可能用 Oracle/SQLServer 数据库局够了，如果随着时间的推移数据量越来越大，通过横向扩展提供更多的计算资源与 IO 资源可以很好的满足业务数据量的增长。
