面向海量数据的极致成本优化-云HBase的一体化冷热分离

前言

随着业务的持续发展，业务数据库存储量会持续增加。一般数据量过亿时，就须要考虑作分库分表，或者选择扩展能力更好的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

招贤纳士

欢迎对数据库、云计算、大数据有兴趣的同窗，加入阿里云数据库NoSQL团队（校招&社招），一块儿探索学习数据库及存储计算的创新动向，在云计算的蓬勃发展中作更好的本身！

原文连接

本文为云栖社区原创内容，未经容许不得转载。