學一門新鮮的技術，其實過程都是相似的，先學基本的原理和概念，再學怎麼使用，最後深究這技術是怎麼實現的，所以本章節就帶你認識認識spark長什麼樣的，帥不帥，時髦不時髦（這貨的基本概念和原理），接着瞭解spark有什麼必殺技（spark的各種大招），我們如何使用它的必殺技，最後看看spark如何更加高效的組合它的必殺技，以及spark是如何練就這一身必殺技的。
一、spark帥不帥
· 五官長相-spark架構圖
鼻子、眼睛、耳朵、眉毛、口，缺一不可，這斯就經長什麼鳥樣，先上照片，如下所示
前文說到spark是分佈式內存計算模型，既然是分佈式，那就得明確老大（master） ，要不然各個小弟（worker）還不打起來，所以：
master節點是老大，控制、管理和監督一幫小弟弟們正常衣食住行和生老病死（老大的地位是明顯的：1.管理，2.監督，3.使喚），
worker是小弟弟，接收老大的命令並且領取砍殺的任務，彙報砍殺的進度和結果給老大，
Executor是馬仔，就是那個真刀實槍去看人的小弟弟的小弟弟。
client是客戶，要幹什麼事情，都是它提出來，有什麼活要幹，他告知老大master
driver：老大的司機，老大那麼多事情，不可能每個事情都親自監督，所以不同的事情（不同的應用），它都有driver來跟蹤，driver來負責具體事務，一件事情拍一個司機（一個應用一個driver），司機是做事的入口（application的main方法）。
sparkContext：做這件事情的流水帳本，什麼時候搞事、誰搞事、搞的怎麼樣、是不是不搞了，都是sparkContext來記錄。所以沒有了sparkContext，那這個事情就沒法搞了，一筆糊塗賬。
DAG Scheduler:老大做事的計劃，所有的事情都是老大（master）來規劃的，事情這麼多，小弟也是有限的，所以老大必須規劃做事的方式和方法-DAG Scheduler，這樣才能將這些小弟更好的用起來
RDD:具體計劃執行的細節，記錄了每個具體的做事方法，怎麼做，在哪裏做，拿什麼做。
所以事來了基本是這個流程：
client（我要搞事）-> master（生意來了）->driver（老大會先思考好下面哪個小弟弟有能力去辦，想好了之後就派司機去執行[driver申請資源、管理和跟蹤]）->Work（收到老大要搞事的指令,司機driver帶來的老大指令）-> executor(一堆人馬去搞事)。worker可能是羣毆（多個worker執行），也可能是單挑（單個worker執行）．
二、spark做事的套路
spark考慮了多種情況的做事套路，這幾種情況的區分在於司機（driver）在哪裏工作：
· 老大臨時安排工作地點，
· 在客戶現場工作（client端），
· 在老大的祕書辦公室工作（yarn或mesos），所以工作地不一樣，做事的套路也不同。
下面一一介紹各種工作場景下的做事套路。
（1）老大臨時安排driver工作地點
作業執行流程描述：
1.客戶提交作業給老大Master，說一起搞事。
2.老大master深思熟慮，決定搞事，並且確定了搞事辦公地點（從衆多小弟中選一個worker），讓driver去選定的辦公地點籌備並執行（選定的辦公地點有個霸氣的名號：Spark AppMaster）。driver先紮根下來（啓動DriverRunner線程），然後正式啓動做事計劃（SchedulerBackend）。
3.老大master怕司機driver搞不定，與此同時，它也在通知其他兄弟們（其他worker）抄傢伙（Work糾結馬仔Exeuctor即ExecutorBackend）
4. 兄弟們work都會帶領馬仔去司機driver那裏報到，driver會結合每個worker的情況告訴具體的做事計劃和做事方式DAGScheduler（計劃分成多個步驟stage），小弟弟work用TaskScheduler記好，讓馬仔Exeuctor去執行，去砍殺。馬仔們砍殺的時候，driver會密切注視，如果發現哪個馬仔砍殺效率低，會讓其他的馬仔頂上，看誰砍殺效率更高（推測執行）。
5.計劃中的所有stage被執行完了之後，各個worker彙報給driver，driver確定都做完了，就向master彙報戰果。另外客戶也會跳過master直接和driver聯繫關注砍殺的進度。
（2）driver在客戶現場辦公
作業執行流程描述：
1.司機driver到了客戶現場，做好搞事準備工作，如計劃好做事的策略和方式（DAGScheduler），回憶一下各個小弟都有什麼裝備和技能 (BlockManagerMaster);
2.司機dirver一切準備妥當，就去老大master那裏彙報，可以號召小弟們幹活了。
3.老大master號召小弟們（所有work節點）抄傢伙（Work糾結馬仔Exeuctor即ExecutorBackend）
4. 後面的工作和前面的工作模式一樣：兄弟們work都會帶領馬仔去司機driver那裏報到，driver會結合每個worker的情況告訴具體的做事計劃和做事方式DAGScheduler（計劃分成多個步驟stage），小弟弟work用TaskScheduler記好，讓馬仔Exeuctor去執行，去砍殺。馬仔們砍殺的時候，driver會密切注視，如果發現哪個馬仔砍殺效率低，會讓其他的馬仔頂上，看誰砍殺效率更高（推測執行）。
5.計劃中的所有stage被執行完了之後，各個worker彙報給driver，driver確定都做完了，就向master彙報戰果。此時driver在客戶現場，所有搞事的進度，客戶也一目瞭然。
（3）在老大的祕書辦公室工作-基於yarn
既然老大master選定了祕書yarn，那麼主要的事情都是yarn來安排、管理和監控，所以yarn是整個業務的顏值和主事擔當。讓yarn主事之前，先看看yarn是何人，有什麼本事，憑什麼她就能成爲老大的祕書。
（1）yarn出世的背景
yarn的出現，完全是因爲前輩mapreduce太忙太累導致的，mapreduce既要管理家務事（管理集羣資源）還要爲外面的業務操碎心（job的調度、監控和執行），叫誰都扛不住，所以爲前輩mapreduce v1分憂，是yarn出現的主要原因。那前輩有哪些困擾的事情呢，總結起來有如下困惱：
a.不能發展新的小弟 - 可擴展行不好，前輩MRV1因爲又裏裏外外都去管，精力有限，如果來更多的小弟（slave），是管不來的，心有餘而力不足，超過4000個小弟，再增加就會力不從心。
b.隨時都會面臨解散- 可靠性差，因爲是老大管小弟的機制，而老大Jobtracker只有一個，一旦老大哪天掛了，大家（tasktracker）都完蛋，隨時可能捲鋪蓋回家。
c.全體辦事效率低-資源利用率低，這個不能怪前輩mapreduce，要怪就怪能管事的人太少了，事太多了，每天都忙的天昏地暗，忙塵夠，所以做出點錯誤的決策，不瞭解小弟們的思想等等是時有發生的，下面的小弟抱怨也沒辦法，運作機制就這樣。而且還有一個該死的機制，就是每件事情都分成2個包（map和reduce，當然也可以只有一個map），必須做了第一個才能去做第二個，或者第一個完成了百分之多少，才能去做第二個（map和reduce slot），並且要分先後，有先有後，就必然會有等待，有等待j就有資源，簡直就是變態。
總結起來，就是前輩mapreduce太忙，忙成狗，yarn就是爲優化MR V1低效率的工作模式而生，就是這麼橫空出世、閃亮登場的。
（2）yarn的架構及其技能
yarn總結了前輩mapreduce v1工作累的原因：a.事無鉅細的做事方式-又是管理家務,又是打理外面業務;b.任務分包的方式有問題(map slot和reduce slot)，因此做了一些改進和優化
(1) 明確分工，專業的人做專業的事
專業的人做專業的事情，首先分清出有哪些事情，纔好安排專業人
a,資源的管理，資源誰來統一分配和監控，資源被分配後如何監控與上報，怎麼將資源的使用情況告知任務分配人員
b.任務的管理，任務誰來統一分配和監控，領到任務的人如何監控自己的任務運行情況以及上報
所以總結起來就2件屁事：資源的分配、監控和管理，任務的分配、監控和管理，以前這些事情都是jobtracker分配、監控和管理資源及任務，所有的東西都找他彙報，效率低的很。前車之鑑，慘不忍睹，因此，天才的hadoop設計者重新規劃，將資源的管理和任務的管理剝離開。確定了三個角色
· 統籌者：resourceManager，他負責資源的分配、管理和監控，同時也負責分配任務，但是不負責任務的具體監控。爲什麼他還要負責任務的分配，還不單獨任務分配也交給其他人做，主要是因爲，分配任務要結合資源的使用情況，需要時時刻刻知曉資源的情況，所以，就讓resourceManger也負責分配任務。
單個資源管理的馬仔-nodeManager，集羣中的每個節點都有nodemanager，負責監控節點中每個container的生老病死以及每個節點的健康狀況。
監控的馬仔-applicationMaster，來了一個任務，resourceManager確定是不是要做，一旦做了，就會從衆多兄弟中選一個人做爲applicationMaster，由它來全場安排和監控任務的執行情況，applicationMaster一旦接到任務肯定要知道是由哪些兄弟來做事（resourceManager會規劃好），然後挨個去通知兄弟們：各位在老大點過名的兄弟們，抄傢伙上，讓你撲街啊。
applicationMaster帶領人去執行任務的時候會密切和nodeManager保持聯繫，掌握各小弟們的情況，如果某個小弟生病了，那它就會及時選出備選，不讓其出戰。
（2）優化任務分包方式-container
這裏需要提到的是以前的map和reduce的分包方式已經被徹底拋棄，現在所有的資源都叫做container，誰需要資源，誰向resourceManager申請，用完了就還過去，只要你需要就去申請，在也沒有排隊等候浪費資源的問題了。
整體上,yarn是怎麼來的，是個什麼樣的，有什麼本事就是這樣，她的主要能力：能夠很好的將資源和任務分配、管理和監控起來，辦事效率高，老闆很放心。
（3）在老大的祕書辦公室工作（yarn或mesos）
· 客戶端提出要搞事，將要做的事情打好草稿（生成作業信息），發送給統籌人員resourceManager。
· resourceManager從它的爪牙nodeManager中選一個出來做該事件的主要負責人，辦公地址名都選好了，美其名曰Spark AppMaster
· 被選中的nodeManger，開始做準備工作了，準備工作做好了之後，向resourceManger申請要找幫手。
resourceManager結合要做的事情以及各個小弟的實際情況，確認參加人員
· Spark AppMaster 去老大確定的人員nodeManager上部署任務。
· 參加人員收到任務之後，糾結馬仔 spark executor，開始砍殺，並且向Spark AppMaster砍殺進度。所以AppMaster掌握整個事情的發展情況，client通過Appmaster溝通獲得任務最新執行進展。
三、參考資料
1.http://www.tuicool.com/articles/qaEVFb
2.http://www.csdn.net/article/2013-12-04/2817706--YARN
3.http://www.cnblogs.com/cxzdy/p/5494929.html-yarn 的架構和原理
4.http://www.aboutyun.com/thread-6785-1-1.html-爲什麼會產生yarn
