为了让更多的数据库从业者理解数据库畛域的最新研究成果，相熟更多行业前沿发展趋势，腾讯云数据库打算举办系列“DB · 洞见”流动，打造数据库技术交流平台，邀请学界及腾讯技术大咖，解读数据库根底技术创新趋势，分享数据库技术创新成绩。
本次为大家带来“DB · 洞见”系列流动第一期的局部内容，由腾讯云数据库专家工程师朱阅岸解读 HTAP 零碎的问题与主义之争，以下是分享实录：
问题与主义之争其实是上世纪初胡适与李大钊之间的一场论战。胡适主张改进，提倡解决一个个问题，也就是少谈些主义，多钻研些问题；而李大钊则主张改革，认为只有解决了这个基本问题，其余的问题能力解决，二人代表着两个截然不同的路线。其实围绕着 HTAP 零碎的演进也存在相似两条路线，一条路线是改进，一个路线是通过改革的形式打造全新的零碎。明天我就为大家分享 HTAP 零碎的技术实现相干路线。
1. HTAP 的定义与挑战
咱们先来解释 HTAP 的定义与挑战是什么。下图是经典的数据处理框架，咱们在外面划分出两种数据库系统：一种是事务型的零碎，这是数据源头产生的中央；另一种是剖析型的零碎，是咱们的数仓。数据会定期从交易型数据库中借助 ETL 的形式流入到数仓. 而后在数据仓库做剖析解决，产生相应的报表和报告。企业的经营决策者可能通过剖析报告和决策报表去察看企业的经营行为，从而察看到将来的发展趋势。这是数据贵重之处的体现之一。不少公司都在数据基础设施上投入人力物力，期待在数据变现上取得更好的回报。
钻研表明，这些样本公司在每 13 美金的投入中就有 1 美金投入到数据分析里，有 74% 的公司想成为一个数据驱动型的公司，如果一个公司采纳更为先进的数据分析伎俩，那它超过竞争对手的可能性将达到两倍。
数据分析具备微小的商业价值。但在目前的数据处理框架中，OLTP 和 OLAP 两类零碎是割裂开的，次要是通过 ETL 把数据从交易型数据库导入到剖析型数据库，而 ETL 的时延比拟大，能够达到数十分钟到几小时，甚至是几天。上图右下角的图片显示，数据的商业价值会随着工夫的流逝而降落。数据产生再通过 ETL 导入到数仓，在数仓里进行剖析，而后做决策，执行相应的动作。在这时，数据的商业价值就会大打折扣。
因而最现实的状况是在数据产生后就能迅速对其进行剖析。为了解决这个问题，HTAP 零碎应运而生，它的初衷就是要突破事务处理和剖析解决的界线，使企业可能通过 HTAP 零碎更好地发现市场反馈，取得更好的翻新。这么先进的数据处理技术，为什么近年来才引起人们的关注呢？我集体认为，这次要得益于古代列存储技术的倒退，HTAP 零碎的呈现才成为了可能。
以前客户用 SQL Server 做查问剖析解决，须要十多个小时以上。在这种技术能力下是无奈达到实现 HTAP 零碎要求的。起初 SQL Server 采纳列存储技术，耗时十几个小时的剖析能够降到几分钟，甚至能够在秒级工夫内把后果运行进去。列存储技术及背地的向量查问引擎的倒退，使得 HTAP 登上了历史舞台。
HTAP 能让数据产生后马上就能够进入剖析场景。但它面临最大的问题是如何把 OLTP 和 OLAP 两类工作负载更好放在一个零碎上运行，毕竟这两类工作负载实质上是互斥的。交易型的事务是短事务，以写为主；剖析型的事务是长事务，以读为主，常常须要做全表扫描，在扫描的根底上做统计、聚合等操作。这种状况下，OLAP 的事务常常须要独占系统资源，使交易型的事务吞吐量降落。有钻研表明，把 OLTP 和 OLAP 放在一个零碎里调度，OLTP 的吞吐量可能会降落到本来的 1 / 3 到 1 /5。所以如何让 OLTP 和 OLAP 在零碎运行的过程中互相烦扰最小，就成为 HTAP 零碎设计的难题。
从过来十多年的倒退来看，次要有两种实现 HTAP 的计划：第一种是改进的形式，在现有业务零碎上延长扩大，打造一个 HTAP 的零碎来满足业务的须要，；第二种是从头开始设计一个具备颠覆性的零碎. 当然第二种形式会产生更多有价值的技术，也会波及到比拟多技术难题，蕴含技术冲破、业务适配等。
从当初来看很难说哪种更好，明天的分享咱们也不答复哪一条路线更好，咱们会在这两条路线上筛选典型的具备显明技术特色的零碎，来和大家分享，同时会在最初给出最近十年来 HTAP 零碎技术的演变过程和发展趋势。
2. HTAP 零碎的架构实际
2.1 HTAP 零碎的类别
总体来看，HTAP 零碎架构的实际能够分成两类：一类是改革，另一类是改进。前者采纳 One size fits all 的策略，用一个大而全的零碎同时满足 OLTP 和 OLAP 的需要，后者采纳 One size doesn’t fit all 模型，将 OLTP 和 OLAP 两种零碎组合起来，通过 CDC 的形式把 OLTP 上产生的数据以增量的形式导入到数仓进行剖析。
第一类下又分为两个子类。第一个子类是单拷贝零碎，在一个零碎里用一种数据格式满足两种业务需要，通常是采纳 PAX 存储。零碎整体来看是采纳行存储，然而当它把数据打包存储到某个页面时转换成列存储的模式。另一种是双拷贝零碎，一个零碎里同时存在行存储和列存储，行存储上的更新会定期导入到列存储里转换成列存储格局。在列存储上进行剖析，行存储上执行更新。这在某种程度上升高了它们的竞争。第二类能够分为共享存储和独立存储两个子类。
四种类型的零碎实现 HTAP 特色时的比拟，能够从两个维度来刻画，一是数据新鲜度，二是工作负载烦扰水平。
One size fits all 策略把 OLTP 和 OLAP 两种工作负载放在一个零碎上，如图 1 左上角，就烦扰水平而言，OLTP 和 OLAP 互相烦扰最强，而单零碎单拷贝形式尤为显著，其次就是单零碎双拷贝的形式。这两种实现形式的毛病是 OLTP/OLAP 的烦扰比拟大会导致事务工作负载的吞吐重大降落，但长处是数据可见度高，因为不须要做数据的同步导入导出或数据转换。
One size doesn’t fit all 即松耦合模型也有两种类别，橙色椭圆代表共享存储下的松耦合零碎，如同目前还没有有商业化的产品，只有 IBM 出了一个 DEMO；另一种是采纳相似 proxy 形式把 TP 与 AP 两种独立零碎组合起来的松耦合零碎。这两类零碎中，OLTP 和 OLAP 别离在两个独立的零碎上进行，能够把烦扰降到最小，但数据须要同步，交易型数据库更新的数据要通过 CDC 的形式同步到剖析型零碎上，数据的提早会比拟大。
系统监控的提早在 20 毫秒，在线游戏、个性化广告举荐、商品价格监控，则是在 100-200 之间。
2.2 单零碎单拷贝之 Hyper
接下来咱们从四类零碎实际中筛选局部代表性的零碎来看 HTAP 技术如何具体实现。首先是 Hyper。Hyper 是很典型的零碎，它本来是德国慕尼黑工业大学的 Thomas Neumann 传授团队开发的原型产品，然而性能与创新性切实太好，起初被美国 tableau 公司收买，从学术型的产品变成了商业化的产品，不管从技术与经验都具备较高的代表性。
Hyper 的查问执行模式很有讲究。OLTP 是串行执行，不须要加锁。这是因典型 OLTP 数据库把大部分工夫都耗费在加锁、缓冲区治理、日志治理上，这些操作耗费了零碎 80% 左右的资源。在 Hyper 中没有这些开销，事务串行执行，去除保护事务隔离性等开销。一个事务串行执行的耗时只有微秒级别，这个是能够承受的。VoltDB 是相似的一个零碎，事务执行同样不须要加锁，串行地执行（通过分片达到并行执行的成果）。OLAP 则通过 fork 产生子过程在事务一致性的拷贝上运行查问。更新时再把相干的数据页拷贝进去，让交易型事务在不同的数据页上进行更新（Copy-on-Write）。
此外通过辨别冷热数据的形式，把数据分成热数据、冷数据和温数据。上图右下角就是通过硬件的形式即 MMU 的内存治理单元去辨别数据的拜访热度。热数据放在失常页面即小页面上，冷数据是压缩存储，放在 4M 的大页面上。这种做法的益处是更新代价比拟小，同时在做 OLAP 查问的时候，在大页面上会有比拟好的性能。
Hyper 的查问引擎也是相当优良的，它利用向量化的查问引擎，用 LLVM 生成可执行的机器码。这个技术十分具备代表性，连驰名的 Spark 也参考了它的代码生成技术。
2.3 单零碎单拷贝之 SAP HANA
HANA 也是采纳单零碎单拷贝实现 HTAP。它不太像一个数据库系统，反而像是一个反对多引擎多工作负载类型的对立数据管理平台。HANA 零碎的分层构造做得很好，总体来看能够分为编译层和执行层，下层又能够分为查问的解析，生成形象语法树 AST，再映射到计算图模型，接着对计算图模型进行物理优化。尔后由分布式执行框架去构建理论的数据流，将具体的物理执行算子散发到特定的引擎执行。因为 HANA 反对多个工作引擎，比方数据仓的查问引擎、文本、图等，它向上提供了针对这些特定引擎的物理算子，比方关系操作算子、图计算的算子等。
执行引擎下又有对立的表模型。它向上提供一个对立的接口，相似于 MySQL 下的 handler 接口，上面的存储引擎负责实现具体的存储，下面的查问执行器只有实现 handler 接口就能够对接到零碎里去。外面的存储分成三级：首先是 L1-delta，对应的是热数据和无压缩的行存储；其次是 L2-delta，对应的是轻量级压缩的列存储，比方字典压缩；最初是 L3-main store，对应的是重度压缩列存储。更新产生在 L1-delta，数据会定量地导入到 Main store 里。Main store 是读敌对的实现形式，满足 AP 类型的查问，而 L1-delta 是写优化的实现。通过这种形式来满足 HTAP 的需要。
它会定期地执行合并操作，把数据定期地合并到 Main store 里。在合并操作的过程中会生成 Main2 和 Delta2，这时读操作就在 Main1、Delta1 和 Delta2 进行。拷贝实现当前 Main1 和 Delta1 最终会合并到 Main2，最初切换过去，在 Main2 上进行读操作，写操作产生在 Delta2。数据加锁的行为只是产生在缓冲区切换阶段。L1-delta 采纳 redo 日志放弃持久性，Main store 采纳影子页技术缩小日志的写入，放弃一致性与持久性。
2.4 单零碎双拷贝之 SQL Server
SQL Server 是一个双拷贝零碎，把数据按行切分成 group，定期转变成列存储。具体来说是，每一百万条数据做一个 Group，进行切分，而后针对每列转换成列存储，叫做 segment。每个列采纳独自的压缩算法，比方有些适宜用字典压缩，有些适宜用数值压缩，因而不同的列采纳不同的压缩算法。转换后的列存储附加额定字典表（如有），存储到 Blob 类型中。里面的 directory 追踪这些 segment 的寄存地位。SQL Server 也针对列存储提供了批量执行的算法，减速剖析操作。
2.5 单零碎双拷贝之 Oracle
Oracle 是另外一个采纳双拷贝形式实现 HTAP 的零碎，每个零碎里针对有须要的表，会同时存在一份行存储和列存储，在列存储上做剖析操作；在行存储上进行更新，定期同步到列存储里。零碎能够灵便指定须要采纳行存与列存的表，也能够零碎运行时更改表个性。Oracle 利用 RAC 集群进行横向拓展。
这里举两个例子，来介绍 Oracle 是如何利用列存储减速分期操作的。如果咱们查找 Outlet 这个商店类型所有的销售额，首先扫描维表，依据“type 把 Outlet 类型的商店 ID 拿到，生成一个 map”，接着在事实表的对于外键列里把商品 ID 拿进去在这个 map 查找，如果找到就能够把 Amount 累加起来。它通过只扫描某些特定的列，生成相干的 map，就能够把要拜访的数据找进去，即把关联操作简化成表扫描操作，晋升性能。
另外一个比较复杂的是要扫描两个维表，生成两个 vectors，在外面再去事实表找相干的外键列，就能够间接定位到相干的 vector，如果符合条件，就分类写到相应的长期表里。长处在于能够把表关联操作转换成表扫描操作，只须要拜访查问中波及到的列。
2.6 松耦合共享存储之 Wildfire
目前还没有商业化的 HTAP 产品采纳松耦合共享存储架构，然而 IBM 开发了一个原型，叫 Wildfire。从技术细节来看，它的零碎分成两类节点：一类是有状态的节点，一类是无状态的节点。有状态的节点处理事务型的申请，无状态的节点解决 OLAP 型的申请。OLAP 型的申请能够容忍肯定的提早。
OLTP 型的数据不会间接写入到共享文件系统里，会写入公有组成的一个集群，依照表分片的模式在这里进行数据的疾速写入，再定期导入到共享文件系统里，而后供剖析型查问去执行。剖析型查问会本人去定制一个引擎，去对接 spark executor。这个引擎是无状态的，能够去定制批改，在数据分析畛域也是比拟强悍的引擎，叫 BLU，是 IBM 自家的剖析执行引擎。总体上看，这个零碎分成两个集群：一个是 OLTP，一个是 OLAP。
国内有局部产品的技术和该架构比拟相似，利用 spark 的能力和生态去做剖析型查问，比方利用 spark 的查问优化器和机器学习能力去构建 OLAP 能力，OLTP 能力则本人构建，这样就把数据和这两套零碎在某种程度上做了肯定的交融，变成 HTAP。
2.7 松耦合独立存储之 F1 Lightning
松耦合独立零碎近几年比拟风行，有两个典型代表，一个是谷歌的 F1 Lightning，另外一个是 IBM 的 IDAA。咱们先来介绍 F1 Lightning。
F1 Lightning 把零碎分成三个模块：OLTP 数据库、Lightning、查问执行引擎。Lightning 通过 Changepump 捕捉 OLTP 数据库的更新，以订阅的形式把数据散发到订阅者。Lightning 外部还开发了一个适配器，将 CDC 的模式转换成外部对立的格局。外部有两级存储：内存存储和磁盘存储。内存存储是以行存储的模式存在，采纳 B -tree 索引，在这里没有转换成列存储，只有在数据写入磁盘时才把行存储转换成列存储。下层查问通过快照的机制读取可见范畴的相干数据。F1 Lightning 将捕捉的日志分成两层存储, 为日志保护零碎范畴的检查点工夫戳以及为适配不同数据库而设计的客户端接口很大水平上借鉴了 Databus。这种实现形式带来的问题是查问提早。从谷歌的测试来看，查问提早在 8 -10 分钟之间。因为采纳 CDC 形式，要把 OLTP 数据转换成 CDC 外部对立的格局，再批量提交，因而提早会比拟大。
2.8 松耦合独立存储之 IDAA
接下来介绍 IBM 的 IDAA。最后 IBM 也开发了相似松耦合的 HTAP 架构。下图中右边是 Db2，左边是他们的 Warehouse，挂载到事务型引擎，事务型引擎将更新定期同步。但 IBM 零碎设计者认为，CDC 计划须要破费大量的工夫和背景常识来保护额定的过程，且提早比拟大。基于这个起因，他们对此进行了改良，通过轻量级的集成同步计划躲避上述问题，将提早缩小 180 倍。
CDC 的计划须要在源端经验 6 个步骤：读取数据，解密；过滤无关的日志，依照 LSN 排序；之后还要对数据进行行列转换；把数据暂存起来，把数据转换成 CDC 对立外部的格局；再批量期待 commit 或 Rollback，发送之前还要把 Rollback 数据去除。这种状况对源端的压力是比拟大的，提早也会比拟大。
IDAA 则倡议把这几个步骤都挪到目标端执行。目标端可能原生地辨认从 Db2 里传输过去的数据，当然这个是比拟定制化的计划，通用性没那么好，但提早可大幅升高，只有原来的 1 /180。当初提早只有 1 - 2 秒左右就能读到最新的数据。
2.9 HTAP 技术倒退一览
这部分咱们来对 HTAP 近 10 年来的倒退脉络做梳理。图中的直线方向示意后者的技术借鉴前驱或者是从该产品演变过去的。
从图上能够看到，HTAP 技术在 2015、2016 年之前次要是以 One size fits all 策略为主，2015、2016 年当前则以松偶合架构为主。这几年如 F1 Lightning、IDAA 等都是采纳松偶合形式来实现 HTAP，甚至 SAP 也是有采纳松偶合的技术计划实现 HTAP。从 One size fits all 的演变趋势来看，大多是从双拷贝转换成单拷贝，从行存储转换成繁多的列存储来应答 OLTP/OLAP 的申请。从原先在磁盘上用列存储，到内存里用行存储，再到当初对立改成列存储。这就是最近 10 年来 HTAP 技术的演变趋势。
3. 云原生对于 HTAP 零碎的启发
这一部分咱们来看看云原生架构对 HTAP 零碎实现是否能带来帮忙。
上面是三个值得思考的问题：首先是云原生架构即存算拆散架构是否为 HTAP 的设计带来便当？其次是存算拆散架构和弹性算力是否缓解资源竞争？因为这两条技术下的零碎，在资源竞争和数据可见度上的体现各有优缺点，并不能说哪种产品的体现最优，都是在数据提早和资源争用上做取舍。此外，云环境下丰盛的计算资源池和存储资源池是否针对不同的计算、不同的业务特色进行划分从而升高用户的老本，这也是值得大家去思考的问题。
总体来看，现实的状况是，在一个云原生架构里，Share storage 和 Query processing 分层，在查问入口处采纳多租户设计，这里执行查问解析和查问的优化，而后把查问的执行推到查问执行层。
查问执行层分为有状态和无状态两种，别离解决与 OLTP 和 OLAP 相干的申请。共享存储层 Share storage 针对工作模式和工作负载采取不同的存储设计策略。在 OLAP 方面能够主打性价比，用对象存储和纠错编码模式降低成本。AWS Redshift 团队的调研也表明，OLAP 型的用户会更加关注老本，所以在 Share storage 里 OLAP 方面能够偏差性价比的衡量。而 OLTP 数据存储则采纳高性能的存储，优化事务提交的要害门路，达到用户最优体验，比如说高性能 Nvme，减速事务的提交速度，而后定期把数据从 OLTP 型存储导入到 OLAP 型的存储。
心愿在不久的将来，能够看到相干厂商或数据库开发者实现这样的计划或技术特色。
4. 总结
总体来看，HTAP 已有的问题是 OLTP 和 OLAP 这两种互斥的属性，如何在一个零碎里共存而烦扰尽可能小，数据可见度提早尽可能短。
目前存在两种架构实际：一种是 One size fits all，用一个数据库系统来满足 OLTP 和 OLAP 多样化工作负载的需要；对系统相干的架构变革，针对两种工作负载的个性做更好的适配优化。另外一种是采纳松偶合的形式，通过 CDC 把两类零碎黏合起来，在下面架构一个相似于 proxy 的货色，为用户呈现出一个零碎的表象，用户感知不到 OLAP 型零碎的存在。这种计划能更好地升高两类工作负载对资源的竞争，然而因为须要跨零碎进行数据同步因而提早较大。而前一种计划尽管资源竞争比拟大，但不须要对数据进行跨零碎同步，因而提早比拟小，数据能见度、新鲜度高，能够满足紧急型工作的需要。
展望未来，咱们认为云原生的弹性算力可能更适宜 HTAP 零碎，在云原生上会诞生更优良的 HTAP 零碎。