Hadoop 3.0 中的新功能

這篇“ Hadoop 3.0 的新特性”部落格重點關注 Hadoop 3 中的預期變化，因為它仍處於 alpha 階段。Apache 社群已經合併了許多更改，並且仍在處理其中的一些更改。因此，我們將更廣泛地審視預期的變化。

Apache Hadoop 3 將結合 Hadoop-2.x 的許多增強功能。因此，讓我們繼續前進，看看每項增強功能。

1. Hadoop 3 中最低要求的 Java 版本從 7 增加到 8

在 Hadoop 3 中，所有 Hadoop JAR 都是針對 Java 8 的執行時版本編譯的。因此，仍在使用 Java 7 或更低版本的使用者在開始使用 Hadoop 3 時必須升級到 Java 8。

2. 支援 HDFS 中的擦除編碼

那麼現在讓我們先了解一下什麼是擦除編碼。

通常，在儲存系統中，糾刪碼 主要用於廉價磁碟冗餘陣列（RAID）。

RAID通過條帶化striping實現EC ，其中邏輯上連續的資料（如檔案）被分成更小的單元（如位、位元組或塊），並將連續的單元儲存在不同的磁碟上。

然後對於原始資料單元的每個條帶，計算並儲存一定數量的奇偶校驗單元。這個過程稱為編碼。任何條帶單元上的錯誤都可以通過基於倖存資料單元和奇偶校驗單元的解碼計算來恢復。

在我們瞭解了擦除編碼的概念後，現在讓我們首先回顧一下早期的 Hadoop 2.x 中的複製場景。

HDFS 中的預設複製因子是 3，其中一個是原始資料塊，另外 2 個是副本，每個副本都需要 100% 的儲存開銷。因此，這會產生 200% 的儲存開銷，並且會消耗其他資源，例如網路頻寬。

然而，在正常操作期間很少訪問具有低 I/O 活動的冷資料集的副本，但仍然消耗與原始資料集相同數量的資源。

與 HDFS 複製相比，糾刪碼可儲存資料並提供容錯，同時具有更少的空間開銷。可以使用糾刪碼 (EC) 代替複製，這將提供 相同級別的容錯能力，同時儲存開銷更少。

將 EC 與 HDFS 整合可以保持相同的容錯性並提高儲存效率。例如，具有 6 個塊的 3x 複製檔案將消耗 6*3 = 18 個磁碟空間塊。但是在EC（6個資料，3個奇偶校驗）部署下，它只會消耗9個塊（6個資料塊+3個奇偶校驗塊）的磁碟空間。這僅需要高達 50% 的儲存開銷。

由於擦除編碼由於執行遠端讀取而需要額外的資料重構開銷，因此它通常用於儲存不太頻繁訪問的資料。在部署糾刪碼之前，使用者應該考慮所有開銷，如糾刪碼的儲存、網路和 CPU 開銷。

現在為了在 HDFS 中有效地支援擦除編碼，他們對架構進行了一些更改。讓我們來看看架構的變化。

HDFS 擦除編碼：架構

• NameNode 擴充套件– HDFS 檔案被分成塊組，這些塊組具有一定數量的內部塊。現在，為了減少這些附加塊的 NameNode 記憶體消耗，引入了新的分層塊命名協議。塊組的 ID 可以從其任何內部塊的 ID 中推匯出來。這允許在塊組級別而不是塊級別進行管理。

• 客戶端擴充套件——在 HDFS 中實現擦除編碼後，NameNode 工作在塊組級別，客戶端讀寫路徑得到增強，可以並行處理塊組中的多個內部塊。
  • 在輸出/寫入路徑上，DFSStripedOutputStream管理一組資料流處理器，每個 DataNode 一個，在當前塊組中儲存一個內部塊。協調器負責對整個區塊組的操作，包括結束當前區塊組、分配新的區塊組等。
  • 在輸入/讀取路徑上，DFSStripedInputStream將請求的資料邏輯位元組範圍作為範圍轉換為儲存在 DataNode 上的內部塊。然後它並行發出讀取請求。出現故障時，它會發出額外的讀取請求以進行解碼。

• 資料節點擴充套件 -資料管理部執行失敗的擦除編碼塊的背景回收額外ErasureCodingWorker（ECWorker）任務。NameNode 會檢測到失敗的 EC 塊，然後它會選擇一個 DataNode 來執行恢復工作。重建執行三項關鍵任務：
  1. 從源節點讀取資料，只讀取最少數量的輸入塊和奇偶校驗塊進行重構。
  2. 從輸入資料中解碼新資料和奇偶校驗塊。所有丟失的資料和奇偶校驗塊一起解碼。
  3. 解碼完成後，將恢復的塊傳輸到目標 DataNode。

• ErasureCoding 策略——為了適應異構工作負載，我們允許 HDFS 叢集中的檔案和目錄具有不同的複製和 EC 策略。有關編碼和解碼檔案的資訊封裝在 ErasureCodingPolicy 類中。它包含 2 條資訊，即 ECSchema 和剝離單元的大小。

Hadoop 3 中第二個最重要的增強是來自 YARN 版本 1（在 Hadoop 2.x 中）的 YARN 時間線服務版本 2。他們正試圖在 YARN 版本 2 中做出許多積極的改變。

3. YARN 時間線服務 v.2

Hadoop 正在引入 YARN 時間線服務 iev2 的重大修訂。YARN 時間線服務。它的開發是為了解決兩個主要挑戰：

1. 提高時間線服務的可擴充套件性和可靠性
2. 通過引入流和聚合來增強可用性

YARN Timeline Service v.2 可以由開發人員測試以提供反饋和建議。它應該僅在測試能力中被利用。 YARN Timeline Service v.2 中未啟用安全性。

因此，讓我們先討論可擴充套件性，然後再討論流和聚合。 

• YARN 時間線服務 v.2：可擴充套件性

YARN 版本 1 僅限於寫入器/讀取器的單個例項，並且不能很好地擴充套件到小叢集之外。版本 2 使用更具可擴充套件性的分散式寫入器架構和可擴充套件的後端儲存。它將資料的收集（寫入）與資料的服務（讀取）分開。它使用分散式收集器，基本上每個 YARN 應用程式一個收集器。閱讀器是獨立的例項，專門用於通過 REST API 提供查詢服務。 

YARN Timeline Service v.2 選擇 Apache HBase 作為主要的後備儲存，因為 Apache HBase 可以很好地擴充套件到大尺寸，同時保持良好的讀寫響應時間。

• YARN 時間線服務 v.2： 可用性改進

現在談論可用性改進，在很多情況下，使用者對 YARN 應用程式的“流”或邏輯組級別的資訊感興趣。啟動一組或一系列 YARN 應用程式以完成邏輯應用程式更為常見。Timeline Service v.2 明確支援流的概念。此外，它支援在流級別聚合指標，如下圖所示。

• YARN 時間線服務 v.2： 架構

YARN Timeline Service v.2 使用一組收集器（寫入器）將資料寫入後端儲存。收集器與它們所專用於的應用程式主伺服器分佈並位於同一位置。屬於該應用程式的所有資料都被髮送到應用程式級別的時間線收集器，但資源管理器時間線收集器除外。

對於給定的應用程式，應用程式主機可以將應用程式的資料寫入位於同一地點的時間線收集器。此外，執行應用程式容器的其他節點的節點管理器也將資料寫入執行應用程式主節點的時間線收集器。

資源管理器還維護自己的時間線收集器。它僅發出 YARN 通用的生命週期事件以保持其合理的寫入量。

時間線閱讀器是獨立於時間線收集器的獨立守護程式，它們專門用於通過 REST API 提供查詢服務。

4.Shell指令碼重寫

Hadoop shell 指令碼已被重寫以修復許多錯誤、解決相容性問題並在某些現有安裝中進行更改。它還包含一些新功能。所以我將列出一些重要的：

• 所有 Hadoop shell 指令碼子系統現在都執行 hadoop-env.sh，這允許所有環境變數位於一個位置。
• 守護程式已通過 –daemon 選項從 *-daemon.sh 移動到 bin 命令。在Hadoop 3中，我們可以簡單地使用--daemon start來啟動一個守護程式，--daemon stop來停止一個守護程式，以及--daemon status來設定$? 到守護程式的狀態。例如，'hdfs –daemon start namenode'。 
• 如果已安裝，觸發 ssh 連線的操作現在可以使用 pdsh。
• ${HADOOP_CONF_DIR} 現在無處不在，無需符號連結和其他此類技巧。
• 指令碼現在可以在守護程式啟動時針對日誌和 pid 目錄的各種狀態測試和報告更好的錯誤訊息。以前，未受保護的外殼錯誤會顯示給使用者。

當 Hadoop 3 處於測試階段時，您將瞭解更多功能。現在讓我們討論陰影客戶端 jar 並瞭解它們的好處。 

5. 切分客戶Jar

Hadoop 2.x 版本中可用的 hadoop-client將 Hadoop 的可傳遞依賴項拉到 Hadoop 應用程式的類路徑上。如果這些可傳遞依賴項的版本與應用程式使用的版本衝突，這可能會產生問題。

所以在 Hadoop 3 中，我們有新的 hadoop-client-api 和 hadoop-client-runtime 工件，它們將 Hadoop 的依賴項隱藏到一個 jar 中。hadoop-client-api是編譯範圍 & hadoop-client-runtime是執行時範圍，它包含從hadoop-client重新定位的第三方依賴項。因此，您可以將依賴項捆綁到一個 jar 中並測試整個 jar 是否存在版本衝突。這避免了將 Hadoop 的依賴項洩漏到應用程式的類路徑上。例如，HBase 可以用於與 Hadoop 叢集對話，而無需檢視任何實現依賴項。

6. 支援機會容器和分散式排程

引入了一個新的 ExecutionType，即Opportunistic 容器，即使在排程時沒有可用資源，它也可以在 NodeManager 上分派執行。在這種情況下，這些容器將在 NM 排隊，等待資源可用以啟動。機會容器的優先順序低於預設的保證（Guaranteed ）容器，因此在需要時會被搶佔，為保證（Guaranteed ）容器騰出空間。這應該會提高叢集利用率。

保證（Guaranteed ）容器 對應於現有的 YARN 容器。它們由容量排程器分配，一旦被排程到一個節點，就保證有可用的資源可以立即開始執行。此外，只要沒有故障，這些容器就會執行完成。

機會容器預設由中央 RM 分配，但也新增了支援以允許由分散式排程程式分配機會容器，該排程程式實現為 AMRMProtocol 攔截器。

現在繼續前進，讓我們看看 MapReduce 效能是如何優化的。

7. MapReduce 任務級原生優化

在 Hadoop 3 中，MapReduce 中為地圖輸出收集器新增了本機 Java 實現。對於 shuffle 密集型作業，這將效能提高 30% 或更多。

他們新增了地圖輸出收集器的本地實現。對於 shuffle 密集型作業，這可能會提供 30% 或更多的加速。他們正在研究基於 JNI 的 MapTask 原生優化。基本思想是新增一個 NativeMapOutputCollector 來處理對映器發出的鍵值對，因此排序、溢位、IFile 序列化都可以在本機程式碼中完成。他們仍在處理合並程式碼。

現在讓我們看看 Apache 社群是如何嘗試使 Hadoop 3 更具容錯性的。

8. 支援 2 個以上 NameNode

在 Hadoop 2.x 中，HDFS NameNode 高可用性架構具有單個活動 NameNode 和單個備用 NameNode。通過將編輯複製到法定數量的三個 JournalNode，該架構能夠容忍任何一個 NameNode 的故障。

但是，關鍵業務部署需要更高程度的容錯能力。因此，在 Hadoop 3 中允許使用者執行多個備用 NameNode。例如，通過配置三個 NameNode（1 個主動和 2 個被動）和五個 JournalNode，叢集可以容忍兩個節點的故障。

9. 多個服務的預設埠已更改

早些時候，多個 Hadoop 服務的預設埠在 Linux臨時埠範圍內(32768-61000)。除非客戶端程式明確請求特定埠號，否則使用的埠號是臨時埠號。所以在啟動時，服務有時會因為與另一個應用程式衝突而無法繫結到埠。

因此，具有臨時範圍的衝突埠已移出該範圍，從而影響多個服務的埠號，即 NameNode、Secondary NameNode、DataNode 等。其中一些重要的是：

10. 支援檔案系統聯結器

Hadoop 現在支援與 Microsoft Azure Data Lake 和 Aliyun Object Storage System 的整合。它可以用作替代的 Hadoop 相容檔案系統。首先新增了 Microsoft Azure Data Lake，然後他們也新增了阿里雲物件儲存系統。你可能會期待更多。

11. 資料節點內平衡器

單個 DataNode 管理多個磁碟。在正常的寫操作期間，資料被平均劃分，因此磁碟被均勻地填滿。但是新增或更換磁碟會導致 DataNode 內出現偏差。現有的 HDFS 平衡器早期無法處理這種情況。這涉及到 DataNode 內的偏斜。

現在 Hadoop 3 通過新的內部 DataNode 平衡功能處理這種情況，該功能通過 hdfs diskbalancer CLI 呼叫。 

12. 重新設計守護程式和任務堆管理

對 Hadoop 守護程式和 MapReduce 任務的堆管理進行了一系列更改。

• 配置守護程式堆大小的新方法。值得注意的是，現在可以根據主機的記憶體大小進行自動調整，並且不推薦使用 HADOOP_HEAPSIZE 變數。取而代之的是，引入了 HADOOP_HEAPSIZE_MAX 和 HADOOP_HEAPSIZE_MIN 來分別設定 Xmx 和 Xms。 所有全域性和特定於守護程式的堆大小變數現在都支援單位。如果變數只是一個數字，則假定大小以兆位元組為單位。

• 簡化 map 的配置並減少任務堆大小，因此不再需要在任務配置和 Java 選項中指定所需的堆大小。已指定兩者的現有配置不受此更改的影響。