什么是真正的HTAP？（一）背景篇

To digitally transform the business, AI must be real-time. For AI to be real-time, we need real-time analytics.[1]

Hybrid transaction/analytical processing (HTAP) is an emerging application architecture that "breaks the wall" between transaction processing and analytics. It enables more informed and "in business real time" decision making.
——Defined by Gartner

背景篇-引言

自 StoneDB 开源的第一天，我们就说要做真正的 HTAP，那么究竟我们对 HTAP是怎么理解的？解读一门技术，就要从其发展背景入手，本篇文章中我们将从 OLTP 和 OLAP 最近的发展介绍及各自遇到的问题为基础，引出 HTAP 相关概念。

 

OLTP：特点、适用场景、遇到的问题、最新进展

对事务型数据进行处理称为联机事务处理 (On Line Transaction Processing, OLTP)。OLTP 系统其主要的使用场景为记录日常运营中与业务系统之间的交互记录，并且支持以该数据进行查询分析以获得分析结果。

事务数据是指一种信息，用于跟踪与组织活动相关的交互，常为：业务事务。例如：从客户收到的付款、对供应商进行的付款、从库存移动的产品、接受的订单或交付的服务。表示事务本身的事务事件通常包含时间维度、数值等。

事务通常需要原子性和一致性。原子性意味着整个事务始终作为一个工作单元成功或失败，永远不会处于半完成状态。如果无法完成某个事务，数据库系统必须回退任何已完成的该事务的一部分工作，从而能够保证整个工作要么完成，要么失败。一致性意味着事务始终让数据处于最终有效状态，如果已将某个事务的一部分提交到数据库，那么该源事务中所有其他作用域内操作也将处于最终有效状态并提交到数据库中。事务型数据库可以使用各种锁定策略（如悲观锁定）支持事务的强一致性，以确保所有用户和进程的所有数据在业务的上下文中具有强一致性。

事务型数据最常见的部署体系结构是三层体系结构。在该体系结构中，事务型数据在数据存储层被使用。三层体系结构通常包含：表示层、业务逻辑层和数据存储层。

适用场景

如果业务系统对数据完整性和实时性有约束要求，同时在业务的处理过程中需要保证数据的严格完整性，而且更改后的数据需要严格的持久性，此时OLTP 会是你的首要选择。因为，OLTP 系统设计用于高效地处理和存储事务，以及查询事务数据。

面临挑战

实现和使用 OLTP 系统可能会带来一些挑战：

（1）OLTP 系统不是特别适合用于处理大量数据场景的复杂查询。在大数据量复杂查询场景下， OLTP 系统会消耗大量的计算资源和存储资源，所以执行上可能较慢。而且如果此时其它事务也正在对某些复杂查询的数据进行操作，往往会触发系统中的锁机制，这会导致整个系统性能的下降。

（2）在 OLTP 系统中，数据库对象的命名约定通常简洁而精炼，这对业务用户专业素养要求较高。OLTP 系统中增强的规范化与简洁的命名约定共同使得业务用户在没有 DBA 或数据开发者帮助的情况下难以执行查询。

（3）历史记录以及在任何一个表中存储太多数据都会导致查询性能变慢。常见的解决方案是在 OLTP 系统中维护一个相关时间范围（例如当前统计年度）并将历史数据卸载到其他系统，例如：数据仓库。

 

OLAP：特点、适用场景、遇到的问题、最新进展

联机分析处理（英语：Online analytical processing），简称 OLAP，用来快速解决多维分析问题的一种方法。OLAP 是更广泛的商业智能范畴的一部分，它还包括关系数据库、报告编写和数据挖掘。

企业用来存储其所有事务和记录的数据库称为联机事务处理 (OLTP) 数据库。它们通常包含对组织有价值的大量信息。OLTP 的数据库不是为分析而设计的。因此，从这些数据库中检索答案从时间和工作量角度而言成本高昂。OLAP 系统设计用来以高性能方式从数据中提取商业智能信息。这是因为 OLAP 数据库针对高频读取和低频写入进行了优化。

适用场景

• 需要快速执行复杂的分析和即席查询，且不能对 OLTP 系统产生负面影响；

• 为业务用户提供一种简单的方式来基于数据生成报表；

• 提供大量聚合，这些聚合将使用户能够快速获得响应结果。OLAP 适用于大量数据且查询多为聚合计算的场景下。OLAP 系统针对高频读取应用场景（例如分析和商业智能）进行了优化。

面临挑战

OLAP 系统中的数据更新较少，具体取决于业务需求，这意味着 OLAP 系统更适用于战略级业务决策，而非适用于立即对更改做出响应。另外，还需要规划一定级别的数据清理和业务流程来使 OLAP 系统中的数据保持最新。

与 OLTP 系统中使用的传统的规范化关系表不同，OLAP 的数据模型通常是多维的，在这种模型中，每个属性映射到一个列，其难以或无法直接映射到实体关系或面向对象的模型。

 

OLTP VS OLAP

OLTP 和 OLAP 从不同维度之间的对比关系如下所示：

对比维度	OLTP	OLAP
一句话特征	小事务众多的场景	使用复杂查询来处理较大数据量的场景
ACID	强	弱
面向用户	数据库操作人员	决策人员、高级管理人员，数据库科学家、业务分析师和知识工作者
使用场景	金融（如银行、股票）、电商、旅行预订等	商业智能（BI）、数据挖掘和气压决策支持应用程序
基本操作	主要为：insert, update, delete为主	主要为聚合操作，窗口操作等为主
操作数据范围	通常读写数据量较小（数十条记录）	通常读写数据量大（数百万条记录）
主要衡量指标	事务吞吐量（TPS）	查询响应速度（QPS）
响应时间要求	实时性要求高，通常毫秒级	实时性要求低，依赖于所处理的数据量，时间范围由小时，分钟秒级，亚秒级等
数据源	业务系统实时事务数据	业务系统中的历史数据，事务型数据
数据库表设计规范	通常需要满足三范式（3NF）	不作规范
数据量/磁盘空间	较小，MB~TB级	较大，GB~PB级
并发量	需要支持大并发环境	对并发量要求不高
稳定性	要求高	要求高
可用性（备份，恢复）	完整的备份，恢复能力（全量，增量）	主要按时间点进行备份/恢复，备份/恢复要求不高
数据完整性要求	强一致性要求	数据完整性要求不高
系统吞吐量，IOPS	低	高
挑战	1.高吞吐量，保证数据完整性，可靠性等； 2.完整的生态工具，不同异构产品间协调使用难度；	1.海量数据高效，低成本的数据存储； 2.复杂查询高效处理；
可靠性要求	通常要求高可靠性：主备、同城灾备、异地灾备	可靠性要求相对低，一般同城灾备
读特性	简单查询为主、每次查询只返回少量数据	复杂查询为主、对大量数据进行汇总
写特性	1.随机、低延迟、小数据量； 2.数据更新、删除频繁	1.很少有更新、删除操作； 2.大数据量批量、并行导入
数据模型	ER（实体、关系）	星型或者雪花、星座
数据粒度	行级 record	多表
数据结构	高度结构化、复杂，适合操作计算	简单、适合分析
数据字段	动态变化，按字段更新	静态、很少直接更新，定时添加、刷新
数据返回值	一般为记录本身或该记录的多个列	一般为聚合计算结果

随着时间的推移，越来越多的业务对于 AP 的要求越来越向着 TP 的指标看齐，例如：要求 AP 系统能够实时反映出当前 TP 系统中的实际数据。同时，AP 系统可以支持数据的更新等等。总之，TP 系统和 AP 系统之间的边界在业务层面和用户层面上也越来越模糊,市场上迫切希望能够出现一种新的架构或者称之为者解决方案，能够同时满足业务对于 TP 负载和 AP 负载的需求。因此，HTAP 的概念随之而诞生。2014年 Gartner 给出了 HTAP 的明确概念：Systems that can support both OLTP (On-line transaction processing) as well as OLAP (on-line analytics processing) within a single transaction.[4]

 

HTAP：HTAP概念引入的目的，定义，适用场景介绍，HTAP的商业驱动力——问题的源动力？

商业上的驱动力

当前市场上对于数据的处理方式越加的注重多种类型的负载混合进行，即对于用户或者业务端来说，有一个统一的处理逻辑或者架构。如对于广告计算，用户画像，分控，物流，地理信息等商业场景下，原有的处理方式为在海量的历史数据中通过 AP（分析型处理）数据库或者自建的大数据平台，完成对于历史数据的计算，然后将 AP 计算的结果作为 TP（事务型处理）的输入结构，完成对于实时计算需求。

因此，在原有的架构环境下，对于此类的应用需要部署两套环境分别应对 AP 和 TP 两类负载，从而造成整个架构变得复杂，中间涉及到的组件较多，无法及时将 TP 数据实时更新到 AP 系统中，从而影响 BI 等应用的时效性。

" 陈旧的报告、缺失的数据、缺乏高级分析以及完全缺乏实时分析对于任何需要新见解以在商业客户时代保持竞争力的企业来说都是一种无法忍受的状态。"[2]

架构1：异构架构模式

商业上的驱动力，其原动力来自业务端的需求，没有业务端的需求变化，不会导致商业上的驱动力，由于现在市场中无论是互联网企业还是其他传统型企业，在其早期业务的发展过程中通常会采用架构一的方式来往满足业务需求；但该种架构在后期的使用过程中存在着各种各样的问题，如 AP 模块和 TP 模块之间的数据同步问题，运维的问题等等，而着会导致巨大的运营成本。

随着业务需要的发展和数据库技术的发展，使得数据库产品同时具有处理 AP 和 TP 的能力，且在处理 AP 负载的时候并不会对 TP 负载造成太大的性能波动，更重要的一个特性是在 TP 数据和 AP 数据可以做到“准”（或者实时）实时更新。因此，基于数据库的此项能力，业务端即可将原有的 AP 处理模块及 TP 处理模块进行合并，统一的交由该数据库进行处理，从而可以简化业务系统的架构。

架构2：统一架构

HTAP 则为上述问题提供了另外一个解法和思路。将 AP 和 TP 的能力由统一的系统对外提供，由此构成的业务架构简单化，同时具有一定的扩展特性。产生 HTAP 用户侧的需求或者诉求如下：

1. 事务数据及历史数据的集成。

2. 理解用户需求的超维度数据分析的需要；全局视角来看数据，方能看清事物的本质。（例如：从手机的位置信息，用户的填表所获得信息，社交媒体所获得富媒体信息。）

3. 企业运行所需的商业分析的实时性需求。

技术上的驱动力

"May the force be with you." ——Star War.

作为一个新技术产生的另外一个重要的来源：技术驱动力，这才是实现人们想象力的基石。下面我们从技术的发展角度来看看，推动 HTAP 发展的另一个重要的源动力：in-memory， scale-out技术使得我们的架构可以进行扩展，使得我们可以在一个架构内满足不同负载需要变为可能。列存技术的发展则是我们实现 HTAP 的基石，分层存储架构为我们在成本和性能之间找到了一个平衡点。

1. 列存技术

面向列存的数据，最早可以追溯到 1970 年，随着转置文件(transposed files)的出现，在面向时间的数据库（Time oriented Database）中使用转置文件进行医疗数据记录。Cantor 被称为是最早的一个与现代列存数据库相似的系统。例如：在现代列存数据库中所常用的压缩技术，delta 编码等都可在 Cantor 中寻找到身影。

磁盘页中数据所采用的两种数据存储模型：NSM（row-store， N-array Storage Model）和DSM（column-store, Decomposition Storage Model）。

通常数据库的数据物理上以行，页，段等方式进行分级管理的，表中的一行数据由 N 个数据属性构成，N 条数据构成一个页面，多个页面又构成了一个段，如此将众多的记录高效管理起来。以上便是我们所熟知的行存（Row-based）模型。当前，绝大多数数据库为行存数据库。对应行存的优点这里我们不在赘述。我们来谈谈其优点的另一面，缺点。抛开应用场景谈某个事务的优缺点本身就是一件奇怪的事情。

对应行存方式组织数据，我进行以分析型业务为主的系统中，分析所涉及的数据量通常非常多。即，将会有大量的记录会参与到分析计算中。而这些大量的记录需要从磁盘中读取到我们数据库的缓存中，由于数据是以行的方式组织，而我们的分析计算只需要特定的几个属性，例如：在一条包含：产品 Id，产品产地，产品销量，销售时间的记录，分析计算可能只需要产品 ID 和产品销量，这两个属性便可以得到我们需要的分析结果。对于产品的产地和销售时间，我们并不关心。由此可以看出，当我们将这条记录由磁盘读取到数据库的缓存中，产品产地，产品销量这两个属性数据便属于无效工作。其会导致我们这部分的数据属性所对应的 IO 资源和其在数据库缓存中的内存资源被浪费，而这两部分资源在数据库中又属于非常宝贵的系统资源。

为了解决上述问题，在 1985 年，Copeland 和 Khoshafian 提出了 DSM 模型，而这也促成了列存数据库的发展。与行存的方式不同，DSM 模型中，表中的数据已按属性（列）的方式进行组织。由上图中 DSM page 模型可以看出，该种方式下，每个属性数据组织在一起构成一个子的关系并独立于其它属性。由于按属性为单独进行数据组织，那么在磁盘上进行存储这些数据的时候，我们可以对其进行压缩处理。

该种数据存储模型下，我们只需要读取分析计算所需的属性数据即可，从而可以节约宝贵的 IO 和 memory 资源。同时，DSM 模型也属于 CPU Cache 友好型。但是，DSM 有一个问题是：其在将结果返回用户的时候，或者在上层算子进行计算的时候需要重构记录。因为，此时我们获得的数据是不完整的，而需要返回用户时候需要一个完整的记录。

针对上述问题的探索，学术界在 1990 左右进行了积极的尝试，MonetDB项目应运而生。当然在随后的岁月里也产生了 C-Store 和 VectorWise 等，到了 2000 年底的时候，列存数据库百花齐放，涌现出诸如：Vertica, Ingres VectorWise, Paraccel, Infobright, Kickfire等等。当然商业数据库公司也通过收购，自研等方式在各自的产品中提供了列存能力。例如：IBM BLU， SAP HANA，SQL-Server等。

2. in-memory技术(包括：distributed in-memory)

随着内存价格未来的下降，越来越多的个人和组织可以以更加低廉的成本获得由于技术发展带来的技术红利：in-memory 技术。从下表可以看出无论是 PC 上的 DRAM 还是服务器端的 DRAM 价格在已每季度 3-10% 下降。

随着内存价格的下降，我们可以在系统的设计时候，使用更为激进的方式——大量使用内存，甚至是全量内存的方式。

我们从经典的存储层次架构图中知道，DRAM 的访问速度远大于本地磁盘，但价格远比磁盘贵。早期，受限制于 DRAM 高昂的价格，DRAM 都作为高速缓存保存由磁盘中所读取的数据，例如: Buffer Pool。随着内存价格的持续下降使得in-memory 数据库不再是阳春白雪般的存在，慢慢的进入寻常百姓家。GB 级，TB 级的内存数据库也时常可见。

当需要执行Analytical Processing（AP）的时候，可以将 AP 所需数据加载内存中，甚至可以将所需的表的数据全部加载至内存中，从而获得急速的处理速度。同时，可以持续的将 TP 引擎中的数据变化实时的同步到 AP 引擎中，从而满足商业分析的实时性要求。

最后，为了保证系统 crash 的时候可以正确且快速的完成 recovery，需要将内存中的数据持久化至磁盘中。

3. 可扩展的架构：（scale-out architect）: 水平扩展架构的发展，分布式锁技术的成熟，记录的分布式管理

为了满足更大数据量的处理能力，在单节点的基础上，通过水平扩展的方式将单节点的系统扩展为分布式多节点的系统，利用多节点的系统资源能力来解决，在大数据量场景下的计算能力不足的问题。与单节点系统不同，分布式系统通常由多个节点构成，通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的计算、存储任务。其目的是利用更多的机器，处理更多的数据。无论是当前通过中间件的方式来实现的分库分表，还是分布式式数据库系统所采用的将数据通过某种分布策略（例如通过主键或者分布键将数据通过 hash 的方式进行分布或者其它的方式）将数据分布至 N 个数据节点上，由此使得单节点的处理数据量减少。

可扩展的架构并不算一个陌生的技术，尤其现在分布式计算已然大量的应用在生产系统中，无论是分布式框架技术，分布式文件系统，分布式事务等等都已形成了一套成熟的理论并且在工程上也已日益成熟。

对具有可扩展能力的架构来说，做到业务无感知的动态节点的扩缩其方案也日益成熟，例如：一致性 hash 算法可以完成负载在分布式环境下的均衡。现在，对于分布式框架的水平扩展能力，无论是在理论上和工程上都有成熟的方案。

随着具有可水平扩展的分布式架构的发展，分布式系统的能力越来越多的运用在数据库领域。除了，作为基础的分布式框架外，分布式事务的发展是使得我们能够处理跨节点的事务。由此，数据库系统可以充分的利用多节点的计算能力来实现对于大数据业务场景下的实时性的要求。

对于 HTAP，来说由于其涉及到两个不同的存储模型（或称之为：格式），那么我们在事务处理方面对于 row-base 和 columnar-base 两类数据有着不同的处理方式。对于事务的支持这部分需要我们给出仔细的考虑。同时对于 HTAP 所需要的分布式架构其带来的分布式事务处理这里也是一个点，好在当前市面上对于分布式事务处理相关技术相对成熟。

最后，当然分布式对于 HTAP 来说，只是一个充分条件，而非必要条件。不考虑用户实际情况的一上来有最小节点部署要求的解决方案都是“耍流氓”。

4. 数据压缩（data compression）

考虑到AP场景下，通常所需要处理的数据量巨大，从成本的角度考虑，同时也从IO效率的角度出发，对于数据进行有效的压缩，将为系统带来较多的收益。随着压缩算法对于数据类型的支持和压缩比的提升，对数据进行压缩，已变为AP系统来一个标准做法。

5. 分层存储架构（tiered storage）

考虑到用户的计算资源的情况和数据量的实际业务场景下。通常所需要处理的数据量远远大于系统所拥有的计算资源。我们知道越靠近 CPU 的存储，其单价会越高，为了能够以最大的性价比的方式对用户提供搞性能，分层存储架构应运而生。例如：我们可以使用 DRAM，NVME，SSD，HDD 来构成分层存储架构。将对于计算实时性有要求的数据加载至 DRAM 中进行计算，以获得实时计算结果。如果计算过程复杂，中间结果集较大，可将中间结果集保存至 NVME 中，这样既可以保证数据的实时性，又可以支持更大的数据量，以获得较高的性价比。同样，SSD 和 HDD 的也起着同样的作用。

虽然分层存储架构看似有着非常诱人和广阔的使用场景，但是其同样存在着以下几个挑战，使得我们在使用该种方案的时候需要格外小心。

• 首当其冲的，就是在不同层级之间的数据一致性的问题。这个问题比较好理解。在分层存储架构下，数据通常分布在不同的存储层级之间，数据的改写必然导致数据的不致的问题。在内部分层存储时，可以采用写穿透(write through)策略或者写回(write back)策略。而不同的方法也有各自优缺点，这里就不再赘述。但是外部分层存储与内部分层存储有一个最大的不同是，内存储最终数据需要写到内存中，而外分层存储中，则不是必须的。当然也可以设计成这样的实现方案，但是这样话，分层存储的性能优势则必定会受到影响。

• 其次，如何快速的由分层存储中获取相应的数据也将是一个不小的挑战。由于按照分层存储的架构，越是层级越低其存储容量越大，访问速度越慢。如何在这些海量数据中快速定位到所需数据，将给数据的组织，数据的索引等提出挑战。最后，是性能和成本之间的 trade-off。如何选择每个分层中的存储介质，从而能够保证整体性能优秀，同时又不至于导致存储成本飙升。

 

总结

综上，本文对 HTAP 的产生背景做了详细的分析，并提炼出商业和技术上的驱动力，显而易见，一个新型的技术得到追捧，一定离不开技术的成熟、市场的需要和商业的成功，HTAP 就是诞生在这样的背景下。

那么，如果我们从 HTAP 的定义及其核心技术出发，一款真正的 HTAP 产品要具备哪些能力？构建真正的 HTAP 时会遇到什么核心问题？这些核心问题都有哪些解决方案？这些问题的答案将在我们的接下来的文章中揭晓。

可以提前剧透的是：在下一篇文章中，我们将指出，真正的 HTAP 并不应该是简单地将 TP 和 AP 相加：TP + AP ≠ HTAP。HTAP 一定是将 TP 和 AP 进行高度融合的产物。

将 TP 系统通过简单的数据同步方式，例如通过 Binlog 等，将 TP 中的数据同步到 AP 系统，然后由 AP 系统进行处理的方式，虽然该种方式从用户的角度来看似乎其获得同时处理 TP 和 AP 的能力，但是从本质上来看，我们并不认为其是一个 HTAP 产品。

此文是《什么是真正的 HTAP》系列文章的第一篇，后续我们将持续更新此系列文章，敬请关注。

参考资料

[1]AI must be real-time: https://splicemachine.com/blog/how-to-measure-an-htap-data-platform-for-ai-applications/

[2]Forrester: Emerging Technology: Translytical Databases Deliver Analytics At The Speed Of Transactions.

[3]https://docs.microsoft.com/zh-cn/azure/architecture/data-guide/relational-data/online-transaction-processing‍

[4]https://www.gartner.com/en/documents/2657815

StoneDB 是国内首款基于 MySQL 的一体化实时 HTAP 开源数据库，内核引擎完全自研。我们将在开源数据库领域持续耕耘，不断与各个开源数据库社区、企业合作共建，共创国产开源数据库良好生态。

 

StoneDB 在6月29日已宣布正式开源。如果您感兴趣，可以通过下方链接查看 StoneDB 源码、阅读文档，期待你的贡献！

 

StoneDB 开源仓库

https://github.com/stoneatom/stonedb

 

李浩

StoneDB 首席架构师、StoneDB PMC

曾在华为、爱奇艺、北大方正从事数据库内核核心架构设计。超过10年数据库内核开发经验，擅长查询引擎，执行引擎，大规模并行处理等技术。拥有数十项数据库发明专利，著有《PostgreSQL查询引擎源码技术探析》。

 

编辑 &校对：李明康、王学姣

END

 

{{o.name}}

{{m.name}}