1.概述
接著上一篇部落格的內容，繼續介紹Hadoop3的其他新特性。其內容包含：優化Hadoop Shell指令碼、重構Hadoop Client Jar包、支援等待Container、MapReduce任務級別本地優化、支援多個NameNode、部分預設服務埠被改變、支援檔案系統聯結器、DataNode內部新增負載均衡、重構後臺程式和任務堆管理。
2.內容
2.2.1 優化Hadoop Shell指令碼
Hadoop Shell指令碼已經被重寫，用來修復已知的BUG，解決相容性問題和一些現有安裝的更改。它還包含了一些新的特性，內容如下所示：
- 所有Hadoop Shell指令碼子系統現在都會執行hadoop-env.sh這個指令碼，它允許所有環節變數位於一個位置；
- 守護程式已通過*-daemon.sh選項從*-daemon.sh移動到了bin命令中，在Hadoop3中，我們可以簡單的使用守護程式來啟動、停止對應的Hadoop系統程式；
- 觸發SSH連線操作現在可以在安裝時使用PDSH；
- ${HADOOP_CONF_DIR}現在可以任意配置到任何地方；
- 指令碼現在測試並報告守護程式啟動時日誌和程式ID的各種狀態；
2.2.2 重構Hadoop Client Jar包
Hadoop2 中可用的Hadoop客戶端將Hadoop的傳遞依賴性拉到Hadoop應用程式的類路徑上。如果這些傳遞依賴項的版本與應用程式使用的版本傳送衝突，這可能會產生問題。
因此，在Hadoop3中有新的Hadoop客戶端API和Hadoop客戶端執行時工件，它們將Hadoop的依賴性遮蔽到單個JAR中，Hadoop客戶端API是編譯範圍，Hadoop客戶端執行時是執行時範圍，它包含從Hadoop客戶端重新定位的第三方依賴關係。因此，你可以將依賴項繫結到JAR中，並測試整個JAR以解決版本衝突。這樣避免了將Hadoop的依賴性洩露到應用程式的類路徑上。例如，HBase可以用來與Hadoop叢集進行資料互動，而不需要看到任何實現依賴。
2.2.3 支援等待容器和分散式排程
在Hadoop3 中引入了一種新型執行型別，即等待容器，即使在排程時叢集沒有可用的資源，它也可以在NodeManager中被排程執行。在這種情況下，這些容器將在NM中排隊等待資源啟動，等待榮容器比預設容器優先順序低，因此，如果需要，可以搶佔預設容器的空間，這樣可以提供機器的利用率。如下圖所示：
預設容器對於現有的YARN容器，它們由容量排程分配，一旦被排程到節點，就保證有可用的資源使它們執行立即開始。此外，只要沒有故障發生，這些容器就可以允許完畢。
等待容器預設由中心RM分配，但還增加了支援以允許等待容器被分散式排程，該排程群被實現於AM和RM協議的攔截器。
2.2.4 MapReduce任務級別本地化優化
在Hadoop3中，本地的Java實現已加入MapReduce地圖輸出器，對於Shuffle密集的作業，這樣可以提高30%或者更高的效能。
它們新增了對映輸出收集器的本機實現，讓MapTask基於JNI來本機優化。基本思想是新增一個NativeMapOutputCollector收集器來處理對映器發出的鍵值對，因此Sort、Spill、檔案序列化都可以在本機程式碼中完成。
2.2.5 支援多個NameNode節點
在Hadoop2中，HDFS NameNode高可用體系結構有一個Active和Standby NameNode，通過JournalNodes，該體系結構能夠容忍任何一個NameNode失敗。
然而，業務關鍵部署需要更高程度的容錯性。因此，在Hadoop3中允許使用者執行多個備用的NameNode。例如，通過配置三個NameNode（1個Active NameNode和2個Standby NameNode）和5個JournalNodes節點，叢集可以容忍2個NameNode節點故障。如下圖所示：
2.2.6 預設的服務埠被修改
早些時候，多個Hadoop服務的預設埠位於Linux埠範圍以內。除非客戶端程式明確的請求特定的埠號，否則使用的埠號是臨時的，因此，在啟動時，服務有時會因為與其他另一個應用程式衝突而無法繫結到埠。
因此，具有臨時範圍衝突埠已經被移除該範圍，影響多個服務的埠號，即NameNode、Secondary NameNode、DataNode等如下所示：
| Daemon | App | Hadoop2 Port | Hadoop3 Port |
| NameNode Port | Hadoop HDFS NameNode | 8020 | 9820 |
| Hadoop HDFS NameNode HTTP UI | 50070 | 9870 | |
| Hadoop HDFS NameNode HTTPS UI | 50470 | 9871 | |
| Secondary NameNode Port | Secondary NameNode HTTP | 50091 | 9869 |
| Secondary NameNode HTTP UI | 50090 | 9868 | |
| DataNode Port | Hadoop HDFS DataNode IPC | 50020 | 9867 |
| Hadoop HDFS DataNode | 50010 | 9866 | |
| Hadoop HDFS DataNode HTTP UI | 50075 | 9864 | |
| Hadoop HDFS DataNode HTTPS UI | 50475 | 9865 |
2.2.6 支援檔案系統聯結器
Hadoop現在支援與微軟 Azure資料和阿里雲物件儲存系統的整合。它可以作為一種替代Hadoop相容的檔案系統，首先新增微軟Azure資料，然後新增阿里雲物件儲存系統。
2.2.7 DataNode內部負載均衡
單個資料節點配置多個資料磁碟，在正常寫入操作期間，資料被均勻的劃分，因此，磁碟被均勻填充。但是，在維護磁碟時，新增或者替換磁碟會導致DataNode節點儲存出現偏移，這種情況在早期的HDFS檔案系統中，是沒有被處理的。如圖下圖所示，維護前和維護後不均衡的情況：
現在Hadoop3通過新的內部DataNode平衡功能來處理這種情況，這是通過hdfs diskbalancer CLI來進行呼叫的。執行之後，DataNode會進行均衡處理，如下圖所示：
2.2.8 重構後臺程式和任務堆管理
Hadoop守護程式和MapReduce任務的堆管理已經發生了一系列的變化。
- 配置守護程式堆大小的新方法：值得注意的是，現在可以根據主機的記憶體大小進行自動調整，並且已經禁止HADOOP_HEAPSIZE變數。在HADOOP\_HEAPSIZE\_MAX 和 HADOOP\_HEAPSIZE\_MIN位置上，分別設定XMX和XMS。所有全域性和守護程式特定堆大小變數現在都支援單元。如果變數僅為一個數，它的大小為MB。
- Map和Reduce的堆大小的配置被簡化了，所以不再需要任務配置作為一個Java選項指定。已經指定的兩個現有配置不受此更改的影響。
3.總結
Hadoop3的這些新特性還是很吸引人的，目前官方推出的穩定版本是2.9.0，發行版是3.1.0，感興趣的同學可以下載Hadoop3去體驗調研學習一下這些新特性。
4.結束語
這篇部落格就和大家分享到這裡，如果大家在研究學習的過程當中有什麼問題，可以加群進行討論或傳送郵件給我，我會盡我所能為您解答，與君共勉！