這篇文章主要介紹HDFS短路讀的示例分析，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

成都服務器托管，創新互聯提供包括服務器租用、服務器托管、帶寬租用、云主機、機柜租用、主機租用托管、CDN網站加速、域名申請等業務的一體化完整服務。電話咨詢：18980820575

背景

Hadoop的一個重要思想就是移動計算，而不是移動數據。我們更愿意盡可能將計算移動到數據所在節點。因此，HDFS中經常出現客戶端和數據在一個節點上，當客戶端讀取一個數據塊時，就會出現本地讀取。例如HBase場景，ResionServer寫數據一般在HDFS中都會存儲三備份副本并且肯定會往本地節點寫一備份，當ResionServer讀取該數據時也會優先選擇同一節點的數據進行讀取。

短路讀的演進

1、網絡讀

最初，HDFS中本地讀取的處理方式和遠程讀取相同，也是通過網絡讀來實現。客戶端通過TCP套接字連接到DataNode，并通過DataTransferProtocol協議傳輸數據，如下圖：

這種方式簡單，但有明顯的問題：

DataNode必須為每個正在讀取數據塊的客戶端保留一個線程和一個TCP套接字。內核中會有TCP協議的開銷，以及DataTransferProtocol協議的開銷，因此這里有很大的優化空間。

2、HDFS-2246 不安全短路讀

短路讀關鍵思想是因為客戶端和數據塊在同一節點上，所以DataNode不需要出現在讀取數據路徑中。而客戶端本身可以直接從本地磁盤讀取數據。這樣會使讀取性能得到很大的提高。在HDFS-2246中實現的短路讀是DataNode將所有數據塊路徑的權限開放給客戶端，客戶端直接通過本地磁盤路徑來讀取數據，見下圖：

但這種方式引入了很多問題：

（1）系統管理員必須更改DataNode數據目錄的權限，以允許客戶端打開相關文件。將能夠使用短路讀的用戶專門列入白名單，不允許其他用戶使用。通常，這些用戶也必須放在特殊的Unix組中。

（2）這些權限更改會引入了一個安全漏洞，具有讀取DataNode節點上數據塊文件權限的用戶可以任意讀取路徑上所有數據塊，而不僅僅是他們所需訪問的數據塊，這好像讓用戶變成了超級用戶，對于少數用戶來說可能是可以接受的，例如HBase用戶。但總的來說，它會帶來很大安全隱患。

3、HDFS-347  安全短路讀

HDFS-2246的主要問題是向客戶端打開了DataNode的數據目錄，而我們真正需要讀取的只是一部分數據塊文件。Unix有一種機制是可以做到這一點，稱為文件描述符傳遞。HDFS-347使用這種機制來實現安全短路讀。DataNode不是將目錄傳遞給客戶端，而是打開塊文件和元數據文件，并將它們的文件描述符通過domain socket傳遞給客戶端，如下圖：

基于以下兩方面，安全短路讀解決了HDFS-2246存在的安全性問題。

（1）文件描述符是只讀的，因此客戶端無法修改傳遞描述符的文件。

（2）客戶端無法訪問數據塊目錄本身，所以也無法讀取它不應該訪問的任何其他數據塊文件。

HDFS安全短路讀

1、短路讀共享內存

了解了HDFS短路讀的演進，我們來看下HDFS是如何實現安全短路讀的。DataNode將短路讀副本的文件描述符傳給DFSClient，DFSClient緩存副本文件描述符。由于副本的狀態可能隨時發生改變，所以需要DFSClient和DataNode實時同步副本狀態。同時，DFSClient和DataNode在同一臺機器上，共享內存可以通過POSIX提供的 mmap接口實現將文件映射到內存，并且映射數據是實時同步的（如下圖），所以共享內存可以維護所有短路讀副本的狀態，使得DFSClient和DataNode通過共享內存來實時同步副本信息。

共享內存會有很多槽位，每個槽位對應一個短路讀副本的信息。共享內存保存了所有槽位的二進制信息。但是映射數據中的二進制槽位信息不便于管理，所以定義了Slot對象操作映射數據中的一個槽位，如下圖：

Slot槽位大小是64字節，槽位數據格式，前4字節是Slot標志位，5到8字節是錨計數位，剩余字節保留將來使用，例如統計信息等。

兩個標志位：

（1）VALID_FLAG：表示槽位是否有效。

DFSClient在共享內存中分配新的槽位時設置此標志位。當與此槽位關聯的副本不再有效時，DataNode將會消除此標志位。DFSClient本身也會消除此槽位，認為DataNode不再使用此槽位進行通信。

（2）ANCHORABLE_FLAG:表示槽位對應的副本是否已經緩存。

DataNode將槽位對應的副本通過POSIX提供的mlock接口緩存時會設置該標志位。當標志位已設置，DFSClient短路讀取該副本時不再需要進行校驗，因為副本緩存時已經做了檢驗操作，并且這種副本還支持零拷貝讀取。DFSClient對這樣的副本進行讀取時，需要在對應的槽位錨計數加1，只有當槽位的錨計數為0時，DataNode才可以從緩存中刪除此副本。

共享內存段的最大是8192字節，當DFSClient進行大量短路讀時， DFSClient和DataNode之間可能會有多段共享內存。HDFS中DFSClient定義了DFSClientShm類抽象了DFSClient端一段共享內存，DFSClientShmManager類管理所有的DFSClientShm，而DataNode端定義了RegisteredShm類抽象DataNode端的一段共享內存，ShortCircuitRegistry類管理所有DataNode端的共享內存，如下圖所示：

在安全短路讀中，DFSClient和DataNode是通過domain socket來同步共享內存槽位信息的。

• DFSClient申請一段共享內存保存短路讀副本的狀態。DataNode會創建共享內存，并將共享內存文件映射到DataNode內存中，并創建RegisteredShm管理這段共享內存，之后會將共享內存文件的文件描述符通過domain socket返回給DFSClient。

• DFSClient根據文件描述符打開共享內存文件，將該文件映射到DFSClient的內存中，并創建DfsClientShm對象管理這段共享內存。

• DFSClient通過domain socket向DataNode申請數據塊文件以及元數據文件的文件描述符，并且同步共享內存中slot槽位的狀態。DFSClient會在DfsClientShm管理的共享內存中為數據塊申請一個slot槽位，之后通過domain socket向DataNode同步信息，DataNode會在RegisteredShm管理的共享內存中創建相應的slot槽位，然后獲取數據塊文件以及元數據文件的文件描述符，并通過domain socket發送給DFSClient，如下圖：

共享內存機制

2、短路讀流程

當客戶端執行數據塊副本短路讀時，DFSClient與DataNode的交互過程如下：

短路讀簡化流程圖

（1）DFSClient通過requestShortCircuitShm()接口向DataNode請求創建共享內存，DataNode創建共享內存文件并將共享內存文件描述符返回給DFSClient。

（2）DFSClient通過allocShmSlot()接口申請共享內存中的槽位，并通過requestShortCircuitFds()接口向DataNode請求要讀取的副本文件描述符，DataNode打開副本文件并將數據塊文件和元數據文件的文件描述符返回給DFSClient。

（3）DFSClient讀取完副本后，異步通過releaseShortCircuitFds()接口向DataNode請求釋放文件描述符及相應槽位。

小米對HDFS安全短路讀的優化

1、Slot槽位釋放緩慢

幾次壓力場景中，我們發現Hbase ResionServer多個短路讀線程經常會阻塞在domain socket的讀寫上。從DataNode 的dump中發現大量的用于短路讀的ShortCircuitShm。于是我們通過YCSB模擬線上的情況，發現短路讀請求量較大時，BlockReaderLocal分配的QPS很高，并且BlockReaderLocal的分配依賴于同步讀取塊的ShortCircuitShm和slot的分配。

YCSB GET QPS

YCSB GET LATENCY

通過統計slot分配和釋放的QPS，我們發現slot分配的QPS能達到3000+，而釋放的QPS只能達到1000+，并且在YCSB測試經過約1小時，DataNode出現FULL GC。由此可看出，DataNode中積累的，來不及釋放的slot，是導致GC的主要有原因。

現在的短路讀實現中，每次釋放slot，都會新建一個domain socket連接。而DataNode對于每個新建立的domain socket 連接，都會重新初始化一個DataXceiver去處理這個請求。通過profile DataNode發現，SlotReleaser線程花了大量的時間在建立和清理這些連接上。

于是，我們對SlotReleaser的domain socket連接進行了復用。通過復用domain socket，在同樣的測試集上，slot 釋放的QPS能和分配的QPS達到一致。從而消除了過期slot在DataNode中的擠壓。同時，由于DataNode Young GC減少，YCSB的GET的QPS也提升了約20%左右。

2、共享內存分配效率低

在profile HBase短路讀過程中，我們還發現另外一個問題，就是每隔一段時間，會有一批讀會有約200ms左右的延遲而且這些延遲幾乎同時出現。開始我們懷疑 Hbase ResionServer的Minor GC導致。但通過比對ResionServer的GC日志，發現時間并不完全匹配。有一部分卻和DataNode Minor GC時間吻合。數據塊副本的真正讀取操作，是完全不通過DataNode的，如果是DataNode的影響，那問題只能出在ResionServer和DataNode建立短路讀時的交互上。通過進一步在短路讀過程中加trace log，我們發現這些延遲，是由于DataNode Minor GC導致ShortCircuitShm分配請求被阻塞。當分配一個ShortCircuitShm時，會導致很多slot的分配阻塞。slot的分配延遲，又會引起BlockReaderLocal的延遲，從而導致短路讀的延遲。這就是之前發現有一批讀，總是同時報相近的延遲。 為了解決這個問題，我們對ShortCircuitShm進行了預分配，以減輕DataNode Minor GC對短路度影響，使得延遲更為平滑。

3、短禁止正在構建塊的短路讀

禁止了正在構建塊進行短路讀，也就是最后一個塊禁止短路讀。這個問題由于HBase的讀寫模式 ，對其影響不是很大，但對基于HDFS流式服務影響很大。我們正在做的優化工作主要是通過保證短路讀只發生在flush操作之后，同時在讀取過程中檢查塊的有效性，處理讀異常，如果確實失敗，轉成遠程讀的方式。

附錄

（1）文件描述符(File Descriptor)

文件描述符在形式上是一個非負整數。實際上，它是一個索引值，指向內核為每一個進程所維護的該進程打開文件的記錄表。當程序打開一個現有文件或者創建一個新文件時，內核向進程返回一個文件描述符。

Unix和Windows系統都允許在進程間傳遞文件描述符。一個進程打開一個文件，然后把該文件的文件描述符傳遞給另一個進程，另一個進程可以訪問該文件。文件描述符傳遞對于安全性是非常有用的，因為它消除了對第二個進程需要擁有足夠訪問權限來打開文件限制，同時文件描述符是只讀的，所以該方式還可以防止有問題的程序或者惡意的客戶端損壞文件。在Unix系統上，文件描述符傳遞只能通過Unix domain socket完成。

（2）Unix domain socket

Unix domain socket是用于在同一臺主機操作系統上執行的進程間交換數據的通信端點。有效的Unix domain socket類型是SOCK_STREAM(用于面向流的套接字)和SOCK_DGRAM（用于保留消息邊界的面向數據報的套接字）,與大多數Unix實現一樣，Unix domain datagram socket始終可靠且不重新排序的數據報。Unix domain socket是POSIX操作系統的標準組件。  

Unix domain socket的API類似于網絡socket，但是不使用底層網絡協議，所有通信都完全在操作系統內核中進行。Unix domain socket使用文件系統作為其地址名稱空間。進程引用Unix domain socket作為文件系統inode，因此兩個進程可以通過打開相同的socket進行通信。 除了發送數據外，進程還可以使用sendmsg()和recvmsg()系統調用在Unix domain socket連接上發送文件描述符。并且只有發送進程授權給接收進程，接收進程才可以訪問文件描述符的權限。

（3）共享內存（Shared Memory）

共享內存是進程間通信的方法，即在同時運行的程序之間交換數據的方法。一個進程將在RAM中創建一個其他進程可以訪問的區域。由于兩個進程可以像訪問自身內存一樣訪問共享內存區域，因此是一種非常快速的通信方式。但是它的擴展性較差，例如通信必須在同一臺機器上運行。而且必須要避免如果共享內存的進程在不同的CPU上運行，并且底層架構不是緩存一致的。

POSIX提供了使用共享內存的POSIX標準化API。使用sys/mman.h中的函數shm_open。POSIX進程間通信包含共享函數shmat，shmctl，shmdt和shmget。shm_open創建的共享內存是持久化的。它一直保留在系統中，直到被進程明確刪除。這有一個缺點，如果進程崩潰并且無法清理共享內存，它將一直保持到系統關閉。POSIX還提供了用于將文件映射到內存的mmap API，可以共享映射，允許將文件的內容用作共享內存。

以上是“HDFS短路讀的示例分析”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注創新互聯行業資訊頻道！

分享文章：HDFS短路讀的示例分析
標題網址：http://m.newbst.com/article14/gschde.html

成都網站建設公司_創新互聯，為您提供網站設計、網頁設計公司、定制開發、網站內鏈、虛擬主機、

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯