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》再见！