阿里云在HBase冷热分离的实践

内容来源：2018 年 09 月 01 日，阿里云技术专家郭泽晖在“中国HBase技术社区第3届 MeetUp 杭州站 ——HBase应用实践专场”进行《云上HBase冷热分离实践》的演讲分享。IT 大咖说做为独家视频合做方，经主办方和讲者审阅受权发布。

阅读字数：3825 | 10分钟阅读

观看嘉宾完整演讲视频及PPT，请点击：t.cn/ELx5wUX

摘要

本次演讲主要分享的是在云端怎么样作一个HBase的产品，首先会介绍一下冷数据的典型场景，以及HBase在云端的一个实现方案。

典型数据场景

通常冷数据的定义是访问的比较少，且访问频次会随着时间的流逝而减小的数据，好比监控的数据、线上台帐数据，若是在业务上出现问题，咱们查看的确定是最近一段时间的数据，而不会查看诸如半年前的监控数据。

而咱们这边对冷数据的定义，根据时间成原本估算的话，大概是平均每GB数据月度访问不超过10万次这个层次的数据。同时对成本敏感的数据也能够作冷热分离。

传统方案

若是是传统的开源的HBase要作冷热分离，方案只能是搞两个集群，一个集群是SSD的配置，负责在线查询，另外一个集群是机械盘HDD的配置。 这两张表之间须要手动进行同步，而且客户端须要感知两个集群的配置。

这样作的优势就是不须要改HBase代码，缺点也很明显，要同时维护两个集群，开销确定是比较大的，并且对于冷集群来讲，若是查的比较少，集群上cpu资源浪费也会比较多。

在2.0的HBase的版本中新加入了一个特性，能够指定表的HDFS存在哪一种介质上。这利用了HDFS的分级存储功能，HDFS的分级存储功能，能够将DataNode配置到不一样介质的盘。好比上图中有三块是机械盘一块SSD，在表上能够设置这样的策略，指定表的HDFS是写在冷介质仍是热介质上，最后调到HDFS接口的时候，会根据设置的文件的属性放置数据。

这样2.0的HBASE就能够作到在一个集群内既有冷表也有热表，相对来讲比1.x版本更好管理。固然它也有一个缺点，由于要根据业务配比集群的硬件配置，若是集群上混合了比较多的业务，或未来业务的场景有了一些变化，集群的硬件配置是很难调整的。

云HBase云端方案

因此咱们云端的方案，将会是一个比较弹性的方案。在介绍云端的冷存储方案以前，我先大概介绍一下咱们云HBase，它是一个存储计算分离彻底的架构。

因为HBase部署的节点访问磁盘都是远程读的，所以咱们能作到动态调整磁盘大小，作到彻底弹性。这里面还有一个多模式，在云HBase上除开HBase自己的KV功能之外，咱们还架设了一些其余的开源组件。最底下的存储层上，目前咱们的应用数据场景主要有两块，通常的数据是放在云盘，冷数据放在OSS。

基于OSS的HBase冷存储

下面介绍一下基于OSS怎么作HBase冷存储。前面提到过，咱们作的是一个彻底弹性的模式，因此咱们的冷存储方案，其实并无配置磁盘，冷表的数据是直接放在OSS上，而且在同一个集群内也能实现冷表和热表。

可能有朋友不太了解OSS，这里简单介绍下。OSS是阿里云的一款对象存储产品，能够理解为也是一个KV存储，它特色在于能生成很是大的对象，可达到TB级别。 同时还能保证9个9的数据可靠性，而且成本很是低。

成本优点

OSS的成本若是跟云盘对比的话，云盘大概是每GB每月0.7元，OSS则只要两毛钱成本，相差了3.5倍的。

再举一个具体的例子，和一个汽车企业相关，该企业大概有10万辆车，每30秒会上传一个7K的包，而且数据是基本上半年以后就不会访问，这样计算下来三年的数据量大约是2P左右，和OSS相比每月成本的开销会差2.5倍，若是彻底采用云盘架构大概是140万左右，混合OSS加云盘大概是60万的成本。

基于OSS架设HBase的问题

对于在阿里云上使用OSS做为HBase的底层存储的形式，其实如今的Hadoop 社区已经实现了一个叫NativeFileSystem的类，它继承至FileSystem，咱们能够把FileSystem的实现类在配置里边替换掉，这样数据读写就能够直接转发到OSS上。

不过因为NativeFileSystem是针对mapReduce这样的离线做业产品实现的，因此在模拟文件系统过程当中会有几个问题。前面说过OSS其实是一个对象存储，没有文件系统的结构的。

所以常规路径中的反斜杠分割符并不表明目录，只能表示对象名字中的字符。 而要模拟出目录的效果的话，建立目标对象的同时，必须还要建立额外的对象才能模拟出目录结构（如图所示）。这样的模拟存在一个问题，咱们对文件目录操做实际上不是原子的，相似rename这种操做，若是中途crash，会出现不一致，没法保证原子性。对于依赖目录操做原子性的一些系统使用社区实践，就会存在问题，最后会使得目录或文件不一致。

对于该问题云HBase的解决方案是，本身实现了一个OSSFileSystem，它能避免刚才说的原子的问题。具体的实现上，咱们是把云数据的管理放在HDFS上，HBase调用FileSystem的API时候，调用的实际上是咱们实现ApsaraDistnbutedFileSystem，由它来控制文件是放在HDFS里仍是OSS上。HLog依然是彻底放在HDFS上，主要是考虑写入性能。

云HBase冷存架构

云数据操做经过ApsaraFileSystem直接请求能用的进行操做，热表的数据调用Hadoop的FileSystem，冷数据会在HDFS里建立一个文件，这个文件有一个属性的标记表示该数据是冷的，读冷文件时候会把读通道转发到OSS上，而后构建一个OSS的input stream和OSS output stream。

社区版对比

除了架构上区别于社区版，保证HBase能正常使用外。咱们对性能也作了优化。架设在对象存储上的实现会存在一些限制，第一请求是要收费的，第二Hadoop FileSystem是提供OutPutStream让用户输入数据，而OSS SDK提供的是InputStream让用户输入。这样的话，要实现Hadoop FileSystem接口嫁接OSS，就必须作一个OutPutStream到InputStream的转换。

对此社区版实现是这样的，数据写入到NativeOSSOutPutStream上的时候，实际会写到磁盘上，在磁盘上会有buffer文件，当文件写满128兆的时候，会被包装成FileInputStream提交给OSS的SDK，由一个异步线程池负责。

这样的实现有几个问题，首先写入过程须要过磁盘，性能上有一些损耗。 其次会比较依赖于磁盘的性能，以及机型内存的大小，配置参数等因素影响。

理论环境下这个线程池能够并发提交，若是写入速度足够快，一会儿就能在磁盘上产生，好比十个128兆的buffer文件，这样线程池就至关于有十个线程将这10个buffer一块儿提交，速度是能够说是很快的。

可是这只是理论环境，正常HBase下来的数据最多只有100多兆，并且也不可能有那个速度瞬间产生十个128兆个文件。因此实际社区设计的这套写入流程，写入行数不够快的话，这个异步发送线程池会退化成一个单线程，就至关于一个文件只有一个线程在提交。

另一个问题在于crash的时候，会在磁盘上残留一些文件，对运维来讲仍是比较麻烦的。

云Hbase的设计的OSSFileSystem，整个写入过程是不会在磁盘上落地的，这中间有一个RingBuffer，大概有几兆，用户的写入会到这里。RingBuffer里面是由固定数量的page组成，一个page差很少是两兆，总共是有五个page。

写入page以后，蓝色区域至关于用户写好的page。绿色这块有一个异步线程，每一个文件写入会有一个独立的异步线程，这个线程会把蓝色写好的page数据读出来，而后包装成InputStream。

每当InputStream被OSS的SDK读完128兆的时候会return 一个EOF等于-1，至关于欺骗OSS，告诉它这个数据结束了，而后把这128兆数据提交一下，以后再有数据写入，会再包装一个新的InputStream。因此从成本上来讲，虽然跟社区的方案同样，都是128兆提交一次，可是咱们的写入过程是彻底不须要落地磁盘的，而且占的内存开销也很是少。同时咱们考虑到了冷热表混合的场景，buffer内存都是本身管理的，避免了YGC，并解决了元数据操做原子性的问题，而HBase刚好依赖于这样的原子性来完成一些操做。

在云HBase上使用这样的特性，也很是简单，在建表的时候，如上图配置就能够了。设置成冷以后，表的全部数据写入都会存到OSS里面。

冷存储建议使用场景

对于冷存储使用的场景，咱们的建议的是写多读少以及顺序读。若是持续get，咱们会限制冷存储读的IOPS，对于偶尔访问，IOPS限制会适当动态放宽，顺序读写流量不作限制。

以上为今天的分享内容，谢谢你们！

编者：IT大咖说，转载请标明版权和出处