HDFS缓存机制

前言

缓存,英文单词译为Cache,缓存可以帮助我们干很多事,当然最直接的体会就是可以减少不必要的数据请求和操作.同样在HDFS中,也存在着一套完整的缓存机制,但可能使用了解此机制的人并不多,因为这个配置项平时大家比较少用而且HDFS中默认是关闭此功能的.至于是哪个配置项呢,在后面的描述中将会给出详细的分析.

HDFS缓存疑问点

为什么在这里会抛出这样一个问题呢,因为本人在了解完HDFS的Cache整体机理之后,确实感觉到其中的逻辑有点绕,直接分析不见得会起到很好的效果,所以先采取提问的形式来做一个引导会是一个不错的选择.列举如下几个问题,在这里缓存的对象block数据块,需要缓存的目标block叫做CacheBlock,block块从缓存状态需要转变为非缓存状态的block块称之为UnCacheBlock.

如何在物理层面缓存目标block块?
缓存块的生命周期状态有哪几种?
哪些情况会触发CacheBlock, UnCacheBlock操作?
CacheBlock,UnCacheBlock缓存块如何确定?
系统所持有的CacheBlock列表如何更新?
CacheBlock如何被使用?

现在依次从上到下依次揭开谜底,最后你一定会有种恍然大悟的感觉.

HDFS物理层面缓存Block

物理层面缓存Block,这个名词听上去意思怪怪的.在HDFS源码中的解释如下:

Manages caching for an FsDatasetImpl by using the mmap(2) and mlock(2) system calls to lock blocks into memory.

大意为利用mmap,mlock系统调用将block锁入内存.没接触过底层操作系统知识的人可能不是很清楚mmap,mlock调用是怎么一回事,在这里就简单介绍一下.这里以mmap为例,他其实是一个内存映射调用,百度百科中关于mmap的解释如下:

mmap将一个文件或者其它对象映射进内存。文件被映射到多个页上，如果文件的大小不是所有页的大小之和，最后一个页不被使用的空间将会清零。mmap在用户空间映射调用系统中作用很大。

我们主要关注前半部分的解释,将文件或其他对象映射进行内存,这句话直接在代码中得到了体现.

HDFS缓存机制

在上面的代码中,blockChannel对象(本质对象是FileChannel)就被映射到内存上了.OK,当然这是最底层执行的操作了,在HDFS中的上层调用是如何的呢,这才是我们所要真正关心的.

缓存块的生命周期状态

缓存块的生命周期不仅仅只有Cached(已缓存)和(UnCached)(已解除缓存)2种.在FSDatasetCache类中,有了明确的定义:

HDFS缓存机制

这个状态信息被保存在了实际存储的Value中

HDFS缓存机制

实际存储的Value与Block块就构成了Cache中非常常见的key-value的结构

HDFS缓存机制

可能有人会疑问为什么这里不直接用64位的blockId直接当key,而是用ExtendedBlockId,答案是因为要考虑到Block Pool的存在,现在的HDFS是支持多namespace命名空间的.ExtendedBlockId, Value键值对的存储与清除发生在cacheBlock和unCacheBlock方法.

HDFS缓存机制

然后放入CachingTask中异步执行.同理unCacheBlock方法也放在了异步线程中执行.

HDFS缓存机制

CacheBlock,UnCacheBlock场景触发

按照上面的问题顺序,第三个问题就是哪种情况会触发缓存块的行为呢.同样我们要将此情形分为2类,一个是cacheBlock,另外一个就是unCacheBlock.

CacheBlock动作

在ide中通过open call的方式可以追踪出他的上层方法调用,如图

HDFS缓存机制

最下层的方法已经表明了此方法最终是来自于NameNode心跳处理的回复命令.挑出其中一个方法进行查阅

HDFS缓存机制

UnCacheBlock动作

解除缓存block的动作是否也是来自于NameNode的反馈命令呢,答案其实并不仅限如此.同样给出调用关系图

HDFS缓存机制

可以看到,这里汇总成3类调用情况:

当block块被执行append写操作
当block被处理为invalidate的时候
上层NameNode发送unCache反馈命令

其中最后一种跟上小节提到的情况一样,是从NameNode中收到的反馈命令所致.前面2类情况导致unCache动作的理由很好理解.

因为block块被继续执行了写动作,数据必然发生改变,原有的cache缓存块就要重新被更新.
当block被处理为invalidate无效块的时候,接着会被NameNode从系统中清除,cache缓存块自然而言就没有存在的必要了.

CacheBlock,UnCacheBlock缓存块的确定

目标缓存块的确定问题本质上归结为就是上面NameNode中cacheBlock,unCacheBlock回复命令中的blockId组的缘来,就是下述代码中的block pool Id和blockIds.

dn.getFSDataset().cache(blockIdCmd.getBlockPoolId(), blockIdCmd.getBlockIds());

blockIdCmd是NameNode心跳处理的回复命令,所以必然存在回复处理的过程,从而构造出了blockIdCmd的回复指令.这里直接定位到DatanodeManager#handleHeartbeat命令处理方法中

HDFS缓存机制

从这里可以看出,cacheBlock和unCacheBlock来源于nodeInfo中的pendingCache和pendingUncache,实质获取的变量如下:

HDFS缓存机制

好像离目标越来越近了,只要能找到CachedBlockList的直接操作方,就能明白缓存block以及解除缓存block是如何确定的.通过进一步的上层调用,最后发现真正的操作主类CacheReplicationMonitor,这个类的用途如下:

Scans the namesystem, scheduling blocks to be cached as appropriate.

在这里,我做些补充解释,CacheReplicationMonitor自身持有一个系统中的标准缓存块列表,然后通过自身内部的缓存原则,进行cacheBlock的添加和移除,然后对应更新到之前提到过的pendingCache和pendingUncache列表中,随后这些pending信息就会被NameNode拿来放入回复命令中.这里就会有2个疑惑点:

CacheReplicationMonitor内部维护的系统标准缓存块哪里来
CacheReplicationMonitor内部缓存原则,策略是什么,什么情况下block应该被Cache,什么情况下又可以取消Cache

第一个问题会在下面的小节中提到,这里集中看第二条.答案在rescanCachedBlockMap的方法中.鉴于此方法代码处理逻辑比较复杂,我们直接看方法注释中的解释:

Scan through the cached block map.

Any blocks which are under-replicated should be assigned new Datanodes.

Blocks that are over-replicated should be removed from Datanodes.

这里给出了2个基本原则:

任何少于标准副本块个数的副本应该缓存到新的节点上
过副本数的缓存block应该从节点上进行移除

其实仔细一想,这个策略还是很巧妙的,尽量多缓存一些副本数不够的副本(缓存相当于充当了1块副本),移除掉副本数过多的多余缓存.

系统持有的CacheBlock列表如何更新

在上节中提到过CacheReplicationMonitor对象持有的系统CacheBlock列表如何被更新的问题,这个列表是用来发送pendingCache,pengdUncache信息的基础.因为是系统所全局持有的,会存在反馈上报的过程.同样存在于心跳处理代码的附近.

HDFS缓存机制

继续调用到下面这行操作

HDFS缓存机制

最后又重新调用到了FSDatasetCache中的getCacheBlocks方法.到这里你应该可以发现,这里形成了一个闭环操作.最后的缓存操作执行者同样也是缓存块情况的反馈者.CacheReplicationMonitor属于CacheManager对象的内部变量,会从中拿到cacheBlock块的最新信息.