HDFS
hadoop 的基礎分布式文件存儲系統，分為NameNode和DataNode.
NameNode負責存儲文件系統的metadata，管理DataNode的數據存儲和數據安全
DataNode負責存儲數據文件
- 對應配置文件
core-site.xml和hdfs-site.xml - NameNode本地存儲位置配置:
dfs.namenode.name.dir(hdfs-site.xml) - DataNode本地存儲位置配置:
dfs.datanode.data.dir(hdfs-site.xml)
單NameNode配置
Cluster配置
支持NameNode的配置成Cluster
- 注意事項：
- NameNode 的active和standby需要有同等的硬件配置
Note: the machines on which you run the Active and Standby NameNodes should have equivalent hardware to each other, and equivalent hardware to what would be used in a non-HA cluster.
- 當前只支持兩個NameNode結點，配置在集群的NameService中
Note: Currently, only a maximum of two NameNodes may be configured per nameservice.
- 配置
- hdfs-site.xml
-
dfs.nameservices - the logical name for this new nameservice
Choose a logical name for this nameservice, for example “mycluster”, and use this logical name for the value of this config option. The name you choose is arbitrary. It will be used both for configuration and as the authority component of absolute HDFS paths in the cluster.
Note: If you are also using HDFS Federation, this configuration setting should also include the list of other nameservices, HA or otherwise, as a comma-separated list.<property> <name>dfs.nameservices</name> <value>mycluster</value> </property> dfs.ha.namenodes.[nameservice ID] - unique identifiers for each NameNode in the nameservice
-
- core-site.xml
Yarn
名詞含義
- ResourceManager: 以下簡稱RM。YARN的中控模塊，負責統一規劃資源的使用。
- NodeManager: 以下簡稱NM。YARN的資源結點模塊，負責啟動管理container。
- ApplicationMaster: 以下簡稱AM。YARN中每個應用都會啟動一個AM，負責向RM申請資源，請求NM啟動container，并告訴container做什么事情。
- Container：資源容器。YARN中所有的應用都是在container之上運行的。AM也是在container上運行的，不過AM的container是RM申請的。
架構
- RM
ResourceManager是YARN資源控制框架的中心模塊，負責集群中所有的資源的統一管理和分配。它接收來自NM的匯報，建立AM，并將資源派送給AM.
-
調度器概覽
最初的hadoop的版本只有FifoScheduler（先進先出調度器）。
后來，Yahoo!和facebook先后開發了CapacityScheduler（容量調度器）和FairScheduler（公平調度器）。內存中都會維護一個隊列，應用，NM，Container的關系。
-
事件處理器，通過RM的異步的事件調用機制知曉外部的發生的事情。要跟外部交互也要發送相應的事件。調度器一共要處理6個調度事件
Schedule events
除了這6個事件，還有一個函數會在AM跟RM心跳的時候會被調用。
Allocation allocate(ApplicationAttemptId appAttemptId,List<ResourceRequest> ask,List<ContainerId> release);
AM會告訴調度器一些資源申請的請求和已經使用完的container的列表，然后獲取到已經在NODE_UPDATE分配給這個應用的container的分配。
可以看到調度器接受資源的申請和分配資源這個動作是異步的。
RM每次分配，先獲取一個資源隊列，從隊列中獲取一個job，然后依次在各個機器上嘗試分配資源，直到成功或者失敗次數過多。- 調度算法
FifoScheduler：最簡單的調度器，按照先進先出的方式處理應用。只有一個隊列可提交應用，所有用戶提交到這個隊列。可以針對這個隊列設置ACL。沒有應用優先級可以配置。
CapacityScheduler：可以看作是FifoScheduler的多隊列版本。每個隊列可以限制資源使用量。但是，隊列間的資源分配以使用量作排列依據，使得容量小的隊列有競爭優勢。集群整體吞吐較大。延遲調度機制使得應用可以放棄跨機器的調度機會，爭取本地調度。
FairScheduler：多隊列，多用戶共享資源。特有的客戶端創建隊列的特性，使得權限控制不太完美。根據隊列設定的最小共享量或者權重等參數，按比例共享資源。延遲調度機制跟CapacityScheduler的目的類似，但是實現方式稍有不同。資源搶占特性，是指調度器能夠依據公平資源共享算法，計算每個隊列應得的資源，將超額資源的隊列的部分容器釋放掉的特性。 - 本地優化與延遲調度
- 在YARN運行應用的時候，AM會將輸入文件進行切割，然后，AM向RM申請的container來運行task來處理這些被切割的文件段。Yarn是基于HDFS文件系統的資源管理。
- 如果一個HDFS文件有N個副本，存在N臺機器上。那如果AM申請到的container在這N臺機器上的其中一個，那這個task就無須從其它機器上傳輸要處理的文件段，節省網絡傳輸。這就是Hadoop的本地優化。
- YARN的實現本地優化的方式是AM給RM提交的資源申請的時候，會同時發送本地申請，機架申請和任意申請。然后，RM的匹配這些資源申請的時候，會先匹配本地申請，再匹配機架申請，最后才匹配任意申請。
- 延遲調度機制，就是調度器在匹配本地申請失敗的時候，匹配機架申請或者任意申請成功的時候，允許略過這次的資源分配，直到達到延遲調度次數上限。CapacityScheduler和FairScheduler在延遲調度上的實現稍有不同，前者的調度次數是根據規則計算的，后者的調度次數通過配置指定的，但實際的含義是一樣的。
-
容量調度器
在hadoop集群配置中啟動容量調度器之后，調度器會從classpath中加載capacity-scheduler.xml文件，完成容量調度器的初始化總結起來有如下特性：
1) 動態更新配置:容量調度器的配置文件在運行時可以隨時重新加載來調整分配參數。除非重啟ResourceManager，否則隊列只能添加不能刪除，但是允許關閉。修改配置文件后，使用以下命令可以刷新配置。
yarn rmadmin -refreshQueues?
2) 樹形組織隊列:容量調度器的隊列是按照樹形結構組織的。根隊列只有一個root隊列。子隊列分享父隊列的資源。每個隊列設定一個容量值代表可使用父隊列的容量值，容量值會影響隊列的排序。父隊列的所有子隊列的容量相加一定是100，否則加載失敗。還有一個最大容量值表示子隊列絕對不會超過的使用上限。
3) 隊列應用限制:隊列可以設定最大提交的應用數量和AM占用資源的百分比。AM占用資源的百分 比這個配置是用來計算隊列的最大活躍應用數量。這里有個小問題。調度器中最大活躍應用數量=AM占用資源的百分比隊列最大可使用資源量/最小的container分配額度。但是我們在mapred-site.xml中會配置AM的內存額度會比最小container分配額度大，造成最大活躍應用數量虛高（可以理解，如果YARN加入不同的計算框架,AM的分配會不一致，所以這里使用最小container分配額度來計算。但是，如果是這樣的話，應該直接計算AM的內存使用量來控制）。
4) 用戶參數限制:用戶可以提交應用到多個隊列。不同隊列間用戶的應用運行情況，不相互影響。用戶在隊列中最大可占用資源受兩個參數控制，一個是單用戶占據隊列的百分比上限，一個是單用戶內存使用上限。具體參看下面的參數表。
5）資源分配選擇:不同隊列之間，按照隊列的資源使用比排序。同一隊列中的應用按照應用id排序，也就是先進先出。
6）延遲調度*:當調度次數小于本地延遲調度次數的時候不接受機架調度。本地延遲調度次數，由yarn.scheduler.capacity.node-locality-delay配置，默認是-1，不開啟延遲調度。官方文檔中沒有提及這個參數。而任意調度的延遲調度上限是應用申請的機器的數量，不能配置。容量調度器的參數計算關系
在RM的管理界面參數：
容量調度參數
隊列絕對容量=父隊列的 隊列絕對容量*隊列容量
隊列最大容量=yarn.scheduler.capacity.<queue-path>.maximum-capacity/100
隊列絕對最大容量=父隊列的 隊列絕對最大容量*隊列最大容量
絕對資源使用比=使用的資源/全局資源
資源使用比=使用的資源/(全局資源 * 隊列絕對容量)
最小分配量=yarn.scheduler.minimum-allocation-mb
用戶上限=MAX(yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent,1/隊列用戶數量)
用戶調整因子=yarn.scheduler.capacity.<queue-path>.user-limit-factor
最大提交應用=yarn.scheduler.capacity.<queue-path>.maximum-applications
如果小于0 設置為(yarn.scheduler.capacity.maximum-applications*隊列絕對容量)
單用戶最大提交應用=最大提交應用*(用戶上限/100)*用戶調整因子
AM資源占比（AM可占用隊列資源最大的百分比)
=yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent
如果為空，設置為yarn.scheduler.capacity.maximum-am-resource-percent
最大活躍應用數量=全局總資源/最小分配量*AM資源占比*隊列絕對最大容量
單用戶最大活躍應用數量=(全局總資源/最小分配量*AM資源占比*隊列絕對容量)*用戶上限*用戶調整因子
本地延遲分配次數=yarn.scheduler.capacity.node-locality-delay<code>
-
公平調度器
在hadoop集群配置中啟動公平調度器之后，調度器會從classpath中加載fair-scheduler.xml和fair-allocation.xml文件，完成公平調度器的初始化。其中fair-scheduler.xml主要描述重要特性的配置，fair-allocation.xml主要描述了具體的隊列及其參數配置。總結起來有如下特性：
1) 動態更新配置:公平調度器的fair-allocation.xml配置文件在運行時可以隨時重新加載來調整分配參數。除非重啟ResourceManager，否則隊列只能添加不能刪除。修改fair-allocation.xml后，使用以下命令可以刷新配置。
yarn rmadmin -refreshQueues?
2) 樹形組織隊列:公平調度器的隊列是按照樹形結構組織的。根隊列只有一個root隊列。父子隊列除了ACL參數外，其余參數都不繼承。
3) 隊列應用參數:應用只能提交到葉子隊列。受隊列最大應用數量限制。隊列可以設定權重，最小共享量和最大使用量。權重和最小共享量將影響在公平排序算法中的排名，從而影響資源調度傾向。隊列還可以設定最大運行的應用數量。
4) 用戶參數限制:一個用戶可以提交應用到多個隊列。用戶受全局的最大可運行數量限制。
5) 資源分配選擇:資源分配的時候，使用公平排序算法選擇要調度的隊列，然后在隊列中使用先進先出算法或者公平排序算法選擇要調度的應用。
6) 延遲調度:每種資源申請的優先級都有一個資源等級標記。一開始標記都是NODE_LOCAL，只允許本地調度。如果調度機會大于NM數量乘以上界（locality.threshold.node），資源等級轉變為RACK_LOCAL、重置調度機會為0、接受機架調度。如果調度機會再次大于NM數量乘以上界（locality.threshold.rack），資源等級轉變為OFF_SWITCH、重置調度機會為0、接受任意調度。詳情代碼參看[FSSchedulerApp.getAllowedLocalityLevel:470]
7) 資源搶占:調度器會使用公平資源共享算法計算每個隊列應該得到的資源總量。如果一個隊列長時間得不到應得到的資源量，調度器可能會殺死占用掉該部分資源的容器。
配置: fair-scheduler.xml
fair-scheduler.xml公平調度配置公平排序算法:
公平排序算法是公平調度器的核心算法。調度器在選取哪個隊列和隊列中的哪個應用需要優先得到資源調度的時候使用。每個隊列或者應用都有以下幾個供排序的參數：
-
資源需求量。當前隊列或者應用希望獲得的資源的總量。
2)** 最小共享量。隊列的最小共享量在配置中指定。應用的最小共享量為0。
3) 資源使用量。**當前隊列或者應用分配到的總資源。 -
權值。隊列的權重值在配置中指定。在開啟sizebasedweight特性的情況下，應用的權重=（log2(資源需求量)）優先級調整因子。優先級當前都是1,。當應用運行超過5分鐘，調整因子為3。
排序算法的核心是兩個比較體的比較算法，具體如下：
1.計算比較體是否需要資源。即資源使用量是否小于資源需求量且小于最小共享量。
2.如果兩者都需要資源，計算資源分配比=資源使用量/Min（資源需求量，最小共享量）。資源分配比較小的優先。
3.如果一個需要，一個不需要，需要的優先。
4.如果兩者都不需要資源，計算使用權值比=資源使用量/權值。使用權值比較小的優先。
5.如果2或者4中的比較相同，則先提交的優先。
詳情代碼參看[SchedulingAlgorithms.FairShareComparator.compare:81]
*公平資源共享算法:*
公平調度器為公平地分配資源，在開啟資源搶占的特性的情況下，可能會殺死部分運行中的容器，釋放超額的資源。
公平調度器啟動的時候會建立一個UpdateThread的線程，負責計算公平資源量和進行資源搶占。其中，調度器使用了公平資源共享算法重新計算隊列的公平資源量。
名詞解釋： 資源權重比=資源獲得量/隊列權重。知道全局的資源權重比，每個隊列就可以根據自己的權值，知道自己能分配多少資源。
公平資源共享算法的目的是為了每個隊列公平地使用資源，這個公平體現在每個隊列得到的資源比等于他們的權值比。如果只是單純地求一個資源權重比，可以直接相除。但是由于需要滿足隊列的資源分配滿足最小共享量、最大資源量這些隊列上下界的限制，資源權重比不能直接計算。
反過來，如果知道資源權重比，就可以計算出集群一共需要多少資源，而且，集群資源需求量=Fun(資源權重比)是單調的。
所以可以使用二分資源權重比的方法，計算集群資源需求量，使得集群資源需求量逼近當前的集群資源量。
具體算法流程如下：
1.設置根隊列的公平資源量為全局資源總和
2.根隊列調用recomputeFairShares，計算公平資源量
2.1計算當前隊列的分配量=MIN（隊列總需求，公平資源量）
2.2計算資源權重比最大值。最大值=2^n,使得Fun(最大值)>集群資源量>Fun(最大值/2)。
2.2計算資源權重比。采用二分法計算，二分法次數最多25次。每個隊列的公平資源量= （權重*權重資源比，用最小共享量修正下界，用資源需求量修正上界）
2.3設置每個子隊列的公平資源量=資源權重比*權值。
2.4各個子隊列調用recomputeFairShares，遞歸計算。
詳情代碼參看[FairScheduler:221]
*公平調度器的使用設計建議:*
- 隊列的最小共享量越大，在集群繁忙的時候分配到的資源就越多。
- 但是，如果每個用戶都將最小共享量設置到最大，不利于集群間的資源共享。建議，將隊列愿意共享出來的內存大小和隊列的權值掛鉤。含義就是，你愿意共享得越多，在整體資源分配中就越能分得更多的資源。
*公平調度器的全局配置:*
基本配置
- yarn-site.xml
yarn.timeline-service.hostname 配置timeline-service存儲的歷史記錄所在的結點
yarn.timeline-service.leveldb-timeline-store.path 配置timeline-service存儲的歷史記錄所在的結點的目錄
資源配置
配置說明
-
yarn.nodemanager.resource.memory-mb (NM: yarn-site.xml)
表示該節點上YARN可使用的物理內存總量，默認是8192（MB），注意，如果你的節點內存資源不夠8GB，則需要調減小這個值，而YARN不會智能的探測節點的物理內存總量。 (
每個nodemanager可分配的內存總量)Amount of physical memory, in MB, that can be allocated for containers.
-
yarn.nodemanager.vmem-pmem-ratio (NM: yarn-site.xml)
任務每使用1MB物理內存，最多可使用虛擬內存量，默認是2.1。Ratio between virtual memory to physical memory when setting memory limits for containers. Container allocations are expressed in terms of physical memory, and virtual memory usage is allowed to exceed this allocation by this ratio.
-
yarn.nodemanager.pmem-check-enabled (NM: yarn-site.xml)
是否啟動一個線程檢查每個任務正使用的物理內存量，如果任務超出分配值，則直接將其殺掉，默認是true。Whether physical memory limits will be enforced for containers.
-
** yarn.nodemanager.vmem-check-enabled** (NM: yarn-site.xml)
是否啟動一個線程檢查每個任務正使用的虛擬內存量，如果任務超出分配值，則直接將其殺掉，默認是true。Whether virtual memory limits will be enforced for containers.
-
yarn.scheduler.minimum-allocation-mb (RM: yarn-site.xml)
單個任務可申請的最少物理內存量，默認是1024（MB），如果一個任務申請的物理內存量少于該值，則該對應的值改為這個數。(container最小可申請的內存。在調度器中，很多資源計算部分會轉化為這個最小值的N倍進行計算。所以，設定可分配內存等資源的時候，最好是剛好為這個最小值的倍數。)The minimum allocation for every container request at the RM, in MBs. Memory requests lower than this won't take effect, and the specified value will get allocated at minimum.
-
yarn.scheduler.maximum-allocation-mb (RM: yarn-site.xml)
單個任務可申請的最多物理內存量，默認是8192（MB）。 (container最多可申請的內存數量)The maximum allocation for every container request at the RM, in MBs. Memory requests higher than this won't take effect, and will get capped to this value.
mapreduce.map.memory.mb (AM: mapred-site.xml)
mapreduce.reduce.memory.mb (AM: mapred-site.xml)
指定map和reduce task的內存大小，該值應該在RM的最大最小container之間。如果不設置，則默認用以下規則進行計算：max{MIN_Container_Size,(Total Available RAM/containers)}。mapreduce.map.java.opts (AM: mapred-site.xml)
mapreduce.reduce.java.opts (AM: mapred-site.xml)
需要運行JVM程序（java，scala等）準備，通過這兩個參數可以向JVM中傳遞參數，與內存有關的是-Xmx, -Xms等選項，數值的大小應該相應的在AM中的map.mb或reduce.mb之間。
默認情況下，YARN采用了線程監控的方法判斷任務是否超量使用內存，一旦發現超量，則直接將其殺死。由于Cgroups對內存的控制缺乏靈活性（即任務任何時刻不能超過內存上限，如果超過，則直接將其殺死或者報OOM），而Java進程在創建瞬間內存將翻倍，之后驟降到正常值，這種情況下，采用線程監控的方式更加靈活（當發現進程樹內存瞬間翻倍超過設定值時，可認為是正常現象，不會將任務殺死），因此YARN未提供Cgroups內存隔離機制。
其他
NameNode, ResourceManager通過 slaves 讀取到結點列表
