HTAP（Hybrid Transaction / Analytical Processing，混合事务分析处理）在2014 年被首次提出并赋予明确的定义：即同时支持 OLTP 和 OLAP 场景，需要创新的计算存储框架，在一份数据上保证事务的同时支持实时分析，省去费时的 ETL 过程。随着全球进入数字化时代，数字化技术渗透到各行各业，同时产生海量数据，数据的存储和应用成为企业决策的重要依据，业务场景的变化也掀起了一股 HTAP 浪潮。
那么到底什么才是真正的 HTAP，它对于使用者和开发者到底意味着什么？《对话 ACE》第五期便邀请到 OceanBase 互联网&海外架构师负责人弓子介与 Oracle ACE，云和恩墨产品支持工程师吴伟龙，在直播中两位老师就“HTAP 的真正含义”展开深入探讨，为大家揭开 HTAP 的神秘面纱。
吴伟龙和弓子介两位老师分别从自己的视角出发，对 HTAP 进行了深入探讨，以下为对话实录。以下为对话实录：
📣OceanBase 互联网&海外架构师负责人弓子介
Q：OceanBase 的 HTAP 能力是通过什么样的形式或架构实现的？
A：
了解过 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 打榜第一的成绩。
Q：HTAP的典型优势场景，您认为包含哪几方面？
A：
相比于纯 TP 或者纯 AP，HTAP 是 niche market，有真实的业务场景与诉求，最近有个比较火的名词：实时数仓，上游的联机交易采用了MySQL，业务需要实时根据 TP 的落地数据进行 C 端快速反馈，比如实时风控，交易历史明细查询，欺诈监测，千人千面等等，传统的数仓 ETL 链路长，延迟大，很难满足业务快速多变的诉求。
现在流行的解决方案还是把 TP 的数据通过日志解析工具拖出一份到汇聚库，在汇聚库进行负责查询，对于业务需要多份数据且要包装容灾，成本居高不下，这种场景就特别适合 HTAP，减少 IT 投入的同时降低后期运维成本。
Q：HTAP 的架构体系，如何能更好地在实际业务场景中应用？
A：
HTAP 数据库需要能处理高并发海量写入场景的同时，又能准实时的处理一些复杂查询场景，譬如多表关联，批量导入导出等场景， OceanBase 天生三副本 Paxos 协议实现无损容灾，在实际业务场景需要能识别出联机交易场景的 SQL，与复杂查询场景的 SQL，利用OceanBase的多副本采用Hint的方式进行 SQL 分发减少 TP/AP 的资源争抢，一些对于事务有强一致诉求的场景，可以采用 OceanBase 的 Rrsource Manager 能力，进行 SQL 打标，在主副本上进行资源隔离，确保负责查询对于核心场景的抖动影响。
Q：对于 DBA 和运维人员，面临 HTAP 架构应用上，应注意哪些？
A：
原本 TP/AP 分开采用 ETL 进行数据传输的架构上，DBA 需要花费大量精力维护链路的稳定性与时效性，切换至 HTAP 数据库后，DBA 无需再花费精力进行链路维护，DBA 从原先的 Database Administrator 切换至Database architect，深入参与到业务的架构设计中，根据业务逻辑识别出最适合的业务架构与 HTAP 数据库的结合。
举个例子携程的 DBA 基于 OceanBase 的开源版本，在深刻理解业务逻辑的基础上，改造了 OBProxy，通过独立部署不同的 proxy 实现业务无需业务代码侵入访问不同的 proxy 实现 TP/AP 的分离，这就是很典型的例子。
Q：您认为集中式架构的HTAP和分布式架构的HTAP的核心区别在哪里？
A：
集中式的 HTAP 类似 Oracle SQLServer，本身设计就是面临混合负载场景。可以把 HTAP 分为 small htap 或者 big htap，最大的区别还是横向扩展能力，集中式数据库在遇到性能瓶颈的时候主要的解决方案还是 scale up，分布式数据库譬如 OceanBase 采用的是 Scale Out 方式。
集中式架构的 HTAP 和分布式架构的 HTAP 最大的区别是集中数据库的 scale up 是有上限的，譬如 CPU 规格，譬如 IO 的吞吐与 IOPS 能力，所以小型规模业务可能用 Oracle/SQLServer 数据库局够了，如果随着时间的推移数据量越来越大，通过横向扩展提供更多的计算资源与 IO 资源可以很好的满足业务数据量的增长。
📣云和恩墨产品支持工程师吴伟龙
Q：一份数据下，HTAP 到底能否真正地实现 OLTP 和 OLAP 两者兼得？
A：
在Gartner 2014 年首次提出HTAP（Hybrid Transaction / Analytical Processing，混合事务分析处理）概念中给出明确的定义：即同时支持 OLTP 和 OLAP 场景，需要创新的计算存储框架，在一份数据上保证事务的同时支持实时分析，省去费时的 ETL 过程。HTAP模式确实能够很好地兼顾 OLTP 和 OLAP；但 HTAP 并不代表它是万能的，也不代表一个组织只有一套HTAP数据库。这里面既有技术因素，也有非技术因素。一个组织会有多个不同的业务部门，相关的应用会做拆分，这就导致 OLTP 数据库和 OLAP 数据库的决策部门不同，即使是 OLTP 数据库也会按照业务做拆分。全公司一套系统在大多数公司基本是不太现实的，比较容易现实的做法是每个业务一套 HTAP 数据库。例如交易业务一套 HTAP 数据库，同时支持在线交易实时处理和历史订单的实时分析。
Q：您觉得 HTAP 更多会应用在哪些行业内，对于这些行业选择 HTAP 的业务痛点是什么？
A：
HTAP 由于它本身的特点是既可以应用于事务型数据库场景，也可以应用于分析型数据库场景；特别适用于复杂、多模、时效性高这些应用场景；数据不需要从操作型数据库导入到决策类系统；比如电商，金融行业订单，付款信息需要实时同步到结算库的库存数据进行结算对账，各渠道交易数据统计，精准资损防控，这些信息实际上就需要实现快速的数据同步，传统的 ETL 它无法做到这么快速。
Q：您认为 HTAP 如何才能保持数据一致性？
A：
在数据库中的两个技术概念：“快照隔离级别（Snapshot）”和“多版本并发控制（Multi VersionConcurrency Control，简称MVCC）”。这两种技术的意思是：通过维护数据库中的不同版本号（即多个不同的快照），当数据被修改的时候，可以利用不同的版本号区分出正在被修改的内容和修改之前的内容，以此实现对同一份数据的多个版本做并发访问，避免了经典实现中“锁”机制引发的读写冲突问题。传统的数据库都是这么做的，例如 Oracle通常是以分配 SCN(system change number) 作为版本号。不同的 SCN 代表了数据在不同时间点的“已提交版本（Committed Version）”，由此实现了数据的快照隔离级别。
那么，分布式数据库业界有两种实现方式：
1）利用特殊的硬件设备，如 GPS 和原子钟（Atomic Clock），使多台机器间的系统时钟保持高度一致，误差小到应用完全无法感知的程度。在这种情况下，就可以继续利用本地系统时间戳作为版本号，同时也能满足全局范围内的外部一致性。
那么 Google Spanner 就是典型的 GPS 时钟和原子钟来实现数据的一致性，且支持多种不同的事务。Spanner 中支持三种事务，分别为快照读，只读事务，读写事务。
2）版本号不再依赖各个机器自己的本地系统时钟，所有的数据库事务通过集中式的服务获取全局一致的版本号，由这个服务来保证版本号的单调向前。这样一来，分布式架构下获取版本号的逻辑模型和单点架构下的逻辑模型就一样了，彻底消除了机器之间时钟差异的因素。
那么分布式数据库 OceanBase 在实现全局（跨机器）一致的快照隔离级别和多版本并发控制时会面临分布式架构所带来的技术挑战。为了应对这些挑战，OceanBase 数据库在 2.0 版本中引入了“全局一致性快照”技术。
有了“全局一致性快照”技术之后，OceanBase 数据库便具备了在全局（跨机器）范围内实现“快照隔离级别”和“多版本并发控制”的能力，可以在全局范围内保证“外部一致性”，并在此基础之上实现众多涉及全局数据一致性的功能，比如全局一致性读、全局索引等。
这样一来，和传统单点数据库相比，OceanBase 在保留分布式架构优势的同时，在全局数据一致性上也没有任何降级，应用开发者就可以像使用单点数据库一样使用 OceanBase，完全不必担心机器之间的底层数据一致性问题。可以说，借助“全局一致性快照”技术，OceanBase 数据库完美地实现了分布式架构下的全局数据一致性！
Q：我们知道真正的 HTAP 对于事务和分析能力的要求都很高，但真正实现会有一定难度。那么关于事务和分析，我们首先选择哪个会比较好？
A：
HTAP 正是为满足事务和分析这两种高要求场景而设计的；如果说谈到价值的更大化，我相信 OLTP 场景下选择 HTAP 它会是更好；因为交易数据它是组织中快速变化的高价值数据，这些数据如果通过传统的 ETL 去抽取，一旦出现问题，可能就会影响整个企业的业务，这是我们组织无法承受的。
组织需要的 HTAP 能力它可以不必完全覆盖数据仓库业务，仅仅需要对核心业务需要的在线分析能力做一定的提升就可以了。因此在 HTAP 数据库中需要存储的就是 OLTP 系统本身的数据以及部分分析必须的从外部提取过来的高价值数据。
Q：您认为 HTAP 如何能与云更完美的结合？
A：
现在几乎所有数据库大厂和云服务巨头都在布局 HTAP。“新一代 HTAP + 云”正在成为数据库市场重要的潮流。云数据库不再是以往传统数据库部署、运维、扩展等难题，以云的方式提供服务可以让数据库使用更加简单；另外一个原因是，随着云计算的普及，云上用户群体持续增加，来自云上用户群体的需求反馈无时无刻都在发生，对于数据库产品的进化与迭代至关重要。
Q&A
Q：做备库查询，是不是需要额外新增一份副本？
A：
目前有很多厂商都在做 HTAP 数据库，每家厂商的实现方式并不完全一样。在 TP 是三副本的情况下来做复杂查询，就可能会引入像 ClickHouse 或其他的这种技术栈，再去通过行转列的方式将复杂 SQL 放于这种列存数据库。
站在 OceanBase 的角度来讲，这并不是真正的 HTAP 数据库。不管是面向 TP 还是面向 AP，都是采用的一份数据三份副本，在这样的情况下它不需要新增容灾的成本。
Q：如果不新增副本，那如果出主节点故障因为一个备节点压力大会影响切换吗？
A：
以 OceanBase 为例，举一个最典型的场景，当主集群去做连接交易，两个备副本去做复杂查询进行读写分离；当主集群中 HT 的副本出现故障时，由于 OceanBase 采用的是 Paxos 协议，因此它会在剩下的两个副本里面自动的选出一个升任为新的 leader，这个过程不需要人工干预，并且保障数据的不丢失。
以上为两位老师的精彩分享，大家有什么问题也可以文末留言探讨，我们下一期 OceanBase 《对话 ACE》再见！
相关文章
