HDFS集中式的緩存管理原理與代碼剖析

來(lái)源：懂視網(wǎng) 責(zé)編：小采時(shí)間：2020-11-09 13:14:21

HDFS集中式的緩存管理原理與代碼剖析

HDFS集中式的緩存管理原理與代碼剖析:Hadoop 2.3.0已經(jīng)發(fā)布了，其中最大的亮點(diǎn)就是集中式的緩存管理(HDFS centralized cache management)。這個(gè)功能對(duì)于提升Hadoop系統(tǒng)和上層應(yīng)用的執(zhí)行效率與實(shí)時(shí)性有很大幫助，本文從原理、架構(gòu)和代碼剖析三個(gè)角度來(lái)探討這一功能。主要解決了哪些問(wèn)題 1.用

推薦度：

點(diǎn)擊下載本文 文檔為doc格式

導(dǎo)讀HDFS集中式的緩存管理原理與代碼剖析:Hadoop 2.3.0已經(jīng)發(fā)布了，其中最大的亮點(diǎn)就是集中式的緩存管理(HDFS centralized cache management)。這個(gè)功能對(duì)于提升Hadoop系統(tǒng)和上層應(yīng)用的執(zhí)行效率與實(shí)時(shí)性有很大幫助，本文從原理、架構(gòu)和代碼剖析三個(gè)角度來(lái)探討這一功能。主要解決了哪些問(wèn)題 1.用

Hadoop 2.3.0已經(jīng)發(fā)布了，其中最大的亮點(diǎn)就是集中式的緩存管理(HDFS centralized cache management)。這個(gè)功能對(duì)于提升Hadoop系統(tǒng)和上層應(yīng)用的執(zhí)行效率與實(shí)時(shí)性有很大幫助，本文從原理、架構(gòu)和代碼剖析三個(gè)角度來(lái)探討這一功能。主要解決了哪些問(wèn)題 1.用戶(hù)可

主要解決了哪些問(wèn)題

1.用戶(hù)可以根據(jù)自己的邏輯指定一些經(jīng)常被使用的數(shù)據(jù)或者高優(yōu)先級(jí)任務(wù)對(duì)應(yīng)的數(shù)據(jù)常駐內(nèi)存而不被淘汰到磁盤(pán)。例如在Hive或Impala構(gòu)建的數(shù)據(jù)倉(cāng)庫(kù)應(yīng)用中fact表會(huì)頻繁地與其他表做JOIN，顯然應(yīng)該讓fact常駐內(nèi)存，這樣DataNode在內(nèi)存使用緊張的時(shí)候也不會(huì)把這些數(shù)據(jù)淘汰出去，同時(shí)也實(shí)現(xiàn)了對(duì)于?mixed workloads的SLA。

2.centralized cache是由NameNode統(tǒng)一管理的，那么HDFS client（例如MapReduce、Impala）就可以根據(jù)block被cache的分布情況去調(diào)度任務(wù)，做到memory-locality。

3.HDFS原來(lái)單純靠DataNode的OS buffer cache，這樣不但沒(méi)有把block被cache的分布情況對(duì)外暴露給上層應(yīng)用優(yōu)化任務(wù)調(diào)度，也有可能會(huì)造成cache浪費(fèi)。例如一個(gè)block的三個(gè)replica分別存儲(chǔ)在三個(gè)DataNote 上，有可能這個(gè)block同時(shí)被這三臺(tái)DataNode的OS buffer cache，那么從HDFS的全局看就有同一個(gè)block在cache中存了三份，造成了資源浪費(fèi)。?

4.加快HDFS client讀速度。過(guò)去NameNode處理讀請(qǐng)求時(shí)只根據(jù)拓?fù)溥h(yuǎn)近決定去哪個(gè)DataNode讀，現(xiàn)在還要加入speed的因素。當(dāng)HDFS client和要讀取的block被cache在同一臺(tái)DataNode的時(shí)候，可以通過(guò)zero-copy read直接從內(nèi)存讀，略過(guò)磁盤(pán)I/O、checksum校驗(yàn)等環(huán)節(jié)。

5.即使數(shù)據(jù)被cache的DataNode節(jié)點(diǎn)宕機(jī)，block移動(dòng)，集群重啟，cache都不會(huì)受到影響。因?yàn)閏ache被NameNode統(tǒng)一管理并被被持久化到FSImage和EditLog，如果cache的某個(gè)block的DataNode宕機(jī)，NameNode會(huì)調(diào)度其他存儲(chǔ)了這個(gè)replica的DataNode，把它c(diǎn)ache到內(nèi)存。

基本概念

cache directive: 表示要被cache到內(nèi)存的文件或者目錄。
cache pool: 用于管理一系列的cache directive，類(lèi)似于命名空間。同時(shí)使用UNIX風(fēng)格的文件讀、寫(xiě)、執(zhí)行權(quán)限管理機(jī)制。命令例子：

hdfs cacheadmin -addDirective -path /user/hive/warehouse/fact.db/city -pool financial -replication 1?

以上代碼表示把HDFS上的文件city(其實(shí)是hive上的一個(gè)fact表)放到HDFS centralized cache的financial這個(gè)cache pool下，而且這個(gè)文件只需要被緩存一份。

系統(tǒng)架構(gòu)與原理

用戶(hù)可以通過(guò)hdfs cacheadmin命令行或者HDFS API顯式指定把HDFS上的某個(gè)文件或者目錄放到HDFS?centralized?cache中。這個(gè)centralized?cache由分布在每個(gè)DataNode節(jié)點(diǎn)的off-heap內(nèi)存組成，同時(shí)被NameNode統(tǒng)一管理。每個(gè)DataNode節(jié)點(diǎn)使用mmap/mlock把存儲(chǔ)在磁盤(pán)文件中的HDFS block映射并鎖定到off-heap內(nèi)存中。

DFSClient讀取文件時(shí)向NameNode發(fā)送getBlockLocations RPC請(qǐng)求。NameNode會(huì)返回一個(gè)LocatedBlock列表給DFSClient，這個(gè)LocatedBlock對(duì)象里有這個(gè)block的replica所在的DataNode和cache了這個(gè)block的DataNode。可以理解為把被cache到內(nèi)存中的replica當(dāng)做三副本外的一個(gè)高速的replica。

注：centralized cache和distributed cache的區(qū)別：

distributed cache將文件分發(fā)到各個(gè)DataNode結(jié)點(diǎn)本地磁盤(pán)保存，并且用完后并不會(huì)被立即清理的，而是由專(zhuān)門(mén)的一個(gè)線(xiàn)程根據(jù)文件大小限制和文件數(shù)目上限周期性進(jìn)行清理。本質(zhì)上distributed cache只做到了disk locality，而centralized cache做到了memory locality。

實(shí)現(xiàn)邏輯與代碼剖析

HDFS centralized cache涉及到多個(gè)操作，其處理邏輯非常類(lèi)似。為了簡(jiǎn)化問(wèn)題，以addDirective這個(gè)操作為例說(shuō)明。

1.NameNode處理邏輯

NameNode內(nèi)部主要的組件如圖所示。FSNamesystem里有個(gè)CacheManager是centralized cache在NameNode端的核心組件。我們都知道BlockManager負(fù)責(zé)管理分布在各個(gè)DataNode上的block replica，而CacheManager則是負(fù)責(zé)管理分布在各個(gè)DataNode上的block cache。

DFSClient給NameNode發(fā)送名為addCacheDirective的RPC，在ClientNamenodeProtocol.proto這個(gè)文件中定義相應(yīng)的接口。

NameNode接收到這個(gè)RPC之后處理，首先把這個(gè)需要被緩存的Path包裝成CacheDirective加入CacheManager所管理的directivesByPath中。這時(shí)對(duì)應(yīng)的File/Directory并沒(méi)有被cache到內(nèi)存。

一旦CacheManager那邊添加了新的CacheDirective，觸發(fā)CacheReplicationMonitor.rescan()來(lái)掃描并把需要通知DataNode做cache的block加入到CacheReplicationMonitor. cachedBlocks映射中。這個(gè)rescan操作在NameNode啟動(dòng)時(shí)也會(huì)觸發(fā)，同時(shí)在NameNode運(yùn)行期間以固定的時(shí)間間隔觸發(fā)。

Rescan()函數(shù)主要邏輯如下：

rescanCacheDirectives()->rescanFile():依次遍歷每個(gè)等待被cache的directive（存儲(chǔ)在CacheManager. directivesByPath里），把每個(gè)等待被cache的directive包含的block都加入到CacheReplicationMonitor.cachedBlocks集合里面。

rescanCachedBlockMap():調(diào)用CacheReplicationMonitor.addNewPendingCached()為每個(gè)等待被cache的block選擇一個(gè)合適的DataNode去cache（一般是選擇這個(gè)block的三個(gè)replica所在的DataNode其中的剩余可用內(nèi)存最多的一個(gè)），加入對(duì)應(yīng)的DatanodeDescriptor的pendingCached列表。

2.NameNode與DataNode的RPC邏輯

DataNode定期向NameNode發(fā)送heartbeat RPC用于表明它還活著，同時(shí)DataNode還會(huì)向NameNode定期發(fā)送block report（默認(rèn)6小時(shí)）和cache block（默認(rèn)10秒）用于同步block和cache的狀態(tài)。

NameNode會(huì)在每次處理某一DataNode的heartbeat RPC時(shí)順便檢查該DataNode的pendingCached列表是否為空，不為空的話(huà)發(fā)送DatanodeProtocol.DNA_CACHE命令給具體的DataNode去cache對(duì)應(yīng)的block replica。

3.DataNode處理邏輯

DataNode內(nèi)部主要的組件如圖所示。DataNode啟動(dòng)的時(shí)候只是檢查了一下dfs.datanode.max.locked.memory是否超過(guò)了OS的限制，并沒(méi)有把留給Cache使用的內(nèi)存空間鎖定。

在DataNode節(jié)點(diǎn)上每個(gè)BlockPool對(duì)應(yīng)有一個(gè)BPServiceActor線(xiàn)程向NameNode發(fā)送heartbeat、接收response并處理。如果接收到來(lái)自NameNode的RPC里面的命令是DatanodeProtocol.DNA_CACHE，那么調(diào)用FsDatasetImpl.cacheBlock()把對(duì)應(yīng)的block cache到內(nèi)存。

這個(gè)函數(shù)先是通過(guò)RPC傳過(guò)來(lái)的blockId找到其對(duì)應(yīng)的FsVolumeImpl (因?yàn)閳?zhí)行cache block操作的線(xiàn)程cacheExecutor是綁定在對(duì)應(yīng)的FsVolumeImpl里的)；然后調(diào)用FsDatasetCache.cacheBlock()把這個(gè)block封裝成MappableBlock加入到mappableBlockMap里統(tǒng)一管理起來(lái)，然后向?qū)?yīng)的FsVolumeImpl.cacheExecutor線(xiàn)程池提交一個(gè)CachingTask異步任務(wù)(cache的過(guò)程是異步執(zhí)行的)。

FsDatasetCache有個(gè)成員mappableBlockMap(HashMap)管理著這臺(tái)DataNode的所有的MappableBlock及其狀態(tài)(caching/cached/uncaching)。目前DataNode中”哪些block被cache到內(nèi)存里了”也是只保存了soft state(和NameNode的block map一樣)，是DataNode向NameNode 發(fā)送heartbeat之后從NameNode那問(wèn)回來(lái)的，沒(méi)有持久化到DataNode本地硬盤(pán)。

CachingTask的邏輯：調(diào)用MappableBlock.load()方法把對(duì)應(yīng)的block從DataNode本地磁盤(pán)通過(guò)mmap映射到內(nèi)存中，然后通過(guò)mlock鎖定這塊內(nèi)存空間，并對(duì)這個(gè)映射到內(nèi)存的block做checksum檢驗(yàn)其完整性。這樣對(duì)于memory-locality的DFSClient就可以通過(guò)zero-copy直接讀內(nèi)存中的block而不需要校驗(yàn)了。

4.DFSClient讀邏輯：

HDFS的讀主要有三種：網(wǎng)絡(luò)I/O讀 -> short circuit read -> zero-copy read。網(wǎng)絡(luò)I/O讀就是傳統(tǒng)的HDFS讀，通過(guò)DFSClient和Block所在的DataNode建立網(wǎng)絡(luò)連接傳輸數(shù)據(jù)。?

當(dāng)DFSClient和它要讀取的block在同一臺(tái)DataNode時(shí)，DFSClient可以跨過(guò)網(wǎng)絡(luò)I/O直接從本地磁盤(pán)讀取數(shù)據(jù)，這種讀取數(shù)據(jù)的方式叫short circuit read。目前HDFS實(shí)現(xiàn)的short circuit read是通過(guò)共享內(nèi)存獲取要讀的block在DataNode磁盤(pán)上文件的file descriptor(因?yàn)檫@樣比傳遞文件目錄更安全)，然后直接用對(duì)應(yīng)的file descriptor建立起本地磁盤(pán)輸入流，所以目前的short circuit read也是一種zero-copy read。

增加了Centralized cache的HDFS的讀接口并沒(méi)有改變。DFSClient通過(guò)RPC獲取LocatedBlock時(shí)里面多了個(gè)成員表示哪個(gè)DataNode把這個(gè)block cache到內(nèi)存里面了。如果DFSClient和該block被cache的DataNode在一起，就可以通過(guò)zero-copy read大大提升讀效率。而且即使在讀取的過(guò)程中該block被uncache了，那么這個(gè)讀就被退化成了本地磁盤(pán)讀，一樣能夠獲取數(shù)據(jù)。?

對(duì)上層應(yīng)用的影響

對(duì)于HDFS上的某個(gè)目錄已經(jīng)被addDirective緩存起來(lái)之后，如果這個(gè)目錄里新加入了文件，那么新加入的文件也會(huì)被自動(dòng)緩存。這一點(diǎn)對(duì)于Hive/Impala式的應(yīng)用非常有用。

HBase in-memory table：可以直接把某個(gè)HBase表的HFile放到centralized cache中，這會(huì)顯著提高HBase的讀性能，降低讀請(qǐng)求延遲。

和Spark RDD的區(qū)別：多個(gè)RDD的之間的讀寫(xiě)操作可能完全在內(nèi)存中完成，出錯(cuò)就重算。HDFS centralized cache中被cache的block一定是先寫(xiě)到磁盤(pán)上的，然后才能顯式被cache到內(nèi)存。也就是說(shuō)只能cache讀，不能cache寫(xiě)。

目前的centralized cache不是DFSClient讀了誰(shuí)就會(huì)把誰(shuí)cache，而是需要DFSClient顯式指定要cache誰(shuí)，cache多長(zhǎng)時(shí)間，淘汰誰(shuí)。目前也沒(méi)有類(lèi)似LRU的置換策略，如果內(nèi)存不夠用的時(shí)候需要client顯式去淘汰對(duì)應(yīng)的directive到磁盤(pán)。

現(xiàn)在還沒(méi)有跟YARN整合，需要用戶(hù)自己調(diào)整好留給DataNode用于cache的內(nèi)存和NodeManager的內(nèi)存使用。