宣告：本文件所有內容均在本人的學習和理解上整理，僅供參考，歡迎討論。不具有權威性，甚至不具有精確性，也會在以後的學習中對不合理之處進行修改。
按照hadoop的常規學習流程，在底層的檔案儲存結束後，應該介紹它的演算法核心模組mapreduce。yarn作為協調者會在之後的各種演算法中穿插用到。原本想單獨介紹mapreduce演算法思想，但發現怎麼都繞不開yarn這個話題。將二者放在一塊，裡面的一些概念又容易混淆，不利於以後對計算層的其他演算法的理解。故這一篇文件單獨將yarn作為整個hadoop的協調層來介紹，並且放在演算法之前。要理解yarn的「協調者」這個概念，我想來想去給他定了個比較容易理解的身份——大管家。作為乙個家族的大管家，他不必像底層傭人親自動手事必躬親，但也不能同決策者制定方針謀劃未來。他能做的，是根據主人下達的命令，籌集資源、動員人手，下放給傭人實際操作。希望這樣比喻比較好理解。
一、yarn出現的背景
yarn作為一種協調機制，是在hadoop 2.0版本才出現使用的。在1.0版本中，對資料的處理、資源的排程主要依賴於mapreduce演算法。來看一下hadoop 1.版本的應用處理機制：
1、乙個需要用到data a和data c的應用提交給m/r
2、m/r為應用建立乙個job，job將應用分片後提交給job tracker
3、job tracker根據應用所需的資料找到相應的dn節點，在dn節點上分配相應的task tracker執行任務
4、task tracker在執行任務時實時與job tracker進行互動，匯報任務執**況
5、job tracker接受各task tracker的計算結果
我們先理解一下job tracker和task tracker。應用在提交給job tracker時已經分好片，在job tracker接受到的仍是乙個完整的應用。之後由job tracker將分片的應用下放到相應的dn節點，由task tracker具體執行，這個時候task tracker收到的時整個應用的一部分，可以成為任務。那麼我們可以將job tracker理解為整個應用和整個dn集群的管理器，而task tracker則是分片任務的管理器。選擇回顧整個處理機制，我們能發現兩個突出的問題：
1、job tracker的地位很重要，但負載也太大了。除了初始的應用分片不需要它處理，剩下的一切都需要它」追蹤「，包括任務的具體執**況也要它操個心。對整個系統來說，這不是好事。
2、job tracker時按照所需資料來進行分配，那麼資源（主要指記憶體）就很容易分配不均。打個比方：乙個job被分成6個子job，每個子job需要的資源（記憶體）是1gb。但所有子job所需要的資料全部集中在一台dn節點上，該節點記憶體只有4gb，一次只能接受4給子job。剩下的2個子job正能等記憶體釋放後再進入執行。而在等待工程中，其他的dn節點是處於空閒狀態的。
這兩個問題暴露了hadoop 1.0版本的資源協調在處理大規模資料時會有些」力不從心「。而隨著資料規模的快速擴大，hadoop亟需一種更優化的資源協調解決方案，yarn就在這一背景下誕生。
二、yarn的重要角色及概念
1、resourcemanager（rm）
rm是整個集群的資源管理器，負責整個集群的資源排程和管理。同時也負責與客戶端互動，處理客戶端的應用請求等。它主要有２個組建構成：
①resource scheduler：純資源排程器，只負責為程式程序排程所需的資源
2、node manager（ｎｍ)：節點管理器，負責管理自己節點上的資源和使用，於rm互動，上報節點的狀態，以便rm呼叫
4、container：資源打包容器，am向rm申請來的資源的集合，並利用這些資源負責具體執行任務。位於dn節點上。
三、yarn執行流程
還是要提一下，yarn作為資源的協調者，本身不提**用程式和檔案資料。應用程式由客戶端發起，由hadoop上層的演算法轉化成不同的任務，資料檔案儲存在hdfs上。所以說，yarn只是輔助任務去呼叫資源來計算這些資料，並不參與到計算中去。
1、客戶端向rm傳送應用請求
2、rm根據nm的節點資訊選擇合適的dn節點
3、rm在選中的dn節點上建立並啟動am，將任務分發給am
4、am根據自己的任務情況向rm申請相應的資源
5、rm為am分配相應的資源
6、am得到資源後啟動對應的資源容器（container）執行任務並進行監控
7、conrtainer將任務執行完畢報告給am
8、am將任務的執行結果上報給rm
9、rm向client返回應用的執行結果
現在我們再回顧一下hadoop 1.0版本的侷限性：
1、job tracker既要排程又要監控，負載過高
再yarn中，區別於1.0版本最主要的思想就是將排程和監控功能分離。rm主要負責資源的排程，具體任務監控則由am來完成。rm只要在節點上啟動am並將任務發給am就行，不用管任務具體是怎麼執行的，當任務完成後由am向rm報告乙個結果就行了。且am分布在各節點上，不占用rm本身資源，大大減少了rm的工作量，整個系統的穩定性就有了極大的提高。
2、任務按資料需求分配，資源分配不均，效率低下
am在向rm申請資源時，不在侷限於本節點的資源，而是由rm根據各節點資訊選擇合適的節點資源調配給am使用。換句話說，」am你有什麼需求儘管提，只要我有一定給你（哦吼，霸道總裁既視感）「這個」我「指的就是整個集群了。
yarn的加入使得hadoop 2.0系統有了一種高效、可靠的處理大規模資料的能力。但老樣子，為保持整個hadoop系統的高可靠性，yarm也需要一套高可靠性機制。
四、yarn的高可靠性
高可靠性，主要就是對整個執行環節中的任一環節的出錯情況有一套快速恢復的預案。我們結合yarn的角色看一下每個環節的解決方案
1、任務執行出錯（container）
container作為任務的具體執行者，由任務管理器am所監控。當container出錯時會向am傳送報告，隨後釋放自己的資源。am收到失敗報告後會重新啟動該任務，一般會選在不同節點
2、任務管理器出錯（am）
am作為節點資訊，會週期性的向rm傳送心跳資訊。當am出錯時，一般會嘗試進行重啟。重啟失敗後，rm會發現該am不可用，則會在其他節點建立乙個新的am，用來接管原am管理的container
３、節點管理器出錯（nm）
節點管理器管理者整個節點的資源和資訊，並與rm建立心跳聯絡。當nm出現問題，即表示該節點損壞，rm檢測到之後，會將該節點從自己的節點池中移除，並將該節點上的程序載入到其他節點上執行
４、資源管理器出錯（rm）
rm作為整個集群的資源管理器，是yarn最核心的部分，一旦宕機將會丟失一切任務和資源資訊。為保障其高可靠性，採取了主備機制。整個集群中會執行多個rm，通過zookeeper進行主備選舉。主rm執行中的相關資訊會儲存在zookeeper的乙個儲存區內，當主rm宕機或算壞後，zookeeper會立即選舉出新的主rm。新的主rm會從zookeeper中獲取程序的執行資訊和節點的資訊，來接替主rm的工作
五、總結
yarn作為hadoop的資源協調者，是hadoop處理大規模資料的保障。在以後學習hadoop的上層演算法中，基本都會涉及到yarn的資源協調。換句話說，yarn為大資料的高效演算法提供了優秀的協調機制。
ps：計算層過段時間再更，容老夫理理思路。
電商平台的系統組織架構
參與電商系統開發已有兩年，我一直負責的工作就是跟電商平台對接，起初對接的平台只有 天貓 京東這幾個主流大平台，後來隨著各品牌的業務拓展，後續逐漸對接其他比較有規格的電商平台 目前已對接 唯品會，蘇寧易購，小紅書，寺庫，網易考拉，噹噹，後續還會繼續對接其他渠道 一開始我對於對接這麼多平台並不是很理解，...
java SSH網上拍賣平台系統
系統包括的主要內容 前台部分 1 使用者註冊登入模組 使用者信註冊登入模組主要針對系統使用者，核實使用者資訊，保證平台的安全性。2 拍品發布模組 發布拍品，修改拍品，拍品的分類，拍品拍賣倒計時的選擇。3 拍品資訊查詢模組 拍品展示，查詢分類的物品。4 拍品競拍模組 使用者競拍 競價及成交。競價拍賣模...
直播平台錄播系統架構
在直播時，彈幕 禮物特效 人數的變化都是通過廣播訊息包推送到客戶端，流水錄 務器以摸擬客戶端的方式接收廣播訊息包存放在資料庫，資料庫中需要儲存訊息的時間戳和廣播包的內容。流水錄 務器同時也去拉取直播時的禮物特效配置表，存放成乙份禮物特效快照資料。原封不動的儲存廣播訊息包在資料庫裡，是為了客戶端架構支...