阿里云HBase发布冷存储特性,轻松搞定冷数据处理
摘要: 9月27日,阿里云HBase发布了冷存储特性。用户可以在购买云HBase实例时选择冷存储作为一个附加的存储空间,并通过建表语句指定将冷数据存放在冷存储介质上面,从而降低存储成本。冷存储的存储成本仅为高效云盘的1/3,适用于数据归档、访问频率较低的历史数据等各种场景。
9月27日,阿里云HBase发布了冷存储特性。用户可以在购买云HBase实例时选择冷存储作为一个附加的存储空间,并通过建表语句指定将冷数据存放在冷存储介质上面,从而降低存储成本。冷存储的存储成本仅为高效云盘的1/3,适用于数据归档、访问频率较低的历史数据等各种场景。
阿里云HBase是基于Apache HBase深度优化的全托管、PB级、千万级QPS随机读写的云数据库,其在物联网、车联网、用户画像、历史数据存储、AI人工智能、Feeds等场景有广泛的应用。自产品发布以来,我们一直在努力优化,为用户提供更高的性能和更低的成本。此次发布的冷存储特性,针对冷数据存储的场景,可以在保证数据随时可访问及不低于云盘的写入性能的前提下,大幅降低用户的存储成本。
适用场景
一般随着业务的发展,HBase中存储的数据量会逐渐变大。在这些数据中,业务最关心的,最常访问的,往往是某些特定范围的数据,比如说最近7天的数据,业务对这类数据访问频次高,延迟要求高,即所谓的热数据。而其他的数据,一般访问量极少,性能要求不高, 但这类数据往往数据量大,即冷数据。如果能把冷热数据分离开,把热数据存储在性能更好的介质中,而把庞大的冷数据放到成本更低的介质中,从而实现把更多优质资源用来提高热数据的读写性能,同时节省存储成本的目的。
通常来说,冷数据具有如下特点:
1 数据量大,因此对成本更敏感。
2 较低的访问频率,因此可以容忍更低的访问qps和更高的访问延时,但是大多数场景下都要求随时可以访问。
3 写入tps并不低。无论是历史数据还是归档数据,他们的写入速度其实都和热数据相当。
基于以上这些特点,HBase冷存储在优化成本的同时,提供了和高效云盘相当的写入性能,并保证数据随时可访问。当然,作为优化成本的代价,冷存储上HBase的读操作qps较低,延时(在不命中缓存情况下)也比云盘要高一些。
下表对HBase上的冷存储和高效云盘两种形态做了比较。可以看出,冷存储在冷数据场景下有极大的优势。
大幅降低存储成本
只看存储成本的话,冷存储的成本不到高效云盘的1/3,由于冷数据的量通常都比较大,存储介质的成本占大头,因此即使考虑到计算资源的成本不变,整体上成本仍然有很大幅度的下降。
以某车联网应用为例:拥有10万台车, 每台车每30秒上传7K的包,数据半年后就很少访问了,但是有时会有查询历史数据的需求,所以这部分冷数据又不能删除。有了云HBase的冷存储特性,就可以把半年之前的数据放在冷存储上面节约存储成本,半年内的数据仍然放在高效云盘保证热数据的高效访问。
我们以3年的存储 ( 约2P)来估算成本,见下图。
可见,对于冷热数据混合的场景,通过把冷数据存放在冷存储上面可以大幅降低存储成本。对于纯冷数据的场景(例如归档数据),节省的成本就更加可观了。
写入性能与云盘相当
测试环境:
HDFS 6台8核32G DataNode
HBase 1台8核32G RegionServer
每台ECS挂载4块300G 高效云盘valueSize=100B
threads=120
测试结果:
无需代码改动,轻松搞定冷数据
冷存储可以独立购买,作为一个附加存储空间使用。购买冷存储介质后,可以在建表时候中指定把表创建在冷存储上(即冷表),默认是创建在云盘介质上(即热表)。HBase会根据表的属性将数据放在对应的存储介质上面,这个细节对应用是透明的,应用不需要关心表的数据存储在哪里,都是通过hbase的API对表进行读写操作,因此访问冷数据的代码不需要做任何改动。
注意事项
1.冷存储的__读IOPS__能力很低,所以冷表只适合存储冷数据。
2.写入吞吐上,冷表和基于高效云盘的热表相当,可以放心写入数据。
3.建议平均每个core节点管理冷数据不要超过10T。如果是同时有冷热表的集群,需要看region数量来衡量。