hadoop3.0新特性介紹

 

    hadoop3.0新特性介紹

 

1. 基於jdk1.8（最低版本要求）

2. mr採用基於內存的計算，提升性能（快spark 10倍）

3. hdfs 通過最近black塊計算，加快數據獲取速度(塊大小：256M)

4. 支持多NameNode(實現了更加可靠的HA)

5. 引入EC糾刪碼技術(EC: Erasure Coding) 存儲空間節省50%

6. 精簡了內核

7．hadoop shell腳本重構

8．默認端口修改

9.支持數據的balancer（平衡）Intra-datanode均衡器

10. 基於API來配置 Capacity Scheduler 隊列的配置

2、主要變動介紹總架構的改變>> 1. Shell腳本重寫（1）增加了參數衝突檢測，避免重複定義和冗餘參數
（2）CLASSPATH, JAVA_LIBRARY_PATH, and LD_LIBRARY_PATH等參數的去重，縮短環境變量
（3）shell腳本重構，將更多的代碼加入function中，提供重載，刪除重複代碼，便於測試
（4）腳本清理和簡化
（5）儘可能與當前系統保持兼容
（6）提供一份Hadoop環境變量列表

(7) 提供一份Hadoop環境變量列表  Shell腳本現在支持一個–debug選項，它將報告有關各種環境變量，java選項，classpath等構造的基本信息，以幫助進行配置調試。
(8) 增加了distch和jnipath子命令到hadoop命令。
(9) 觸發ssh連接的操作現在可以使用pdsh（如果已安裝）。$ {HADOOP \ _SSH \ _OPTS}仍然被應用。
(10) 一個名爲–buildpaths的新選項將嘗試將開發人員構建目錄添加到類路徑以允許在源代碼樹測試中。
(11) 守護進程已經通過–daemon選項從* -daemon.sh移動到了bin命令。只需使用–daemon啓動一個守護進程
>> 2. 精簡內核剔除了過期的API和實現，廢棄hftp轉由webhdfs替代,將默認組件實現替換成最高效的實現（比如將FileOutputCommitter缺省實現換爲v2版本，廢除hftp轉由webhdfs替代，移除Hadoop子實現序列化庫org.apache.hadoop.Records
>> 3. Classpath isolation防止不同版本jar包衝突防止不同版本jar包衝突，例如google guava在混合使用hadoop、hbase、spark時出現衝突。mapreduce有參數控制忽略hadoop環境中的jar，而使用用戶提交的第三方jar，但提交spark任務卻不能解決此問題，需要在自己的jar包中重寫需要的第三方類或者整個spark環境升級。classpath isolation用戶可以很方便的選擇自己需要的第三方依賴包。
>> 4. jdk最低版本1.8>> 5. 支持MicrosoftAzure Data Lake文件系統>> 6. 部分服務默認端口修改不再綁定到Linux臨時端口 (HDFS-9427,HADOOP-12811)
Kms server ports: 16000 –> 9600 (原先的16000與HMaster端口衝突)

端口整理		2.x	3.x
NN ports	namenode ports	8020/9000	9820
	nn http ui	50070	9870
	nn https ui	50470	9871
SNN ports	snn http	50091	9869
	snn http ui	50090	9868
DN ports	dn ipc	50020	9867
	dn ipc	50010	9866
	dn http ui	50075	9864
	dn https ui	50475	9865
Kms server ports	舊16000與 HMaster端口衝突	16000	9600

HDFS新功能>>1. 糾刪碼將數據存儲空間節省50%hadoop-3.0之前，HDFS存儲方式爲每一份數據存儲3份，這也使得存儲利用率僅爲1/3，
hadoop-3.0引入糾刪碼技術(EC技術)，實現1份數據+0.5份冗餘校驗數據存儲方式
Erasure coding糾刪碼技術簡稱EC,是一種數據保護技術.最早用於通信行業中數據傳輸中的數據恢復,是一種編碼容錯技術.他通過在原始數據中加入新的校驗數據,使得各個部分的數據產生關聯性.在一定範圍的數據出錯情況下,通過糾刪碼技術都可以進行恢復.EC技術可以防止數據丟失，又可以解決HDFS存儲空間翻倍的問題。

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

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

>>2. 基於HDFS路由器的聯合HDFS基於路由器的聯合會添加一個RPC路由層，提供多個HDFS命名空間的聯合視圖。這與現有ViewFs和HDFS聯合功能類似），不同之處在於安裝表由服務器端由路由層而不是客戶端進行管理。這簡化了對現有HDFS客戶端的聯合集羣的訪問。與現有ViewFs和HDFS聯合功能類似），不同之處在於安裝表由服務器端由路由層而不是客戶端進行管理。這簡化了對現有HDFS客戶端的聯合集羣的訪問。


>>3. 支持多個NameNode但是Active的NameNode始終只有1個，餘下的都是Standby。 Standby NN會不斷與JN同步，保證自己獲取最新的editlog，並將edits同步到自己維護的image中去，這樣便可以實現熱備，在發生failover的時候，立馬切換成active狀態，對外提供服務。同時，JN只允許一個active狀態的NN寫入
>>4. Disk Balancer支持單個Datanode上，不同硬盤間的數據balancer。老版本的hadoop只支持在Datanode之間進行balancer，每個節點內部不同硬盤之間若發生了數據不平衡，則沒有一個好的辦法進行處理。現在可以通過hdfs diskbalancer命令，進行節點內部硬盤間的數據平衡。該功能默認是關閉的，需要手動設置參數dfs.disk.balancer.enabled爲true來開啓。

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不會自動更改。
YARN新功能與特性
>> 1. YARN Timeline Service v.2Yarn Timeline Service V2提供一個通用的應用程序共享信息和共享存儲模塊。可以將metrics等信息保存。可以實現分佈式writer實例和一個可伸縮的存儲模塊。同時，v2版本在穩定性和性能上面也做出了提升，原先版本不適用於大集羣，v2版本使用hbase取代了原先的leveldb作爲後臺的存儲工具。
>> 2. YARN資源類型YARN資源模型已被推廣爲支持用戶定義的可數資源類型，超越CPU和內存。例如，集羣管理員可以定義諸如GPU，軟件許可證或本地附加存儲器之類的資源。YARN任務可以根據這些資源的可用性進行調度。

>> 3. Hadoop守護進程和MapReduce任務的堆內存管理髮生了一系列變化主機內存大小可以自動調整，HADOOP_HEAPSIZE已棄用。
所需的堆大小不再需要通過任務配置和Java選項實現。已經指定的現有配置不受此更改影響。
>> 4.支持隨機container和分佈式調度已經引入了ExecutionType的概念，從而應用程序現在可以請求執行類型爲Opportunistic的容器。即使在調度時沒有可用的資源，也可以調度此類型的容器在NM處執行。在這種情況下，這些容器將在NM處排隊，等待資源啓動。機會容器的優先級低於默認的保證容器，因此如果需要的話，爲搶佔保證容器而騰出空間。這應該會提高羣集利用率。
機會容器默認由中央RM分配，但是也添加了支持以允許機會容器由分佈式調度器分配，該分佈式調度器被實現爲AMRMProtocol攔截器。
>> 5. S3Guard：S3A文件系統客戶端的一致性和元數據緩存爲Amazon S3存儲的S3A客戶端添加了一個可選功能：能夠將DynamoDB表用作文件和目錄元數據的快速一致存儲。
>> 6. Capacity Scheduler隊列配置的基於API的配置容量調度程序的OrgQueue擴展提供了一種編程方式，通過提供用戶可以調用的REST API來修改隊列配置來更改配置。這使管理員可以在隊列的administrators_queue ACL中自動執行隊列配置管理。