云海Insight HD V4.6.5技術(shù)白皮書

云海InsightHDV4.6.5技術(shù)白皮書浪潮（北京）電子信息產(chǎn)業(yè)有限公司2020年5月云海InsightHDV4.6.5規(guī)格指標產(chǎn)品概述需求及背景當前，新一代信息技術(shù)正在快速改變著我們的生活方式，數(shù)據(jù)已經(jīng)成為組織和企業(yè)的核心資產(chǎn)，數(shù)字經(jīng)濟正在驅(qū)動新一輪的社會變革，政府和企業(yè)的數(shù)字化轉(zhuǎn)型已經(jīng)成為大數(shù)據(jù)時代的一種趨勢。為了應(yīng)對行業(yè)轉(zhuǎn)型和產(chǎn)業(yè)升級的需要，越來越多的用戶開始向大數(shù)據(jù)運營模式轉(zhuǎn)型。Hadoop技術(shù)經(jīng)過多年的蓬勃發(fā)展，使大數(shù)據(jù)技術(shù)真正承托起一大批企業(yè)的數(shù)據(jù)基礎(chǔ)架構(gòu)。大數(shù)據(jù)平臺需要建設(shè)成為一個高可靠性、高安全性、高性能、可擴展性、容錯性俱全的先進系統(tǒng)；用來對數(shù)據(jù)進行存儲、計算、檢索、分析、查詢和管理等操作。開源的大數(shù)據(jù)生態(tài)體系中，各個組件更新升級頻繁，組件之間存在兼容性、穩(wěn)定性問題，也缺乏技術(shù)支持，距離落地為企業(yè)級產(chǎn)品仍然有較大差距。浪潮基于豐富的行業(yè)大數(shù)據(jù)實踐經(jīng)驗，選擇符合主流技術(shù)發(fā)展方向的開源組件，并進行功能增強、性能優(yōu)化、統(tǒng)一管理、安全保障等，發(fā)布了企業(yè)級大數(shù)據(jù)平臺云海InsightHD。云海InsightHD提供了多源數(shù)據(jù)的高效集成、異構(gòu)超媒體數(shù)據(jù)的海量存儲、場景豐富的計算框架、海量數(shù)據(jù)的實時分析挖掘、統(tǒng)一的平臺化管理監(jiān)控、便捷易用的數(shù)據(jù)操作、立體化的數(shù)據(jù)安全等能力。能夠使用戶可以在生產(chǎn)中可靠地使用Hadoop，同時又可以從開源社區(qū)借助到持續(xù)無窮創(chuàng)新的最佳方案。產(chǎn)品定位企業(yè)級大數(shù)據(jù)平臺云海InsightHD是浪潮面向多源異構(gòu)超媒體數(shù)據(jù)融合構(gòu)建數(shù)據(jù)生態(tài)的核心平臺，也是浪潮“云數(shù)智”技術(shù)堆棧中的重要組成部分。云海InsightHD內(nèi)置了大數(shù)據(jù)生態(tài)中的20多種常用組件，提供統(tǒng)一的平臺化管理運維能力，實現(xiàn)了重點功能深度增強和性能優(yōu)化；提供PB級別數(shù)據(jù)的多源采集、統(tǒng)一存儲和多引擎計算、數(shù)據(jù)高效處理、任務(wù)編排、安全管理等全過程治理能力。作為業(yè)界領(lǐng)先的企業(yè)級分布式大數(shù)據(jù)處理環(huán)境，云海InsightHD除了包含業(yè)界流行的基于開源Hadoop及其生態(tài)組件構(gòu)建的核心，還包含了很多為支撐企業(yè)級業(yè)務(wù)的高級管理特性。借助于云海InsightHD成熟的整體方案，政府或企業(yè)可以放心將數(shù)據(jù)整合在云海InsightHD進行數(shù)據(jù)創(chuàng)新，進而專注于自己的業(yè)務(wù)能力。產(chǎn)品價值浪潮云海InsightHD，被廣泛應(yīng)用在海量文本實時搜索、多維數(shù)據(jù)交互分析式挖掘和比對碰撞、統(tǒng)一平臺的數(shù)據(jù)開放共享、流數(shù)據(jù)實時計算、海量數(shù)據(jù)挖掘分析等行業(yè)業(yè)務(wù)場景中；同時也是浪潮企業(yè)云、政務(wù)云平臺中分布式計算服務(wù)（托管Hadoop服務(wù)、流式計算服務(wù)、數(shù)據(jù)科學探索服務(wù)等）的核心技術(shù)組件。用戶可以基于云海InsightHD產(chǎn)品快速搭建起安全可靠、高效智能的數(shù)據(jù)湖平臺，實現(xiàn)傳統(tǒng)產(chǎn)業(yè)數(shù)字化、智能化的轉(zhuǎn)型。從宏觀層面，政府數(shù)據(jù)及互聯(lián)網(wǎng)數(shù)據(jù)的開發(fā)利用已進入新的階段，產(chǎn)品將推動政府數(shù)據(jù)社會化流通、市場化運營，助力數(shù)字經(jīng)濟建設(shè)及大數(shù)據(jù)產(chǎn)業(yè)發(fā)展。數(shù)據(jù)運營將進一步整合政府數(shù)據(jù)、社會數(shù)據(jù)、互聯(lián)網(wǎng)數(shù)據(jù)，建立起安全可靠、快速精準、高效滿意的政府數(shù)據(jù)社會化利用的紐帶和橋梁，服務(wù)于社會治理、公共安全、企業(yè)經(jīng)營等領(lǐng)域，充分挖掘數(shù)據(jù)價值，激發(fā)創(chuàng)新創(chuàng)業(yè)活力，推動數(shù)字經(jīng)濟的發(fā)展。產(chǎn)品特性云海Insight加強版將Hadoop生態(tài)系統(tǒng)的力量帶給客戶，產(chǎn)品具有如下關(guān)鍵特性：靈活性可以存儲任意類型的數(shù)據(jù)并可以使用多種不同的處理框架對數(shù)據(jù)進行處理，如批處理、交互式SQL、文本查詢、機器學習和統(tǒng)計分析計算。集成化快速建立并快速運行于一個完整的包裝好的基于ApacheHadoop的系統(tǒng)。安全性方便處理和控制敏感的數(shù)據(jù)，提供多租戶的運行保護機制。可擴展為廣泛的應(yīng)用提供運行設(shè)施，并隨著業(yè)務(wù)成長支持靈活彈性擴展。高可用可以應(yīng)對多任務(wù)高負載的應(yīng)用場景，保證集群的穩(wěn)定。兼容性擴充和利用現(xiàn)有的基礎(chǔ)架構(gòu)，保護投資。開放性受益于高速的創(chuàng)新，并且無需受制于專有供應(yīng)商的鎖定。產(chǎn)品應(yīng)用場景大數(shù)據(jù)的典型應(yīng)用場景主要有：批處理(ETL)在線服務(wù)實時數(shù)據(jù)分析全文檢索不同的應(yīng)用場景，所用到的組件及架構(gòu)有些差異，具體分析如下：批處理ETL批處理的特點是處理時間窗口比較長，通常輸入輸出的數(shù)據(jù)量都比較大，諸如數(shù)據(jù)的裝載、轉(zhuǎn)換以及清洗等等。批處理的數(shù)據(jù)源一般會來自于傳統(tǒng)的OLTP系統(tǒng)、數(shù)據(jù)倉庫、客戶關(guān)系庫或是一些線上的應(yīng)用服務(wù)器?？梢酝ㄟ^Flume或者Sqoop導入到HDFS上，作為原始數(shù)據(jù)存放。如果合適，可以將這部分原始數(shù)據(jù)轉(zhuǎn)載成列式存儲的文件格式。之后可以借助一些圖形化的配置工具或者腳本來定義ETL的處理流程，調(diào)用Hive來完成數(shù)據(jù)處理。執(zhí)行引擎可以選擇MapReduce或者是Spark。處理完之后生成的中間結(jié)果，建議采用列式存儲。在線服務(wù)應(yīng)用與傳統(tǒng)的在線應(yīng)用相比，基于HBase的方案優(yōu)勢在于：良好的水平可擴展性、高可靠性及高并發(fā)性。在線應(yīng)用的數(shù)據(jù)源主要有兩種：一種是存量數(shù)據(jù)，來源于DW或者一些備份庫上；還有一種來自于線上系統(tǒng)實時產(chǎn)生的數(shù)據(jù)。對于存量數(shù)據(jù)可以先導入到HDFS上，然后通過批處理引擎加載進HBase庫。數(shù)據(jù)先加載進HDFS，有幾個原因：1）可以減少對其他系統(tǒng)的依賴；2）提高加載的性能（如果從其他系統(tǒng)直接加載入HBase，系統(tǒng)之間的數(shù)據(jù)訪問性能得不到保障）；3）載入的HDFS數(shù)據(jù)可以用于OLAP的應(yīng)用。對于實時數(shù)據(jù)可以通過Flume或者Kafka采集進來，借助于SparkStreaming對實時數(shù)據(jù)做一些過濾或者統(tǒng)計（這個處理過程可選），然后載入HBase，通過HBase的API或者SQL前端（如ApachePhoenix）進行在線數(shù)據(jù)查詢。實時數(shù)據(jù)分析實時數(shù)據(jù)分析的時間窗口一般都在秒級，如實時的文本搜索、實時推薦引擎等。這種分析的數(shù)據(jù)源一般都來自線上系統(tǒng)，或是外部捕獲的實時數(shù)據(jù)。獲取的數(shù)據(jù)可以通過Flume和Kafka加載入Hadoop平臺，數(shù)據(jù)一方面可以存入HDFS，其中保存了全量數(shù)據(jù)，可以對數(shù)據(jù)做全量的或者批量的分析；另一方面數(shù)據(jù)可以經(jīng)過SparkStreaming引擎，它只是對一個很小的時間窗口數(shù)據(jù)進行分析。在HDFS上的數(shù)據(jù)可用于建模，模型可以存入分布式數(shù)據(jù)庫，并做定期的模型修正。實時處理模塊可以從分布式數(shù)據(jù)庫中獲取相應(yīng)的模型，并對實時數(shù)據(jù)使用模型計算出實時的結(jié)果，這些結(jié)果可以用于線上系統(tǒng)的實時展現(xiàn)。全文檢索基于ElasticSearch的全文搜索解決方案，用于在企業(yè)內(nèi)部構(gòu)建實時的大數(shù)據(jù)搜索引擎。可以將離線數(shù)據(jù)批量導入到ElasticSearch存儲中，再通過Kafka、在線應(yīng)用等實時數(shù)據(jù)管道接入最新數(shù)據(jù)。開箱即用的高適用性配置，支持多種文本分詞技術(shù)索引數(shù)據(jù)，功能強大的查詢表達式（QueryDSL）使開發(fā)者無需了解底層架構(gòu)就可以開發(fā)出高效的搜索引擎。

總體架構(gòu)架構(gòu)圖組件說明InsightHD包含Manager和眾多組件，分別提供功能如下：Manager為InsightHD提供高可靠、安全、容錯、易用的集群管理能力，支持大規(guī)模集群的安裝部署、監(jiān)控、告警、用戶管理、權(quán)限管理、審計、服務(wù)管理、健康檢查、問題定位、升級、補丁等。Hue提供了圖形化用戶Web界面。支持展示多種組件。Flume一個分布式、可靠和高可用的海量日志聚合系統(tǒng)，支持在系統(tǒng)中定制各類數(shù)據(jù)發(fā)送方，用于收集數(shù)據(jù)；此外它提供了對數(shù)據(jù)進行簡單處理和寫入各種數(shù)據(jù)接收方的能力。Hive建立在Hadoop之上的數(shù)據(jù)倉庫，提供類似于SQL的HQL語言、操作結(jié)構(gòu)化數(shù)據(jù)存儲服務(wù)和基本的數(shù)據(jù)分析服務(wù)。MapReduce提供快速并行處理海量數(shù)據(jù)的能力，是一種分布式數(shù)據(jù)處理模式。Spark基于內(nèi)存的大規(guī)模數(shù)據(jù)處理的快速通用引擎。Solr一個高性能，基于Lucene的全文檢索服務(wù)器。Solr對Lucene進行了擴展，提供了比Lucene更為豐富的查詢語言，同時實現(xiàn)了可配置、可擴展，并對查詢性能進行了優(yōu)化。提供了一個完善的功能管理界面，是一款非常優(yōu)秀的全文檢索引擎。Oozie提供了對Hadoop組件的任務(wù)編排、執(zhí)行的功能。以JavaWeb應(yīng)用程序的形式運行在Javaservlet容器（如：Tomcat）中，并使用數(shù)據(jù)庫來存儲工作流定義當前運行的工作流實例（含實例的狀態(tài)和變量）。Kafka一個分布式的、分區(qū)的、多副本的實時消息發(fā)布和訂閱系統(tǒng)。提供可擴展、高吞吐、低延遲、高可靠的消息分發(fā)服務(wù)。YARN資源管理系統(tǒng)，它是一個通用的資源模塊，可以為各類應(yīng)用程序進行資源管理和調(diào)度。HDFSHadoop分布式文件系統(tǒng)，提供高吞吐量的數(shù)據(jù)訪問，適合大規(guī)模數(shù)據(jù)集方面的應(yīng)用。HBase提供海量數(shù)據(jù)存儲功能，是一種構(gòu)建在HDFS之上的分布式、面向列的存儲系統(tǒng)。Zeppelin基于網(wǎng)絡(luò)的筆記本，支持交互式數(shù)據(jù)分析。能夠使用SQL、Scala等工具生成交互協(xié)作文檔。ZooKeeper提供分布式、高可用性的協(xié)調(diào)服務(wù)能力。幫助系統(tǒng)避免單點故障，從而建立可靠的應(yīng)用程序。Tez是一個支持DAG作業(yè)的計算框架，可以將多個有依賴的作業(yè)轉(zhuǎn)換為一個作業(yè)從而大幅提升DAG作業(yè)的性能。SqoopHadoop和結(jié)構(gòu)化數(shù)據(jù)存儲（如關(guān)系數(shù)據(jù)庫）之間的數(shù)據(jù)交換工具。Storm是一個分布式實時計算系統(tǒng)，可以簡單、可靠地處理大量的數(shù)據(jù)流。可以集成隊列和數(shù)據(jù)庫系統(tǒng)，主要用例有：實時分析、在線機器學習、分布式RPC和ETL等。Ranger是一個跨Hadoop平臺的管理和監(jiān)控數(shù)據(jù)安全的框架。提供對Hadoop組件的授權(quán)和審計服務(wù)。Phoenix是HBase的SQL驅(qū)動，它使得HBase支持通過JDBC的方式進行訪問，并將Sql查詢轉(zhuǎn)換成HBase的掃描和相應(yīng)的動作。Kerberos是一種應(yīng)用對稱密鑰體制進行密鑰管理的系統(tǒng)。采用客戶端/服務(wù)器結(jié)構(gòu)與DES加密技術(shù)，并且能夠進行相互認證，即客戶端和服務(wù)器端均可對對方進行身份認證?？梢杂糜诜乐垢`聽、防止replay攻擊、保護數(shù)據(jù)完整性等場合。ElasticSearch基于Lucene的分布式、高擴展、高實時的搜索與數(shù)據(jù)分析引擎，具備存儲、搜索、快速實時分析大量數(shù)據(jù)等特性。OpenTSDB基于HBase的分布式、可伸縮的時間序列數(shù)據(jù)庫。DataSpaceDataSpace是一個簡單易用的大數(shù)據(jù)集群資源管理系統(tǒng)。用戶可以輕松通過界面或RestAPI創(chuàng)建自己的數(shù)據(jù)空間，并將數(shù)據(jù)空間中的資源共享給其他用戶使用。ML適合各水平開發(fā)人員利用和學習機器學習技術(shù)的Web工具。用戶可通過界面的引導操作完成機器學習模型的創(chuàng)建，并提供結(jié)果預(yù)測。RedisRedis提供一個內(nèi)存中的數(shù)據(jù)結(jié)構(gòu)存儲系統(tǒng)，它可以用作數(shù)據(jù)庫、緩存和消息中間件。

NiFi 一個易用、強大、可靠的系統(tǒng)，用于處理和分發(fā)數(shù)據(jù)。LogSerach 提供日志聚合、分析和可視化服務(wù)。

產(chǎn)品功能Manager功能描述為InsightHD提供高可靠、安全、容錯、易用的集群管理能力，支持大規(guī)模集群的安裝部署、監(jiān)控、告警、用戶管理、權(quán)限管理、審計、服務(wù)管理、健康檢查、問題定位、升級、補丁等。解決Hadoop生態(tài)系統(tǒng)部署Hadoop部署時，組件間有依賴，包括配置、版本、啟動順序、權(quán)限配置等問題。Manager能夠進行部署過程跟蹤，展示部署過程中每個步驟的狀態(tài)及相關(guān)信息。隨著集群規(guī)模的不斷增加，機器出問題概率也會增加，在部署或更新中可能會出現(xiàn)故障。Hadoop及其組件需要允許機器的故障，同時需要防止不兼容版本組件給系統(tǒng)帶來的影響。Manager部署服務(wù)時，能夠容忍某些組件啟動、更新失敗。配置管理可以將默認配置寫入stack中，在開啟時Manager讀取stack中各個版本的config文件，在使用blueprint創(chuàng)建集群部署Hadoop時，直接生成command-json文件。服務(wù)狀態(tài)展示、監(jiān)控，報警預(yù)先配置好關(guān)鍵的運維指標（metrics），可以直接查看HadoopCore（HDFS和MapReduce）及相關(guān)組件（如HBase、Hive和HCatalog）的健康狀況。支持作業(yè)與任務(wù)執(zhí)行的可視化與分析，能夠更好地查看依賴和性能。通過一個完整的RESTfulAPI把監(jiān)控信息暴露出來，集成了現(xiàn)有的運維工具。用戶界面非常直觀，用戶可以輕松有效地查看信息并控制集群。架構(gòu)原理在Manager-server開放的RestAPI中分為主要的兩大類API，其中一類為Manager-web提供監(jiān)控管理服務(wù)，另一類用于與Manager-agent交互，接受Manager-agent向Manager-server發(fā)送的心跳請求。Master模塊接受API和AgentInterface的請求，完成Manager-server的集中式管理監(jiān)控，而每個agent節(jié)點只負責所在節(jié)點的狀態(tài)采集及維護工作。Agent內(nèi)部架構(gòu)：Agent是一個無狀態(tài)的，其功能分兩部分：采集所在節(jié)點的信息并且匯總發(fā)送心跳報告給server；處理server的執(zhí)行請求。因此它有兩種隊列：消息隊列MessageQueue，或稱為ResultQueue。包括節(jié)點狀態(tài)信息（包括注冊信息）和執(zhí)行結(jié)果信息，并且匯總后通過心跳發(fā)送給server。操作隊列ActionQueue。用于接收server發(fā)送過來的狀態(tài)操作，然后交給執(zhí)行器調(diào)用puppet或Python腳本等模塊執(zhí)行任務(wù)。Manager-server內(nèi)部架構(gòu)：LiveClusterState：集群現(xiàn)有狀態(tài)，各個節(jié)點匯報的狀態(tài)信息會改變該狀態(tài);DesiredState：用戶希望該節(jié)點所處狀態(tài)，是用戶在頁面進行了一系列的操作，需要更改某些服務(wù)的狀態(tài)，這些狀態(tài)還沒有在節(jié)點上產(chǎn)生作用;ActionState：操作狀態(tài)，是狀態(tài)改變時的請求狀態(tài)，也可以看作是一種中間狀態(tài)，這種狀態(tài)可以輔助LiveClusterState向DesiredState狀態(tài)轉(zhuǎn)變。Manager-server的HeartbeatHandler模塊用于接收各個agent的心跳請求（心跳請求里面主要包含兩類信息：節(jié)點狀態(tài)信息和返回的操作結(jié)果），把節(jié)點狀態(tài)信息傳遞給FSM狀態(tài)機去維護該節(jié)點的狀態(tài)，并且把返回的操作結(jié)果信息返回給ActionManager去做進一步的處理。Coordinator模塊又可以稱為APIhandler，主要在接收WEB端操作請求后，會檢查它是否符合要求，stageplanner會分解成一組操作，最后提供給ActionManager去完成執(zhí)行操作。因此，從上圖就可以看出，Manager-Server的所有狀態(tài)信息的維護和變更都會記錄在數(shù)據(jù)庫中，用戶更改服務(wù)的操作都會在數(shù)據(jù)庫上有相應(yīng)的記錄，同時，agent通過心跳來獲得數(shù)據(jù)庫的變更歷史。特性與平臺無關(guān)該系統(tǒng)體系結(jié)構(gòu)支持多種硬件和操作系統(tǒng)，如RHEL，SLES，Ubuntu，Windows等?？刹灏谓M件該架構(gòu)不限定具體的工具和技術(shù)，任何具體的工具和技術(shù)都可以通過可插拔的組件封裝。版本管理和升級各個節(jié)點上運行Manager組件支持多個版本的協(xié)議，該協(xié)議支持組件的獨立升級。任何Manager的組件的升級不影響集群狀態(tài)?？蓴U展性可以輕松添加新的服務(wù)，組件和API。

擴展性也意味著易于為Hadoop棧修改任何配置或provisioning步驟。故障恢復能夠從任何元件故障恢復到一致的狀態(tài)，恢復后應(yīng)盡量完成掛起操作。如果錯誤是不可恢復的，那么應(yīng)該使系統(tǒng)處于一致狀態(tài)。安全認證和Manager用戶（包括API和WebUI）的基于角色的授權(quán)、安裝、管理和監(jiān)控Hadoop的堆棧，通過Kerberos授權(quán)，以及認證和加密Manager組件之間的通信。錯誤跟蹤能夠提供錯誤跟蹤的能力，并且提供錯誤分析信息方便用戶排錯。操作的準實時反饋對于需要一段時間才能完成操作，系統(tǒng)需要能夠及時（準實時）向用戶提供反饋當前正在運行的任務(wù)的進展，操作完成的百分比，操作日志的鏈接等。企業(yè)級增強一鍵式安裝Manager的WebUI提供向?qū)降募喊惭b步驟，用戶根據(jù)界面引導可一步步完成集群安裝。無人值守安裝Manager提供智能無人值守安裝模式，按照最新RA架構(gòu)，可以最大化的利用集群性能，自動分配各節(jié)點適合安裝的組件。此模式，只需簡單配置好網(wǎng)絡(luò)，設(shè)置必要參數(shù)，即可自動快速部署高可用集群。完善的告警體系Manager為用戶提供界面化的系統(tǒng)運行環(huán)境自動檢查服務(wù)，幫助用戶實現(xiàn)一鍵式系統(tǒng)運行健康度巡檢和審計，保障系統(tǒng)的正常運行，降低系統(tǒng)運維成本。用戶查看檢查結(jié)果后，還可導出檢查報告用于存檔及問題分析。系統(tǒng)可靠性所有組件的管理節(jié)點均實現(xiàn)HA。Hadoop開源版本的數(shù)據(jù)、計算節(jié)點已經(jīng)是按照分布式系統(tǒng)進行設(shè)計的，單節(jié)點故障不影響系統(tǒng)整體運行；而以集中模式運作的管理節(jié)點可能出現(xiàn)的單點故障，就成為整個系統(tǒng)可靠性的短板。InsightHD產(chǎn)品對所有業(yè)務(wù)組件的管理節(jié)點都提供了類似的雙機機制，包括HDFSNameNode、HiveServer、HBaseHMaster、YARNResourcesManager、KerberosServer等，全部采用主備或負荷分擔配置，有效避免了單點故障場景對系統(tǒng)可靠性的影響。數(shù)據(jù)可靠性InsightHD通過對節(jié)點硬件（特別是硬盤）、操作系統(tǒng)、進程的監(jiān)控，及時發(fā)現(xiàn)相關(guān)部件的異常狀況，縮短了對應(yīng)部件的故障檢測時間和修復時間，從而提高了整體系統(tǒng)的可靠性。ZooKeeper功能描述ZooKeeper可為大型分布式計算提供開源的分布式配置服務(wù)、同步服務(wù)和命名注冊等功能。其目標是封裝復雜易出錯的關(guān)鍵服務(wù)，將簡單易用的接口和性能高效、功能穩(wěn)定的系統(tǒng)提供給用戶。它主要提供以下功能:數(shù)據(jù)訂閱/發(fā)布發(fā)布者將數(shù)據(jù)發(fā)布到ZooKeeper的一個或一系列節(jié)點上，供訂閱者進行數(shù)據(jù)訂閱，進而達到動態(tài)獲取數(shù)據(jù)的目的，從而實現(xiàn)配置信息的集中式管理和數(shù)據(jù)的動態(tài)更新。負載均衡分布式系統(tǒng)具有對等性，為了保證系統(tǒng)的高可用性，通常采用副本的方式來對數(shù)據(jù)和服務(wù)進行部署。對消費者而言，則需要在這些對等的服務(wù)提供方中選擇一個來執(zhí)行相關(guān)的業(yè)務(wù)邏輯，ZooKeeper則很好的解決了這個問題。命名服務(wù)在分布式系統(tǒng)中，通過使用命名服務(wù)，客戶端應(yīng)用能夠根據(jù)指定名字來獲取資源或服務(wù)的地址，提供者等信息。被命名的實體通?？梢允羌褐械臋C器，提供的服務(wù)地址，遠程對象等等——這些都可以統(tǒng)稱為名字（Name）。其中較為常見的就是一些分布式服務(wù)框架中的服務(wù)地址列表。通過調(diào)用ZooKeeper提供的創(chuàng)建節(jié)點的API，能夠創(chuàng)建一個全局唯一的path，這個path就可以作為一個Name。集群管理客戶端如果對ZooKeeper的一個數(shù)據(jù)節(jié)點注冊Watcher監(jiān)聽，那么當該數(shù)據(jù)節(jié)點的內(nèi)容或時其子節(jié)點的列表發(fā)生變更時，ZooKeeper服務(wù)器就會向訂閱的客戶端發(fā)送變更通知。而對在ZooKeeper上創(chuàng)建的臨時節(jié)點，一旦客戶端與服務(wù)器之間的會話失效，那么該臨時節(jié)點也就被自動清除。分布式鎖有了ZooKeeper的一致性文件系統(tǒng)，鎖的問題變得容易。鎖服務(wù)可以分為兩類，一個是保持獨占，另一個是控制時序。對于第一類，將ZooKeeper上的一個znode看作是一把鎖，通過createznode的方式來實現(xiàn)。所有客戶端都去創(chuàng)建/distribute_lock節(jié)點，最終成功創(chuàng)建的那個客戶端也即擁有了這把鎖。用完刪除掉自己創(chuàng)建的distribute_lock節(jié)點就釋放出鎖。對于第二類，/distribute_lock已經(jīng)預(yù)先存在，所有客戶端在它下面創(chuàng)建臨時順序編號目錄節(jié)點，和選master一樣，編號最小的獲得鎖，用完刪除。ZooKeeper與HDFS的關(guān)系ZKFC（ZKFailoverController），用來監(jiān)控NameNode的狀態(tài)信息。ZKFC僅僅部署在NameNode中，ActiveNameNode和StandbyNameNode節(jié)點中均部署ZKFC進程。HDFSNameNode連接到ZooKeeper，把主機名等信息保存到ZooKeeper中，即“/Hadoop”下的znode目錄里。先創(chuàng)建znode目錄的NameNode節(jié)點為主節(jié)點，另一個為備份節(jié)點。HDFSNameNodeStandBy通過ZooKeeper定時讀取NameNode信息。當主節(jié)點進程異常結(jié)束時，HDFSNameNodeStandBy通過ZooKeeper感知“/Hadoop”目錄下發(fā)生了變化，NameNode會進行主備切換。ZooKeeper與YARN的關(guān)系YARN采用了基于ZooKeeper的ActiveStandbyElector實現(xiàn)Active節(jié)點的選取，不需要像HDFS那樣需要單獨的ZKFC進程。在系統(tǒng)啟動時，ResourceManager會嘗試把state信息寫入ZooKeeper,第一個成功把state信息寫入ZooKeeper的ResourceManager被選舉為ActiveResourceManager，其他的為StandByResourceManager。StandByResourceManager定時去ZooKeeper讀取信息。ResouceManager的state信息保存在ZooKeeper中，發(fā)生故障轉(zhuǎn)移時，新選取的ResouceManager從ZooKeeper中讀取RMstate信息進行恢復。ZooKeeper和HBase的關(guān)系HRegionServer把自己以Ephemeral方式注冊到ZooKeeper中。其中ZooKeeper存儲HBase的如下信息：HBase元數(shù)據(jù)、HMaster地址。HMaster通過ZooKeeper隨時感知各個HRegionServer的健康狀況，以便進行控制管理。HBase也可以通過部署多個HMaster，類似HDFSNameNode，當HMaster主節(jié)點出現(xiàn)故障時，HMaster備用節(jié)點會通過ZooKeeper獲取整個集群的狀態(tài)信息。即通過ZooKeeper實現(xiàn)避免HBase單點故障問題。架構(gòu)原理ZooKeeper中的角色主要有三種，如下表所示：角色描述領(lǐng)導者（Leader）領(lǐng)導者進行投票的發(fā)起和決議，更新系統(tǒng)狀態(tài)學習（Learner）跟隨者（Follower）Follower用于接收客戶請求并向客戶端返回結(jié)果，在選主過程中參與投票觀察者（Observer）Observer可以接收客戶端連接，將寫請求轉(zhuǎn)發(fā)給leader節(jié)點。但Observer不參加投票過程，只同步leader的狀態(tài)。Observer的目的是為了擴展系統(tǒng)，提高讀取速度客戶端（Client）請求發(fā)起方系統(tǒng)模型如圖所示：一個ZooKeeper集群通常由一組機器組成，一般3-5臺機器就可以組成一個可用的ZooKeeper集群了。組成ZooKeeper集群的每臺機器都會在內(nèi)存中維護當前服務(wù)器狀態(tài)，并且每臺機器之間都保持著通信。只要集群中存在超過一半的機器能夠正常工作，那么整個集群就能正常對外服務(wù)。ZooKeeper的客戶端程序會選擇和集群中任意一臺機器共同創(chuàng)建一個TCP連接，一旦客戶端和某臺ZooKeeper服務(wù)器之間的連接斷開后，客戶端會自動連接到集群中的其他機器。特性1.高可用在ZooKeeper集群中，讀可以從任意一個ZooKeeperServer讀，寫的請求會先提交到Leader，然后由Leader來通過ZooKeeper中的原子廣播協(xié)議，將請求廣播給所有的Follower，Leader收到一半以上的寫成功的ACK后，就認為該寫操作成功了，就會將該寫操作進行持久化，并告訴客戶端寫成功了。2.WAL和Snapshot對于每一個更新操作，ZooKeeper都會先寫WAL,然后再對內(nèi)存中的數(shù)據(jù)做更新，然后向Client通知更新結(jié)果。另外，ZooKeeper還會定期將內(nèi)存中的目錄樹進行Snapshot，保存到磁盤上。這么做的主要目的，一是數(shù)據(jù)的持久化，二是加快重啟之后的恢復速度。3.有序ZooKeeper使用時間戳來記錄導致狀態(tài)變更的事務(wù)性操作，也就是說，一組事務(wù)通過時間戳來保證有序性。基于這一特性。ZooKeeper可以實現(xiàn)更加高級的抽象操作，如同步等。HDFS功能描述Hadoop分布式文件系統(tǒng)（HadoopDistributedFileSystem）能提供高吞吐量的數(shù)據(jù)訪問，適合大規(guī)模數(shù)據(jù)集方面的應(yīng)用，為海量數(shù)據(jù)提供存儲。HDFS是一個高度容錯性的系統(tǒng)，適合部署在廉價的機器上。HDFS能提供高吞吐量的數(shù)據(jù)訪問，非常適合大規(guī)模數(shù)據(jù)集上的應(yīng)用。HDFS放寬了一部分POSIX約束，來實現(xiàn)流式讀取文件系統(tǒng)數(shù)據(jù)的目的。HDFS具有高容錯性的特點，并且設(shè)計用來部署在低廉的硬件上。HDFS放寬了POSIX的要求，這樣可以實現(xiàn)流的形式訪問文件系統(tǒng)中的數(shù)據(jù)。此外HDFS提供了高可用架構(gòu)（HA）保證了集群的可用性?？煺湛煺罩С衷谝粋€特定時間存儲一個數(shù)據(jù)拷貝，快照可以將失效的集群回滾到之前一個正常的時間點上。HDFS已經(jīng)支持元數(shù)據(jù)快照。數(shù)據(jù)塊HDFS的設(shè)計是用于支持大文件的。運行在HDFS上的程序也是用于處理大數(shù)據(jù)集的。這些程序僅寫一次數(shù)據(jù)，一次或多次讀數(shù)據(jù)請求，并且這些讀操作要求滿足流式傳輸速度。HDFS支持文件的一次寫多次讀操作。HDFS中典型的塊大小是128MB，一個HDFS文件可以被被切分成多個128MB大小的塊，如果需要，每一個塊可以分布在不同的數(shù)據(jù)節(jié)點上。流水式復制當客戶端寫數(shù)據(jù)到HDFS文件中時，數(shù)據(jù)首先被寫入本地文件中，假設(shè)HDFS文件的復制因子是3，當本地文件堆積到一塊大小的數(shù)據(jù)，客戶端從NameNode獲得一個數(shù)據(jù)節(jié)點的列表。這個列表也包含存放數(shù)據(jù)塊副本的數(shù)據(jù)節(jié)點。當客戶端刷新數(shù)據(jù)塊到第一個數(shù)據(jù)節(jié)點。第一個數(shù)據(jù)節(jié)點開始以4kb為單元接收數(shù)據(jù)，將每一小塊都寫到本地庫中，同時將每一小塊都傳送到列表中的第二個數(shù)據(jù)節(jié)點。第二個數(shù)據(jù)節(jié)點將小塊數(shù)據(jù)寫入本地庫中同時傳給第三個數(shù)據(jù)節(jié)點，第三個數(shù)據(jù)節(jié)點直接寫到本地庫中。一個數(shù)據(jù)節(jié)點在接前一個節(jié)點數(shù)據(jù)的同時，還可以將數(shù)據(jù)流水式傳遞給下一個節(jié)點，所以，數(shù)據(jù)是流水式地從一個數(shù)據(jù)節(jié)點傳遞到下一個。HDFS與HBase的關(guān)系HDFS作為HBase的文件存儲系統(tǒng)，為其提供了高可靠的底層存儲支持。HBase中的數(shù)據(jù)文件可以存儲在HDFS文件系統(tǒng)上。HDFS與MapReduce的關(guān)系在MapReduce程序中計算的數(shù)據(jù)可以來自多個數(shù)據(jù)源，如LocalFile、HDFS、數(shù)據(jù)庫等。最常用的是HDFS，可以利用HDFS的高吞吐性能讀取大規(guī)模的數(shù)據(jù)進行計算。同時在計算完成后，也可以將數(shù)據(jù)存儲到HDFS。架構(gòu)原理HDFS是一個的主從結(jié)構(gòu)，一個HDFS集群是由一個NameNode節(jié)點和一些DataNode節(jié)點組成。NameNode是一個管理文件命名空間和調(diào)節(jié)客戶端訪問文件的主服務(wù)器。DataNode通常是一個節(jié)點一個機器，它來管理對應(yīng)節(jié)點的存儲。HDFS對外開放文件命名空間并允許用戶數(shù)據(jù)以文件形式存儲。內(nèi)部機制是將一個文件分割成一個或多個塊，這些塊被存儲在一組DataNode中。NameNode用來操作文件命名空間的文件或目錄操作，如打開，關(guān)閉，重命名等等。它同時確定塊與DataNode的映射。DataNode負責來自文件系統(tǒng)客戶的讀寫請求。DataNode同時還要執(zhí)行塊的創(chuàng)建，刪除，和來自NameNode的塊復制指令。NameNode和DataNode都是運行在普通的機器之上，機器都是GNU/Linux，HDFS是用java編寫的，任何支持java的機器都可以運行NameNode或DataNode，利用java語言的輕便特性，很容易將HDFS部署到大范圍的機器上。典型的部署是由一個專門的機器來運行NameNode，集群中的其他每臺機器運行一個DataNode實例。集群中只有一個NameNode極大地簡單化了系統(tǒng)的體系結(jié)構(gòu)。NameNode是仲裁者和所有HDFS元數(shù)據(jù)的倉庫，用戶的實際數(shù)據(jù)不經(jīng)過NameNode。HDFSHA架構(gòu)HA即為高可用性，定義為系統(tǒng)對外正常提供服務(wù)時間的百分比。HDFS由NameNode和DataNode兩類節(jié)點組成，由于NameNode只有1個，且負責整個HDFS文件系統(tǒng)的管理和控制，因此當NameNode不能提供正常服務(wù)時，會直接導致HDFS不能對外正常服務(wù)，因此NameNode的可靠性是影響HDFS可靠性的重要因素。因此在一個HDFSHA中，通常由兩個NameNode組成，一個處于Active狀態(tài)，一個處于Standby狀態(tài)。一旦ActiveNameNode出現(xiàn)問題，Standby狀態(tài)的NameNode就會迅速切換至Active狀態(tài)并繼續(xù)提供服務(wù)。特性處理超大文件這里的超大文件通常是指百GB、甚至數(shù)百TB大小的文件。目前在實際應(yīng)用中，HDFS已經(jīng)能用來存儲管理PB級的數(shù)據(jù)了。運行于廉價的X86服務(wù)器上Hadoop設(shè)計對硬件需求比較低，只須運行在低廉的商用硬件集群上，而無需昂貴的高可用性機器上。流式數(shù)據(jù)訪問HDFS的設(shè)計建立在更多地響應(yīng)"一次寫入、多次讀寫"任務(wù)的基礎(chǔ)上。這意味著一個數(shù)據(jù)集一旦由數(shù)據(jù)源生成，就會被復制分發(fā)到不同的存儲節(jié)點中，然后響應(yīng)各種各樣的數(shù)據(jù)分析任務(wù)請求。在多數(shù)情況下，分析任務(wù)都會涉及數(shù)據(jù)集中的大部分數(shù)據(jù)，也就是說，對HDFS來說，請求讀取整個數(shù)據(jù)集要比讀取一條記錄更加高效。高吞吐比關(guān)注數(shù)據(jù)訪問的低延遲問題，更關(guān)鍵的在于數(shù)據(jù)訪問的高吞吐。高可用提供對高可用性的支持，當活動NameNode失效，備用NameNode就會接管它的任務(wù)并開始服務(wù)于來自客戶端的請求，而不會有任何明顯的中斷。數(shù)據(jù)安全支持對存儲在HDFS上的數(shù)據(jù)進行加密，保證數(shù)據(jù)的安全存儲。企業(yè)級增強HDFS的元數(shù)據(jù)信息，包括文件信息，塊信息等，都存儲在NameNode中，一般當存儲的文件數(shù)大于1億時，NameNode就成為瓶頸。通過增強，每次擴容一對NameNode，保障可靠性，從而突破文件存儲數(shù)量的限制，最終可達到10億以上的文件。這是HDFS的聯(lián)邦特性。HDFS糾刪碼簡介Erasurecoding糾刪碼技術(shù)簡稱EC，是一種數(shù)據(jù)保護技術(shù)。最早用于通信行業(yè)中數(shù)據(jù)傳輸中的數(shù)據(jù)恢復，是一種編碼容錯技術(shù)。它通過在原始數(shù)據(jù)中加入新的校驗數(shù)據(jù)，使得各個部分的數(shù)據(jù)產(chǎn)生關(guān)聯(lián)性。在一定范圍的數(shù)據(jù)出錯情況下，通過糾刪碼技術(shù)都可以進行恢復。因此可以使用糾刪碼(ErasureCoding)來代替多副本的方式，它使用更少的存儲卻可以保證相同級別的容錯。在典型配置下，與三副本300%的存儲開銷相比，EC策略的存儲開銷約為150%。目前HDFSEC已經(jīng)在HDP3中發(fā)布。應(yīng)用場景HDFSEC在數(shù)據(jù)容錯與存儲效率中具有顯著的優(yōu)勢，以下是一些常用的應(yīng)用場景：適用于PB級、EB級數(shù)據(jù)量極大的場景；結(jié)合HDFS高吞吐量的優(yōu)勢，EC更適應(yīng)于需求高寫入效率的場景；適合一次寫入，多次讀取的應(yīng)用場景；適用于多節(jié)點（九節(jié)點以上），高網(wǎng)絡(luò)帶寬的應(yīng)用場景；適用于存有大量冷數(shù)據(jù)的集群，EC提供了高存儲效率的數(shù)據(jù)存儲模式，可減少冷數(shù)據(jù)的存儲空間。功能特性主要功能特性如下所示：（1）處理超大文件與HDFS傳統(tǒng)的存儲策略相比，當存儲GB、TB、PB級超大文件時，EC策略可極大的縮短寫入時間。（2）低存儲開銷相比傳統(tǒng)的三副本存儲方案，EC可以將存儲開銷降低約50%。（3）高容錯EC主要通過利用糾刪碼算法將原始的數(shù)據(jù)進行編碼得到校驗，并將數(shù)據(jù)和校驗一并存儲起來以達到容錯的目的。EC可以保證與三副本相同甚至更高級別的容錯。（4）EC策略多樣性HDFSEC在存儲方式上提供給用戶更多的策略選擇，用戶可根據(jù)數(shù)據(jù)熱度、集群節(jié)點數(shù)等信息選擇多樣化的存儲方案。（5）條帶化布局條帶化布局可以提供比連續(xù)布局更好的I/O吞吐量，因為它可以并行的更好的利用多個磁盤。并且，條帶式布局的cell大小通常為64KB-1MB，因此可以同時實現(xiàn)小文件和大文件存儲空間的節(jié)省。（6）操作簡單HDFSEC是在目錄級別指定EC策略，可通過shell指令完成策略啟用、設(shè)置、刪除等操作，整體操作簡單易執(zhí)行。局限性HDFSEC在具有眾多優(yōu)勢的同時，存在著一些弊端和待解決問題，其局限性如下所示：（1）EC會造成兩大資源的消耗網(wǎng)絡(luò)帶寬的消耗，因為數(shù)據(jù)需要去讀其他的數(shù)據(jù)塊和校驗塊；CPU資源的消耗，存入數(shù)據(jù)時，EC需要進行編碼計算，恢復數(shù)據(jù)時需要進行解碼計算。（2）操作限制以EC方式存儲的文件，不能執(zhí)行hflush，hsync和append操作。（3）轉(zhuǎn)換繁瑣當目錄設(shè)置EC策略后，該目錄下已有文件不會自動轉(zhuǎn)換為EC策略的存儲模式，只有新寫入該目錄的文件會按照EC策略存儲。（4）本地化特性EC條帶式的存儲布局會導致強依賴數(shù)據(jù)本地化特性的MapReduce作業(yè)消耗大量的網(wǎng)絡(luò)資源，其工作性能會有所下降。（5）節(jié)點及機架數(shù)量要求高EC條帶式的存儲布局雖然具有更好的存儲效率，但對集群中的節(jié)點和機架數(shù)量有更高的要求。以RS-6-3-1024k策略為例，其Datanode節(jié)點數(shù)應(yīng)為一個條帶上數(shù)據(jù)塊與校驗塊之和，即9個Datanode?；靖拍钤诖鎯ο到y(tǒng)中，糾刪碼技術(shù)主要是通過利用糾刪碼算法將原始的數(shù)據(jù)進行編碼得到校驗塊，并將數(shù)據(jù)塊和校驗塊一并存儲起來，以達到容錯的目的。其基本思想是將k塊原始的數(shù)據(jù)元素通過一定的編碼計算，得到m塊校驗元素。對于這k+m塊元素，當其中任意的m塊元素出錯（包括數(shù)據(jù)和校驗出錯），均可以通過對應(yīng)的重構(gòu)算法恢復出原來的k塊數(shù)據(jù)，其存儲開銷為（k+m）/k。生成校驗的過程被成為編碼（encoding），恢復丟失數(shù)據(jù)塊的過程被稱為解碼（decoding）。EC策略EC策略為了適應(yīng)異構(gòu)的工作負載，它允許HDFS集群中的文件和目錄具有不同EC策略。每個EC策略封裝了編碼/解碼器，其策略由以下信息定義：（1）EC模式：這包括EC組（例如6+3）中的數(shù)據(jù)和奇偶校驗塊的數(shù)量，以及編解碼器算法（例如Reed-Solomon，XOR）。（2）條帶化單元的大?。哼@確定了條帶讀取和寫入的粒度，包括緩存大小和編碼工作。（3）策略被命名為：編碼/解碼器—數(shù)據(jù)塊數(shù)—奇偶校驗塊數(shù)—塊單元大小。當前，支持五種糾刪碼策略：RS-3-2-1024k，RS-6-3-1024k，RS-10-4-1024k，RS-LEGACY-6-3-1024k，XOR-2-1-1024k。各個EC策略的編碼/解碼器、數(shù)據(jù)容錯與存儲開銷如下表所示。表EC策略詳解EC策略編碼/解碼器數(shù)據(jù)容錯存儲開銷RS-3-2-1024kRS_NATIVE,RS_JAVA2166%RS-6-3-1024kRS_NATIVE,RS_JAVA3150%RS-10-4-1024kRS_NATIVE,RS_JAVA4140%RS-LEGACY-6-3-1024kRS-LEGACY_JAVA3150%XOR-2-1-1024kXOR_NATIVE,XOR_JAVA1150%條帶式布局存儲為了管理非常大的文件，分布式存儲系統(tǒng)通常將文件劃分為固定大小的邏輯塊。然后將這些邏輯塊映射到集群上的存儲塊，這反映了集群上數(shù)據(jù)的物理布局。條帶式塊布局將邏輯塊分成更小的存儲單元（通常稱為cells），并在一組存儲塊中以輪詢的方式寫入單元條帶(stripesofcells)。在條形布局下，數(shù)據(jù)被依次寫入條的各個單元中，當條被寫滿之后就寫入下一個條，一個條的不同單元位于不同的數(shù)據(jù)塊中，如下圖所示。讀取帶有條帶布局的文件需要查詢邏輯塊的存儲塊集，然后從存儲塊集中讀取單元條帶。圖RS(3,2)條帶式布局HDFSEC架構(gòu)HDFSEC的架構(gòu)設(shè)計同樣遵從主從結(jié)構(gòu)，有一個中心的管理對象(ECManager)，然后有對應(yīng)的worker對象(ECWorker)，這兩大角色類有明確的分工。HDFS通過ECPolicy進行控制，每個EC策略對應(yīng)一種ECSchema參數(shù)配置的EC算法。同時這些ECPolicy策略對象被ErasureCodingPolicyManager對象所掌管，如下圖所示。圖EC策略關(guān)系HDFSEC架構(gòu)主要包含三部分：圖HDFSEC架構(gòu)設(shè)計圖1.NameNode擴展條帶化HDFS文件在邏輯上由塊組組成，每個塊組包含一定數(shù)量的內(nèi)部塊。為了減少這些附加塊的NameNode內(nèi)存消耗，引入了新的分層塊命名協(xié)議?？梢詮钠淙魏蝺?nèi)部塊的ID推斷出塊組的ID。這允許在塊組而不是塊的級別進行管理。2.客戶端擴展客戶端讀取和寫入路徑得到了增強，可以并行處理塊組中的多個內(nèi)部塊。在輸出/寫入路徑上，DFSStripedOutputStream管理著一組數(shù)據(jù)流，每個數(shù)據(jù)節(jié)點一個，在當前塊組中存儲一個內(nèi)部塊。協(xié)調(diào)器負責整個塊組的操作，包括結(jié)束當前塊組，分配新的塊組等等。在輸入/讀取路徑上，DFSStripedInputStream將請求的邏輯字節(jié)數(shù)據(jù)范圍轉(zhuǎn)換為存儲在DataNode上的內(nèi)部塊。然后，它并行發(fā)出讀取請求。發(fā)生故障時，它將發(fā)出其他讀取請求以進行解碼。3.DataNode擴展DataNode運行附加的ErasureCodingWorker（ECWorker）任務(wù)，用于對失敗的EC塊進行后臺恢復。NameNode檢測到失敗的EC塊，然后NameNode選擇一個DataNode進行恢復工作?；謴腿蝿?wù)作為心跳響應(yīng)傳遞。此過程類似于失敗時如何重新復制復制的塊。重建執(zhí)行三個關(guān)鍵任務(wù)：（1）從源節(jié)點讀取數(shù)據(jù)：使用專用線程池從源節(jié)點并行讀取輸入數(shù)據(jù)。基于EC策略，它計劃對所有源目標提出讀取請求，并僅讀取最少數(shù)量的輸入塊以進行重建。（2）解碼數(shù)據(jù)并生成輸出數(shù)據(jù)：從輸入數(shù)據(jù)解碼新數(shù)據(jù)和奇偶校驗塊。所有丟失的數(shù)據(jù)和奇偶校驗塊一起解碼。（3）將生成的數(shù)據(jù)塊傳輸?shù)侥繕斯?jié)點：解碼完成后，恢復的塊將傳輸?shù)侥繕薉ataNode。常用操作HDFS提供了一個ec命令來執(zhí)行與糾刪碼有關(guān)的管理命令。hdfsec[genericoptions][-setPolicy-path<path>[-policy<policyName>]][-getPolicy-path<path>][-unsetPolicy-path<path>][-listPolicies][-addPolicies-policyFile<file>][-listCodecs][-enablePolicy-policy<policyName>][-disablePolicy-policy<policyName>][-help[cmd...]]以下是每條指令的操作細節(jié)：[-setPolicy-path<path>[-policy<policyName>]]在指定路徑的目錄上設(shè)置擦除編碼策略。path：HDFS中的目錄。這是必填參數(shù)。設(shè)置策略僅影響新創(chuàng)建的文件，而不影響現(xiàn)有文件。policyName：用于此目錄下文件的EC策略。如果設(shè)置了“node.ec.system.default.policy”配置，則可以省略此參數(shù)。路徑的EC策略將在配置中設(shè)置為默認值。[-getPolicy-path<path>]獲取指定路徑下文件或目錄的EC策略的詳細信息。[-unsetPolicy-path<path>]取消設(shè)置先前對目錄上調(diào)用setPolicy所設(shè)置的EC策略。如果目錄從上級目錄繼承了EC策略，則unsetPolicy是NOOP（無操作）。注意，在沒有明確EC策略設(shè)置的目錄上取消EC策略將不會返回錯誤。[-listPolicies]列出在HDFS中注冊（啟用，禁用和刪除狀態(tài)下）的所有EC策略。只有啟用的策略才能夠與setPolicy命令一起使用。[-addPolicies-policyFile<file>]添加EC策略列表。請參閱etc/hadoop/user_ec_policies.xml.template獲取示例策略文件。最大單元大小在屬性“node.ec.policies.max.cellsize”中定義，默認值為4MB。當前，HDFS允許用戶總共添加64個策略，并且添加的策略ID在64到127之間。如果已經(jīng)添加了64個策略，添加策略將失敗。[-listCodecs]獲取系統(tǒng)中支持的EC解碼器和編碼器的列表。編碼器是編解碼器的一種實現(xiàn)。編解碼器可以具有不同的實現(xiàn)，因此可以具有不同的編解碼器。[-removePolicy-policy<policyName>]刪除擦除編碼策略。[-enablePolicy-policy<policyName>]啟用擦除編碼策略。[-disablePolicy-policy<policyName>]禁用擦除編碼策略。操作示例一般情況下，設(shè)置指定目錄的EC策略具體流程如下圖所示。圖EC策略操作流程查看EC策略列表hdfsec-listPolicies可以看到所有支持的EC策略與其啟用狀態(tài)，默認情況下只有RS-6-3-1024k處于啟用狀態(tài)。查看EC編碼/解碼器hdfsec-listCodecs啟用EC策略hdfsec-enablePolicy-policyRS-3-2-1024k設(shè)置EC策略在特定目錄上設(shè)置EC策略：hdfsec-setPolicy-path/test/dir1-policyRS-6-3-1024k輸入指令查看指定目錄是否應(yīng)用了EC策略：hdfsec-getPolicy-path/test/dir1查看EC策略制定目錄的塊狀態(tài)hdfsfsck/test/dir1更改EC策略修改/test/dir1目錄EC策略：hdfsec-setPolicy-path/test/dir1-policyRS-3-2-1024k修改后提示，/test/dir1路徑下已有的文件不會因EC策略修改而自動轉(zhuǎn)換策略，但新寫入的文件會按照重新設(shè)置的EC策略進行編碼。取消EC策略設(shè)置hdfsec-unsetPolicy-path/test/dir1糾刪碼增強ISA-L概述ISA-L全稱Intelstorageaccelerationlibrary（Intel存儲加速庫），包括兩個大類：加密和非加密。非加密的有crc、izip、erase-code，加密的包括sha512、sha256、md5、sha1等。核心技術(shù)是使用Intelsse/avx/avx2/avx256的擴展指令，并行運算多個流的方法，以實現(xiàn)存儲加速。單線程而言，比openssl快2-8倍。糾刪碼作為ISA-L庫所提供的功能之一，其性能是目前業(yè)界最佳。需要注意的是Intel采用的性能測試方法與學術(shù)界常用的方式略有出入，其將數(shù)據(jù)塊與校驗塊的大小之和除以總耗時作為吞吐速率，而一般的方法是不包含校驗塊的。另外，ISA-L未對vandermonde矩陣做特殊處理，而是直接拼接單位矩陣作為其編碼矩陣，因此在某些參數(shù)下會出現(xiàn)編碼矩陣線性相關(guān)的問題。但是，ISA-L提供了cauchy矩陣作為第二方案。ISA-L編解碼速度快是因為它將整體矩陣運算遷移到匯編中進行，并且實現(xiàn)了增量編碼。另外，ISA-L支持的指令集擴展豐富，下至SSSE3，上到AVX512，平臺適應(yīng)性強。在Insight產(chǎn)品中，ISA-L可增強糾刪碼中的RS編/解碼器，提升糾刪碼文件的IO性能。ISA-L配置在Insight集群中，ISA-L以動態(tài)鏈接庫的形式存放在native庫。HDFS糾刪碼默認優(yōu)先調(diào)用native庫中的編解碼器，因此無需配置就可使用ISA-L。但在一些特殊應(yīng)用場景中，不適用ISA-L的編解碼器，則需進行一些配置。HDFS糾刪碼中涉及ISA-L的編碼解碼操作為RS編碼算法，其中配置編解碼器的使用需在core-site.xml中修改下列屬性。<property><name>io.erasurecode.codec.rs.rawcoders</name><value>rs_native,rs_java</value></property>例如，關(guān)閉RS算法的ISA-L增強，修改如下：<property><name>io.erasurecode.codec.rs.rawcoders</name><value>rs_java</value></property>上層應(yīng)用及指令支持上層應(yīng)用支持根據(jù)EC存儲現(xiàn)狀，上層服務(wù)使用EC存在一定的限制，例如EC文件不適用與append()操作等。因此，對于各服務(wù)適用EC存儲的HDFS目錄有著嚴格的限定，具體適用HDFS目錄如下表所示。上層服務(wù)HDFS目錄存儲數(shù)據(jù)用途HBase/apps/hbase/data/.tmp建表等臨時目錄/apps/hbase/data/archive歸檔目錄/apps/hbase/data/data表數(shù)據(jù)目錄Hive/warehouse默認存放表數(shù)據(jù)目錄若在HBase、Hive服務(wù)中將上述表格外的目錄使用EC策略，將導致業(yè)務(wù)運行失敗。指令支持distcp指令當使用distcp的源文件有EC文件時，需要針對不同的需求，添加不同的參數(shù)。如果在拷貝過程中，按照目標目錄的EC策略將文件重新寫入目標目錄，則需要在distcp時加入?yún)?shù)：-p和-skipcrccheck。如果在拷貝過程中，按照目標目錄的副本策略將文件重新寫入目標目錄，則需要在distcp時加入?yún)?shù)：-pugp和-skipcrccheck。fsck指令fsck指令通常用于查看副本文件的塊信息，對于EC文件fsck指令仍然有效。fsck指令結(jié)果中，添加了對于EC文件的塊信息報告，如下圖所示。其中，包含EC文件的塊組數(shù)、平均塊組大小、塊組的健康狀態(tài)等。HDFS異構(gòu)存儲簡介最初HDFS被設(shè)計用于同構(gòu)的硬件環(huán)境，然而隨著集群硬件的迭代更新，存儲介質(zhì)的硬件異構(gòu)特性愈發(fā)明顯。為了充分利用高性能存儲介質(zhì)，提升HDFS的數(shù)據(jù)訪問性能，HDFS實現(xiàn)了異構(gòu)存儲。在異構(gòu)存儲的第一階段中將數(shù)據(jù)節(jié)點存儲模型從單個存儲策略更改為存儲策略的集合（對應(yīng)于多個物理存儲介質(zhì)），每種存儲策略都對應(yīng)于一個物理存儲介質(zhì)。添加了存儲類型DISK、SSD、ARCHIVE、RAM_DISK的概念，其中DISK是默認存儲類型。ARCHIVE具有很高的存儲密度（PB級存儲），但計算能力卻很小，可用于支持歸檔存儲。RAM_DISK以支持在內(nèi)存中寫入單個副本文件。存儲策略主要有以下六種：HOT：用于存儲和計算。常用數(shù)據(jù)將以該策略保存。當策略啟用時，其所有副本都存儲在DISK中。COLD：僅適用于計算量有限的存儲。不再使用的數(shù)據(jù)或需要歸檔的數(shù)據(jù)從HOT移動到COLD。當塊處于冷狀態(tài)時，所有副本都存儲在ARCHIVE中。WARM：部分熱和部分冷。當一個塊變熱時，其某些副本存儲在DISK中，其余副本存儲在ARCHIVE中。All_SSD：用于將所有副本存儲在SSD中。One_SSD：用于將副本之一存儲在SSD中，其余副本存儲在DISK中。Lazy_Persist：用于在內(nèi)存中寫入具有單個副本的塊。首先將副本寫入RAM_DISK，然后將其延遲保存在DISK中。該策略與執(zhí)行寫入操作的客戶端相關(guān)，第一副本會優(yōu)先選擇客戶端所在的DataNode節(jié)點，若客戶端所在節(jié)點未配置RAM_DISK，則會寫入所在節(jié)點的DISK磁盤。（RAM_DISK不支持Kerberos模式下使用，不支持append操作，例如限制SSM壓縮功能使用）存儲策略由以下字段組成：策略編號策略名稱塊放置的存儲類型列表用于文件創(chuàng)建的后備存儲類型列表用于副本的后備存儲類型列表以下是典型的存儲策略表：Policy

IDPolicy

NameBlockPlacement

(n

replicas)Fallbackstorages

forcreationFallbackstorages

forreplication15Lazy_PERSISTRAM_DISK:1,DISK:

n-1DISKDISK12All_SSDSSD:

nDISKDISK10One_SSDSSD:1,DISK:

n-1SSD,DISKSSD,DISK7Hot(default)DISK:

n<none>ARCHIVE5WarmDISK:1,ARCHIVE:

n-1ARCHIVE,DISKARCHIVE,DISK2ColdARCHIVE:

n<none><none>注：副本及DataNode數(shù)需大于等于2。配置流程HDFS異構(gòu)存儲配置前，需要集群已有其他的存儲介質(zhì)作為支持。配置過程中，將DataNode下存儲目錄分別掛載至不同存儲介質(zhì)，從而實現(xiàn)異構(gòu)存儲。SSD、ARCHIVE的目錄掛載操作與傳統(tǒng)磁盤目錄掛載相似。RAM_DISK作為內(nèi)存存儲，目錄掛載前對系統(tǒng)配置有一定要求。具體配置流程如下所示。配置DISK\SSD\ARCHIVE磁盤分區(qū)與格式化對于初裝集群而言，需要對每個節(jié)點的磁盤設(shè)備依次進行分區(qū)與格式化操作。以某節(jié)點的sdb磁盤設(shè)備為例，具體操作如下：fdisk/dev/sdbfdisk操作中應(yīng)根據(jù)需求選擇分區(qū)表類型、磁盤分區(qū)號、磁盤分區(qū)起始位置與結(jié)束位置等。分區(qū)完畢后，進行對應(yīng)分區(qū)的格式化操作：mkfs.xfs/dev/sdb1-f該節(jié)點的其他磁盤設(shè)備操作相同，重復上述步驟即可。完成磁盤分區(qū)與格式化后，即可掛載。掛載DISK\SSD\ARCHIVE目錄將完成分區(qū)與格式化的磁盤設(shè)備掛載至DataNode目錄。以掛載三個磁盤設(shè)備與目錄為例，具體操作如下所示：mkdir-p/hadoop/hdfs/data1mkdir-p/hadoop/hdfs/data2mkdir-p/hadoop/hdfs/data3mount/dev/sdb1/hadoop/hdfs/data1mount/dev/sdc1/hadoop/hdfs/data2mount/dev/sdd1/hadoop/hdfs/data3即完成掛載。配置RAM_DISK修改limits.conf文件Linux對于每個用戶限制其使用的內(nèi)存數(shù)，掛載目錄前，需先修改各個DataNode節(jié)點hdfs用戶的內(nèi)存使用數(shù)。其中內(nèi)存數(shù)為bytes，此例以1GB為例：（RAM_DISK不支持Kerberos模式下使用）vim/etc/security/limits.conf掛載RAM_DISK目錄首先在配置RAM_DISK的DataNode節(jié)點上創(chuàng)建目錄，然后使用tmpfs實現(xiàn)內(nèi)存存儲掛載。需保證掛載tmpfs大小與memlock一致：mkdir/hadoop/hdfs/data4sudomount-ttmpfs-osize=1024mtmpfs/hadoop/hdfs/data4掛載完成后，可用df-h查看掛載。注意：RAM_DISK配置與副本數(shù)相關(guān)，建議RAM_DISK掛載操作只在一個DataNode上操作。修改hdfs-site.xml修改DataNode目錄打開Insight管理頁面，選擇HDFS-配置參數(shù)-SETTINGS，修改DataNode目錄。其中對于每個data目錄前，添加“[]”以指定存儲介質(zhì)：添加dfs.datanode.max.locked.memory屬性打開Insight管理頁面，選擇HDFS-配置參數(shù)-ADVANCED-自定義hdfs-site，添加屬性以確定專用于存儲在內(nèi)存中的副本內(nèi)存量。同樣的，該屬性大小應(yīng)于小于已掛載的RAM_DISK磁盤空間大小：最后，保存設(shè)置重啟HDFS即可。常用操作存儲策略指令HDFS提供了storagepolicies命令來執(zhí)行與存儲策略相關(guān)的管理命令。hdfsstoragepolicies[genericoptions][-setStoragePolicy-path<path>-policy<policy>][-getStoragePolicy-path<path>][-unsetStoragePolicy-path<path>][-listPolicies][-help[cmd...]]以下是每條指令的操作細節(jié)：[-setStoragePolicy-path<path>-policy<policy>]在指定路徑的目錄上設(shè)置存儲策略。path：HDFS中的目錄，這是必填參數(shù)。設(shè)置策略僅影響新創(chuàng)建的文件，而不影響現(xiàn)有文件。policyName：用于指定此目錄下文件的存儲策略。注意：該指令是目錄級別的設(shè)定，其子目錄將繼承父目錄的存儲策略。[-getStoragePolicy-path<path>]獲取指定路徑下文件或目錄的存儲策略的詳細信息。[-unsetStoragePolicy-path<path>]取消設(shè)置先前對目錄上調(diào)用setStoragePolicy所設(shè)置的存儲策略。如果目錄從上級目錄繼承了存儲策略，則unsetStoragePolicy是NOOP（無操作）。注意，在沒有明確存儲策略設(shè)置的目錄上取消存儲策略將不會返回錯誤。[-listPolicies]列出在HDFS中所有的存儲策略，包括具體的策略ID、策略名稱、塊放置策略等。Mover指令Mover是HDFS支持的數(shù)據(jù)遷移工具，它會掃描HDFS中的文件，以檢查塊放置是否滿足存儲策略。對于違反存儲策略的塊，它將副本移動到其他存儲類型，以滿足存儲策略要求。其操作如下所示。hdfsmover[-p<files/dirs>|-f<localfile>]其中，-p<files/dirs>指定要遷移的HDFS文件/目錄。-f<localfile>指定一個本地文件，該文件包含要遷移的HDFS文件/目錄列表。注意：存儲類型RAM_DISK較為特殊，Mover工具遷移時會忽略存儲在RAM_DISK中的副本，Mover操作對于Lazy_Persist策略而言為NOOP（無操作）。Mover使用過程中，涉及到Mover進程相關(guān)的可調(diào)參數(shù)，均可在hdfs-site.xml中進行設(shè)置。主要參數(shù)如下表所示。參數(shù)描述默認值dfs.mover.movedWinWidth一個塊可以再次移動到另一個位置的最小時間間隔，以毫秒為單位。5400000dfs.moverThreads配置Mover的線程池大小。1000dfs.mover.retry.max.attemptsMover遷移失敗后的最大重試次數(shù)。10操作示例HDFS中默認的存儲策略是HOT策略，本例以修改指定目錄存儲策略為ONE_SSD為例，假設(shè)該目錄下已存有文件，其具體操作如下所示。修改存儲策略將指定目錄存儲策略修改為ONE_SSD，新寫入該目錄的文件將以O(shè)NE_SSD策略存儲。hdfsstoragepolicies-setStoragePolicy-path/test-policyONE_SSD查看文件存儲策略存儲策略修改前，/test目錄下已存有文件test_io_0。策略修改后，該文件不會自動轉(zhuǎn)換為新的存儲策略，需要使用Mover工具進行數(shù)據(jù)遷移。首先，查看該文件的存儲策略。hdfsstoragepolicies-getStoragePolicy-path/test/test_io_0從查看的存儲策略信息可知，文件雖然顯示已為ONE_SSD策略存儲，但實際并未轉(zhuǎn)換，利用fsck查看塊信息即可驗證。hdfsfsck/test/test_io_0-files-blocks-locations遷移數(shù)據(jù)利用Mover工具將test_io_0文件遷移至新策略存儲。hdfsmover-p/test/test_io_0遷移后，再使用fsck查看文件塊信息，實現(xiàn)數(shù)據(jù)遷移。日志介紹日志描述HDFS相關(guān)日志的默認存儲路徑為“/var/log/hadoop/”。HDFS的日志啟動了自動備份歸檔功能，默認情況下，當日志大小超過256MB的時候（此日志文件大小可進行配置），會自動備份，備份后的日志文件名規(guī)則為：“<原有日志名>.log.yyyy-mm-dd”。備份文件保留個數(shù)可以在Insight界面中配置。表HDFS日志列表日志類型日志文件名描述運行日志hadoop-(USER)-namenode-(hostname).logHDFS中namenode的系統(tǒng)日志，記錄namenode運行時所產(chǎn)生的日志。hadoop-(USER)-datanode-(hostname).logHDFS中datanode的系統(tǒng)日志，記錄datanode運行時所產(chǎn)生的日志。hadoop-(USER)-namenode-(hostname).out記錄namenode標準輸出和標準錯誤日志.hadoop-(USER)-datanode-(hostname).out記錄datanode標準輸出和標準錯誤日志.hadoop-(USER)-namenode-(hostname).out.(number)系統(tǒng)保留的5個namenodeout日志。hadoop-(USER)-datanode-(hostname).out.(number)系統(tǒng)保留的5個datanodeout日志。gc.log-(DATA)記錄Java垃圾回收日志。審計日志hdfs-audit.logHDFS操作審計日志（例如：文件增刪改查）。SecurityAuth.auditHDFS安全審計日志。日志級別日志庫將日志分為5個級別，分別為DEBUG、INFO、WARN、ERROR和FATAL。這5個級別對應(yīng)的日志信息重要程度不同，它們的重要程度由低到高依次為DEBUG<INFO<WARN<ERROR<FATAL。日志輸出規(guī)則為：只輸出級別不低于設(shè)定級別的日志信息。比如，級別設(shè)定為INFO，則INFO、WARN、ERROR和FATAL級別的日志信息都會被輸出，但級別比INFO低的DEBUG則不會被輸出。修改日志級別通過http://<namenode:50070>/logLevel在線修改NameNode的日志級別。如下所示：輸入“org.apache.hadoop.hdfs.StateChange”，通過“GetLogLevel”可查看日志級別：

輸入”org.apache.hadoop.hdfs.StateChange”，通過“SetLogLevel”可設(shè)置日志級別：Results顯示設(shè)置日志級別成功。注：重啟NameNode后該設(shè)置失效，需重新設(shè)置。修改默認日志級別Hadoop的默認日志級別為INFO，對于百臺以上的集群，如果文件操作頻繁的話，NameNode會輸出較多日志，對性能會有一定的影響。因此，可以通過Insight界面，配置默認日志級別，具體流程如下所示。（1）進入“HDFS”-“配置參數(shù)”-“ADVANCED”中配置：（2）配置hadoop-env中的日志級別設(shè)置，可將“INFO”修改為“WARN”，“hadoop-env.template”中可根據(jù)需求進一步配置：（3）配置hdfs-log4j中的“hadooprootlogger”，如“WARN”：（4）配置完成后，保存并重啟服務(wù)即可。日志格式HDFS的日志格式如下所示：表HDFS日志格式日志類型格式示例運行日志（yyyy-MM-ddHH:mm:ss,SSS）+（LogLevel）+（產(chǎn)生該日志的線程名字）+（log中的message）+（日志事件的發(fā)生位置）2019-11-1113:56:50,437INFOBlockStateChange(BlockManager.java:computeReplicationWorkForBlocks(1651))-BLOCK*neededReplications=0,pendingReplications=0.審計日志（yyyy-MM-ddHH:mm:ss,SSS）+（LogLevel）+（產(chǎn)生該日志的線程名字）+（log中的message）+（日志事件的發(fā)生位置）2019-11-1113:57:32,826INFOFSNamesystem.audit:allowed=trueugi=spark(auth:SIMPLE)ip=/1cmd=createsrc=/spark2-history/.a94cd4c9-996d-4dc6-b11a-5cfd29290ad2dst=nullperm=spark:hadoop:rw-r—r—proto=rpcHDFS重點參數(shù)調(diào)優(yōu)操作場景在真實的業(yè)務(wù)場景中，HDFS承擔著重要的存儲角色。根據(jù)工作負載的不同，某些配置參數(shù)的默認值可能會導致集群性能不佳，甚至作業(yè)失敗。本章針對該問題對HDFS重點參數(shù)進行說明，具體配置需依據(jù)應(yīng)用場景進行調(diào)整。操作步驟大多數(shù)參數(shù)可在Insight管理平臺中直接查看得到，便于修改。如有需要，同樣可以在自定義配置中添加參數(shù)的配置，以添加參數(shù)至hdfs-site.xml為例，具體操作步驟如下所示：（1）進入Insight管理平臺頁面，選擇“HDFS”-“配置參數(shù)”-“ADVANCED”；（2）選擇“自定義hdfs-site”-“添加屬性”；（3）將需要添加的鍵值填入后，選擇添加即可。最后保存設(shè)置重啟集群后，配置即可生效。重點參數(shù)表HDFS重點參數(shù)參數(shù)描述默認值來源dfs.replication默認塊副本數(shù)。創(chuàng)建文件時，可以指定實際的副本數(shù)。如果在創(chuàng)建時未指定副本數(shù)，則使用默認值。注意：默認塊副本數(shù)需小于或等于集群DataNode數(shù)量。3node.handler.count偵聽客戶端請求的NameNodeRPC服務(wù)線程數(shù)。當集群工作負載較高、集群規(guī)模較大時，應(yīng)增大NameNode處理RPC服務(wù)的線程數(shù)。100hdfs-site.xmldfs.datanode.handler.countDataNodeRPC的服務(wù)線程數(shù)。當集群工作負載較高、集群規(guī)模較大時，應(yīng)增大DataNode處理RPC服務(wù)的線程數(shù)。需要注意的是，每添加一個線程，內(nèi)存將會增加。4096hdfs-site.xmldfs.datanode.du.reserved每個卷的保留空間（字節(jié)）。要注意留足夠的空間給非HDFS文件使用。對于有異構(gòu)存儲的集群，該屬性后可以跟相應(yīng)的存儲類型[ssd]/[disk]/[archive]/[ram_disk]。例如，dfs.datanode.du.reserved.ssd為配置ssd存儲的保留空間。建議保留磁盤容量的5%或者50GB以上。409164185600hdfs-site.xmlipc.maximum.data.length表示服務(wù)器可以接收的最大IPC消息長度（字節(jié)）。大于此值的消息將立即被拒絕，以避免可能的OOM錯誤。該值需大于等于塊大小。134217728core-site.xmlHADOOP_NAMENODE_OPTS設(shè)置NameNodeJVM的堆內(nèi)存（MB）。NameNode堆大小取決于許多因素，例如文件數(shù)、塊數(shù)和系統(tǒng)負載。具體堆內(nèi)存大小需參考集群文件數(shù)進行配置，不恰當?shù)亩褍?nèi)存會導致HDFS崩潰。3072hadoop-env.shYARN功能描述YARN是一種Hadoop資源管理器，它是一個通用資源管理系統(tǒng)，可為上層應(yīng)用提供統(tǒng)一的資源管理和調(diào)度。YARN對可伸縮性、可靠性和集群利用率進行了提升。YARN實現(xiàn)這些需求的方式是，把JobTracker的兩個主要功能（資源管理和作業(yè)調(diào)度/監(jiān)控）分成了兩個獨立的服務(wù)程序——全局的資源管理（RM）和針對每個應(yīng)用的應(yīng)用Master（AM）。架構(gòu)原理YARN是Hadoop中的資源管理系統(tǒng)，包括兩個獨立的服務(wù)：一個全局的資源管理器ResourceManager和每個應(yīng)用程序特有的ApplicationMaster。其中ResourceManager負責整個系統(tǒng)的資源管理和分配，而ApplicationMaster負責單個應(yīng)用程序的管理。YARN是Master/Slave結(jié)構(gòu)，在整個資源管理框架中，ResourceManager為Master，NodeManager為Slave，ResourceManager負責對各個NodeManager上的資源進行統(tǒng)一管理和調(diào)度。當用戶提交一個應(yīng)用程序時，需要提供一個用以跟蹤和管理這個程序的ApplicationMaster，它負責向ResourceManager申請資源，并要求NodeManger啟動可以占用一定資源的任務(wù)。由于不同的ApplicationMaster被分布到不同的節(jié)點上，因此它們之間不會相互影響。下圖描述了YARN的基本組成結(jié)構(gòu)，YARN主要由ResourceManager、NodeManager、ApplicationMaster（圖中給出了MapReduce和MPI兩種計算框架的ApplicationMaster，分別為MRAppMstr和MPIAppMstr）和Container等幾個組件構(gòu)成。ResourceManager（RM）RM是一個全局的資源管理器，負責整個系統(tǒng)的資源管理和分配。它主要由兩個組件構(gòu)成：調(diào)度器（Scheduler）和應(yīng)用程序管理器（ApplicationsManager，ASM）。調(diào)度器調(diào)度器根據(jù)容量、隊列等限制條件（如每個隊列分配一定的資源，最多執(zhí)行一定數(shù)量的作業(yè)等），將系統(tǒng)中的資源