Hadoop3.0新特性介紹，比Spark快10倍的Hadoop3.0新特性

Apache hadoop 專案組最新訊息，hadoop3.x以後將會調整方案架構，將Mapreduce 基於記憶體+io+磁碟，共同處理資料。
其實最大改變的是hdfs,hdfs 通過最近black塊計算，根據最近計算原則，本地black塊，加入到記憶體，先計算，通過IO，共享記憶體計算區域，最後快速形成計算結果。

1. Hadoop 3.0簡介

Hadoop 2.0是基於JDK 1.7開發的，而JDK 1.7在2015年4月已停止更新，這直接迫使Hadoop社群基於JDK 1.8重新發佈一個新的Hadoop版本，而這正是hadoop 3.0。

Hadoop 3.0的alpha版預計今年夏天釋出，GA版本11月或12月釋出。

Hadoop 3.0中引入了一些重要的功能和優化，包括HDFS 可擦除編碼、多Namenode支援、MR Native Task優化、YARN基於cgroup的記憶體和磁碟IO隔離、YARN container resizing等。

2. Hadoop 3.0新特性概述

Hadoop 3.0在功能和效能方面，對hadoop核心進行了多項重大改進，主要包括：

2.1 Hadoop Common

（1）精簡Hadoop核心，包括剔除過期的API和實現，將預設元件實現替換成最高效的實現（比如將FileOutputCommitter預設實現換為v2版本，廢除hftp轉由webhdfs替代，移除Hadoop子實現序列化庫org.apache.hadoop.Records

（2）Classpath isolation以防止不同版本jar包衝突，比如google Guava在混合使用Hadoop、HBase和Spark時，很容易產生衝突。（https://issues.apache.org/jira/browse/HADOOP-11656）

（3）Shell指令碼重構。 Hadoop 3.0對Hadoop的管理指令碼進行了重構，修復了大量bug，增加了新特性，支援動態命令等。https://issues.apache.org/jira/browse/HADOOP-9902

2.2 Hadoop HDFS

（1）HDFS支援資料的擦除編碼，這使得HDFS在不降低可靠性的前提下，節省一半儲存空間。（https://issues.apache.org/jira/browse/HDFS-7285）

（2）多NameNode支援，即支援一個叢集中，一個active、多個standby namenode部署方式。注：多ResourceManager特性在hadoop 2.0中已經支援。（https://issues.apache.org/jira/browse/HDFS-6440）

2.3 Hadoop MapReduce

（1）Tasknative優化。為MapReduce增加了C/C++的map output collector實現（包括Spill，Sort和IFile等），通過作業級別引數調整就可切換到該實現上。對於shuffle密集型應用，其效能可提高約30%。（https://issues.apache.org/jira/browse/MAPREDUCE-2841）

（2）MapReduce記憶體引數自動推斷。在Hadoop 2.0中，為MapReduce作業設定記憶體引數非常繁瑣，涉及到兩個引數：mapreduce.{map,reduce}.memory.mb和mapreduce.{map,reduce}.java.opts，一旦設定不合理，則會使得記憶體資源浪費嚴重，比如將前者設定為4096MB，但後者卻是“-Xmx2g”，則剩餘2g實際上無法讓java heap使用到。（https://issues.apache.org/jira/browse/MAPREDUCE-5785）

2.4 Hadoop YARN

（1）基於cgroup的記憶體隔離和IO Disk隔離（https://issues.apache.org/jira/browse/YARN-2619）

（2）用curator實現RM leader選舉（https://issues.apache.org/jira/browse/YARN-4438）

（3）containerresizing（https://issues.apache.org/jira/browse/YARN-1197）

（4）Timelineserver next generation （https://issues.apache.org/jira/browse/YARN-2928）

3. Hadoop3.0 新特性總結

Hadoop 3.0的alpha版預計2016夏天釋出，GA版本11月或12月釋出。

Hadoop 3.0中引入了一些重要的功能和優化，包括HDFS 可擦除編碼、多Namenode支援、MR Native Task優化、YARN基於cgroup的記憶體和磁碟IO隔離、YARN container resizing等

3.1．hadoop-3.0要求JDK版本不低於1.8，對之前的Java版本不再提供支援.

所有Hadoop JAR現在都是針對Java 8的執行時版本編譯的。

3.2．部分服務預設埠修改，不再繫結到Linux臨時埠 (HDFS-9427,HADOOP-12811)

Namenode ports: 50470 --> 9871, 50070--> 9870, 8020 --> 9820

Secondary NN ports: 50091 --> 9869,50090 --> 9868

Datanode ports: 50020 --> 9867, 50010--> 9866, 50475 --> 9865, 50075 --> 9864

Kms server ports: 16000 --> 9600 (原先的16000與HMaster埠衝突)

3.3. 精簡了核心，剔除了過期的API和實現，廢棄hftp轉由webhdfs替代

將預設元件實現替換成最高效的實現（比如將FileOutputCommitter預設實現換為v2版本，廢除hftp轉由webhdfs替代，移除Hadoop子實現序列化庫org.apache.hadoop.Records

3.4.重寫 client jars

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

添加了新的hadoop-client-api和hadoop-client-runtime構件，可以將Hadoop的依賴關係集中到一個jar中。這可以避免將Hadoop的依賴洩漏到應用程式的類路徑中。

3.5. Classpath isolation防止不同版本jar包衝突

防止不同版本jar包衝突，例如google guava在混合使用hadoop、hbase、spark時出現衝突。mapreduce有引數控制忽略hadoop環境中的jar，而使用使用者提交的第三方jar，但提交spark任務卻不能解決此問題，需要在自己的jar包中重寫需要的第三方類或者整個spark環境升級。classpath isolation使用者可以很方便的選擇自己需要的第三方依賴包。

3.6.支援微軟的Azure分散式檔案系統和阿里的aliyun分散式檔案系統

3.7. Shell指令碼重寫

（1）增加了引數衝突檢測，避免重複定義和冗餘引數

（2）CLASSPATH, JAVA_LIBRARY_PATH, and LD_LIBRARY_PATH等引數的去重，縮短環境變數

(3) 提供一份Hadoop環境變數列表  Shell指令碼現在支援一個--debug選項，它將報告有關各種環境變數，java選項，classpath等構造的基本資訊，以幫助進行配置除錯。

(4) 增加了distch和jnipath子命令到hadoop命令。

(5) 觸發ssh連線的操作現在可以使用pdsh（如果已安裝）。$ {HADOOP \ _SSH \ _OPTS}仍然被應用。

(6) 一個名為--buildpaths的新選項將嘗試將開發人員構建目錄新增到類路徑以允許在原始碼樹測試中。

(7) 守護程序已經通過--daemon選項從* -daemon.sh移動到了bin命令。只需使用--daemon啟動一個守護程序

3.8. Hadoop守護程序和MapReduce任務的堆記憶體管理髮生了一系列變化

主機記憶體大小可以自動調整，HADOOP_HEAPSIZE已棄用。
所需的堆大小不再需要通過任務配置和Java選項實現。已經指定的現有配置不受此更改影響。

3.9. 支援隨機container和分散式排程

已經引入了ExecutionType的概念，從而應用程式現在可以請求執行型別為Opportunistic的容器。即使在排程時沒有可用的資源，也可以排程此型別的容器在NM處執行。在這種情況下，這些容器將在NM處排隊，等待資源啟動。機會容器的優先順序低於預設的保證容器，因此如果需要的話，為搶佔保證容器而騰出空間。這應該會提高群集利用率。

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

3.10. S3Guard：S3A檔案系統客戶端的一致性和元資料快取

為Amazon S3儲存的S3A客戶端添加了一個可選功能：能夠將DynamoDB表用作檔案和目錄元資料的快速一致儲存。

3.11. Capacity Scheduler佇列配置的基於API的配置

容量排程程式的OrgQueue擴充套件提供了一種程式設計方式，通過提供使用者可以呼叫的REST API來修改佇列配置來更改配置。這使管理員可以在佇列的administrators_queue ACL中自動執行佇列配置管理。

3.12. HDFS新功能與特性

(1)支援HDFS中的擦除編碼Erasure Encoding

Erasure coding糾刪碼技術簡稱EC,是一種資料保護技術.最早用於通訊行業中資料傳輸中的資料恢復,是一種編碼容錯技術.他通過在原始資料中加入新的校驗資料,使得各個部分的資料產生關聯性.在一定範圍的資料出錯情況下,通過糾刪碼技術都可以進行恢復.EC技術可以防止資料丟失，又可以解決HDFS儲存空間翻倍的問題。

建立檔案時，將從最近的祖先目錄繼承EC策略，以確定其塊如何儲存。與3路複製相比，預設的EC策略可以節省50％的儲存空間，同時還可以承受更多的儲存故障。

建議EC儲存用於冷資料，由於冷資料確實數量大，可以減少副本從而降低儲存空間，另外冷資料穩定，一旦需要恢復資料，對業務不會有太大影響。

(2) 基於HDFS路由器的聯合

HDFS基於路由器的聯合會新增一個RPC路由層，提供多個HDFS名稱空間的聯合檢視。這與現有ViewFs和HDFS聯合功能類似），不同之處在於安裝表由伺服器端由路由層而不是客戶端進行管理。這簡化了對現有HDFS客戶端的聯合叢集的訪問。與現有ViewFs和HDFS聯合功能類似），不同之處在於安裝表由伺服器端由路由層而不是客戶端進行管理。這簡化了對現有HDFS客戶端的聯合叢集的訪問。

(3)支援多個NameNode

允許使用者執行多個備用NameNode。例如，通過配置三個NameNode和五個JournalNode，群集能夠容忍兩個節點的故障，而不是一個故障。

但是Active的NameNode始終只有1個，餘下的都是Standby。 Standby NN會不斷與JN同步，保證自己獲取最新的editlog，並將edits同步到自己維護的image中去，這樣便可以實現熱備，在發生failover的時候，立馬切換成active狀態，對外提供服務。同時，JN只允許一個active狀態的NN寫入

(4)DataNode內部添加了負載均衡  Disk Balancer

支援單個Datanode上，不同硬碟間的資料balancer。老版本的hadoop只支援在Datanode之間進行balancer，每個節點內部不同硬碟之間若發生了資料不平衡，則沒有一個好的辦法進行處理。現在可以通過hdfs diskbalancer命令，進行節點內部硬碟間的資料平衡。該功能預設是關閉的，需要手動設定引數dfs.disk.balancer.enabled為true來開啟。

3.13.MapReduce新功能與特性  

（1）MapReduce任務級本地優化（引入Native Task加速計算）

為MapReduce增加了C/C++的map output collector實現（包括Spill，Sort和IFile等），通過作業級別引數調整就可切換到該實現上。

本地庫將使用-Pnative自動生成。使用者可以通過設定mapreduce.job.map.output.collector.class = org.apache.hadoop.mapred來選擇新的收集器。
nativetask.NativeMapOutputCollectorDelegator的作業配置。對於shuffle密集型工作，這可能會提高30％以上的速度。

（2）MapReduce記憶體引數自動推斷

在Hadoop 2.0中，為MapReduce作業設定記憶體引數非常繁瑣，涉及到兩個引數：mapreduce.{map,reduce}.memory.mb和mapreduce.{map,reduce}.java.opts，一旦設定不合理，則會使得記憶體資源浪費嚴重，比如將前者設定為4096MB，但後者卻是“-Xmx2g”，則剩餘2g實際上無法讓java heap使用到。

有了這個JIRA，我們建議根據可以調整的經驗比例自動設定Xmx。如果使用者提供，Xmx不會自動更改。

3.14.YARN新功能與特性

（1）YARN資源型別

YARN資源模型已被推廣為支援使用者定義的可數資源型別，超越CPU和記憶體。例如，叢集管理員可以定義諸如GPU，軟體許可證或本地附加儲存器之類的資源。YARN任務可以根據這些資源的可用性進行排程。

（2）YARN Timeline Service v.2

提供YARN時間軸服務v.2 alpha 2，以便使用者和開發人員可以對其進行測試，並提供反饋意見和建議，使其成為Timeline Service v.1.x的替代品。它只能用於測試能力。

Yarn Timeline Service V2提供一個通用的應用程式共享資訊和共享儲存模組。可以將metrics等資訊儲存。可以實現分散式writer例項和一個可伸縮的儲存模組。同時，v2版本在穩定性和效能上面也做出了提升，原先版本不適用於大叢集，v2版本使用hbase取代了原先的leveldb作為後臺的儲存工具。

（3）基於cgroup的記憶體隔離和IO Disk隔離

（4）用curator實現RM leader選舉

（5）支援更改分配容器的資源Container resizing

當前的YARN資源管理邏輯假定分配給容器的資源在其生命週期中是固定的。當用戶想要更改分配的容器的資源時，唯一的辦法就是釋放它並分配一個具有預期大小的新容器。
允許執行時更改分配容器的資源將使我們更好地控制應用程式中的資源使用情況