做动效的网站,wordpress 3无法上传rar zip,杭州app开发公司普悦科技,广州花都网站建设前言
HBase是当下流行的一款海量数据存储的分布式数据库。往往海量数据存储会涉及到一个成本问题#xff0c;如何降低成本。常见的方案就是通过冷热分离来治理数据。冷数据可以用更高的压缩比算法#xff08;ZSTD#xff09;#xff0c;更低副本数算法#xff08;Erasure…前言
HBase是当下流行的一款海量数据存储的分布式数据库。往往海量数据存储会涉及到一个成本问题如何降低成本。常见的方案就是通过冷热分离来治理数据。冷数据可以用更高的压缩比算法ZSTD更低副本数算法Erasure Coding更便宜存储设备HDD高密集型存储机型。
HBase冷热分离常见解决方案
1.主备集群
备冷集群用更廉价的硬件主集群设置TTL这样当数据热度退去冷数据自然只在冷集群有。 优点方案简单现成内核版本都能搞 缺点维护开销大冷集群CPU存在浪费
1.x版本的HBase在不改内核情况下基本只能有这种方案。
2.HDFS Archival Storage HBase CF-level Storage Policy
需要在2.x之后的版本才能使用。结合HDFS分层存储能力 在Table层面指定数据存储策略实现同集群下不同表数据的冷热分离。 优点同一集群冷热分离维护开销少更灵活的配置不同业务表的策略 缺点磁盘配比是个很大的问题不同业务冷热配比是不一样的比较难整合在一起一旦业务变动集群硬件配置是没法跟着变的。
云HBase冷热分离解决方案
上述2套方案都不是最好的方案对于云上来说。第一套方案就不说了客户搞2个集群对于数据量不大的客户其实根本降不了成本。第二套方案云上客户千千万业务各有各样磁盘配置是很难定制到合适的状态。
云上要做 cloud native 的方案必须满足同集群下极致的弹性伸缩才能真正意义上做到产品化。云上低成本弹性存储只有OSS了。所以很自然的想到如下架构 实现这样的架构最直接的想法是直接改HBase内核1增加冷表数据标记 2根据标记增加写OSS的IO路径。
这样做的缺陷非常明显你的外部系统如备份恢复数据导入导出很难兼容这些改动他们需要感知哪些是冷文件得去OSS哪个位置读哪些是热文件得去部署在云盘上的HDFS上读。这些本质上都是一些重复的工作所以从架构设计角度来看必须抽象出一层。这一层能读写HDFS文件读写OSS文件感知冷热文件。这一层也就是我最后设计出的ApsaraDB FileSystem实现了Hadoop FileSystem API。对于HBase备份恢复数据导入导出等系统只要替换原先FileSystem的实现即可获得冷热分离的功能。
下面将详细阐述这套FileSystem设计的细节与难点。
ApsaraDB FileSystem 设计
核心难点A
1.OSS并非文件系统
OSS并不是一个真正意义上的文件系统它仅仅是两级映射 bucket/object所以它是对象存储。你在OSS上看到类似这样一个文件/root/user/gzh/file。你会以为有3层目录1个文件。实际上只有一个对象这个对象的key包含了/字符罢了。
这么带来的一个问题是你要想在其上模拟出文件系统你必须先能创建目录。很自然想到的是用/结尾的特殊对象代表目录对象。Hadoop社区开源的OssFileSystem就是这么搞的。有了这个方法就能判断到底存不存在某个目录能不能创建文件不然会凭空创建出一个文件而这个文件没有父目录。
当然你这么做依然会有问题。除了开销比较大创建深层目录多次HTTP请求OSS最严重的是正确性的问题。试想一下下面这个场景 把目录/root/user/source rename 成 /root/user/target。这个过程除了该目录它底下的子目录子目录里的子文件都会跟着变。类似这样/root/user/source/file /root/user/target/file。这很好理解文件系统就是一颗树你rename目录实际是把某颗子树移动到另一个节点下。这个在NameNode里的实现也很简单改变下树结构即可。
但是如果是在OSS上你要做rename那你不得不递归遍历/root/user/source把其下所有目录对象文件对象都rename。因为你没法通过移动子树这样一个简单操作一步到位。这里带来的问题就是假设你递归遍历到一半挂了。那么就可能会出现一半目录或文件到了目标位置一半没过去。这样rename这个操作就不是原子的了本来你要么rename成功整个目录下的内容到新的地方要么没成功就在原地。所以正确性会存在问题像HBase这样依赖rename操作将临时数据目录移动到正式目录来做数据commit就会面临风险。
2.OSS rename实则是数据拷贝
前面我们提到了rename在正常文件系统中应该是一个轻量级的数据结构修改操作。但是OSS并没有rename这个操作实际上rename得通过 CopyObject DeleteObject 两个操作完成。首先是copy成目标名字然后delete掉原先的Object。这里有2个明显的问题一个是copy是深度拷贝开销很大直接会影响HBase的性能。另一个是rename拆分成2个操作这2个操作是没法在一个事物里的也就是说可能存在copy成功没delete掉的情况此时你需要回滚你需要delete掉copy出来的对象但是delete依然可能不成功。所以rename操作本身实现上正确性就难以保证了。
解决核心难点A
解决上面2个问题需要自己做元数据管理即相当于自己维护一个文件系统树OSS上只放数据文件。而因为我们环境中仍然有HDFS存储在为了放热数据所以直接复用NameNode代码让NodeNode帮助管理元数据。所以整体架构就出来了 ApsaraDB FileSystem以下简称ADB FS将云端存储分为主存PrimaryStorageFileSystem和 冷存ColdStorageFileSystem。由ApsaraDistributedFileSystem类以下简称ADFS负责管理这两类存储文件系统并且由ADFS负责感知冷热文件。
ApsaraDistributedFileSystem 总入口负责管理冷存和主存数据该从哪里读该写入哪里ADFS。主存PrimaryStorageFileSystem 默认实现是 DistributedFileSystemHDFS冷存ColdStorageFileSystem 默认实现是 HBaseOssFileSystemHOFS 基于OSS实现的Hadoop API文件系统可以模拟目录对象单独使用也可以只作为冷存读写数据相比社区版本有针对性优化后面会讲。
具体NameNode如何帮助管理冷存上的元数据很简单。ADFS在主存上创建同名索引文件文件内容是索引指向冷存中对应的文件。实际数据在冷存中所以冷存中的文件有没有目录结构无所谓只有一级文件就行。我们再看下一rename操作过程就明白了 rename目录的场景也同理直接在NameNode中rename就行。对于热文件相当于全部代理HDFS操作即可冷文件要在HDFS上创建索引文件然后写数据文件到OSS然后关联起来。
核心难点B
引入元数据管理解决方案又会遇到新的问题是索引文件和冷存中数据文件一致性问题。 我们可能会遇到如下场景
主存索引文件存在冷存数据文件不存在冷存数据文件存在主存索引文件不存住主存索引文件信息不完整无法定位冷存数据文件
先排除BUG或者人为删除数据文件因素上诉3种情况都会由于程序crash产生。也就是说我们要想把法把生成索引文件写入并生成冷数据文件关联这3个操作放在一个事物里。这样才能具备原子性才能保证要么创建冷文件成功那么索引信息是完整的也指向一个存在的数据文件。要么创建冷文件失败包括中途程序crash永远也见不到这个冷文件。
解决核心难点B
核心思想是利用主存的rename操作因为主存的rename是具备原子性的。我们先在主存的临时目录中生产索引文件此时索引文件内容已经指向冷存中的一个路径但是实际上这个路径的数据文件还没开始写入。在冷存完成写入正确close后那么此时我们已经有完整且正确的索引文件数据文件。然后通过rename一把将索引文件改到用户实际需要写入到目标路径即可。
如果中途进程crash索引文件要么已经rename成功要么索引文件还在临时目录。在临时目录我们认为写入没有完成是失败的。然后我们通过清理线程定期清理掉N天以前临时目录的文件即可。所以一旦rename成功那目标路径上的索引文件一定是完整的一定会指向一个写好的数据文件。
为什么我们需要先写好路径信息在索引文件里因为如果先写数据文件在这个过程中crash了那我们是没有索引信息指向这个数据文件的从而造成类似“内存泄漏”的问题。 冷热文件标记
对于主存需要实现给文件冷热标记的功能通过标记判断要打开怎样的数据读写流。这点NameNode可以通过给文件设置StoragePolicy实现。这个过程就很简单了不详细赘述下面说HBaseOssFileSystem写入优化设计。
HBaseOssFileSystem 写入优化
在说HOFS写设计之前我们先要理解Hadoop社区版本的OssFileSystem设计这也是社区用户能直接使用的版本。
社区版本写入设计
Write - OutputStream - disk buffer(128M) - FileInputStream - OSS
这个过程就是先写入磁盘磁盘满128M后将这128M的block包装成FileInputStream再提交给OSS。这个设计主要是考虑了OSS请求成本OSS每次请求都是要收费的但是内网流量不计费。如果你1KB写一次费用就很高了所以必须大块写。而且OSS大文件写入设计最多让你提交10000个blockOSS中叫MultipartUpload如果block太小那么你能支持的最大文件大小也是受限。
所以要攒大buffer另外一个因素是Hadoop FS API提供的是OutputStream让你不断write。OSS提供的是InputStream让你提供你要写入内容它自己不断读取。这样你必然要通过一个buffer去转换。
这里会有比较大的一个问题就是性能慢。写入磁盘再读取磁盘多了这么两轮会比较慢虽然有PageCache存在读取过程不一定有IO。那你肯定想用内存当buffer不就好了。内存当buffer的问题就是前面说的有费用所以buffer不能太小。所以你每个文件要开128M内存是不可能的。更何况当你提交给OSS的时候你要保证能继续写入新数据你得有2块128M内存滚动这个开销几乎不能接受。
HBaseOssFileSystem 写入设计
我们既要解决费用问题也要解决性能问题同时要保证开销很低看似不可能那么怎么做呢
这里要利用的就是这个InputStreamOSS让你提供InputStream并从中读取你要写入的内容。那么我们可以设计一个流式写入当我传入这个InputStream给OSS的时候流中并不一定得有数据。此时OSS调read读取数据会block在read调用上。等用户真的写入数据InputStream中才会有数据这时候OSS就能顺利读到数据。当OSS读了超过128M数据时候InputStream会自动截断返回EOF这样OSS会以为流已经结束了那么这块数据就算提交完成。
所以我们本质只要开发这么一个特殊的InputStream即可。用户向Hadoop API提供的OutputStream中写入数据数据每填满一个page2M就发给InputStream让其可读取。OuputStream相当于生产者InputStream相当于消费者。这里的内存开销会非常低因为生产者速度和消费者速度相近时也就2个page的开销。最后将这整套实现封装成OSSOutputStream类当用户要写入冷文件时实际提供的是OSSOutputStream这里面就包含了这个特殊InputStream的控制过程。
当然实际生产中我们会对page进行控制每个文件设置最多4个page。并且这4个page循环利用减少对GC对影响。所以最后我们得到下面一个环形缓冲的写入模式 性能对比1社区版本 vs 云HBase版
因为不用写磁盘所以写入吞吐可以比社区的高很多下图为HBase1.0上测试结果。在一些大KV写入压力更大的场景实测可以接近1倍。这个比较是通过替换ADFS冷存的实现(用社区版本和云HBase版本)都避免了rename深拷贝问题。如果直接裸用社区版本而不用ADFS那性能会差数倍。 性能对比2热表 vs 冷表
热表数据在云盘冷表数据在OSS。 得益于上述优化加上冷表WAL也是放HDFS的并且OSS相对HBase来说是大集群吞吐上限高冷表的HDFS只用抗WAL写入压力。所以冷表吞吐反而会比热表略高一点点。
不管怎么说冷表的写入性能和热表相当了这样的表现已经相当不错了。基本是不会影响用户灌数据否则使用冷存后吞吐掉很多那意味着要更多机器那这功能就没什么意义了。
总结
这大约是1年多前落地的项目已经稳定运行很久。之前也有出去分享过但是没有今天这么细致。现在写出来主要是自我总结下。当设计一个服务去解决某个问题的时候上下游的关系可能存在的问题得考虑清楚。在做这个项目最初的时候想把HBase直接架设在社区版本OssFileSytem上发现性能不行外正确性也存在很大风险。不断思考考虑各种情况后才有了今天这套方案。
原文链接 本文为云栖社区原创内容未经允许不得转载。
