HDFS 细粒度锁优化，FusionInsight MRS有妙招
本文分享自華為云社區(qū)《FusionInsight MRS HDFS 細粒度鎖優(yōu)化實踐》，作者：pippo。
背景
? ? ?HDFS依賴NameNode作為其元數(shù)據(jù)服務。NameNode將整個命名空間信息保存在內(nèi)存中提供服務。讀取請求（getBlockLocations、listStatus、getFileInfo）等從內(nèi)存中獲取信息。寫請求（mkdir、create、addBlock）更新內(nèi)存狀態(tài)，并將日志事務寫入到日志服務（QJM）。
? ? ?HDFS NameNode的性能決定了整個Hadoop集群的可擴展性。命名空間性能的改進對于進一步擴展Hadoop集群至關重要。
- ? ? ?Apache HDFS 整體架構如下：
- ? ? ?Apache HDFS 交互信息如下：
? ? ?
痛點
? ? ? HDFS NameNode的寫操作的性能受全局命名空間系統(tǒng)鎖的限制。每個寫操作都會獲取鎖并保留鎖，直到該操作執(zhí)行完成。這樣可以防止寫入操作的并發(fā)執(zhí)行，即使它們是完全獨立的，例如命名空間中的對象不相交部分。
什么是Fine Grained Locking（FGL）
? ? ? FGL【細粒度鎖】的主要目的是通過在獨立命名空間分區(qū)上用多個并發(fā)鎖替換全局鎖，允許寫入操作的并發(fā)。?
當前狀態(tài)
? ? ??HDFS設計思路為一次寫，多次讀。讀操作使用共享鎖，寫操作使用獨占鎖。由于HDFS NameNode元數(shù)據(jù)被設計為單個內(nèi)存空間中的命名空間樹，因此樹的任何級別的寫操作都會阻塞其它寫操作，直到當前寫操作完成。雖然寫是一次，但是當涉及大量并發(fā)讀/寫操作時，這就會影響整體性能。
? ? ?在HDFS NameNode中，內(nèi)存中的元數(shù)據(jù)有三種不同的數(shù)據(jù)結構：
- INodeMap: inodeid -> INode
- BlocksMap: blockid -> Blocks
- DataNodeMap: datanodeId -> DataNodeInfo
? ? ?INodeMap結構中包含inodeid到INode的映射，在整個Namespace目錄樹種存在兩種不同類型的INode數(shù)據(jù)結構：INodeDirectory和INodeFile。其中INodeDirectory標識的是目錄樹中的目錄，INodeFile標識的是目錄樹中的文件。
? ? ?BlocksMap結構中包含blockid到BlockInfo的映射。每一個INodeFile都會包含數(shù)量不同的Block，具體數(shù)量由文件大小以及每個Block大小來決定，這些Block按照所在文件的先后順序組成BlockInfo數(shù)組，BlockInfo維護的是Block的元數(shù)據(jù)；通過blockid可以快速定位Block。
? ? DataNodeMap結果包含datanodeid到DataNodeInfo的映射。當集群啟動過程中，通過機架感知逐步建立起整個集群的機架拓撲結構，一般在NameNode的生命周期內(nèi)不會發(fā)生大變化。
? ? ?通過INodeMap和BlocksMap共同標識存儲在HDFS中的每個文件及其塊的信息。隨著文件數(shù)量的增加，此數(shù)據(jù)結構大小也會隨之增加，并對單個全局鎖的性能產(chǎn)生很大影響。下面我們采用簡單的文件目錄樹結構來演示現(xiàn)有的單一全局鎖在文件系統(tǒng)的缺點。
?HDFS NameNode 內(nèi)存目錄樹結構
? ? ? ?如上圖所示，/D11/D21/D31/F2 和 /D12/D24/D38/F16是不相交的文件，即有不同的父節(jié)點和祖父節(jié)點。可以看到F2和F16是兩個獨立的文件，對其中一個文件的任何操作都不應該影響另一個文件。
設計
? ? ? 如前所述，HDFS NameNode將文件信息和元數(shù)據(jù)結構在內(nèi)存中保存為一個目錄樹結構。當修改任意兩個獨立的文件時，第二次操作需要等到第一次操作完成并釋放鎖。釋放鎖以后，只有第二個操作獲取鎖后才能繼續(xù)修改文件系統(tǒng)。類似的，后續(xù)操作也會阻塞，直到第二次操作釋放鎖。
? ? ? 在下面的例子中，我們考慮2個文件并發(fā)寫入（創(chuàng)建、刪除、追加。。。）操作。F2和F16是文件系統(tǒng)下的2個獨立文件（具有不同的父節(jié)點和祖父節(jié)點）。在將內(nèi)容追加到F2時，F16也可以同時進行修改。但是由于整個目錄樹全局對象鎖，對F16的操作必須等對F2的操作完成后才能執(zhí)行。
? ? ? 代替全局鎖，可以將鎖分布在一組名為“分區(qū)”的文件中，每個分區(qū)都可以有自己的鎖。現(xiàn)在F2屬于分區(qū)-1，F16屬于分區(qū)-2。F2文件操作可以通過獲取分區(qū)-1的鎖來進行修改，F16文件操作可以通過獲取分區(qū)-2的鎖來進行修改。
? ? ? 和以前一樣，需要先獲取全局鎖，然后搜索每個文件屬于哪個分區(qū)。找到分區(qū)后，獲取分區(qū)鎖并釋放全局鎖。因此全局鎖并不會完全被刪除。相反，通過減少全局鎖時間跨度，一旦釋放全局鎖，則其它寫操作可以獲取全局鎖并繼續(xù)獲取分區(qū)鎖來進行文件操作。
? ? ? ?分區(qū)的數(shù)量如何決定？如果有效的定義分區(qū)從而獲得更高的吞吐量？
? ? ? ?默認情況下，分區(qū)大小為65K，溢出系數(shù)為1.8。一旦分區(qū)達到溢出條件，將會創(chuàng)建新分區(qū)并加入到分區(qū)列表中。理想情況下，可以擁有等于NameNode可用CPU核數(shù)的分區(qū)數(shù)，過多的分區(qū)數(shù)量將會使得CPU過載，而過少的分區(qū)數(shù)量無法充分利用CPU。
實現(xiàn)
? ? ? ?引入新的數(shù)據(jù)結構-PartitionedGSet，它保存命名空間創(chuàng)建的所有分區(qū)信息。PartitionEntry是一個分區(qū)的對象結構。LatchLock是新引入的鎖，用于控制兩級鎖--頂層鎖和子鎖。
PartitionedGSet
? ? ? ?PartitionedGSet是一個兩級層次結構。第一層RangeMap定義了INode的范圍，并將它們映射到相應的分區(qū)中。分區(qū)構成了層次結構的第二級，每個分區(qū)存儲屬于指定范圍的INode信息。為了根據(jù)鍵值查找INode，需要首先在RangeMap中找到對應鍵值的范圍，然后在對應的RangeSet，使用哈希值獲取到對應的INode。
HDFS NameNode 兩級層次結構
? ? ? RangeGSet的容量有一定的閾值。當達到閾值后，將創(chuàng)建新的RangeGSet。空的或者未充分利用的RangeGSet由后臺RangeMonitor守護程序來進行垃圾回收。
? ? ? HDFS NameNode啟動時，根據(jù)鏡像中的INode數(shù)量計算合理的初始分區(qū)數(shù)。同時還需要考慮CPU核數(shù)，因為將分區(qū)數(shù)量提高到遠超CPU核數(shù)并不會增加系統(tǒng)的并行性。
- 動態(tài)分區(qū)：分區(qū)的大小有限，可以像平衡樹一樣可以進行分裂和合并。
- 單個分區(qū)：只有一個分區(qū)，且只有一個與之相對應的鎖，并且應和全局鎖類似。這適用于小型集群或寫入負載比較輕的集群。
- 靜態(tài)分區(qū)：有一個固定的RangeMap，不添加或者合并現(xiàn)有分區(qū)。這適用于分區(qū)均勻增長的文件系統(tǒng)。而且這將消除鎖定RangeMap的要求，允許并行使用鎖。
Latch Lock
? ? ?RangeMap與RangeGSet分別有單獨的鎖。Latch Lock是一種鎖模式，其中首先獲取RangeMap的鎖，以查找與給定INode鍵對應的范圍，然后獲取與分區(qū)對應的RangeGSet的鎖，同時釋放RangeMap鎖。這樣針對任何其它范圍的下一個操作都可以開始并發(fā)執(zhí)行。
? ? ?在RangeMap上持有鎖類似于全局鎖。目錄刪除、重命名、遞歸創(chuàng)建目錄等幾個操作可能需要鎖定多個RangeGSet。這要確保當前HDFS語義所要求的操作的原子性。例如，如果重命名將文件從一個目錄移動到另一個目錄，則必須鎖定包含文件、源和目標目錄的RangeMap，以便使重命名成為原子。此鎖定模式的一個理想優(yōu)化是允許某些操作的Latch Lock與其他操作的全局鎖結合使用。
INode Keys
? ? ?HDFS中的每個目錄和文件都有一個唯一的INode，即使文件被重命名或者移動到其它位置，該INode會保持不變。INode鍵是以文件INode本身結尾，前面包含父INode的固定長度序列。
? ? ? Key Definition:??key(f) = <ppId, pId, selfId>
? ? ? selfId是文件的INodeId，pId是父目錄的INodeId，ppId是父目錄的父目錄的INodeId。INode鍵的這種表達不僅保證了同級，同時也保證了表親（相同祖父節(jié)點）在大多數(shù)情況下被分區(qū)到相同的范圍中。這些鍵基于INodeId而非文件名，允許簡單的文件和目錄進行重命名，稱為就地重命名，而無需重新進行分區(qū)。
效果
? ? ? 經(jīng)過測試驗證使用和不使用FGL功能性能，在主要寫入操作情況下，吞吐量平均提高了25%左右。
詳細性能對比
? ? ? 使用Hadoop NN Benchmarking工具（NNThroughputBenchmark）來驗證NameNode的性能。每個寫入API驗證并觀察到平均25%的性能提升。有很少一部分輕微或者沒有提升的API，分析并發(fā)現(xiàn)這些API均是輕量級API，因此沒有太大的提升。
? ? ? ?NNThroughputBenchmark是用于NameNode性能基準測試工具。該工具提供了非常基本的API調(diào)用，比如創(chuàng)建文件，創(chuàng)建目錄、刪除。在這個基礎上進行了增強，從而能夠支持所有寫入API，并能夠捕獲使用和不使用FGL的版本的性能數(shù)據(jù)。
? ? ? 用于測試的數(shù)據(jù)集：線程數(shù) 1000、文件數(shù) 1000000、每個目錄文件數(shù) 40。
寫入調(diào)用頻率高的API
其它內(nèi)部寫API
常用讀取API：
? ? ?通過完整的FGL實現(xiàn)，讀取API也有很好的性能提升。
運行基準測試工具的命令：
? ? ? ?./hadoop org.apache.hadoop.hdfs.server.namenode.NNThroughputBenchmark -fs file:/// -op create -threads 200 -files 1000000 -filesPerDir 40 –close
? ? ? ?./hadoop org.apache.hadoop.hdfs.server.namenode.NNThroughputBenchmark -fs hdfs:x.x.x.x:dddd/hacluster -op create -threads 200 -files 1000000 -filesPerDir 40 -close
參考
? ? ? ? 與FGL相關的社區(qū)討論
? ? ? ??Hadoop Meetup Jan 2019 —?HDFS Scalability and Consistent Reads from Standby Node, which covers Three-Stage Scalability Plan. Slides 21–25
? ? ? ? 社區(qū)中跟蹤與NameNode可擴展性相關的其它Jira
? ? ? ??HDFS-5453. Support fine grain locking in FSNamesystem
? ? ? ? HDFS-5477. Block manager as a service
? ? ? ? HDFS-8286. Scaling out the namespace using KV store
? ? ? ? HDFS-14703. Namenode Fine Grained Locking (design inspired us to implement it fully)
總結
? ? ??華為云FusionInsight MRS云原生數(shù)據(jù)湖為政企客戶提供湖倉一體、云原生的數(shù)據(jù)湖解決方案，構建一個架構可持續(xù)演進的離線、實時、邏輯三種數(shù)據(jù)湖，支撐政企客戶全量數(shù)據(jù)的實時分析、離線分析、交互查詢、實時檢索、多模分析、數(shù)據(jù)倉庫、數(shù)據(jù)接入和治理等大數(shù)據(jù)應用場景。
? ? ? 華為云FusionInsight MRS通過FGL對HDFS NameNode鎖機制進行優(yōu)化，有效提升了NameNode的讀寫吞吐量，從而能夠支持更多數(shù)據(jù)，更多業(yè)務請求訪問，從而更好的支撐政企客戶高效用數(shù)，業(yè)務洞見更準，價值兌現(xiàn)更快。
點擊關注，第一時間了解華為云新鮮技術~?
總結
以上是生活随笔為你收集整理的HDFS 细粒度锁优化，FusionInsight MRS有妙招的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 社保卡信息读取
- 下一篇： 地下管线探测TFN T-6000地下管线