?

? ? hadoop3.0新特性介紹

?

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

2. mr采用基于內(nèi)存的計算，提升性能（快spark 10倍）

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

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

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

6. 精簡了內(nèi)核

7．hadoop shell腳本重構(gòu)

8．默認端口修改

9.支持?jǐn)?shù)據(jù)的balancer（平衡）Intra-datanode均衡器

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

2、主要變動介紹總架構(gòu)的改變>> 1.?Shell腳本重寫（1）增加了參數(shù)沖突檢測，避免重復(fù)定義和冗余參數(shù)
（2）CLASSPATH, JAVA_LIBRARY_PATH, and LD_LIBRARY_PATH等參數(shù)的去重，縮短環(huán)境變量
（3）shell腳本重構(gòu)，將更多的代碼加入function中，提供重載，刪除重復(fù)代碼，便于測試
（4）腳本清理和簡化
（5）盡可能與當(dāng)前系統(tǒng)保持兼容
（6）提供一份Hadoop環(huán)境變量列表

(7) 提供一份Hadoop環(huán)境變量列表??Shell腳本現(xiàn)在支持一個–debug選項，它將報告有關(guān)各種環(huán)境變量，java選項，classpath等構(gòu)造的基本信息，以幫助進行配置調(diào)試。
(8) 增加了distch和jnipath子命令到hadoop命令。
(9) 觸發(fā)ssh連接的操作現(xiàn)在可以使用pdsh（如果已安裝）。$ {HADOOP \ _SSH \ _OPTS}仍然被應(yīng)用。
(10) 一個名為–buildpaths的新選項將嘗試將開發(fā)人員構(gòu)建目錄添加到類路徑以允許在源代碼樹測試中。
(11) 守護進程已經(jīng)通過–daemon選項從* -daemon.sh移動到了bin命令。只需使用–daemon啟動一個守護進程
>> 2. 精簡內(nèi)核剔除了過期的API和實現(xiàn)，廢棄hftp轉(zhuǎn)由webhdfs替代,將默認組件實現(xiàn)替換成最高效的實現(xiàn)（比如將FileOutputCommitter缺省實現(xiàn)換為v2版本，廢除hftp轉(zhuǎn)由webhdfs替代，移除Hadoop子實現(xiàn)序列化庫org.apache.hadoop.Records
>> 3. Classpath isolation防止不同版本jar包沖突防止不同版本jar包沖突，例如google guava在混合使用hadoop、hbase、spark時出現(xiàn)沖突。mapreduce有參數(shù)控制忽略hadoop環(huán)境中的jar，而使用用戶提交的第三方j(luò)ar，但提交spark任務(wù)卻不能解決此問題，需要在自己的jar包中重寫需要的第三方類或者整個spark環(huán)境升級。classpath isolation用戶可以很方便的選擇自己需要的第三方依賴包。
>> 4. jdk最低版本1.8>> 5. 支持MicrosoftAzure Data Lake文件系統(tǒng)>> 6. 部分服務(wù)默認端口修改不再綁定到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. 糾刪碼將數(shù)據(jù)存儲空間節(jié)省50%hadoop-3.0之前，HDFS存儲方式為每一份數(shù)據(jù)存儲3份，這也使得存儲利用率僅為1/3，
hadoop-3.0引入糾刪碼技術(shù)(EC技術(shù))，實現(xiàn)1份數(shù)據(jù)+0.5份冗余校驗數(shù)據(jù)存儲方式
Erasure coding糾刪碼技術(shù)簡稱EC,是一種數(shù)據(jù)保護技術(shù).最早用于通信行業(yè)中數(shù)據(jù)傳輸中的數(shù)據(jù)恢復(fù),是一種編碼容錯技術(shù).他通過在原始數(shù)據(jù)中加入新的校驗數(shù)據(jù),使得各個部分的數(shù)據(jù)產(chǎn)生關(guān)聯(lián)性.在一定范圍的數(shù)據(jù)出錯情況下,通過糾刪碼技術(shù)都可以進行恢復(fù).EC技術(shù)可以防止數(shù)據(jù)丟失，又可以解決HDFS存儲空間翻倍的問題。

創(chuàng)建文件時，將從最近的祖先目錄繼承EC策略，以確定其塊如何存儲。與3路復(fù)制相比，默認的EC策略可以節(jié)省50％的存儲空間，同時還可以承受更多的存儲故障。

建議EC存儲用于冷數(shù)據(jù)，由于冷數(shù)據(jù)確實數(shù)量大，可以減少副本從而降低存儲空間，另外冷數(shù)據(jù)穩(wěn)定，一旦需要恢復(fù)數(shù)據(jù)，對業(yè)務(wù)不會有太大影響。

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


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

MapReduce新功能與特性>>1. MapReduce任務(wù)級本地優(yōu)化（引入Native Task加速計算）為MapReduce增加了C/C++的map output collector實現(xiàn)（包括Spill，Sort和IFile等），通過作業(yè)級別參數(shù)調(diào)整就可切換到該實現(xiàn)上。
本地庫將使用-Pnative自動生成。用戶可以通過設(shè)置mapreduce.job.map.output.collector.class = org.apache.hadoop.mapred來選擇新的收集器。
nativetask.NativeMapOutputCollectorDelegator的作業(yè)配置。對于shuffle密集型工作，這可能會提高30％以上的速度。
>>2. MapReduce內(nèi)存參數(shù)自動推斷在Hadoop 2.0中，為MapReduce作業(yè)設(shè)置內(nèi)存參數(shù)非常繁瑣，涉及到兩個參數(shù)：mapreduce.{map,reduce}.memory.mb和mapreduce.{map,reduce}.java.opts，一旦設(shè)置不合理，則會使得內(nèi)存資源浪費嚴(yán)重，比如將前者設(shè)置為4096MB，但后者卻是“-Xmx2g”，則剩余2g實際上無法讓java heap使用到。
有了這個JIRA，我們建議根據(jù)可以調(diào)整的經(jīng)驗比例自動設(shè)置Xmx。如果用戶提供，Xmx不會自動更改。
YARN新功能與特性
>> 1. YARN Timeline Service v.2Yarn Timeline Service V2提供一個通用的應(yīng)用程序共享信息和共享存儲模塊。可以將metrics等信息保存。可以實現(xiàn)分布式writer實例和一個可伸縮的存儲模塊。同時，v2版本在穩(wěn)定性和性能上面也做出了提升，原先版本不適用于大集群，v2版本使用hbase取代了原先的leveldb作為后臺的存儲工具。
>> 2. YARN資源類型YARN資源模型已被推廣為支持用戶定義的可數(shù)資源類型，超越CPU和內(nèi)存。例如，集群管理員可以定義諸如GPU，軟件許可證或本地附加存儲器之類的資源。YARN任務(wù)可以根據(jù)這些資源的可用性進行調(diào)度。

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

總結(jié)

以上是生活随笔為你收集整理的hadoop3.0新特性介绍的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。