HDFS集中式的缓存管理原理与代码剖析.docVIP

HDFS集中式的缓存管理原理与代码剖析 Hadoop 2.3.0已经发布了，其中最大的亮点就是集中式的缓存管理 HDFS centralized cache management 。这个功能对于提升Hadoop系统和上层应用的执行效率与实时性有很大帮助，本文从原理、架构和代码剖析三个角度来探讨这一功能。 用户可以根据自己的逻辑指定一些经常被使用的数据或者高优先级任务对应的数据，让他们常驻内存而不被淘汰到磁盘。例如在Hive或Impala构建的数据仓库应用中fact表会频繁地与其他表做JOIN，显然应该让fact常驻内存，这样DataNode在内存使用紧张的时候也不会把这些数据淘汰出去，同时也实现了对于 mixed workloads的SLA。 centralized cache是由NameNode统一管理的，那么HDFS client（例如MapReduce、Impala）就可以根据block被cache的分布情况去调度任务，做到memory-locality。 HDFS原来单纯靠DataNode的OS buffer cache，这样不但没有把block被cache的分布情况对外暴露给上层应用优化任务调度，也有可能会造成cache浪费。例如一个block的三个replica分别存储在三个DataNote 上，有可能这个block同时被这三台DataNode的OS buffer cache，那么从HDFS的全局看就有同一个block在cache中存了三份，造成了资源浪费。 加快HDFS client读速度。过去NameNode处理读请求时只根据拓扑远近决定去哪个DataNode读，现在还要加入speed的因素。当HDFS client和要读取的block被cache在同一台DataNode的时候，可以通过zero-copy read直接从内存读，略过磁盘I/O、checksum校验等环节。 即使数据被cache的DataNode节点宕机，block移动，集群重启，cache都不会受到影响。因为cache被NameNode统一管理并被被持久化到FSImage和EditLog，如果cache的某个block的DataNode宕机，NameNode会调度其他存储了这个replica的DataNode，把它cache到内存。 cache directive: 表示要被cache到内存的文件或者目录。?cache pool: 用于管理一系列的cache directive，类似于命名空间。同时使用UNIX风格的文件读、写、执行权限管理机制。命令例子： hdfs cacheadmin -addDirective -path /user/hive/warehouse/fact.db/city -pool financial -replication 1 以上代码表示把HDFS上的文件city 其实是Hive上的一个fact表 放到HDFS centralized cache的financial这个cache pool下，而且这个文件只需要被缓存一份。 用户可以通过hdfs cacheadmin命令行或者HDFS API显式指定把HDFS上的某个文件或者目录放到HDFS centralized cache中。这个centralized cache由分布在每个DataNode节点的off-heap内存组成，同时被NameNode统一管理。每个DataNode节点使用mmap/mlock把存储在磁盘文件中的HDFS block映射并锁定到off-heap内存中。 DFSClient读取文件时向NameNode发送getBlockLocations RPC请求。NameNode会返回一个LocatedBlock列表给DFSClient，这个LocatedBlock对象里有这个block的replica所在的DataNode和cache了这个block的DataNode。可以理解为把被cache到内存中的replica当做三副本外的一个高速的replica。 注：centralized cache和distributed cache的区别： distributed cache将文件分发到各个DataNode结点本地磁盘保存，并且用完后并不会被立即清理的，而是由专门的一个线程根据文件大小限制和文件数目上限周期性进行清理。本质上distributed cache只做到了disk locality，而centralized cache做到了memory locality。 HDFS centralized cache涉及到多个操作，其处理逻辑非常类似。为了简化问题，以addDirective这个操作为例说明。 NameNode内部主要的组件如图所示。FSN