在信息爆炸的大数据时代，如何以更低成本来解决海量数据的存储问题，已成为企业大数据业务中的重要一环。UCloud自研的新一代对象存储服务US3，在过来一段时间，针对大数据业务场景推出了计算存储拆散和大数据备份解决方案。

这背地的次要起因包含：

1、因为网络技术的高速倒退，使得网络传输性能不再是大数据场景下高吞吐业务需要的瓶颈；
2、Hadoop技术栈中的HDFS存储解决方案运维简单且老本昂扬；
3、云平台基于海量存储资源池构建的对象存储服务US3具备按需应用、操作简略、牢靠稳固、价格便宜的劣势，是替换HDFS的最佳存储计划抉择。因而，为了让用户可能更加不便的在Hadoop场景下，应用US3实现计算存储拆散和大数据备份解决方案，US3自研了US3Hadoop适配器、US3Vmds、US3Distcp三个组件。

本文次要介绍US3Hadoop适配器在研发设计过程中的一些思路和问题解决。

总体设计思路

Hadoop生态里对存储的操作基本上都是通过一个通用的文件系统基类FileSystem来进行的。US3Hadoop适配器(简称:适配器)是通过US3FileSystem实现该基类来操作US3。相似于HDFS实现的DistributedFileSystem和基于AWS S3协定实现的S3AFileSystem。适配器间接把IO和索引都申请发给US3，架构如下图所示：

这里的索引操作次要是不波及读写数据的API，如: HEADFile, ListObjects, Rename, DeleteFile, Copy(用于批改metadata)；IO操作的API，如GetFile，PutFile(小于4M文件)曾经分片上传相干的4个API: InitiateMultipartUpload，UploadPart，FinishMultipartUpload，AbortMultipartUpload。US3有了这些API后，怎么跟FileSystem的成员办法能对应起来，能够看下FileSystem须要重写哪些办法。结合实际需要和参考DistributedFileSystem、S3AFileSystem的实现，咱们确定了须要重写的次要办法：initialize、create、rename、getFileStatus、open、listStatus、mkdirs、setOwner、setPermission、setReplication、setWorkingDirectory、getWorkingDirectory、getSchem、getUri、getDefaultBlockSize、delete。同时对一些难以模仿的办法，重写为异样不反对，如Append成员办法。

其实从下面FileSystem的成员办法阐明来看，其语义和单机文件系统引擎的接口语义相似，基本上也是以目录树结构来组织治理文件系统。US3提供的ListObjects API刚好也提供了目录树拉取的一种形式，当Hadoop调用listStatus办法时，就能够通过ListObjects循环拉取到当前目录(前缀)下所有子成员从而返回对应的后果。

设置文件所属用户/组，操作权限等相干操作则利用了US3的元数据性能，把这些信息都映射到文件的KV元数据对上。写入文件流则会优先缓存在内存中最多4MB数据，再依据后续的操作来决定采纳PutFile还是分片上传的API来实现。

读取文件流则通过GetFile返回流实例来读取期待的数据。尽管这些办法实现看上去很直白，然而潜在着很多值得优化的中央。

getFileStatus的时空博弈
通过剖析FileSystem的调用状况，能够晓得索引操作在大数据场景中占比达70%以上，而getFileStatus在索引操作重占比最高，所以有必要对其进行优化。那优化点在哪里呢？

首先因为US3中的“目录”(对象存储是KV存储，所谓目录只是模仿而已)是以‘/’结尾的Key，而FileSystem的对文件的操作是通过Path构造进行，该构造的门路都不会以‘/’结尾，所以通过Path拿到的Key去US3中进行HeadFile时，有可能因为该Key在US3中是目录，HeadFile就会返回404, 必须通过第二次用“Key/”去US3中Head能力确认。如果这个Key目录还是不存在，就会导致getFileStatus时延大大增加了。

因而US3适配在创立目录时做了以下两件事:1．向US3写入mime-type为“file/path”, 文件名为“Key”的空文件;2．向US3写入mime-type为“application/x-director”, 文件名为“Key/”的空文件;

而一般文件mime-type为“application/octet-stream”。这样在getFileStatus中通过一次HeadFile API就判断以后Key到底是文件还是目录，同时当该目录下为空时，也能在US3控制台展现出该目录。而且因为Hadoop场景写入的次要是大文件，减少一次空文件索引的写入耗时在ms级别，时延根本可疏忽。

此外，getFileStatus在Hadoop的应用中具备显著的“时空局部性”特色，在具体的FileSystem实例中最近被getFileStatus操作的Key，在短时间会被屡次操作。利用这个特点，US3FileSystem在实现过程中，getFileStatus失去对应的后果在FileStatus返回之前，会把有3s生命周期的FileStatus插入到Cache中。那后续3秒内对该Key的操作就会复用Cache中该Key的FileStatus信息，当然delete操作会在US3中删除完Key后，间接把Cache中的无效FileStatus标记为有3s生命周期的404 Cache，或者直接插入一个有3s生命周期的404 Cache。如果是rename，会复用源的Cache来结构目标Key的Cache，并删除源，这样就能缩小大量跟US3的交互。Cache命中(us级别)会缩小getFileStatus上百倍的时延。

当然这会引入肯定的一致性问题，但仅限于在多个Job并发时至多有一个存在“写”的状况，如delete和rename的状况下，如果仅仅只有读，那么无影响。不过大数据场景根本属于后者。

ListObjects一致性问题

US3的ListObjects接口跟其余对象存储计划相似，目前都只能做到最终一致性（不过US3后续将推出强一致性保障的ListObjects接口），因而其余对象存储实现的适配器也都会存在写入一个文件，而后立刻调用listStatus时会偶然呈现这个文件不存在的状况。其余对象存储计划有时会通过引入一个中间件服务(个别是数据库)，当写入一个文件会向这个中间件写入这个文件索引，当listStatus时会跟中间件的索引信息进行合并，这样的确缓解了这种状况，进一步提高了一致性。

但还不够，比方写入对象存储胜利，但写入中间件时程序奔溃了，这样就导致不统一的问题，又回到了最终一致性的问题。

US3Hadoop适配器的实现绝对更加简略无效，不须要借助额定的服务，能提供索引操作级别的Read-Your-Writes一致性，而该一致性级别在Hadoop大部分场景根本等同于强一致性。US3Hadoop适配器不像S3AFileSystem的实现，在create或者rename、delete后立马返回，而是在外部调用ListObjects接口做了一次“对账”，直到“对账”后果合乎预期则返回。

当然这里也是有优化空间的，比方delete一个目录时，对应会把这个目录下所有文件先拉进去，而后顺次调用DeleteFile API去删除，如果每次DeleteFile API删除都“对账”一次，那么整个时延会翻倍。US3Hadoop适配器的做法是只对最初一次索引操作进行“对账”，这是因为索引的oplog是按时序同步到列表服务中，如果最初一条索引“对账”胜利，那么后面的oplog肯定在列表服务中写入胜利。

Rename的深度定制

后面提到的rename也是US3的一个重要优化点，其余对象存储计划的实现个别通过Copy的接口会先把文件复制一遍，而后再删除源文件。能够看出如果rename的文件很大，那么rename的整个过程势必导致时延很高。

US3依据该场景的需要，专门开发了Rename的API接口，因而US3Hadoop适配器实现rename的语义绝对比拟轻量，而且时延放弃在ms级别。

保障read高效稳固

读是大数据场景的高频操作，所以US3Hadoop适配器的读取流实现，不是对http响应的body简略封装，而是思考了多方面的优化。例如，对读取流的优化，通过退出预读Buffer，缩小网络IO零碎调用频率，升高read操作的期待时延，特地是大批量程序读的IO晋升成果显著。

另外，FileSystem的读取流具备seek接口，也就是须要反对随机读，这里又分两种场景：

1、seek到已读流地位的前置地位，那么作为Underlay Stream的Http响应的body流就要作废敞开掉，须要从新发动一个从seek的地位开始分片下载的GetFile API，取得其Http响应的body流来作为新的Underlay Stream。然而理论测试过程中发现，很多seek操作过后不肯定会进行read操作，有可能间接敞开，或者seek回到已读取流地位的后置地位，所以在seek产生时，US3Hadoop适配器的实现是只做seek地位标记，在read的时候依据理论状况对Underlay Stream做提早敞开关上解决。此外如果seek的地位还在Buffer中，也不会从新关上Underlay Stream，而是通过批改Buffer的生产偏移。

2、随机读的另一种场景就是，seek到已读流地位的后置地位。这里同样跟后面一样采纳提早流关上，然而在确定要做实在的seek操作时，不肯定会通过敞开老的Underlay Stream，从新在指标地位关上新的Underlay Stream来实现。因为以后已读的地位跟seek的后置地位可能间隔很近，假如只有100KB间隔，说不定这段距离齐全在预读Buffer的范畴中，这时也能够通过批改Buffer的生产偏移来实现。

事实上US3Hadoop适配器的确也是这么做的，不过目前的规定是seek的后置地位到以后已读流地位的间隔小于等于预读Buffer残余空间加上16K的和，则间接通过批改预读Buffer的生产偏移和生产Underlay Stream中的数据来定位到seek的后置地位上。之所以还加了16K是思考到TCP接管缓存中的数据。当然后续确定从一个ready的Underlay Stream中生产N字节数据的工夫老本大抵等于从新发动一个GetFile API并在筹备传输该Http响应body之前的工夫老本，也会思考把这N字节的因素计入偏移计算过程中。

最初流的优化还要思考到Underlay Stream异样的状况，比方HBase场景长时间持有关上的流，却因为其余操作导致长时间没有操作该流，那么US3可能会被动敞开开释Underlay Stream对应的TCP连贯，后续对在Underlay Stream上的操作就会报TCP RST的异样。为了提供可用性，US3Hadoop适配器的实现是在曾经读取地位点上进行Underlay Stream的从新关上。

写在最初

US3Hadoop适配器的实现在借鉴开源计划下，进一步优化了相干外围问题点，晋升了Hadoop拜访US3的可靠性与稳定性，并在多个客户案例中施展着买通Hadoop与US3的重要桥梁作用，帮忙用户晋升大数据场景下的存储读写效率。

但US3Haoop适配器还存在很多可晋升的空间，相比于HDFS，索引、IO的时延还有差距，原子性保障上也绝对比拟弱，这些也是咱们接下来要思考解决的问题。目前推出的US3Vmds解决了索引时延的大部分问题，使得通过US3Hadoop适配器操作US3的性能失去大幅晋升，并在局部场景靠近原生HDFS的性能。具体数据能够参考官网文档(https://docs.ucloud.cn/ufile/...

将来，US3产品会不断改进优化大数据场景下的存储解决方案，在升高大数据存储老本的同时，进一步晋升用户在大数据场景下的US3应用体验。