如何提高hadoop中Short-CircuitLocalReads時的性能及安全性

本文由 ImportNew - Royce Wong 翻譯自 Cloudera。如需轉載本文，請先參見文章末尾處的轉載要求。 大家都知道，apache hadoop的一個關鍵思想就是移動計算比移動數據更廉價。所以只要可能，我們就樂忠移動計算到數據地方。因此，HDFS通常使用許多的本地讀，在

大家都知道，apache hadoop的一個關鍵思想就是移動計算比移動數據更廉價。所以只要可能，我們就樂忠移動計算到數據地方。因此，HDFS通常使用許多的本地讀，在本地機器構造讀對象讀出數據。

最初，hdfs本地讀其實和遠程讀使用的同一種方式：client端通過TCP 連接DN，并通過DataTransferProtocol傳輸數據。該方法簡單，但是有一些不好的地方。例如，DN需要維護一個線程運行，并為每個client打開的tcp套接字建立連接傳輸數據。在linux內核中tcp協議是有開銷的，同時DataTransferProtocol本身也有開銷。這里有優化空間。

本文大家將會了解到一項HDFS新的優化，叫做“secure short-circuit local reads”,學習該優化如何實現并怎樣提速本地讀的。

HDFS-2246 曾經實現的Short-Circuit LocalReads

HDFS-2246，ndrew Purtell, Suresh Srinivas, Jitendra Nath Pandey, and Benoy Antony等人添加了一項稱為“short-circuit local reads”優化。

其關鍵思想如下：因為客戶端和數據在同一個節點，所以沒必要再去和DN交互。客戶端本身直接就從本地磁盤讀出數據。這個性能優化被加入了CDH3u3。

HDFS-2246實現的short-circuit local read 是一個好的開始，但其帶來了許多配置上麻煩。系統管理員必須改變DN數據目錄權限，允許客戶端打開相關文件。還需要定義一個白名單用戶，可以使用這個特性。其他用戶不允許。通常，這些用戶被搞到一個特殊的UNIX 用戶組里。

不幸的是，這種權限改變帶來了安全漏洞。有這種權限的用戶就可以直接瀏覽所有數據了，不僅是他們需要的數據。簡直就是超級用戶啊！這個在一些場景下可以接受，比如 HBase用戶，但是一般來講，它還是帶來了問題。這不是一個通用的方式。

HDFS-347：讓Short-Circuit Local Reads 安全

HDFS-2246的主要問題就是它將DN的所有數據路徑直接開放給了客戶端。其實，客戶端只是想要幾個其關心的數據文件。

幸虧Unix提供了可以這樣做的機制，文件描述符。HDFS-347使用該機制實現安全的short-circuit local reads. 客戶端向DN請求數據時，DN簡單地打開blockfile和元數據文件，并直接傳給客戶端，而不是將路徑傳給客戶端。因為文件描述符是只讀的，客戶端不能修改接收到的文件。同時不支持對block所在路徑的訪問，所以也就不能訪問其他數據。

Windows 有類似的機制允許將文件描述符在進程間傳遞。CDH目前還不支持該特性，同時Windows用戶可以配置dfs.cient.use.legacy.blockreader.local為true使用legacy block reader。

Cache 文件描述符

HDFS客戶端經常多次讀取相同的block文件（y尤其對HBase而言）。為了提高這種場景下的本地讀，HDFS-2246實現的機制中有一個block 路徑的Cache。Cache允許客戶端重新打開block文件，而不需要再去訪問DN。

相對于路徑Cache，新機制實現了一個FileInputStreamCache，緩存文件描述符。優點在于不需要客戶端重新打開數據文件。該處實現性能優于老的讀取機制。

cache的大小可以通過dfs.client.read.shortcircuit.stream.cache.size調整,cache超時時間通過dfs.client.read.shortcircuit.streams.cache.expiry.ms設定。也可以關掉該cache，設置cache大小為0即可。大多數情況下，默認配置就可以了。如果你面對的是特殊的大規模的工作集和高文件描述符限制，你可以試著提高參數值。

HDFS-347配置

HDFS-347實現的新機制，所有hdfs用戶都可以使用該特性，而不是局限于配置的幾個用戶。也沒有必要去修改Unix用戶組來設定誰可以訪問DN路徑。然而，java標準庫并不包含支持文件描述符傳遞的庫，所以該特性需要使用JNI。同時需要安裝libhadoop.so庫.

HDFS-347也需要一個Unix域套接字路徑，可通過dfs.domain.socket.path設置。該路徑必須安全地阻止無優先級進程進行中間人攻擊(MITM攻擊,man-in-the-middle attack)。每個套接字路徑必須是root擁有或者DN用戶擁有，不能使用人人都可以寫或者用戶組可寫方式的路徑。

如果你安裝cloudera包 rpm，deb，cloudera會創建一個默認的安全的unix域套接字路徑。同時會講libhadoop.so安裝到正確路徑下。

詳細配置信息可以參考 the upstream documentation

性能

新實現到底咋樣呢？作者使用 hio_bench程序獲取到一些性能統計數據。hiobench github 地址 https://github.com/cmccabe/hiotest。

測試案例運行在8核 intelXeon 2.13 12塊磁盤服務器上，集群使用CDH4.3.1，底層使用ext4文件系統。 下圖每個值是運行三次的平均值。

在所有測試案例中，HDFS-347實現是最快的，可能歸功于FileInputStreamCache.相反HDFS-2246實現會重復打開ext4 塊文件多次，打開文件是一個重操作。

short-circuit實現在隨機讀場景下比順序讀相對于hdfs初始的讀取機制有相對優勢。部分原因是為short-circuit local reads場景的 高速預讀（readahead）還未實現。可以參考HDFS-4697參與相關討論。

結論

SCR （short-circuit local reads）是hadoop模型下優化的一項極好的案例。他們也有如何解決規模不斷增長的挑戰，Cloudera目前正挑戰在集群中獲取每個節點更多性能方向的研究。

如果你正使用CDH4.2 或以上版本，用下新的實現把！

Colin McCabe is a Software Engineer on the Platform team, and a Hadoop Committer.

原文地址：如何提高hadoop中Short-Circuit Local Reads時的性能及安全性, 感謝原作者分享。

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com