目前业界和学术界都对HTAP 有非常大的热度， HTAP的快速发展也是指日可待。HTAP，到底是不是最终解决方案呢？
作者 | 祁国辉
责编 | 韩 楠
对于数据库领域的人士来说， OLAP和OLTP都耳熟能详了。
OLTP 说的是在线事务处理，强调小数据量快速处理，要求高并发， 低延时，对于数据一致性有极高的要求，一般用IOPS来衡量性能。
OLAP 指的则是在线分析处理， 重点是大量数据的统计分析，要求大数据量的快速处理和汇总，数据可以容忍少量滞后，一般用IO Throught来评价这种大块IO的性能。
在企业的应用场景中，一般而言， 核心业务系统都是属于 OLTP， 比如 CRM、订单系统、销售系统等等。而报表和分析， 都会被划为 OLAP， 典型就是数据仓库， 而我们通常讲的多维数据库， 那更是典型中的典型， OLAP 中的 OLAP（hyperion）。
HTAP 的前世今生
前面简单讲了一下OLTP和OLAP，因为它们的侧重点不同， 自然对数据库和软硬件系统有了不太一样的要求。
在投资有限不能兼顾的时候， 就会适当有所取舍， 比如OLTP系统， 容量就不是第一要求。 有条件的话， 磁盘选择最快的， 容量小一点无所谓， 绝大多数的OLTP系统数据量都在100TP以下，甚至有些企业的核心系统为了高性能， 控制在10TB以下。
而OLAP类的系统， 都会有一个巨大的体量， 100TB只是开始， PB级别的系统比比皆是，这时候再追求磁盘速度就有点强人所难了。
有了这样的需求， 自然也会催生出对应的产品。OLTP领域，因为一般都是企业核心数据，数据库会进一步向高稳定、高并发、高可靠的方向推进， 企业的投资也会更大。Oracle、Mysql 基本上在这个领域处于主导地位。
相对而言， OLAP领域的空间更大一些， 选择的因素也会更多样化， 有通过海量数据预处理来实现快速报表生成的， 有利用大量硬件并发处理的MPP数据库， 当然某种角度上， Hadoop 也是一类OLAP的应用， 采用的大量集群来实现海量数据处理。
但，万事无绝对。
我们可能找出一个100%的OLAP系统， 它只处理OLAP的需求， 但是我们很难说某个OLTP系统是100%的OLTP。因为，任何业务系统， 发展到一定阶段， 都会有一个简单的子系统来处理即时报表。
更有甚者， 有些业务自带大量的统计查询， 举个例子，为了要求手机号码实名制， 甚至控制一人多号的情况发生。
当一个人去开设新的手机号码时， 首先需要统计该身份证下在全国范围内有多少个电话号码，另外还需要查之前的号码是否有欠费等行为，如此等等，不一而足， 我印象中， 曾经有一个用户鉴权过程，包含多达40+项的验证 。
更不提， 还有大量的新兴企业， 还在快速的原始积累， 市场拓展， 没有时间和精力去架构企业级的数据仓库系统。
就像每次去吃西餐，我们发现面前赫然摆着好几副刀叉和勺子， 大多数人是没法分辨到底应用用哪个叉子吃沙拉？哪个叉子切牛排？西餐礼仪固然重要， 但是绝大多数时间吃西式简餐的时候， 我们还是一副刀叉吃完全程。
因为刚提到的这种场景屡见不鲜， 所以就催生出一个在OLAP和OLTP之间的灰色地带，该如何处理的问题。架构师们一般都倾向于寻找一个平衡点， 切分OLTP和OLAP， 这样有利于将来的整个企业架构，更加清晰可持续发展。
不过站在业务的角度， 是希望用最简单的方法， 直接解决这些接踵而至的即时分析需求。因此HTAP应运而生。
在这个过程中，有一个小插曲， 因为我们一直说某个数据库是适合OLTP， 某个数据库适合OLAP。自然也就会有OLTP数据库和OLAP数据库的说法， 这时候， 有的数据库也会说， 我的数据库既可以支持OLTP， 也可以支持OLAP， 所以我们的数据库就是HTAP。
当然这个话题也无可厚非， 投资足够的前提下，是完全可行的。这个我们后面也会有描述， 但是目前业界已经约定俗成的HTAP概念， 还是利用内存技术，实现在同一个应用中OLTP和OLAP并行的技术。
把握 HTAP 的关键技术点
基于这样的共识和定义， 我们也需要进一步去理解HTAP中的一些关键技术点， 把握了这些技术点， 我们才可以对HTAP有深入的了解。
◆ 内存/闪存技术
首先，就是内存/闪存技术。随着技术的发展， 摩尔定律一直在推动着IT技术的飞速发展， 计算机的内存从 KB 到了 TB， 闪存的容量也在不断地刷新，虽然这使得一些老牌程序员非常失落， 他们认为只有认真考虑过 640k 内存使用的程序员，才是真正的程序员。
但是，这些新的技术使很多之前的不可能变成了可能，目前最新技术， 闪存容量已经突破单片容量 2TB， 这对于很多企业的核心数据库来说， 已经绰绰有余了。怎样利用内存/闪存技术进一步突破数据处理效率， 自然也是技术人员孜孜以求的目标。
那既然内存都这么大了， 为什么不把所有的数据都存在内存里， 那不是就一下解决所有问题了吗？究其原因， 还是有几个相关的考虑：
首先是数据持久化的问题， 大家都知道， 内存是通过电路来实现数据存储的。当内存掉电， 所有内容会消失，下次加电，数据需要重新装载， 对于企业的核心数据， 一方面， 不能接受这样的风险， 另一方面，数据加电之后的数据装载也需要很长时间， 比如100TB的数据加载进内存， 然后内存中重新建立索引， 怎么也需要几十分钟的时间， 这就是一个硬伤。
历史上曾经出现过不少纯内存的产品， 就是这个原因，一直都没有占领企业核心应用领域。
不过， 随着新技术的发展， 曙光乍现， 最新的PMem 技术， 可以保证加载在PMem中的数据， 掉电后不丢失， 相信几年之后， 这个领域还会有新的惊喜。
另外一个方面是，就是下面说的列式存储技术。
◆ 列式存储
因为OLTP和OLAP的访问模式不一样， 对于OLTP来说， 基本上每次访问都是某行数据的全部内容， 但是对于OLAP来说， 更大几率是每次查询分析只涉及部分列， 所以在这种情况下， OLAP应用采用列式存储， 能够进一步提升查询的效率。
对比之后，就可以看出， 对于统计汇总中的列式存储， 会大大减少查询时的扫描数量， 从而大幅提升性能。
◆ 数据复制技术
因为我们的OLTP数据还是在行式数据中存储，所以，我们需要有一种手段， 保证用户的每一笔数据操作， 在OLTP系统中完成之后，都需要尽快地体现在列式存储中， 这样才能使得用户看到及时的统计数据。
这个时候，就会有一个小小的问题， 因为每次转换都是有额外的开销， 我们都知道列式数据库的优势在于数据查询， 弱点在于数据的update， 而每次转换都有可能导致列式数据库的update。
那么我们就需要找到一个平衡， 并不是每次新数据来都刷新列存， 而是积累到一定时候， 统一做一次刷新， 但是如果OLTP系统的数据刷新量非常大， 那对HTAP系统来说就是一个巨大的考验。不同数据库在此都有独家的秘方来进行优化。
另外一点， 看HTAP的架构， 会有两种， 一种是在现有系统之上， 通过增加内存来实现在原系统之上的HTAP支持， 另外一种是通过日志等手段， 同步到另一批机器上，实现分系统的HTAP， 这种技术带来的时延就会更大，我们都知道， 本地内存存取的速度和网络访问的速度，是有巨大的差异。
这种架构下， 数据复制后，带来的数据延迟就会远远大于第一种方式， 但是相应带来的好处就是有更好的隔离度和扩展性。
◆ 查询路由和资源调度
数据准备好了， 那应用程序怎么知道什么时候用行存？什么时候用列存？如果这需要应用程序自己选择， 那和前面举的例子， 吃西餐时的选叉子一样，还是不能解决问题。
所以在这里， 所有的数据库厂商都会有比较一致的价值观， 就是透明实现路由切换。当用户的SQL 进来之后， 由系统的优化器来分析， 这个SQL 是需要OLTP操作还是OLAP操作， 因为目前的数据库，基本都采用了基于成本的优化器， 很容易分辨出应用的访问模式， 在分析完成之后， 系统会自动把SQL 路由到对应的数据存储中，进行执行， 当数据处理完成之后， 再返回给用户。
谈到自动调度， 那就不得不说资源调度的问题， 当一个系统同时处理OLTP和OLAP的时候。尤其在资源不够充分的情况下， 如何根据需求来动态决定资源分配，就是一门艺术， 比如通常情况下， 我们都需要OLAP不阻塞OLTP， 查询分析的优先级是低于业务处理的优先级， 但是如果是一个突发的决策需求， 如何尽快完成？
能否通过自动策略， 实现OLTP和OLAP之间的动态平衡， 这对于 OLAP和OLTP在同一台机器上的HTAP 就是一个问题。而对于OLTP和OLAP分开在不同机器的HTAP， 就天然不存在这种资源争用的问题
◆ 动态加载和数据压缩
数据是无限的， 内存是有限的， 那怎么最大限度地发挥内存中列式存储的优势呢？ 这个时候就有两个方向， 可以在一定情况下来缓解这个问题。
1.列式数据动态加载。一般而言， 对于那些数据需要加载在内存中的列式数据中，来加速查询和报表， 这个是可以通过人工来指定， 特定的表， 或者特定表的某个分区。但是如果能够由数据库系统来自行决定呢？
首先数据库可以根据历史SQL的执行情况， 来预估出一个内存容量大小对于系统加速的对比曲线， 这样用户就可以找到一个最佳的平衡点。
更进一步， 甚至可以容许系统在运行的过程中， 自行决定把一些很少用到的数据移出内存， 把一些没有命中的数据从磁盘加载到内存中， 以避免出现查询的时候缓存击穿的问题。这个技术存在一定的风险， 目前还不是特别完善。
2.列式数据的压缩。我们都知道， 当数据以列式来管理的时候， 单个列中重复数据的出现几率会远大于行式存储， 所以内存中的列式存储， 天然具备可压缩的能力， 所以在内存的列式数据库中， 采用压缩， 也是提高空间利用率的一大法宝。
• 数据块越大， 数据重复的几率越高， 所以， 尽量采用大数据块；
• 表宽度要小， 因为表太宽， 一个数据块中相同的数据都可能出现不了几次；
• 尽量在入库前按照重复率高的大字段进行排序， 这样相同的数据就可以出现在相邻的位置。
几种 HTAP 场景的技术解析
下面我们根据不同的场景，来看看几种最常见的HTAP场景。
◆ 一快破万法， O记神器 Exadata
把Exadata 拿来做HTAP， 也许会有人持有不同意见， 但是因为Exadata天生利用了大量的软硬件结合和内存技术， 而且能够在同一个系统中，同时支持高并发数据更新和海量数据查询，说它是HTAP并不过分。
天下武功， 唯快不破。我们之所以提出HTAP， 都是在预算有限的环境下，采用多种技术结合的方式，来实现扬长避短， Exadata的Smart Scan ， 混合列压缩， 内存， Pmem， 闪存和硬盘的多级存储技术， 给用户带来了极高的性能，极大的便利性。
一言以蔽之， 如果你不想那么复杂， 又有足够的投资， Exadata 应该是最好的选择， 谁用谁知道。具体特性就不赘述了。
◆ 不换手机不换号， 一键上5G
对于那些在原来业务系统上， 通过在内存中开辟一块空间， 在内存中进行列式存储以加速 OLAP 应用的产品，用户可以对应用不做任何修改 ， 也不需要更换硬件平台；应用系统无感升级， 用户 SQL 通过优化器自动路由到相应的存储的技术， 代表产品有 Oracle 的 DBIM 和 SQL Server。
对于这种技术， 我经常和客户做这样一个比喻，就是不换手机不换号， 一键上5G。
在这里我们吧，可以简单地以 Oracle DBIM 为例， 来深入了解一下这种技术。
首先， 所有数据在硬盘上是以传统行式进行存储的， 这个是最基本的。
除了传统的内存中的 Buffer Cache 之外，Oracle DBIM 在内存中单独开辟了一个部分， 叫做 In-Memory Column Store， 在这片区域中， 数据是以列的方式进行存储的， 用户的查询会在优化器的干预下，自动路由到相应的区域。
进一步， 我们看一下这片内存中的数据存储格式。
所有的数据的DML操作， 为了保证数据的完整性和一致性， 都是先通过行式处理进行保存， 保存完毕之后， 再同步到in memory 区域。而在in-memory中的数据是由两部分组成， 第一部分是列式存储IMCU， 另外一部分记录最新数据变化的SMU。
对于列式数据的查询是遍历IMCU和SMU之后的组合结果， 当数据增量达到一定的值， 就会进行合并。
在合并的时候， 首先标记当前IMCU为旧数据， 然后结合IMCU和SMU的数据， 生成新的IMCN， 同时生成空的SMU， 而旧的IMCU 会在不再使用或者空间不足的时候，自动删除， 这样就避免了新的数据进来之后， 对列式数据存储的频繁更新。
但是， 即使采用这种技术， 合并的时候还是会有额外开销， 当数据刷新量巨大的时候， 会造成OLAP性能的抖动。
◆ 兄弟齐心， 其利断金
上面这种方式的优点在于架构变化小， 但是缺点在于硬件需求加大， 因为在同一个系统中， 首先要额外的内存。另外， OLTP和OLAP混合， 会造成资源的冲突和争用。在X86化大行其道的今天，出现了新的架构。
方法就是保持原始系统不动， 在相邻增加一批计算资源专门负责 OLAP 计算， 然后通过日志传输等技术， 把数据同步到相邻的 OLAP 集群中，OLTP 系统将会在迁移耗费资源的 OLAP 请求后，性能和稳定性有大幅提高， 同时 OLAP 集群可以采用分布式技术，实现横向的扩展。
代表产品，就是 MySQL 的 Heatwave 和 StoneDB 的 Tianmu， 我们以 Heatwave 为例， 简单看看其中的技术要点。
HeatWave 本身是 InnoDB 的子引擎， OLTP 系统的数据， 会利用 binlog 投递到HeatWave 集群， 而查询优化器会自动把用户的 OLAP 查询路由到 HeatWave 中进行执行。
HeatWave 目前 Oracle 只在 Cloud 上部署销售， 希望本地部署的用户， 其实可以考虑其他国内的开源 HTAP 产品（比如 StoneDB 等）， 原理上都是一致的。
HTAP 是不是最终解决方案
谈了这么多， 大家也看到了， 目前业界和学术界都对 HTAP 有非常大的热度， HTAP 的快速发展也是指日可待， 但是 HTAP 是不是最终解决方案呢？
实质上，HTAP 还是有自身的一些限制， 首先从架构上来说， HTAP是定位单个系统， 在一个独立系统中同时存在 OLTP 和 OLAP， 这个很常见。但是绝大多数的企业， 并不仅仅存在一套系统，尤其在现在单元化、中台化之后， 单个系统支撑企业的场景是越来越少了。
其次， 除了简单报表， 绝大多数的企业决策支持需求， 都需要来自企业内外多种渠道的数据， 进行整合加工之后， 才能构成企业级的决策支持信息。
数据仓库需要繁琐的 ETL 和建模，最终才能生成决策信息， 随着实时数仓的技术快速发展， HTAP 的实时分析场景，会遇到实时数仓的挑战。
所以， HTAP 更大程度上是基于部门级的战术工具， 可以在中小规模的数据库上， 短平快地实现数据分析。各种部门级的应用， 小范围的数据汇总统计在基层非常常见。
万事开头难， 大量的中小企业在初期， 没有精力物力来实现大规模的企业级数据仓库，利用HTAP来解决迫在眉睫的分析问题， 这些也是HTAP 可以提供助力的地方。
写在最后
HTAP 作为一轮新的技术热点， 带来了更多的机会和挑战。 在各个企业都有大量的使用场景，虽然不是重量级的解决方案， 但是市场和前途还是挺有看头的。
▼
作者介绍
祁国辉
前 Oracle 云平台事业部电信行业技术总监
现就职于杭州石原子科技有限公司
【作者介绍】网名"atiger"，前 Oracle 云平台事业部电信行业技术总监。拥有超过25年数据库和数据仓库HK经验。