前言
在YARN上运行的任务，在任务正式开始运行之前，需要有一步资源的localization的过程，然后用户的任务才能顺利地跑起来。这个”资源“可以是用户依赖的库文件等任务运行所需要的文件。这些资源文件被YARN中此任务对应的Container所共享，这些Container会从一个共享存储的地方去下载这个资源文件。那么在此之前，这个资源文件还需要被上传到一个共享存储的地方。本文，笔者将要阐述的主题就是关于共享存储的主题。
YARN的共享存储服务的起源
在YARN早期的实现中，YARN将HDFS作为一个中间资源文件的存储媒介，然后后续的Container task根据资源路径从HDFS中download下文件。这个资源文件并不是完全共享的，它只作用于当前所属的应用，更准确地来说，它只作用于某个applicationId。在这种模式下，假设后续有完全相同的任务再次被执行，它还是要上传完全一样的文件到HDFS中，这无疑造成了带宽的浪费。
于是，YARN实现了一种真正意义上的完全共享的存储服务，它可以跨应用间提供资源的共享服务，下面开始进入本文的主题。
YARN的共享存储服务架构
共享存储服务的组件构成
YARN的共享存储服务并没有实现在现有的RM服务中，而是另外实现了一个独立的服务来做这个事情，名为ShardCacheManager。在这个Manager内，具体模块包含以下：
- SharedCacheUploaderService，缓存资源上传服务，用以上传用户的资源文件。
- CleanerService，缓存资源清理服务，清理stale的资源文件。
- ClientProtocolService，用户提交使用资源的协议。
- SCMAdminProtocolService，共享存储服务管理员接口服务，目前只要用于外界人工触发启动cleaner服务。
- SCMStore，共享存储资源的元数据信息存储，目前SCM只维护了in memory的存储，还并不支持persist的外部存储。
共享存储服务的流程
当我们说一个任务启动的时候，它是如何将自己的资源文件上传到YARN的共享存储服务中，供后续其它应用的使用呢？下面我们来简单看看里面的过程。
1)任务在正常执行YARN内部的localization之后，判断是否启用共享存储的服务，如果启用了，则调用ClientProtocolService接口，上传资源文件到SCM服务中。
2)SCM进而会触发SharedCacheUploaderService来上传用户的资源文件，在这里资源文件的区分方式是以它的checksum值作为唯一区分标志key，然后再结合一定的目录深度。目录深度的引入是为了防止一个目录下文件数量过多导致性能下降。同时还有appId的传入，意为此appId对该资源的一个引用。对应地，有一个释放资源的接口，两个客户端使用接口定义如下：
Path use(String checksum, String appId)
boolean release(String checksum, String appId);
如上面use接口定义的，当应用在请求使用一个已有资源的情况时，它会得到一个HDFS的path，然后直接从这个path里去取得资源。
3)对应共享存储服务而言，它的定位是足以支持大规模量级的缓存资源文件，它不仅在目录级别做了深度划分的处理，其次它实现了一种基于staleness的资源清除策略。此规则策略大致如下：
1.每个共享存储资源在SCMStore中除了标志key信息外，还额外附有1)最近访问时间2)引用计数值信息。
2.当满足没有应用引用该共享存储资源并且他的最近访问时间距离当前时间已经超过stale阈值时，cleaner服务即可以将此资源从HDFS中删除了。SCM以此达到一个比较稳定的资源存储量。
按照上述的步骤，流程图如下所示：
后续改进工作
当然在后续还是有很多东西可以进行继续完善的，比如设计Security方面的控制，token，authorization的管控，SCM服务和RM的localization服务之间的协同合作等等。
回过头来看YARN的共享存储服务，整体实现较为轻量级，因为实际存储过程完全依赖了HDFS,所以过程也比较清晰，简洁。用一句话来概括其实现，SCM是基于HDFS之上实现了一个二次资源存储管理系统。
参考文献
[1].https://issues.apache.org/jira/browse/YARN-1492 . truly shared cache for jars (jobjar/libjar)