回顾·云上 HBase 冷热分离实践


本文地址:http://www.6aiq.com/article/1536989556514
知乎专栏 点击关注
本文版权归作者和AIQ共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出

本文根据阿里云技术专家郭泽晖在中国 HBase 技术社区第 3 届 MeetUp 杭州站中分享的《云上 HBase 冷热分离实践》编辑整理而成。

今天分享的内容分为两个方面,首先会介绍下冷数据的经典场景,以及如果使用开源的 HBase 应该如何实现,最后介绍下 HBase 在云端的实现方案。

冷数据定义就是访问比较少,其访问频次可能会随时间流逝而减少。如你在淘宝买的东西产生的很久以前的订单信息你可能不会去看,还有一些监控数据,当业务有问题你肯定是查最近一小时或者半天的数据,但是半年前的数据你根本访问不到。还有车联网数据一般需要保存多久,这些数据如果政府不查基本很难访问。还有一些归档信息,如银行交易记录归档信息。

我们云服务上对冷数据的定义依据成本估算而言,平均每月访问不会超过十万次,我们认为是比较冷的数据,同时对成本敏感的数据也可以做冷热分离。

传统方案 1.x 版本的解决方案是采用两个集群,一个集群可能是 SSD 的配置,负责在线查询,延迟较低,还有一种是 HDD 的配置。但是这两张表之间需要进行一个同步,客户端需要感知两个集群的配置。优点是简单不需要改 HBase 代码,缺点是双集群维护开销大,还有就是冷集群 CPU 资源可能浪费。2.X 版本引入一个配置,就是你可以指定表的 hfile 存在哪种介质上。主要是利用率 HDFS 分级处理功能,可以给 DataNode 配置不同介质的盘,可以指定表写在冷介质还是热介质上,最后在 HDFS 上可以依据你设置在文件上的属性决定是将数据放在机械盘还是 SSD 上。这样一个集群可以存在冷表和热表,这样相对于 1.X 版本更好管理,但是缺点是因为你要依据你的业务在集群硬件配置,这样如果一个集群混合多种业务或者业务发生变化,几群的硬件配置很难调整。

因此在云端解决方案是一个比较弹性的方案,在介绍之前先介绍下我们云端 HBase。云 HBase 是一个存储计算完全分离的架构,底层是存储,今天主要讲冷存储,云端 regionserver 访问部署的节点,磁盘都是远程读的。因此磁盘大小是可以动态设置的,完全弹性。多模式是 HBase 云端之上除了 HBase 本身 kv 功能,还架设很多开源组件,如 phoenix 做一些简单的查询分析。Graph 主要是应用一些欺诈场景,这个在国外比较成熟,如伪造车祸骗取保险,而图可以分析一个关系网,能够预防这种情况。openTSDB 主要是物联网、车联网这些场景使用,geospatial 是时空数据库,主要应用在轨迹场景。底下存储层主要是有两块,热数据或一般数据会放在云盘,冷数据是放在 OSS。整个模式是一个免运维模式,上来可以直接用。

接下来介绍下 OSS 如何做冷存储,并没有给磁盘配置具体数目,冷表数据是直接放在 OSS 上,同一个集群也能实现冷表和热表。OSS 是阿里的一个对象存储产品,也是一个 k-v 存储,特点是可以存大对象,可以达到 TB 级别,同时保证 99% 的数据可靠性,而且成本非常低。成本和云盘对比,云盘本身也保证数据可靠性,在云上自建 HBase、HDFS 用两副本就可以,以为你需要一个副本保证数据读取可靠性,否则一台机器宕机所有机器都挂掉。当使用云盘需要 0.7,OSS 只需要 0.2。举例说明如某车企拥有 10 万辆车,每车每 30 秒上传 7kb 的包,数据半年基本不访问,三年基本存储量是 2P 左右,那么成本开销相差 2.5 倍。

如果在阿里云上使用 OSS 作为 HBase 的底层存储,Hadoop 社区 Native Oss File System 已经实现,这个类是继承 File System,这样你可以直接替换掉,这样你的读写会直接转发到 OSS 上,也可以享受 OSS 低成本特性。但是存在几个问题,一个是 Native Oss File System 针对的是 MapReduce 离线作业场景实现,在模拟文件系统过程中会有几个问题。因为 OSS 是 k-v 存储,没有文件系统结构,“/”字符并不代表目录,只是代表对象名中某一字符。如果要模拟文件系统创建“/root/parent/son/file”, 你需要创建图中右边四个对象才能模拟出目录结构,这样就导致你对目录操作不是原子的。比如你要讲“/root/parent”root 到其他地方,原本是直接移走,而社区 Native Oss File System 实现是一个遍历递归的过程,如果 server 在 mv 操作时中途 crash 只会移走一部分,导致目录文件不一致。



我们自己实现 Oss File System 方案,这种能避免原子问题。解决方案是将元数据管理还是放在 HDFS 上,在 APP 调用 Hadoop File System 实际是调用 Apsara Distributed File System,这个实现会控制你的文件调用 Oss File System 就将其放到 OSS 里面,调 Distributed File System 就将其放到 HDFS 里面,hlog 也是放在 HDFS 里面,主要考虑的是一个写入性能。

元数据操作通过 Apsara FileSystem 通过请求操作,如果是热表数据就是直接调 Hadoop 的 FileSystem,直接构造 HDFSoutputstream 或者 HDFSinputStream 进行读写。如果是冷数据会在 HDFS 里创建一个冷文件,利用 Hadoop 分级存储功能会有一个属性标记,这个文件存储也是保证原子的。读取冷文件时将读的通道转发到 OSS 上,然后构建一个 OSSinputstream 和 OSSoutputstream。

性能上和社区版比较也做了一些优化,实现上会有一些限制,请求 OSS 是有费用的,Hadoop File System 是提供 OutputStream 接口输入数据,不断调 write 接口将数据写进去,OSS 的 sdk 提供的是一个 InputStream 让数据输入。实现 Hadoop filestream 接口来嫁接到 OSS 上必须做一个 OutputStream 到 InputStream 的转化,社区版实现是将数据写到 native OSS OutputStream 里,实际是写到磁盘上,实际有个 buffer 文件,写满 128M 将其包装成 file InputStream 提交给 OSS 的 SDK,会有一个异步线程池来提交 buffer 文件。这样存在的问题是写入过程需要入磁盘,会损耗性能;第二比较依赖磁盘性能,异步发送 buffer 会变成一个单线程;crash 会残留这些文件,对运维比较麻烦。

我们实现版本写入是不在磁盘落地,中间会有一个 ring buffer(只有几 M),用户写入到 ring buffer 里,里面由固定数量配置组成,有 5 个配置。蓝色是写入,绿色有一个异步线程将蓝色写好的数据读取出来包装成 inputstream,相当于实时源源不断类似于流的形式。每当 inputstream 被 OSS 的 SDK 读完 128M,将数据提交,然后再有数据写入再包装成 inputstream。成本上都相当于 128M 提交一次,请求成本很低,但是写入完全不需要落地磁盘,占用内存开销也很少。性能测试写入吞吐差 25%,我的 valuesize 只有 100B。

在 HBase 使用这个特性,建表的时候配一下 config,create ‘test’, {NAME => ‘info’}, CONFIGURATION => {‘HFILE_STORAGE_POLICY’=>‘COLD’} 将表变为冷表,那么所有数据都会存在 OSS 里面。冷存储使用场景建议是写多读少、顺序读,如果持续读会限制存储读的 lops,请求是有成本的,每 get 一次需要到文件上 seek 一次,等于发生一次请求到 OSS。如果是顺序读或者是写入流量不限,写入的 tds 也是不限的,如果冷数据很少读只是偶尔读 lops 会适当放宽机制。

对比将表放在 OSS 和放在云盘上,测试配置 DFS 6 台 8 核 32G Data Node HBase 1 台 8 核 32G Region Server,对比 TPS 是相差不大,略高一点是因为 hlog 也是在云盘上,hfile 流量是打在云盘上。虽然定义为冷存储,但是写入吞吐量是和云盘茌平的。

除了冷存储特性,还有一些其他特性,如企业级安全,除了白名单机制还做了一个基于 VPC 机制的 ECS 方案,通过 User/Password 模式访问云 HBASE。还准备推出一种双活模式,满足集群级别的容灾,一个机房出错其他机房不受影响。异步同步保持数据一致性,再者在切换时,延迟不超过 200ms。

上图列举了云 HBase 和自建 HBase 的一些特性,如果关注社区的可以看到有个 ccsmap 会替换现在 mainstore 结构,目前 mainstore 数据结构是 region 列表,如果记录很多会存在很多对象,这样对 YGC 压力很大。Ccsmap 使用数组连模拟这个列表,理论上能将 YGC 延迟降到 5ms,社区版本会有 100ms 延迟。

作者介绍:

郭泽晖(花名:索月),阿里云技术专家,HBase contributor,负责云 HBase 平台设计 & 开发。

——END——


本文地址:http://www.6aiq.com/article/1536989556514
知乎专栏 点击关注
本文版权归作者和AIQ共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出