4.一体化架构StoneDB对HTAP数据库的思考和实践-李浩

1 .什么是真正的 HTAP ？ 李浩 StoneDB首席架构师 

2 . 问题背景 Agenda HTAP所面临的挑战 什么是真正的 HTAP ？ HTAP实践-StoneDB介绍 Q&A 

3 .1 问题背景 HTAP产生的底层逻辑 从两个方面 OLTP 和 OLAP 为基础，引出为什么会需要HTAP：即HTAP产生的底层逻辑是什么。 OLTP/OLAP阐述角度 特点 适用场景 挑战 

4 .1 问题背景 OLTP - Online Transaction Processing 在线事务处理 定义 对事务型数据进行处理称为联机事务处理 (Online Transaction Processing, OLTP)。 OLTP系统其主要的使用场景为记录日常运营中与业 务系统之间的交互记录，并且支持以该数据进行查询分析以获得分析结果 。 事务数据是指一种信息，用于跟踪与组织活动相关的交互，常为：业务事 务。例如：从客户收到的付款、对供应商进行的付款、从库存移动的产品 、接受的订单或交付的服务。 表示事务本身的事务事件通常包含时间维度 、数值等。 

5 .1 问题背景 OLTP - Online Transaction Processing 在线事务处理 特点：事务通常需要原子性和一致性。(其它两个特性：隔离性和持久性)，ACID。 事务型数据库可以使用各种锁定策略（如：悲观锁定）支持事务的强一致性。 原子性 一致性 整个事务始终作为一个工作单元成功或失 事务始终让数据处于最终有效状态，如果 败，永远不会处于半完成状态。 已将某个事务的一部分提交到数据库，那 么该源事务中所有其他作用域内操作也将 处于最终有效状态并提交到数据库中。 

6 .1 问题背景 OLTP - Online Transaction Processing 在线事务处理 适用场景 如果业务系统对于数据的完整性等有一定的要求，同时对于实时性也有着一 定的约束要求。在业务的处理过程中需要保证数据的严格意义上的完整和需 要更改后的数据的持久性同样有着严格的要求时。此时，OLTP会是你的首 要选择。因为，OLTP 系统设计用于高效地处理和存储事务，以及查询事务 数据。 表示层 业务逻辑层 数据存储层 事务型数据的最常见部署体系结构是三层体系结构中的数据存储层。 

7 .1 问题背景 OLTP - Online Transaction Processing 在线事务处理 挑战 • 不适合用于大数据场景。 大数据量复杂查询场景下，会消耗大量的计算 资源和存储资源。 同时，在该场景下可能执行较慢，并且可能会因为其 它事务也正在对某些数据进行操作，此时系统中的锁机制会导致系统性 能下降。 • 使用难度大。数据库对象的命名约定通常简洁而精炼，使得业务用户在 没有 DBA 或数据开发者帮助的情况下难以执行查询。 • 表中数据过多会导致查询性能变慢。 常见的解决方案是在 OLTP 系统中 维护一个相关时间范围（例如，当前统计年度）并将历史数据卸载到其 他系统，例如：数据仓库。 

8 .1 问题背景 OLAP - Online Analytical Processing 在线分析处理 定义 联机分析处理（Online Analytical Processing），简称OLAP，用来快速 解决多维分析问题的一种方法。OLAP是更广泛的商业智能范畴的一部分， 它还包括关系数据库、报告编写和数据挖掘。 OLAP通常包含对组织有价值的大量信息。OLTP 的数据库不是为分析而设 计的。 因此，从这些数据库中检索答案从时间和工作量角度而言成本高昂 。 OLAP系统设计用来以高性能方式从数据中提取此商业智能信息。这是 因为 OLAP 数据库针对高频读取和低频写入进行了优化。 

9 .1 问题背景 OLAP - Online Analytical Processing 在线分析处理 特点 • 快速性：OLAP要求具有快速反应能力，系统应能在用户要求的时间内对 用户的大部分分析要求做出反应。 • 可分析性：OLAP系统应能处理与应用有关的任何逻辑分析和统计分析。 用户无需编程即可连接到其他外部分析工具上，如时间序列分析工具、 数据挖掘工具等。 • 多维性：OLAP关键属性是多维性。系统必须提供对数据分析的多维视图 和分析，包括对层次维和多重层次维的完全支持。 • 信息性：OLAP系统应能及时获得信息。需要考虑数据的可复制性、可利 用的磁盘空间、OLAP产品的性能及与数据仓库的结合度等。 

10 .1 问题背景 OLAP - Online Analytical Processing 在线分析处理 适用场景 • 需要快速执行复杂的分析和临时查询，且不能对 OLTP 系统产生负面影 响； • 为业务用户提供一种简单的方式来基于数据生成报表； • 提供大量聚合，这些聚合将使用户能够快速获得响应结果。 • OLAP适用于大量数据且查询多为聚合计算的场景下。OLAP 系统针对高 频读取应用场景（例如分析和商业智能）进行了优化。 

11 .1 问题背景 OLAP - Online Analytical Processing 在线分析处理 挑战 尽管 OLTP 系统中的数据多来源于业务系统，但是，OLAP中的数据更新较少 ，具体取决于业务需求。这意味着 OLAP 系统更适用于战略业务决策，而非 适用于立即对更改做出响应。 另外，还需要规划一定级别的数据清理和业务 流程来使 OLAP保持最新。 与 OLTP 系统中使用的传统的规范化关系表不同，OLAP数据模型通常是多维 模型。 这导致难以或无法直接映射到实体关系或面向对象的模型，在这种模 型中，每个属性映射到一个列。相反，OLAP 系统通常使用星型或雪花型架构 ，而非使用传统的规范化。 

12 .1 问题背景 对比维度 TP AP 一句话特征 小事务众多的场景 使用复杂查询来处理较大数据量的场景 ACID 强 弱 决策人员，高级管理人员、数据科学家、 业务分析师和知识 面向用户 数据库操作人员 工作者 使用场景 金融( 如银行、股票) 、电商、旅行预订等 商业智能 (BI)、数据挖掘和其他决策支持应用程序 操作数据范围 通常读写数据量较小（数十条记录） 通常读写数据量大（数百万条记录） 实时性要求低，依赖于所处理的数据量，时间范围由小时， 响应时间要求 实时性要求高，通常毫秒级 分钟秒级，亚秒级等 数据源 业务系统实时事务数据 业务系统中的历史数据，事务型数据 数据库表设计规范 通常需要满足三范式（3NF） 不作规范 数据量/磁盘空间 较小，MB~TB级 较大，GB~PB级 数据完整性要求 强一致性要求 数据完整性要求不高 数据模型 ER（实体、关系） 星型或者雪花、星座 数据返回值 一般为记录本身或该记录的多个列 一般为聚合计算结果 

13 .1 问题背景 HTAP问题的起源-商业驱动力 随着时间的推移，越来越多的业务对于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.” 

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

15 .1 问题背景 HTAP问题的起源-商业驱动力 产生 HTAP 用户侧的需求或者诉求 “陈旧的报告、缺失的数据、缺乏高级 • 事务数据及历史数据的集成 分析以及完全缺乏实时分析对于任何 需要新见解以在商业客户时代保持竞 • 理解用户需求的超维度数据分析的需要；全局视角来 争力的企业来说都是一种无法忍受的 看数据，方能看清事物的本质。 状态。” - Forrester • 企业运行所需的商业分析的实时性需求。 

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

17 .1 问题背景 HTAP问题的起源-技术驱动力 列存技术 磁盘页中数据所采用的两种数据存储模型： NSM（row-store， N-array Storage Model） DSM（column-store, Decomposition Storage Model） 

18 .1 问题背景 HTAP问题的起源-技术驱动力 列存技术 对比维度 行存 列存 把一行记录拆分成单列保存，写入次数明显比行存储多，实际 写性能 写入一次完成，性能更高 花费时间比行存储多 读取少数几列时，需遍历其他无关列，IO开销较大;读取整行 读取少数几列时，无需读取无关列，性能高；读取整行时，需 读性能 数据时，依次顺序读即可，性能高 分别读取所有列，并拼装成行，性能低 以列为单位存储数据，这使得类型相同的数据存放在一起，对 数据压缩 每行数据存储在一起，压缩比较低 压缩算法友好，压缩比较高 

19 .1 问题背景 HTAP问题的起源-技术驱动力 in-memory技术(包括：distributed in-memory) • 价格的下降 • 系统的设计时候，使用更为激进的 方式：大量使用内存，甚至是全量 内存的方式。 

20 .1 问题背景 HTAP问题的起源-技术驱动力 in-memory技术(包括：distributed in-memory) • 内存访问速度优势得以充分发挥 • Analytical Processing（AP）的时候， 可以将 AP 所需数据加载内存中，甚至 可以将所需的表的数据全部加载至内存 中，从而获得急速的处理速度 

21 .1 问题背景 HTAP问题的起源-技术驱动力 可扩展的架构：（scale-out architect）: 水平扩展架构的发展，分布式锁技术的成熟，记录的分布式管理等 单节点的基础上，通过水平扩展的方式将 单节点的系统扩展为分布式多节点的系统 ，利用多节点的系统资源能力来解决在大 数据量场景下的计算能力不足的问题。 

22 .1 问题背景 HTAP问题的起源-技术驱动力 数据压缩（data compression） AP场景下，通常所需要处理的数据量巨 大，从成本的角度考虑，同时也从IO效率 的角度出发，对于数据进行有效的压缩， 将为系统带来较多的收益。 

23 .1 问题背景 HTAP问题的起源-技术驱动力 分层存储架构（tiered storage） 总结：冷热数据的分层管理问题，是性能和成本之间的 trade-off。 依据局部性原理（时间局部性、空间局部性），使用 DRAM，NVME，SSD，HDD 等来构成分层存储架构。将对于 计算实时性有要求的数据加载至 DRAM 中进行计算，以获得实时计算结果。如果计算过程复杂，中间结果集较大，可 将中间结果集保存至 NVME 中，这样既可以保证数据的实时性，又可以支持更大的数据量，以获得较高的性价比。同 样，SSD 和 HDD 的也起着同样的作用。 分层存储架构下，要考虑数据在各个层级之间流动的时延问题。同时，仍需考虑就是在不同层级之间的数据一致性的问题。 

24 .2 HTAP面临的挑战 HTAP 是将 TP 和 AP 进行高度融合的产物， 而非简单的 TP 和 AP 相加， TP+AP ≠ HTAP 架构选择 事务语义 architecture choice transaction semantics 数据导入及查询处理引擎 数据的时效性 ingestion and query processing engines recency of data being read by OLAP 存储方案 索引支持 storage options indexing supports 数据组织方案 AP 负载和 TP 负载的相互干扰 data organization workload interference 

25 .2 HTAP面临的挑战 架构选择（Architecture choice） Single system 是未来架构趋势 Single system（即 One system） 还是 Seperate system 的选择当前更多是基 于工程上的难度。 优势 One system 不仅架构简洁，对于事务的支持能力和数据的时效性等方面都 能提供更好的保证。 缺点 One system 架构的技术难度相对较大，工程上也具有一定的难度，同时还 需要考虑 TP 和 AP 负载间的相互干扰等问题。 

26 .2 HTAP面临的挑战 数据导入及查询处理引擎 （Ingestion and query processing engines） 数据加载是基础，查询处理是核心 数据加载 查询处理 HTAP 数据库首先需要解决的问题是高速的数据载 最重要的能力是能够同时完成 TP 负载和 AP 负载的处 入 理 • 查询负载的识别。 • 全量数据的载入方案，保证海量数据快速、准确导入 • 基于查询代价的查询负载的offload。 • 增量数据的更新方案，保证数据的时效性。 • 索引的问题 

27 .2 HTAP面临的挑战 存储方案 （Storage options） 高速存储介质正在广泛地应用到数据库领域 影响选择 TP 部分和 AP 部分的存储方案因素 架构 成本 业务场景 … 性能 

28 .2 HTAP面临的挑战 数据组织方案 （Data organization） 列存储加行存储（DSM + NSM）OR PAX （Partition Attributes Across）方案 选择数据组织方案的指标 系统性能 数据存储成本 整体性价比 

29 .2 HTAP面临的挑战 事务语义（Transaction semantics） 需要具有支持完整的事务语义的能力 无论是 TP 部分还是 AP 部分都需要对事务进行完整的支持。现有的很多 HTAP 解决方案，AP 系统中所处理的数据均是同步自 TP 系统中 已提交的数据。 对应长事务场景下，如何保证 AP 系统可以获得最新 通过以同步日志的方式，数据的时效性和一致性需 版本的数据值得我们仔细考虑。 要认真考虑。 为了解决上述问题，会影响到事务的执行效率，导致系统吞吐量的下降。