OLTP + OLAP -> HTAP

之前介绍了数据库的两种最常见的存储模型：NSM 和 DSM （列式存储的起源：DSM），今天介绍这两种存储模型和 HTAP 的联系。

本文预计阅读时间 5 分钟。

介绍 HTAP 之前，先介绍 OLTP 和 OLAP 两个概念。

OLTP

OLTP：On-Line Transaction Processing，联机（线上）事务处理。指处理事务型应用的场景，事务这个词的英文是 Transaction，其实就是交易（一般指金融交易）。这种场景有个最常见的业务，就是转账，从一个账户转到另一个账户。一般要求实时处理，对响应的速度要求很高，并且要保证事务的 ACID 特性。面向 OLTP 场景的数据库管理系统就叫做 OLTP DBMS。一般涉及大量的增删改操作。

OLTP 与 NSM： OLTP 的场景一般需要一次操作一个对象的多个属性，比如查询一个人的姓名、银行账号、余额等。而 NSM 这种将一个对象的多个属性连续存储的行式存储模型就很适合 OLTP 的场景了。同时 NSM 也适用于写密集场景，一个对象的写入只需要一次写磁盘就能完成。

传统的关系数据库都是面向 OLTP 场景的，如 Oracle 通常用在银行系统、医疗系统等对操作的响应速度要求很高的场景。

OLAP

OLAP：On-Line Analytical Processing，联机（线上）分析处理。指处理分析型应用的场景。进入大数据时代，数据多了，计算机计算能力增强，并出现了分布式存储、分布式计算等技术，人们开始对大量的数据有分析的需求了。这种分析型的场景一般需要查询大量的数据进行分析，对速度的要求没有 OLTP 高，每天晚上或每周做一次，慢慢分析就好了。一般涉及大量的查询操作，对数据的修改需求不高。

OLAP 与 DSM：OLAP 的查询模式一般是同时查很多对象的几个属性。之前看过马云的介绍对淘宝用户进行分析，比如不同地区购买衣服的平均尺寸（他举的例子比这个性感一点），这样只需要按地区筛选尺寸这个属性就好了。就很适合 DSM 这种按属性存储的列式存储模型。

列存数据库等就是面向 OLAP 的，因此，列式存储在大数据时代这种分析型场景中火了一把，如数据仓库 HBase。

NSM 不适用于 OLAP，因为会额外读取很多不需要的列。而 DSM 就不适用于 OLTP，因为列式存储对增删改的代价很大。

HTAP

HTAP：Hybrid transaction/analytical processing，混合事务/分析处理。是Gartner公司提出的，Gartner 是美国一家很权威的从事信息研究和顾问的公司。

HTAP 就是 OLAP 和 OLTP 两种场景的结合。在对新旧数据进行 OLAP 分析的情况下增加事务的处理来对数据进行更新。

在实际场景中，往往 OLAP、OLTP 是同时存在的，一种解决方案是，将数据分为冷热数据，新到达的数据放在内存数据库 Redis 中，以支持 OLTP。当数据变冷后，将数据移动到 HDFS 上，准备后续的分析。

举个例子：朋友圈数据，最近一两天之内修改（评论和点赞）的频率很高，过了几天之后就变成了冷数据，基本只用来查询分析了。

再举个例子：状态数据，比如用户的登录状态，可能有的平台用户数很多，但是大多是僵尸，活跃用户数很少，这也可以区分冷热数据。

区分冷热数据是一个很实用且黑科技的方式，与 one-size-fits-all 相反，针对不同的部分做不同的优化。一个数据之前是冷数据，后来变热了，可以动态调整。区分冷热数据这种方式一般都需要这种调整是不常发生的，大量的操作还是针对热数据的。

这样，需要在系统中部署两套系统，一套 OLTP 数据库，一套 OLAP 数据库。那么能不能用一个数据库来同时支持这两种场景呢？这种数据库就叫做 HTAP DBMS。

一种构造 HTAP DBMS 的方式就是分别针对新旧数据构建两套引擎，一套负责 OLTP，一套负责 OLAP，相当于将关系数据库和列存数据库进行结合。一个查询到达后，需要分别解析成两套查询，在两个查询引擎都得到结果后进行合并，还可能用到两阶段提交等分布式事务。这样混合会带来性能的下降和查询模式的限制。

总结

存储模型与适用场景是一一对应的，而 HTAP 是两种场景的结合。将两者结合也得益于将数据区分为冷热数据，并根据冷热数据划分操作种类，这样不同的操作种类有不同的性能，满足不同的需求，这是一个比较工程化的解决方案，也很实用。

水到绝境是飞瀑，人到绝境是重生。