前言

随着业务的持续发展，业务数据库存储量会持续增长。通常数据量过亿时，就需要考虑做分库分表，或者选择扩展能力更好的NOSQL/NewSQL数据库，如HBase就可以单表支持PB级数据，足够满足大多数业务的存储需求。然而，对于大量存储瓶颈类业务，存储成本依然是系统设计中需要关注的重中之重，冷热分离的解决方案应用而生。

适合冷热分离的业务

账单/订单类系统的数据非常适合做冷热分离，这类系统的数据随着时间的推移往往会积攒了海量数据，而且由于数据的重要性，这些数据都要被永久保存。但是，用户往往只会查询最近消费的订单或者账单，超过半年的订单基本不会被访问。

监控系统的数据也呈非常明显的冷热分层特性。用户通常只会查看实时监控，历史数据只有在回溯故障的时候，才可能去查询。而如果把实时数据与历史数据混杂在一起，不仅会让存储的成本非常高，而且会拖慢实时查询的速度。

聊天系统是冷热分离的另外一个实用场景，用户通常只会查看实时的聊天消息，聊天记录的访问频次要低非常多。

总的来说，适合将数据做冷热分离的业务会有以下几个特征：

海量数据持续增长的业务：如交易历史数据，聊天记录，数据无法做TTL，且单个用户的数据会持续累加。
数据生命周期分明的业务：如监控数据，物流信息，feed收件箱，通常只会查询近期的数据，冷数据仅作为回溯问题使用。
重写轻读的业务：在IOT场景下，车联网中会有大量车辆上报的传感器信息，和实时的轨迹信息，写入吞吐会非常大。但是这些数据往往只是用来做归档，查询的频率非常低。

现有冷热分离方案

目前业界的冷热分离方案大多是将数据分为冷库和热库两个库。热库可以采用速度较快，但存储成本比较高的数据库方案如内存数据库Redis，或是MySQL+SSD存储介质。而冷库则采用存储成本比较低的数据库方案，如MySQL+HDD或者是使用HBase等稀疏存储的NoSQL数据库，甚至使用高压缩比的列存数据库。而热库到冷库的数据迁移往往会有以下几个方案。

冷热库定时迁移

用户实时写入热库，并通过其他中间件定时将旧的数据倒入离线库。比如，热库可以是使用SSD介质的MySQL数据库，而冷库可以是使用HDD介质的MySQL数据库，通过DataX等数据迁移工具，定期将热库的数据迁移到HDD介质的冷库中。

冷热库双写

用户实时双写冷热库，热数据在较短时间后过期（对于不支持TTL的数据库，需要删除清理）。比如热库采用内存数据库Redis，冷库采用MySQL或者海量存储HBase，数据同时写入Redis热库和冷库。Redis中只保留最近7天的数据。查询层先查询在线库，如果在线库无数据则直接查询离线库返回。此方案无需维护一个定时迁移的任务，但是需要依赖用户双写。

基于日志的增量导出方案

在方案2的基础上，很多有日志导出能力的数据库提供了基于日志的离在线库同步方案。比如我们可以使用MySQL做热库，HBase做为冷库，然后通过导出MySQL binlog的方式，将数据增量写入到HBase中。除此之外，redis的冷热分离方案swapdb，本身也是基于redis的PSYNC实现，本质上也是属于增量导出的方案。

此方案可以上减少冷热数据库管理的开销。然而这种方案仍然需要用户自行管理在线库数据的生命周期问题，且需要额外的查询层来分别访问冷热数据。

无论是使用哪种同步方案，将数据分为热库和冷库两个库的方案，都存在一定的缺陷：

运维难度增加

用户需要运维热库和冷库两个数据库，在使用增量导出时，用户还需要维护一个定时任务来做数据导出。

数据一致性难以维护

无论是哪种数据同步方案，冷库和热库的数据一致性很难保证。比如说双写方案，用户需要处理一边写成功一边写失败的情况来自行维护两边数据的一致性。定时迁移方案和增强导出由于数据迁移都是异步的，处于冷热边界的数据有可能还在热库中，也有可能已经进入到冷库，多次读取可能会产生不同的结果。

用户查询改造成本大

对于业务来说，使用了冷热分离后，数据对于业务来说不再是一个“单库”，用户需要决定这一次查询需要去热库查询还是要去冷库，并且由于冷热数据数据迁移是异步的，用户并不知道数据到底是在热库还是冷库中，通常要冷热库一起查才能得到全量数据。另外，在使用异构的冷库和热库的情况下（如热库使用Redis/MySQL,冷库使用MySQL/HBase），用户必须针对热库和冷库查询开发两套查询接口,开发成本大大上升。

冷热分离一体化 —— 海量数据冷热分离终极解决方案

针对设置冷库热库这种将数据分离开，给业务带来运维和改造困难的缺陷，云HBase增强版开发了全新的一体冷热分离特性——在同一张表中全透明地实现冷热分离，服务端自动根据用户设置的冷热分界线自动将表中的冷数据归档到冷存储中。

冷热分离一体化的核心是应用无感知，HBase增强版用户无需改动一行查询即可享受冷热分离带来的好处。冷数据和热数据存储在一张表中，通过LSM的compaction操作在后台将热数据定期迁移到冷数据中。用户可以通过设置访问的timerange来实现查询优化，也可以完全不指定hint，云HBase增强版会保证在查询结果无损的情况下通过kv层的访问优化来最大程度上规避冷数据的访问。

冷热分离的一大目的就是为了降低存储成本，HBase增强版目前选用了云盘（高效/SSD）做为热数据存储，而使用了低成本的OSS做为了冷存储，冷存储成本仅为高效云盘的1/3。

在使用过程中，用户只需要在HBase的表上加上冷热分界线这个设置，即可开启冷热分离功能。在下面的例子中COLD_BOUNDARY被设置为86400秒（一天），代表这张表中一天前的数据会被自动归档在冷存储中。

 hbase(main):002:0> create 'chsTable', {NAME=>'f', COLD_BOUNDARY=>'86400'}

在查询时，由于冷热数据都在同一张表中，用户全程只需要和一张表交互。用户可以设置Hot_Only的Hint告诉服务器只查热数据，或者在Get/Scan请求中加上TimeRange，系统会根据设置TimeRange决定是查询热区，冷区还是冷热都查。具体的使用方式可以参考HBase增强版帮助文档中的冷存储和冷热分离章节

一体化的冷热分离方案完全避免了分库方案的种种弊端。

分库方案云HBase增强版冷热分离一体化运维复杂度需要运维冷热两个库，并可能为异构数据库业务冷热数据都在同一个库中数据一致性两个库之间数据一致性很难保证冷热数据在同一个表中，不存在一致性问题查询复杂度查询复杂度高，需要分别查两个库，查询复杂度高冷热数据一体化，业务查询无需改造使用复杂度使用复杂度高，涉及到两个库的配置和查询接口开发使用简单，冷热分离一个配置搞定

最后

云HBase增强版是基于阿里内部HBase分支(别称Lindorm)构建，历经9年大规模考验，多次支持天猫双十一，服务于阿里经济体中的淘宝，天猫，支付宝，高德，优酷等几乎所有部门。阿里内部署超过12000台机器，主打成熟稳定、高性能、低成本、多租户及安全等大规模场景追求的能力，并提供了最高7倍于HBase开源版本的性能和一半的存储成本。冷热分离只是HBase增强版众多企业级特性中的一个。欢迎大家使用HBase增强版，直达连接：https://promotion.aliyun.com/ntms/act/hbaseenhancededition.html