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的效能

小檔案合併  具體操作已實操

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與preshufflinga) 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來處理。