HTAP（Hybrid Transactional / Analytical Processing）是近些年需要一直受到关注的技术名词，它形容了一个数据库可能同时满足交易以及剖析两种作业。TiDB 4.0 是一个针对 HTAP 进行了特地的设计和架构强化，这次给大家带来一篇 VLDB 2020 HTAP 主题的论文解读，比拟非凡的是这篇论文是 PingCAP 写的，对于 TiDB HTAP 架构。所以这篇解读，是以作者团队（中的一部分）的视角来写的。原文在此，欢送斧正。
说重点
论文整体介绍了一下 TiDB 的架构和设计，对 TiDB 有趣味的同学举荐残缺看下，会对了解架构有很大帮忙。不过既然重点是 HTAP，那么在我看来比拟重要的中央是这三点：
- 实时更新的列存
- Multi-Raft 的复制体系
- 依据业务 SQL 智能抉择行 / 列存储
前面我也会着重说一下这三局部。
先说存储
TP 和 AP 传统来说仰赖不同的存储格局：行存对应 OLTP，列存对应 OLAP。然而这两者的优劣差别在内存中会显得不那么显著，因而 SAP Hana 的作者 Hasso Plattner 提出应用 In-Memory + 列存技术同时解决 OLTP 和 OLAP。随后 2014 年 Gartner 提出的 HTAP 概念，也次要是针对内存计算。
这里有个要害信息，列存不适合 TP 类场景。这兴许曾经是很多人的常识，不过兴许并不是所有人都想过为何列存不适合 TP。
数据快速访问须要仰赖 Locality，简略说就是心愿依据你的拜访模式，要读写的数据尽量放在一起。并不在一起的数据须要额定的 Seek 并且 Cache 效率更低。行存和列存，去除 encoding 和压缩这些因素，实质上是针对不同的拜访模式提供了不同的数据 Locality。行存让同一行的数据放在一起，这样相似一次拜访一整行数据就会失去很好的速度；列存将同一列的数据放在一起，那么每次只获取一部分列的读取就会失去减速；另一方面，列存在传统印象里更新很慢也局部是因为如果应用 Naive 的形式去将一行拆开成多列写入到应有的地位，将带来灾难性的写入速度。这些效应在磁盘上很显著，然而在内存中就会得以减弱，因而这些年以来咱们提起 HTAP，首先想到的是内存数据库。
尽管内存价格在一直降落，然而依然老本高企。虽说剖析机构宣传 HTAP 带来的架构简化能够升高总成本，但实际上内存数据库依然只是在一些非凡畛域失去利用：若非那些无可辩驳的超低提早场景，架构师依然须要压服老板，HTAP 带来的益处是否真的值得应用内存数据库。这样，HTAP 的应用畛域就受到很大的限度。
所以，咱们还是以磁盘而非内存为设计前提。
之前并不是没有人尝试应用行列混合的设计。这种行列混合能够是一种折中格局如 PAX，也能够是在同一存储引擎中通过聪慧的算法糅合两种状态。但无论如何，下面说的 Locality 问题是无奈绕过的，哪怕通过超强的工程能力去压迫性能，也很难同时迫近两侧的最优解，更不必提技术上这将会比单纯思考繁多场景简单数倍。
TiDB 并不想放弃 TP 和 AP 任何一侧，因而尽管也晓得 Spanner 应用 PAX 格局做 HTAP，却没有贸然跟进。兴许有更好的方法呢？
TiDB 整体始终更置信以模块化来化解工程问题，包含 TiDB 和 TiKV 的分层和模块切割都体现了这种设计偏向。这次 HTAP 的构思也不例外。通过各种后期的的 Prototype 试验，包含并不限于通过相似 Binlog 之类的 CDC 计划将 TP 的更新同步到易构的 AP 侧，然而这些成果都不尽如人意，咱们最终选了通过 Raft 来剥离 / 交融行存和列存，而非在同一套引擎中紧耦合两种格局。这种形式让咱们能独自思考两个场景，也无需对现有的引擎做太大的扭转，让产品成型和稳固周期大大缩短。另一方面，模块化也使得咱们能够更
好借助其余开源产品（ClickHouse）的力量，因为简单的细节无需被封印在同一个盒子。
市面上有其余设计采纳了更严密的耦合，例如 MemSQL 节点同时运行 TP 和 AP 两种业务，Spanner 抉择 PAX 兼顾不同的读取模式，甚至传统数据库大多也在同一个引擎中增加了不同数据组织的反对。这样的架构会引入过于简单的设计，也未必能在 TP 和 AP 任意一端获得好的收益。
因为抉择了松耦合的设计，咱们只须要分心解决一个问题就能够搞定存储：如何设计一个可依据主键实时更新的列存零碎。事实上，列存多少都反对更新，只是这种更新往往是通过整体笼罩一大段数据来达到的，这也就是为什么少数传统的 OLAP 数据库只能反对批量的数据更新，。如果无需思考实时主键更新，那么存储能够齐全无需思考数据的去重和排序：存储依照主键程序整顿不止是为了疾速读取定位，也是为了写入更新减速。如果须要更新一笔数据，引擎至多须要让同一笔数据的新老版本能以某种形式疾速去重，无论是读时去重还是间接写入笼罩。传统意义上剖析型数据库或者 Hadoop 列存都摈弃了实时更新能力，因而无需在读或者写的时候累赘这个代价，这也是它们得以反对十分高速批量加载和读取的起因之一。但这样的设计无奈满足咱们场景。要达到 HTAP 的指标，TiDB 的列存引擎必须可能反对实时更新，而且这个更新的速率不能低于行存。
事实上，咱们必定不是第一个在业界尝试实现列存更新的产品。业界对于列存更新，无论是何种变体，一个很通用的做法叫做 Delta Main。既然做列存更新效率不佳，那么咱们何不应用写优化形式存储变更数据，而后逐渐将更新局部归并到读优化的主列存区？只有咱们保持足够的归并频率，那么整个数据的大部分比例都将以读优化的列存状态存在以放弃性能。这是一个简直从列存诞生起就有被想到的设计：你能够认为列存鼻祖 C-Store 就是某种意义上的 Delta Main 设计，它应用一个行存引擎做为写区，并一直将写区数据归并为列存。
咱们的可更新列存引擎 DeltaTree 的设计也是十分相似的思路。宏观上，DeltaTree 将数据依照主键序排序切分，相似 TiDB 的 Region 概念那样，每一个数据范畴独自造成一个片段，每当片段的物理大小超过阈值就会决裂。宏观上来说，每个片段就如上图个别，分成 Delta 和 Stable Space 两局部。其中 Delta 局部以优化写入为主，他们是以写入程序攒批排列的小数据块，以写入顺序排列而非主键程序能使得写入大大减速，因为数据写入只须要一直追加。每当积攒了足够多的 Delta 数据，引擎就会将他们归并到 Stable 区，Stable 区的设计相似 Parquet，也是以行组（Row-Group）再按列切割，并排序后压缩存储。Stable 区无疑是对读取优化的，如果只思考 Stable，那么速度将会很快。但实际上在读取时，仍未归并到 Stable 的 Delta 数据可能须要笼罩 Stable 中的老数据，因而读取会是一个在线归并过程。为了减速这个归并，引擎为 Delta 局部增加了内存中的辅助 B+Tree 索引，这样 Delta 尽管并非物理有序（放弃 Delta 物理有序将大大降低写入性能），但依然放弃逻辑有序，免去了归并前排序的代价。同时，因为宏观上数据区间的划分，使得每次归并无需重写所有数据加重了归并的压力。
回头说之前提到的 LSM 列存计划。实际上你能够认为 LSM 也能够近似认为是一种 Delta Main。当数据写入 MemTable 时，也是以写优化的追加模式写入。那是否 LSM 也能够成为一种反对列存更新的设计呢？咱们也尝试过，并非不可能，只是性能比照 DeltaTree 尚有差距：进行范畴读取时，LSM 须要进行十分重的多路归并，因为任何下层的新数据都可能会笼罩上层的老数据，而层和层之间存在交加，因而 N 层的 LSM 兴许须要进行 N 路归并能力获取一段数据。咱们已经实现过基于 ClickHouse MergeTree 革新的 LSM 列存引擎，比照新的 DeltaTree 将近慢了一倍。
至此为止，咱们解决了可更新列存问题。
再说复制
既然抉择了松耦合的存储引擎，行列存储并不在同一个模块内，那随之而来的问题必然是如何进行数据复制。对于传统的主从复制体系，咱们往往应用比方 MySQL Binlog 这样的 High Level 层级进行复制。实际上，这种复制体系也是咱们第一个原型迭代所应用的伎俩。基于 Binlog 的复制体系能很好封装不必要的细节，只有列存引擎 TiFlash 能够失常回放日志就能够，无需关怀例如事务实现等等细节。这样咱们很快失去了第一版 TiFlash，它通过 binlog 串联行存与列存，然而须要再往下实现容错，负载平衡等等一系列个性。更麻烦的是，TiDB 是一个分布式且多主的零碎。每个 TiDB 服务器都会产生一份 binlog，如果要保持数据一致性，不会新老笼罩，binlog 实际上还须要通过一层汇聚和排序，这简直将分布式降维打击成了单点吞吐，而排序管道也大大增加了数据达到的提早。因而原型版的 TiFlash 是无奈提供行列混合查问的：你只能独自查问行存或者列存，因为数据无奈保障统一，在查问中混合两者会发明无穷无尽的不可知数据谬误。
于是咱们转而从更低层级的日志进行复制，是的，咱们选了在 Raft 层进行对接。从更底层进行对接的益处不言而喻，Raft Log 保留了数据复制所需的所有细节，咱们得以将 TiFlash 设计成一种特异的 TiKV 节点，从而可能间接取得 Multi-Raft 体系所赋予的所有益处：数据变得能够通过 PD 进行通明迁徙扩容，容错自身也齐全无需操心全副交由 Raft 体系来实现，当正本失落时，存储层会主动发动复原，而复制自身的简单一致性保障也变得无需操心。从面临本人欠缺基于 ClickHouse 的正本体系，到不劳而获，一切都是如此美妙。当然在理论的工程实现上也有代价，由高层准 SQL 级的 Binlog 改为齐全底层的 Raft Log，代价也是相当微小的。咱们须要在 ClickHouse 上实现所有 Multi-Raft 体系所需的简单操作，例如 Region 的决裂与合并，以及迁徙和读取容错。
新的设计是整个 HTAP 体系成立的要害，它给与 TiFlash 无缝接入整个存储层的能力。同一套复制体系，同一套调度体系，一样的事务模型，一样的一致性保障。它的复制设计是齐全分布式，负载平衡且主动容错的。
相比通过主从复制或者同机器行列双写，它的 AP 和 TP 局部能够齐全独立地运行，自在扩容：如果你须要更多 AP 算力，那请减少 TiFlash 节点；如果你须要减少 TP 算力，请减少 TiKV 节点。互不烦扰，以 Workload 而言或者计算资源扩大而言都是。
与此同时，这种复制又是主动负载平衡且点对点间接链接的。每个 Region Leader 正本会独自与列存侧的正本进行沟通齐全无需两头存储介质，当 Region 正本过大决裂时，列存正本也会跟着决裂；当正本因为热点打散进行迁徙时，他们之间的复制管道也会跟着迁徙。这对于 TiDB 的 Multi-Raft 体系来说都是曾经实现的性能。
另外 Raft 体系带来的最大益处却是一致性和异步复制的共存。
传统意义上，如果须要复制放弃正本统一，就必须采纳同步复制。这样，无论是列存节点的低压，还是网路提早加大，都会对 TP 业务带来微小冲击：为了保持数据一致性，行存事务必须期待列存的确实现写入能力返回，否则期间的故障将会带来数据失落和不统一。另外新增任何列存节点也会加大遭逢网络提早的概率。尽管诸多 HTAP 产品并不会态度思考 AP 和 TP 相互影响的问题，咱们依然心愿娇弱的 TP 能收到更大程度的爱护。
这，恰好能够通过 Raft 解决。TiFlash 通过 Learner 角色接入 Raft 体系，这容许列存以不投票只异步缮写的形式退出集群，这意味着它不会因为本身的稳固烦扰失常 TP 业务的运行。当 TP 侧有事务写入，TiKV 无需期待 TiFlash 的数据同步，仅仅在实现失常的行存正本容错复制就能够返回客户端实现事务。那你兴许要问了，这样是否数据无奈保障一致性，是否行存和列存之间兴许存在数据提早？是也不是。物理上来说，的确存在，一个零碎实践上并无可能做到异步复制依然能同时物理上放弃正本统一。但实际上咱们也无需保证数据每时每刻在物理上统一，咱们只须要提供一种统一的逻辑读取后果就行了。这也是 Raft 自身的外围特点之一，尽管多个正本并非全都每时每刻保持一致，然而只有读取的时候能失去最新的一致性数据即可。当理论读取产生时，列存正本会向行存的 Leader 发动校对申请，这个申请自身很简略：请通知我在你收到申请的霎时，最新日志序号是多少。而 TiFlash 会期待数据复制进度追上校对后果。仅此而已。这就使得 TiFlash 可能保障获得足够陈腐的数据，陈腐到保障囊括上一个霎时写入的信息。是的，从 TiKV 写入的最新数据保障能从 TiFlash 被读取，这造成了读取的水位线。而通过工夫戳和 MVCC 配合，TiFlash 的异步同步也能够提供与 TiKV 一样的强统一保障。这使得 TiFlash 列存体现得并不像一套异构复制体系，而更像是一种非凡的列存索引，也使得咱们能够放心大胆地在同一个查问中混合两种不同引擎，而无需放心是否会由不统一带来奥妙难以追究的谬误。
智能抉择
智能抉择放在最初说，是因为它也确实是咱们最初实现的。TiDB 的行列存智能抉择就是通过代价优化主动抉择行存或者列存。说起来这部分也很简略，犹如应用统计信息抉择索引，咱们也能够通过代价公式估算列存的应用代价。综合各个拜访门路的开销，咱们就能晓得须要抉择何种形式读取数据，而列存只是其中一种，并无特殊性。
技术上来说，这并没有太多新意。但通过主动抉择，TiDB 的 HTAP 体系从 TP + 报表的用况一下子拓展到了 HTAP 混合业务。一些边界含糊的业务零碎，通过 TiFlash 加持，变得架构简略。例如物流零碎，用户心愿可能在同一套查问平台检索个别单号以及投递明细，又心愿能统计某时间段不同货物类别的收发状况。明细查问对于 TiDB 来说并无任何阻碍，但以往没有列存的时候，大数据集下的多维分析性能比照真的剖析型产品仍有不小的差距。有了 TiFlash 之后，这样 AP 和 TP 边界含糊的业务就立马变得圆润残缺起来。反倒是原始打算中的 TiSpark 读取，因为 TiDB 更贴近业务和 DBA 而非大数据的特点，相较之下显得并没有那么多。
最初
这篇文章并不齐全讲述了咱们论文的内容。缺失的局部是 TiDB 非 HTAP 局部的设计，有趣味的同学能够点击原文在此。另外，也欢送大家应用咱们的产品，各位的应用和宝贵意见是 TiDB 倒退最根本的推动力。