关于数据库:什么是真正的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 从不同维度之间的比照关系如下所示：

随着工夫的推移，越来越多的业务对于 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/blo…
[2]Forrester: Emerging Technology: Translytical Databases Deliver Analytics At The Speed Of Transactions.
[3]_https://docs.microsoft.com/zh…‍
[4]_https://www.gartner.com/en/do…
StoneDB 是国内首款基于 MySQL 的一体化实时 HTAP 开源数据库，内核引擎齐全自研。咱们将在开源数据库畛域继续耕耘，一直与各个开源数据库社区、企业单干共建，共创国产开源数据库良好生态。

StoneDB 在 6 月 29 日已发表正式开源。如果您感兴趣，能够通过下方链接查看 StoneDB 源码、浏览文档，期待你的奉献！

StoneDB 开源仓库

https://github.com/stoneatom/…

作者：李浩
StoneDB 首席架构师、StoneDB PMC
曾在华为、爱奇艺、北大方正从事数据库内核外围架构设计。超过 10 年数据库内核开发教训，善于查问引擎，执行引擎，大规模并行处理等技术。领有数十项数据库发明专利，著有《PostgreSQL 查问引擎源码技术探析》。

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