HDFS優化之實戰經驗

Linux系統優化

一、禁止文件系統記錄時間

Linux文件系統會記錄文件創建、修改和訪問操作的時間信息，這在讀寫操作頻繁的應用中將帶來不小的性能損失。在掛載文件系統時設置noatime和nodiratime可禁止文件系統記錄文件和目錄的訪問時間，這對HDFS這種讀取操作頻繁的系統來說，可以節約一筆可觀的開銷。可以修改/etc/fstab文件中noatime和nodiratime來實現這個設置。

如對/mnt/disk1使用noatime屬性，可以做如下修改:

$ vim /etc/fstab
/ ext4 defaults 1 1
/mnt/disk1 ext4 defaults,noatime 1 2

修改完成後，運行下述命令使之生效：
$ mount –o remount /mnt/disk1

二、預讀緩沖
預讀技術可以有效的減少磁盤尋道次數和應用的I/O等待時間，增加Linux文件系統預讀緩沖區的大小(默認為256 sectors，128KB)，可以明顯提高順序文件的讀性能，建議調整到1024或2048 sectors。預讀緩沖區的設置可以通過blockdev命令來完成。下面的命令將/dev/sda的預讀緩沖區大小設置為2048 sectors。
$ blockdev –setra 2048 /dev/sda

HDFS配置及相關優化

根據業務需求和服務器配置合理設置這些選項可以有效提高HDFS的性能

配置項

優化原理

推薦值

dfs.namenode.handler.count

NameNode中用於處理RPC調用的線程數，默認為10。對於較大的集群和配置較好的服務器，可適當增加這個數值來提升NameNode RPC服務的並發度。

64

dfs.datanode.handler.count

DataNode中用於處理RPC調用的線程數，默認為3。可適當增加這個數值來提升DataNode RPC服務的並發度。

10

dfs.replication

數據塊的備份數。默認值為3，對於一些熱點數據，可適當增加備份數。

3

dfs.block.size

HDFS數據塊的大小，默認為64M。數據庫設置太小會增加NameNode的壓力。數據塊設置過大會增加定位數據的時間。

128

dfs.datanode.data.dir

HDFS數據存儲目錄。將數據存儲分布在各個磁盤上可充分利用節點的I/O讀寫性能。

設置多個磁盤目錄

hadoop.tmp.dir

Hadoop臨時目錄，默認為系統目錄/tmp。在每個磁盤上都建立一個臨時目錄，可提高HDFS和MapReduce的I/O效率。

設置多個磁盤目錄

dfs.data.dir

HDFS數據存儲配置 提高I/O效率

以逗號隔開

dfs.name.dir

HDFS元數據存儲配置, 要想提升hadoop整體IO性能，對於hadoop中用到的所有文件目錄，都需要評估它磁盤IO的負載，對於IO負載可能會高的目錄，最好都配置到多個磁盤上，以提示IO性能

--

Io.file.buffer.size

HDFS文件緩沖區大小，默認為4096(即4K)

131072(128K)

fs.trash.interval

HDFS清理回收站的時間周期，單位為分鐘。默認為0，表示不使用回收站特性。為防止重要文件誤刪，可啟用該特性

1440(1day)

dfs.datanode.du.reserved

DataNode保留空間大小，單位為字節。默認情況下，DataNode會占用全部可用的磁盤空間，該配置項可以使DataNode保留部分磁盤空間工其他應用程序使用。

視具體應用而定

RAID

獨立硬盤冗余陣列（RAID, Redundant Array of Independent Disks) 軟件RAID管理工具：mdadm | 支持的RAID級別：LINEAR、RAID0、1、4、5、6、10

配置使用【作業 1】

機架感應

對於較大的集群，建議啟用HDFS的機架感應功能。啟用機架感應功能可以使HDFS優化數據塊備份的分布，增強HDFS的性能和可靠性。

配置使用【作業 2】

小文件合並 具體操作已實操

SSD存儲介質

註意：在全SSD機型的服務器上，如果應用使用的HDFS客戶端jar包版本與服務端不一致，會導致無法寫入數據的問題。

該問題是由於HDFS客戶端ABI不兼容導致的，在HDFS 2.5.x版本中，對存儲策略的編號與HDFS 2.6.x版本的編號不一致，在全SSD機型中，客戶端寫入數據的策略被定義為HOT，而在服務端，該策略被解析為DISK，因為全SSD機型中不存在SATA盤，所以無法獲取可行的磁盤，導致無法寫入數據。

HDFS異構存儲解決冷熱數據問題 **

Hadoop從2.6.0版本開始支持異構存儲功能。我們知道HDFS默認的存儲策略，對於每個數據塊，采用三個副本的存儲方式，保存在不同節點的磁盤上。異構存儲的作用在於利用服務器不同類型的存儲介質（包括HDD硬盤、SSD、內存等）提供更多的存儲策略（例如三個副本一個保存在SSD介質，剩下兩個仍然保存在HDD硬盤），從而使得HDFS的存儲能夠更靈活高效地應對各種應用場景。

隨著數據量的不斷增長積累，數據也會呈現出訪問熱度不同的巨大差異。例如一個平臺會不斷地寫入最新的數據，但通常情況下最近寫入的數據訪問頻率會比很久之前的數據高很多。如果無論數據冷熱情況，都采用同樣的存儲策略，是對集群資源的一種浪費。如何根據數據冷熱程度對HDFS存儲系統進行優化是一個亟待解決的問題。

拓展》》》

調度延遲和可移植性【涉及到後時代的3駕馬車，了解即可】

1、調度延遲
關於調度延遲主要是發生在兩個階段：
a) tasktracker上出現空余的slot到該tasktracker接收到新的task；
b) tasktracker獲取到了新的Task後，到連接上了datanode，並且可以讀寫數據。
之所以說這兩個階段不夠高效，因為一個分布式計算系統需要解決的是計算問題，如果把過多的時間花費在其它上，就顯得很不合適，例如線程等待、高負荷的數據傳輸。

下面解釋下會經歷上邊兩個階段發生的過程：
a) 當tasktracker上出現slot時，他會調用heartbeat方法向jobtracker發送心跳包（默認時間間隔是3秒，集群很大時可適量調整）來告知它，假設此時有準備需要執行的task，那麽jobtracker會采用某種調度機制（調度機制很重要，是一個可以深度研究的東東）選擇一個Task，然後通過調用heartbeat方法發送心跳包告知tasktracker。在該過程中，HDFS一直處於等待狀態，這就使得資源利用率不高。
b) 這個過程中所發生的操作都是串行化的：tasktracker會連接到namenode上獲取到自己需要的數據在datanode上的存儲情況，然後再從datanode上讀數據，在該過程中，HDFS一直處於等待狀態，這就使得資源利用率不高。
若能減短hdfs的等待時間;在執行task之前就開始把數據讀到將要執行該task的tasktracker上，減少數據傳輸時間，那麽將會顯得高效很多。未解決此類問題，有這樣幾種解決方案：重疊I/O和CPU階段（pipelining），task預取（task prefetching），數據預取（data prefetching）等。

2可移植性
Hadoop是Java寫的，所以可移植性相對較高。由於它屏蔽了底層文件系統，所以無法使用底層api來優化數據的讀寫。在活躍度較高的集群裏（例如共享集群），大量並發讀寫會增加磁盤的隨機尋道時間，這會降低讀寫效率;在大並發寫的場景下，還會增加大量的磁盤碎片，這樣將會大大的增加了讀數據的成本，hdfs更適合文件順序讀取。
對於上述問題，可以嘗試使用下面的解決方案：
tasktracker現在的線程模型是：one thread per client，即每個client連接都是由一個線程處理的（包括接受請求、處理請求，返回結果）。那麽這一塊一個拆分成兩個部分來做，一組線程來處理和client的通信（Client Threads），一組用於數據的讀寫（Disk Threads）。
想要解決上述兩個問題，暫時沒有十全十美的辦法，只能盡可能的權衡保證調度延遲相對較低+可移植性相對較高。

優化策略：Prefetching與preshuffling
a) Prefetching包括Block-intra prefetching和Block-inter prefetching：
Block-intra prefetching：對block內部數據處理方式進行了優化，即一邊進行計算，一邊預讀將要用到的數據。這種方式需要解決兩個難題：一個是計算和預取同步，另一個是確定合適的預取率。前者可以使用進度條（processing bar）的概念，進度條主要是記錄計算數據和預讀數據的進度，當同步被打破時發出同步失效的通知。後者是要根據實際情況來設定，可采用重復試驗的方法來確定。
Block-inter prefetching：在block層面上預讀數據，在某個Task正在處理數據塊A1的時候，預測器能預測接下來將要讀取的數據塊A2、A3、A4，然後把數據塊A2、A3、A4預讀到Task所在的rack上。

b) preshuffling
數據被map task處理之前，由預測器判斷每條記錄將要被哪個reduce task處理，將這些數據交給靠近reduce task的map task來處理。

原文：https://blog.csdn.net/Jackie_ZHF/article/details/79369001

HDFS配置參數及優化之實戰經驗（Linux hdfs）