1．hadoop-3.0要求JDK版本不低於1.8，對之前的Java版本不再提供支持.
所有Hadoop JAR現在都是針對Java 8的運行時版本編譯的。
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. 精簡了內核，剔除了過期的API和實現，廢棄hftp轉由webhdfs替代
將默認組件實現替換成最高效的實現（比如將FileOutputCommitter缺省實現換為v2版本，廢除hftp轉由webhdfs替代，移除Hadoop子實現序列化庫org.apache.hadoop.Records
4.重寫 client jars
2.x版本中的hadoop-client Maven工件將Hadoop的傳遞依賴關系拉到Hadoop應用程序的類路徑上。如果這些傳遞性依賴的版本與應用程序使用的版本沖突，這可能會有問題。
添加了新的hadoop-client-api和hadoop-client-runtime構件，可以將Hadoop的依賴關系集中到一個jar中。這可以避免將Hadoop的依賴泄漏到應用程序的類路徑中。
5. Classpath isolation防止不同版本jar包沖突
防止不同版本jar包沖突，例如google guava在混合使用hadoop、hbase、spark時出現沖突。mapreduce有參數控制忽略hadoop環境中的jar，而使用用戶提交的第三方jar，但提交spark任務卻不能解決此問題，需要在自己的jar包中重寫需要的第三方類或者整個spark環境升級。classpath isolation用戶可以很方便的選擇自己需要的第三方依賴包。
6.支持微軟的Azure分布式文件系統和阿里的aliyun分布式文件系統
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啟動一個守護進程
8. Hadoop守護進程和MapReduce任務的堆內存管理發生了一系列變化
主機內存大小可以自動調整，HADOOP_HEAPSIZE已棄用。
所需的堆大小不再需要通過任務配置和Java選項實現。已經指定的現有配置不受此更改影響。
9. 支持隨機container和分布式調度
已經引入了ExecutionType的概念，從而應用程序現在可以請求執行類型為Opportunistic的容器。即使在調度時沒有可用的資源，也可以調度此類型的容器在NM處執行。在這種情況下，這些容器將在NM處排隊，等待資源啟動。機會容器的優先級低於默認的保證容器，因此如果需要的話，為搶占保證容器而騰出空間。這應該會提高群集利用率。
機會容器默認由中央RM分配，但是也添加了支持以允許機會容器由分布式調度器分配，該分布式調度器被實現為AMRMProtocol攔截器。
10. S3Guard：S3A文件系統客戶端的一致性和元數據緩存
為Amazon S3存儲的S3A客戶端添加了一個可選功能：能夠將DynamoDB表用作文件和目錄元數據的快速一致存儲。
11. Capacity Scheduler隊列配置的基於API的配置
容量調度程序的OrgQueue擴展提供了一種編程方式，通過提供用戶可以調用的REST API來修改隊列配置來更改配置。這使管理員可以在隊列的administrators_queue ACL中自動執行隊列配置管理。
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來開啟。
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不會自動更改。
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資源管理邏輯假定分配給容器的資源在其生命周期中是固定的。當用戶想要更改分配的容器的資源時，唯一的辦法就是釋放它並分配一個具有預期大小的新容器。
允許運行時更改分配容器的資源將使我們更好地控制應用程序中的資源使用情況