Yarn
Yarn產(chǎn)生背景：
Yarn直接來(lái)自于MR1.0
MR1.0 問(wèn)題：采用的是master slave結(jié)構(gòu)凤薛，master是JobTracker敬矩。Slave是TaskTracker、JobTracker整個(gè)集群只有一個(gè)礼华，構(gòu)建調(diào)度和資源管理育特，兩個(gè)功能啃憎。每個(gè)節(jié)點(diǎn)上，可以通過(guò)一個(gè)TaskTracker控制本節(jié)點(diǎn)的資源管理和任務(wù)管理次洼。每個(gè)TaskTracker通過(guò)心跳機(jī)制周期性的向JobTracker發(fā)送本節(jié)點(diǎn)的資源使用情況以及任務(wù)運(yùn)行狀態(tài)关贵，JobTracker會(huì)通過(guò)心跳應(yīng)答將新的命令或者任務(wù)發(fā)送至TaskTracker。
1卖毁、 JobTracker是一個(gè)性能瓶頸坪哄，既負(fù)責(zé)資源管理有負(fù)責(zé)作業(yè)調(diào)度，實(shí)際上势篡，資源管理是所有的計(jì)算框架共有的一個(gè)模塊翩肌，不能將其寄宿在某一個(gè)特殊的計(jì)算框架中，另禁悠，作業(yè)調(diào)度模塊是與應(yīng)用層相關(guān)的念祭，與通用的資源管理模塊分開(kāi)。
2碍侦、 JobTracker是一個(gè)單點(diǎn)故障粱坤，一旦出現(xiàn)宕機(jī)隶糕，整個(gè)集群將無(wú)法正常使用，
3站玄、 只支持Map Reduce這一種計(jì)算模型枚驻，如果希望支持Map-reduce-reduce這種計(jì)算框架，無(wú)法支持株旷，需要修改JobTracker再登。
4、 MRv1.0 擴(kuò)展性差晾剖、可靠性差锉矢、資源利用率低（MRv1采用了基于槽位的資源分配模型，槽位是一種粗粒度的資源劃分單位齿尽；通常一個(gè)任務(wù)不會(huì)用完槽位對(duì)應(yīng)的資源沽损，且其他任務(wù)也無(wú)法使用這些空閑資源，無(wú)法支持多種計(jì)算框架）
Yarn安裝常見(jiàn)問(wèn)題：
1循头、 運(yùn)行APP時(shí)內(nèi)存不足：確保yarn-site.xml文件中的yarn.scheduler.maximum-allocation-mb參數(shù)大于mapred-site.xml中的yarn.app.mapreduce.am.resource.mb參數(shù)
2绵估、 無(wú)法加載本地hadoop庫(kù)：
WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platform
如果要使用native library，只能從Hadoop源碼重新編譯生成binary安裝文件
只是想不輸出這個(gè)WARN信息的話卡骂，在core-site.xml中配置hadoop.native.lib的值為false即可
重新編譯方法：http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/NativeLibraries.html
Yarn產(chǎn)生背景-資源利用率
不同計(jì)算框架所在集群其資源利用率不均衡壹士，導(dǎo)致整體的資源利用率很低。
引入中間層（資源管理層）偿警，管理所有節(jié)點(diǎn)上的資源躏救，框架在使用之前首先申請(qǐng)資源，然后運(yùn)行自己內(nèi)部的作業(yè)和任務(wù) 螟蒸，通過(guò)引入資源管理層盒使，可以有效解決資源利用率的問(wèn)題，將公司的各種集群整合為一個(gè)大的集群七嫌，非常方便管理少办。
Yarn產(chǎn)生背景-運(yùn)維成本：
如果采用 一個(gè)框架一個(gè)集群 的模式，則可能需要多個(gè)管理員管理這些集群诵原，增加運(yùn)維成本英妓，共享模式通常需要少數(shù)管理員即可完成多個(gè)框架的統(tǒng)一管理。
Yarn產(chǎn)生背景-數(shù)據(jù)共享：
隨著數(shù)據(jù)量的暴增绍赛，跨集群間的數(shù)據(jù)移動(dòng)不僅花費(fèi)更多時(shí)間蔓纠，硬件成本也會(huì)更大，共享集群模式可讓更多框架共享數(shù)據(jù)和硬件資源吗蚌，將大大減小數(shù)據(jù)移動(dòng)帶來(lái)的成本腿倚。
產(chǎn)生背景-總結(jié)：
源于MR1.0的缺陷：?jiǎn)吸c(diǎn)故障 性能瓶頸 擴(kuò)展性受限 難以支持MR以外的計(jì)算
多計(jì)算框架各自為戰(zhàn)，數(shù)據(jù)共享困難：MR 離線計(jì)算框架 Storm實(shí)時(shí)計(jì)算框架 Spark 內(nèi)存計(jì)算框架
編程模型對(duì)比
第一代MR框架：編程模型
第二代框架：編程模型
編程模型對(duì)比：
為保證編程模型的向下兼容性蚯妇，MRv2重用了MRv1中的編程模型和數(shù)據(jù)處理引擎敷燎，但運(yùn)行環(huán)境被完全重寫(xiě)
編程模型與數(shù)據(jù)處理引擎：
MapReduce應(yīng)用程序編程接口有兩套：新API（mapred）和舊API（mapreduce）
1暂筝、 采用MRv1舊API編寫(xiě)的程序可直接運(yùn)行在MRv2上；
2硬贯、 采用MRv1新API編寫(xiě)的程序需要使用MRv2編程庫(kù)重新編譯并修改不兼容的參數(shù)和返回值
運(yùn)行時(shí)環(huán)境
1焕襟、 MRv1：JobTracker和TaskTracker；
2饭豹、 MRv2：YARN和ApplicationMaster
編程模型：
Yarn基本構(gòu)成與資源調(diào)度
也是采用master（Resource Manager）- slave （Node Manager）架構(gòu)鸵赖，Resource Manager 整個(gè)集群只有一個(gè)，一個(gè)可靠的節(jié)點(diǎn)墨状。
1卫漫、 每個(gè)節(jié)點(diǎn)上可以負(fù)責(zé)該節(jié)點(diǎn)上的資源管理以及任務(wù)調(diào)度菲饼，Node Manager 會(huì)定時(shí)向Resource Manager匯報(bào)本節(jié)點(diǎn)上 的資源使用情況和任務(wù)運(yùn)行狀態(tài)肾砂，
2、 Resource Manager會(huì)通過(guò)心跳應(yīng)答的機(jī)制向Node Manager下達(dá)命令或者分發(fā)新的任務(wù)宏悦，
3镐确、 Yarn 將某一資源分配給該應(yīng)用程序后，應(yīng)用程序會(huì)啟動(dòng)一個(gè)Application Master饼煞，
4源葫、 Application Master為應(yīng)用程序負(fù)責(zé)向Resource Manager申請(qǐng)資源，申請(qǐng)資源之后砖瞧，再和申請(qǐng)到的節(jié)點(diǎn)進(jìn)行通信息堂，運(yùn)行內(nèi)部任務(wù)。
兩層調(diào)度：
1块促、 第一層是Yarn中Resource Manager將資源分配（Driver Application Master所需要的資源）給各應(yīng)用程序荣堰，
2、 第二層是應(yīng)用程序（Application Master啟動(dòng)后竭翠，向Resource Manager申請(qǐng)Container資源振坚，即Executor運(yùn)行所需要的資源）申請(qǐng)資源成功，ResourceManager將資源分配給內(nèi)部的各種任務(wù)斋扰，在對(duì)應(yīng)的節(jié)點(diǎn)上啟動(dòng)Container以運(yùn)行Application Master分發(fā)過(guò)來(lái)的任務(wù)渡八。
Yarn中，任務(wù)會(huì)運(yùn)行在Container的一個(gè)容器內(nèi)传货，封裝的是整個(gè)任務(wù)的運(yùn)行環(huán)境屎鳍，比如CPU、內(nèi)存等環(huán)境變量封裝在container中问裕，在container中運(yùn)行哥艇。
ResourceManager
全局資源管理器，整個(gè)集群只有一個(gè)僻澎，負(fù)責(zé)集群資源的統(tǒng)一調(diào)度和任務(wù)管理
主要由兩個(gè)組件構(gòu)成：資源調(diào)度器 Resource Scheduler 和應(yīng)用程序管理器(Applications Master -- ASM)
調(diào)度器：
1貌踏、 調(diào)度器根據(jù)容量十饥、隊(duì)列等限制條件，將系統(tǒng)中的資源分配給各個(gè)正在運(yùn)行的應(yīng)用程序
2祖乳、 不負(fù)責(zé)具體應(yīng)用程序的相關(guān)工作逗堵，比如監(jiān)控或跟蹤狀態(tài)
3、 不負(fù)責(zé)重新啟動(dòng)失敗任務(wù)
4眷昆、 資源分配單位用“資源容器”（Resource Container）表示
5蜒秤、 Container是一個(gè)動(dòng)態(tài)資源分配單位，它將內(nèi)存亚斋、CPU作媚、磁盤(pán)、網(wǎng)絡(luò)等資源封裝在一起帅刊，從而限定每個(gè)任務(wù)的資源量
6纸泡、 調(diào)度器是一個(gè)可拔插的組件，用戶可以自行設(shè)計(jì)
7赖瞒、 Yarn提供了多種直接可用的調(diào)度器女揭，比如Fair Scheduler、Capacity Scheduler等
應(yīng)用程序管理器：
負(fù)責(zé)管理整個(gè)系統(tǒng)的所有應(yīng)用程序
ResourceManager詳細(xì)功能：
1栏饮、 處理客戶端請(qǐng)求吧兔，
2、 啟動(dòng)/監(jiān)控Application Master（每個(gè)應(yīng)用程序有一個(gè)袍嬉，每個(gè)應(yīng)用程序的master負(fù)責(zé)該應(yīng)用程序的資源申請(qǐng)境蔼，任務(wù)調(diào)度，任務(wù)容錯(cuò)等）伺通，
3箍土、 監(jiān)控Node Manager（如果一個(gè)節(jié)點(diǎn)掛了，Resource Manager會(huì)將運(yùn)行在該Node Manager上的任務(wù)通知Application master泵殴，讓application master觸發(fā)新的調(diào)度或者其他操作涮帘，），
4笑诅、 資源分配與調(diào)度调缨。（集群中所有節(jié)點(diǎn)的資源統(tǒng)籌靈活的智能的分配給各個(gè)應(yīng)用程序）
Application Matser
用戶提交的每個(gè)應(yīng)用程序只有一個(gè)，負(fù)責(zé)應(yīng)用程序的管理
AM主要功能：
1吆你、 與RM調(diào)度器協(xié)商以獲取資源（用Container表示）
2弦叶、 將得到的任務(wù)進(jìn)一步分配給內(nèi)部的任務(wù)
3、 與NM通信以啟動(dòng)/停止任務(wù)
4妇多、 監(jiān)控所有任務(wù)運(yùn)行狀態(tài)伤哺，并在任務(wù)運(yùn)行失敗時(shí)重新為任務(wù)申請(qǐng)資源以重啟任務(wù)
5、 YARN自帶的AM實(shí)現(xiàn)：一個(gè)用于演示AM編寫(xiě)方法的示例程序distributedshell
詳細(xì)功能：
1、 數(shù)據(jù)切分立莉，
2绢彤、 為應(yīng)用程序申請(qǐng)資源，并進(jìn)一步分配給內(nèi)部任務(wù)蜓耻，
3茫舶、 任務(wù)監(jiān)控與容錯(cuò)
Node Manager
整個(gè)集群有多個(gè)，負(fù)責(zé)單節(jié)點(diǎn)資源管理和使用刹淌，每個(gè)節(jié)點(diǎn)上的資源和任務(wù)管理器
詳細(xì)功能：
1饶氏、 定時(shí)向RM匯報(bào)本節(jié)點(diǎn)上的資源使用情況和各個(gè)Container的運(yùn)行狀態(tài)
2、 單個(gè)節(jié)點(diǎn)上的資源管理和任務(wù)管理
3有勾、 處理來(lái)自Resource Manager的命令（殺死任務(wù)或重啟節(jié)點(diǎn)等）
4疹启、 處理來(lái)自Application Master的命令（啟動(dòng)task等命令）
Container
是Yarn中的資源抽象，封裝了某個(gè)節(jié)點(diǎn)上的多維度資源蔼卡，對(duì)任務(wù)運(yùn)行環(huán)境的抽象
Yarn會(huì)為每個(gè)任務(wù)分配一個(gè)Container喊崖，且該任務(wù)只能使用該Container中描述的資源
Container不同于MRv1中的slot，是一個(gè)動(dòng)態(tài)資源劃分單位菲宴，是根據(jù)應(yīng)用程序的需求動(dòng)態(tài)生成的贷祈。
描述一系列信息：
1趋急、 任務(wù)運(yùn)行資源（節(jié)點(diǎn)喝峦、內(nèi)存、CPU）呜达，任務(wù)執(zhí)行在哪個(gè)節(jié)點(diǎn)谣蠢，占用多少內(nèi)存，多少CPU
2查近、 任務(wù)啟動(dòng)命令眉踱，
3、 任務(wù)運(yùn)行環(huán)境霜威，
4谈喳、 當(dāng)Yarn把一個(gè)資源（管理資源）2G內(nèi)存，一個(gè)CPU分配給一個(gè)應(yīng)用程序的時(shí)候戈泼，將運(yùn)行資源的描述封裝為一個(gè)container婿禽，發(fā)送給Application master，application master根據(jù)資源的特點(diǎn)將資源分配給內(nèi)部的某一個(gè)task大猛，之后再與node manager通信啟動(dòng)container扭倾，進(jìn)而啟動(dòng)task。
Yarn通信協(xié)議：
1挽绩、 RPC協(xié)議是連接各個(gè)組件的“大動(dòng)脈”
2膛壹、 Yarn 采用的是拉式（pull-based）通信模型
3、 任何兩個(gè)需要相互通信的組件之間只有一個(gè)RPC協(xié)議
4、 對(duì)于任何一個(gè)RPC協(xié)議模聋，通信雙方有一端是Client肩民，另一端為Server，且Client總是主動(dòng)連接Server的链方。
Yarn主要由以下幾個(gè)RPC協(xié)議組成：
1此改、 ApplicationClientProtocol：JobClient通過(guò)該RPC協(xié)議提交應(yīng)用程序、查詢應(yīng)用程序狀態(tài)等侄柔。
2共啃、 ResourceManagerAdministratorProtocol：Admin通過(guò)該RPC協(xié)議更新系統(tǒng)配置文件，比如節(jié)點(diǎn)黑白名單暂题，用戶隊(duì)列權(quán)限等
3移剪、 ApplicationMasterProtocol：AM通過(guò)該RPC協(xié)議向RM注冊(cè)和撤銷自己，并為各個(gè)任務(wù)申請(qǐng)資源
4薪者、 ContainerManagerProtocol：AM通過(guò)該RPC要求NM啟動(dòng)或者停止Container纵苛，獲取各個(gè)Container的使用狀態(tài)等信息。
5言津、 ResourceTracker：NM通過(guò)該RPC協(xié)議向RM注冊(cè)攻人，并定時(shí)發(fā)送心跳信息匯報(bào)當(dāng)前節(jié)點(diǎn)的資源使用情況和Container運(yùn)行情況。
Yarn工作流程：
運(yùn)行Yarn的應(yīng)用程序有兩類：短應(yīng)用程序和長(zhǎng)應(yīng)用程序悬槽。
短應(yīng)用程序
指在一定時(shí)間內(nèi)可以運(yùn)行完成并正常退出的應(yīng)用程序怀吻，比如MR作業(yè)
長(zhǎng)應(yīng)用程序
是指不出意外，永不終止運(yùn)行的應(yīng)用程序初婆，通常是一些服務(wù)蓬坡，Storm Service，HBase Service等磅叛。
當(dāng)用戶向Yarn提交一個(gè)應(yīng)用程序后屑咳，Yarn將分兩步執(zhí)行該應(yīng)用程序：首先啟動(dòng)Application Master，然后由Application Master啟動(dòng)應(yīng)用程序弊琴。
從并行編程的角度理解YARN
為快速處理一個(gè)大數(shù)據(jù)集兆龙，通常采用多線程并行編程
Yarn-總結(jié)資源管理系統(tǒng)：
對(duì)集群中各類資源進(jìn)行抽象；按照一定的策略敲董，將資源分配給應(yīng)用程序或服務(wù)紫皇；采用一定的隔離機(jī)制防止應(yīng)用程序或者服務(wù)之間因資源搶占而相互干擾
引入YARN這一層后，各種計(jì)算框架可各自發(fā)揮自己的優(yōu)勢(shì)臣缀，并由YARN進(jìn)行統(tǒng)一管理坝橡。
云計(jì)算概念與Yarn：
三層服務(wù)：Infrastructure As A Service IaaS、PaaS和SaaS
1精置、 IaaS：基礎(chǔ)設(shè)施即服務(wù)计寇。消費(fèi)者通過(guò)Internet可以從完善的計(jì)算機(jī)基礎(chǔ)設(shè)施獲得服務(wù)
2、 PaaS：平臺(tái)即服務(wù)。PaaS是將軟件研發(fā)的平臺(tái)作為一種服務(wù)番宁，以SaaS的模式提交給用戶
3元莫、 SaaS：軟件即服務(wù)。 它是一種通過(guò)Internet提供軟件的模式蝶押，用戶無(wú)需購(gòu)買軟件踱蠢，而是向提供商租用基于Web的軟件，來(lái)管理企業(yè)經(jīng)營(yíng)活動(dòng)
YARN可以看作PaaS層棋电，它能夠?yàn)椴煌愋偷膽?yīng)用程序提供統(tǒng)一的管理和調(diào)度
Yarn 運(yùn)行過(guò)程剖析
（以下默認(rèn)為Yarn-Cluster模式）
- 用戶通過(guò)Client向Resource Manager提交應(yīng)用程序并指定Application Master是什么 需要多少CPU 內(nèi)存（driver） 指定程序入口（主類 入口類） driver所需要的內(nèi)存茎截、cpu資源 應(yīng)用程序所需要的額外jar包 需要的外部資源 以及 Executor端的相關(guān)資源情況，
- Resource Manager根據(jù)Application Master（driver端所需資源）通過(guò)調(diào)度器為Application Master尋找到匹配的資源赶盔，找到滿足條件的Node后企锌，ResourceManager 發(fā)送命令給Node Manager，告訴Node Manager 需要多少資源以及CPU于未，要求其啟動(dòng)Application Master進(jìn)程撕攒。（在集群中選擇一個(gè)滿足Driver資源請(qǐng)求的節(jié)點(diǎn)啟動(dòng)Application Master進(jìn)程。）
- Node Manager在相應(yīng)的節(jié)點(diǎn)上啟動(dòng)Application master烘浦。
- 應(yīng)用程序內(nèi)部的邏輯抖坪，若是Map-Reduce Application master應(yīng)用程序，Application master將作業(yè)按照數(shù)據(jù)切分為一個(gè)一個(gè)的Map和Reduce,之后匯總Map和Reduce總的需求（若是Spark Application Master闷叉，將Spark Job切分為跟多Stage擦俐，每個(gè)Stage會(huì)有很多Task，）片习，然后和Resource Manager進(jìn)行通信捌肴，根據(jù)應(yīng)用提交時(shí)所指定的executor資源要求蹬叭，通過(guò)心跳機(jī)制向Resource Manager申請(qǐng)資源藕咏，Resource Manager根據(jù)當(dāng)前節(jié)點(diǎn)的資源使用情況給Application Master分配資源（這些資源是一個(gè)動(dòng)態(tài)分配過(guò)程），通過(guò)心跳應(yīng)答將在相應(yīng)的節(jié)點(diǎn)的資源分配給應(yīng)用程序秽五。
- Application Master 根據(jù)Resource Manager分配給其的Executor 資源當(dāng)前任務(wù)的需求孽查，與對(duì)應(yīng)的節(jié)點(diǎn)Node Manager進(jìn)行通信，啟動(dòng)一個(gè)Task坦喘，
- Node Manager根據(jù)Application Master的描述（比如啟動(dòng)命令盲再、需要的外部jar包、環(huán)境變量是什么瓣铣？）答朋，在已分配資源的相應(yīng)的Node上啟動(dòng)這一任務(wù)，以container形式封裝這些任務(wù)棠笑。
Yarn容錯(cuò)性
1梦碗、 ResourceManager：存在單點(diǎn)故障，但Zookeeper實(shí)現(xiàn)HA BakMaster
2、 NodeManager：
a. 失敗后洪规，NM通過(guò)心跳將失敗任務(wù)的情況告訴RM印屁，RM將失敗后任務(wù)告訴對(duì)應(yīng)的AM；
b. AM決定如何處理失敗的任務(wù)（大數(shù)據(jù)應(yīng)用場(chǎng)景下 有些任務(wù)的失敗 可以考慮丟棄）
3斩例、 ApplicationMaster：
a. 失敗后雄人，由RM負(fù)責(zé)重啟；
b. AM需處理內(nèi)部任務(wù)的容錯(cuò)問(wèn)題
4念赶、 RMAPPMaster 會(huì)保存已經(jīng)運(yùn)行完成的Task础钠，重啟后無(wú)需重新運(yùn)行。
Yarn 調(diào)度框架
雙層調(diào)度框架
1叉谜、 RM將資源分配給AM
2珍坊、 AM收到RM分配的資源后，根據(jù)資源的特點(diǎn)和任務(wù)的情況采用相關(guān)的調(diào)度策略進(jìn)一步分配給各個(gè)Task
基于資源預(yù)留的調(diào)度策略
1正罢、 資源不夠時(shí)阵漏，會(huì)為T(mén)ask預(yù)留，直到資源充足（犧牲資源利用率）
2翻具、 與“all or nothing”策略不同（Apache Mesos 要么給他 要么不給他你 產(chǎn)生餓死情況）
Yarn資源調(diào)度器 --
多類型資源調(diào)度
1履怯、 可以對(duì)多種類型的資源進(jìn)行調(diào)度，不同于MR1.0 基于slot進(jìn)行的調(diào)度
2裆泳、 將多維度的資源抽象為一維度的slot
3叹洲、 資源調(diào)度的過(guò)程就是把slot資源分配給Task的過(guò)程，
Yarn的調(diào)度資源
1工禾、 直接調(diào)度的是CPU和內(nèi)存以及網(wǎng)絡(luò)資源运提，沒(méi)有slot類型概念
2、 采用DRF算法闻葵，Dominant Resource Fairness Fair Allocation of Multiple Resource Types
提供多種資源調(diào)度器
1民泵、 FIFO
2、 Fair Scheduler(多用戶共享模式調(diào)度器)
3槽畔、 Capacity Scheduler（多用戶共享模式調(diào)度器）
調(diào)度器對(duì)比：
? FifoScheduler
? 最簡(jiǎn)單的調(diào)度器栈妆，按照先進(jìn)先出的方式處理應(yīng)用
? CapacityScheduler
? FifoScheduler的多隊(duì)列版本，每個(gè)隊(duì)列可以限制資源使用量
? 隊(duì)列間的資源分配以使用量作排列依據(jù)厢钧，使得容量小的隊(duì)列有競(jìng)爭(zhēng)優(yōu)勢(shì)
? 使得hadoop應(yīng)用能夠被多用戶使用鳞尔，且最大化整個(gè)集群資源的吞吐量
? 啟動(dòng)容量調(diào)度器之后，調(diào)度器會(huì)從classpath中加載capacity-scheduler.xml文件早直，完成容量調(diào)度器的初始化
? FairScheduler
? 多隊(duì)列罕扎，多用戶共享資源芙代。使得hadoop應(yīng)用能夠被多用戶公平地共享整個(gè)集群資源的調(diào)度器
? 根據(jù)隊(duì)列設(shè)定的最小共享量或者權(quán)重等參數(shù)摔握，按比例共享資源
調(diào)度器的集群配置：
容量調(diào)度器參數(shù)定義和計(jì)算關(guān)系：
? 隊(duì)列容量=yarn.scheduler.capacity.<queue-path>.capacity/100
? 隊(duì)列絕對(duì)容量=父隊(duì)列的 隊(duì)列絕對(duì)容量隊(duì)列容量
? 隊(duì)列最大容量=yarn.scheduler.capacity.<queue-path>.maximum-capacity/100
? 隊(duì)列絕對(duì)最大容量=父隊(duì)列的 隊(duì)列絕對(duì)最大容量隊(duì)列最大容量
? 絕對(duì)資源使用比=使用的資源/全局資源
? 資源使用比=使用的資源/(全局資源 * 隊(duì)列絕對(duì)容量)
? 最小分配量=yarn.scheduler.minimum-allocation-mb
? 用戶上限=MAX(yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent,1/隊(duì)列用戶數(shù)量)
? 用戶調(diào)整因子=yarn.scheduler.capacity.<queue-path>.user-limit-factor
? 最大提交應(yīng)用=yarn.scheduler.capacity.<queue-path>.maximum-applications
? 如果小于0 設(shè)置為(yarn.scheduler.capacity.maximum-applications隊(duì)列絕對(duì)容量)
? 單用戶最大提交應(yīng)用=最大提交應(yīng)用(用戶上限/100)用戶調(diào)整因子
? AM資源占比（AM可占用隊(duì)列資源最大的百分比)
? =yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent
? 如果為空，設(shè)置為yarn.scheduler.capacity.maximum-am-resource-percent
? 最大活躍應(yīng)用數(shù)量=全局總資源/最小分配量AM資源占比隊(duì)列絕對(duì)最大容量
? 單用戶最大活躍應(yīng)用數(shù)量=(全局總資源/最小分配量AM資源占比隊(duì)列絕對(duì)容量)用戶上限*用戶調(diào)整因子
? 本地延遲分配次數(shù)=yarn.scheduler.capacity.node-locality-delay<code>
多租戶資源調(diào)度器
1拾给、 支持資源按比例分配
2、 支持層級(jí)隊(duì)列劃分方式（樹(shù)形結(jié)構(gòu)）
3兔沃、 支持資源搶占
資源分配模型：
Yarn 資源隔離方案
Yarn通過(guò)Resource Manager為應(yīng)用分配資源蒋得，Node Manager獲得相應(yīng)的資源在其節(jié)點(diǎn)上執(zhí)行Task，NodeManager 有責(zé)任為T(mén)ask提供一個(gè)隔離的環(huán)境乒疏。
否咋额衙，節(jié)點(diǎn)上所有的Task都在競(jìng)爭(zhēng)資源，性能降低怕吴，服務(wù)質(zhì)量得不到保證窍侧。
支持CPU和內(nèi)存的兩種資源隔離
1、 內(nèi)存是一種決定生死的資源
2转绷、 Cpu是一種影響快慢的資源
內(nèi)存隔離：
1伟件、 基于線程監(jiān)控的方案：在每個(gè)節(jié)點(diǎn)上啟動(dòng)一個(gè)監(jiān)控線程以對(duì)內(nèi)存的訪問(wèn)和使用進(jìn)行監(jiān)控。一旦內(nèi)存的資源使用量超過(guò)了其所申請(qǐng)的資源量议经，其將被殺死斧账。
2、 基于Cgroups的方案：
CPU隔離：
1煞肾、 默認(rèn)不對(duì)CPU資源進(jìn)行隔離：yarn將cpu的資源分配交給node manager所在的操作系統(tǒng)咧织，由os對(duì)cpu資源進(jìn)行分配，
2籍救、 基于Cgroups的方案：需要配置 默認(rèn)沒(méi)有打開(kāi)
Yarn支持的調(diào)度語(yǔ)義：
應(yīng)用程序向yarn申請(qǐng)資源時(shí)习绢，向Yarn表達(dá)出所需資源的方式所需的格式及相關(guān)標(biāo)準(zhǔn)，成為調(diào)度語(yǔ)義蝙昙。申請(qǐng)資源闪萄、歸還資源
支持的語(yǔ)義：
1、 請(qǐng)求某個(gè)特定節(jié)點(diǎn)/機(jī)架上的特定資源量
2奇颠、 將某些節(jié)點(diǎn)加入或移除黑名單败去，不再為自己分配這些節(jié)點(diǎn)上的資源（可能某個(gè)節(jié)點(diǎn)不適合運(yùn)行某種任務(wù)）
3、 請(qǐng)求歸還這些資源
不支持的語(yǔ)義：
1大刊、 請(qǐng)求任意節(jié)點(diǎn)/機(jī)架上的特定資源量
2为迈、 請(qǐng)求一組或幾組符合某種特質(zhì)的資源
3、 超細(xì)粒度資源
4缺菌、 動(dòng)態(tài)調(diào)整Container資源（目前支持）
框架運(yùn)行在Yarn上的好處：
1、 應(yīng)用程序部署變得更簡(jiǎn)單：只需部署YARN服務(wù)搜锰，各類應(yīng)用不再自帶服務(wù)
2伴郁、 服務(wù)部署變得更簡(jiǎn)單：用戶可以運(yùn)行一個(gè)應(yīng)用程序的方式部署一套服務(wù)
3、 多版本共享集群資源：Cgroups隔離機(jī)制
4蛋叼、 資源彈性管理：YARN可根據(jù)不同類型的應(yīng)用程序壓力情況焊傅，調(diào)整對(duì)應(yīng)的資源使用量剂陡，實(shí)現(xiàn)資源彈性管理
Yarn上的計(jì)算框架
Yarn主要的使用是運(yùn)行高級(jí) 的計(jì)算框架，不是用戶寫(xiě)一個(gè)程序直接與yarn交互狐胎，這種情況很少出現(xiàn)鸭栖。直接與計(jì)算框架交互，將計(jì)算框架與yarn交互握巢，用戶與計(jì)算框架進(jìn)行交互晕鹊，應(yīng)用程序種類繁多，每種應(yīng)用程序類型都對(duì)應(yīng)一種計(jì)算框架暴浦，
Map map-reduce spark（stage） stage - DAG圖
Yarn設(shè)計(jì)目標(biāo)
通用的統(tǒng)一資源管理系統(tǒng)：同時(shí)運(yùn)行長(zhǎng)應(yīng)用程序和短應(yīng)用程序溅话，
1、 長(zhǎng)應(yīng)用程序：通常情況下歌焦，永不停止運(yùn)行的程序 service Http Server
2飞几、 短應(yīng)用程序：短時(shí)間 秒級(jí) 分鐘級(jí) 小時(shí)級(jí) 內(nèi)會(huì)結(jié)束運(yùn)行的程序 MR Job Spark Job
以Yarn為核心的生態(tài)系統(tǒng)
在Yarn之上的，以MR為代表批處理應(yīng)用程序 交互式的Tez 在線online的Hbase
流處理 Storm Graph 圖計(jì)算框架 Spark內(nèi)存計(jì)算框架
運(yùn)行在Yarn上的計(jì)算框架：
Map-Reduce 離線計(jì)算框架
Tez：DAG計(jì)算框架
Storm：流式計(jì)算框架
內(nèi)存計(jì)算框架：Spark
離線計(jì)算框架Map Reduce：
將計(jì)算過(guò)程分為兩個(gè)階段：Map和Reduce
Map階段并行處理輸入數(shù)據(jù)
Reduce階段對(duì)Map結(jié)果進(jìn)行匯總
Shuffle連接Map和Reduce兩個(gè)階段
Map Task將數(shù)據(jù)寫(xiě)到本地磁盤(pán)
Reduce Task從每個(gè)Map Task上讀取一份數(shù)據(jù)
僅適合離線批處理
具有很好的容錯(cuò)性和擴(kuò)展性
適合簡(jiǎn)單地批處理任務(wù)
缺點(diǎn)明顯：?jiǎn)?dòng)開(kāi)銷大独撇、過(guò)多使用磁盤(pán)導(dǎo)致效率低下等
MapReduce On Yarn
- Client提交MR應(yīng)用程序至Yarn的Resource Manager的Applications Manager屑墨，
- Resource Manager的Applications Manager收到請(qǐng)求后找到一個(gè)節(jié)點(diǎn)Node Manager啟動(dòng)Application Master（MR APP Mstr MapReduce中已經(jīng)實(shí)現(xiàn)好了），
- Application Master啟動(dòng)成功后纷铣，會(huì)根據(jù)輸入數(shù)據(jù)的大小绪钥，將應(yīng)用程序切分為很多的MapTask 和Reduce Task，
- Application Master向Resource Manager的Resource Scheduler發(fā)送請(qǐng)求資源信息关炼，程腹，根據(jù)Task所需申請(qǐng)
- Resource Manager的Resource Scheduler會(huì)根據(jù)當(dāng)前資源的使用情況和任務(wù)狀態(tài)進(jìn)行資源的分配，產(chǎn)生一個(gè)心跳應(yīng)答儒拂，動(dòng)態(tài)的將資源分配給Application Master
- Application Master獲得資源后寸潦，發(fā)送消息給Node Manager啟動(dòng)task
- Node Manager啟動(dòng)Container封裝Task
- Node Manager的Task啟動(dòng)后會(huì)向Application Master 發(fā)送心跳，維護(hù)一個(gè)心跳信息社痛，Application Master 通過(guò)心跳信息監(jiān)控各個(gè)Task的運(yùn)行狀態(tài)见转。如果一段時(shí)間內(nèi)未接收到相關(guān)Task的心跳信息，則認(rèn)為該Task掛了蒜哀，重新為T(mén)ask申請(qǐng)資源斩箫，運(yùn)行Task
DAG計(jì)算框架Tez
多個(gè)作業(yè)之間存在數(shù)據(jù)依賴關(guān)系，并形成一個(gè)依賴關(guān)系有向圖（Directed Acyclic Graph）撵儿，該圖的計(jì)算稱為“DAG計(jì)算”
Apache Tez：基于Yarn 的DAG計(jì)算框架
? 直接源于MapReduce框架乘客，核心思想是將Map和Reduce兩個(gè)操作進(jìn)一步拆分
? Map被拆分成Input、Processor淀歇、Sort易核、Merge和Output
? Reduce被拆分成Input、Shuffle浪默、Sort牡直、Merge缀匕、Processor和Output
? 分解后的元操作可以任意靈活組合，產(chǎn)生新的操作碰逸，這些操作經(jīng)過(guò)一些控制程序組裝后乡小，可形成一個(gè)大的DAG作業(yè)
? 天生融入Hadoop 2.0中的資源管理平臺(tái)YARN
? Tez主要由兩部分組成
? 數(shù)據(jù)處理引擎
? DAGAppMaster
Tez數(shù)據(jù)處理引擎：
? Tez提供了6中可編程組件，實(shí)現(xiàn)了一些常見(jiàn)的算法和組件
? Input：對(duì)輸入數(shù)據(jù)源的抽象饵史，類似于MR模型中的InputFormat满钟，它解析輸入數(shù)據(jù)格式，并吐出一個(gè)個(gè)Key/value
? Output：對(duì)輸出數(shù)據(jù)源的抽象约急，類似于MR模型中的OutputFormat零远，它將用戶程序產(chǎn)生的Key/value寫(xiě)入文件系統(tǒng)
? Partitioner：對(duì)數(shù)據(jù)進(jìn)行分片，類似于MR中的Partitioner
? Processor：對(duì)計(jì)算單元的抽象厌蔽，它從一個(gè)Input中獲取數(shù)據(jù)牵辣，經(jīng)用戶定義的邏輯處理后，通過(guò)Output輸出到文件系統(tǒng)
? Task：對(duì)任務(wù)的抽象奴饮，每個(gè)Task由一個(gè)Input纬向、Ouput和Processor組成
? Maser：管理各個(gè)Task的依賴關(guān)系，并按照依賴關(guān)系執(zhí)行他們
? Tez數(shù)據(jù)處理引擎實(shí)現(xiàn)了一些常見(jiàn)的組件
? Tez數(shù)據(jù)處理引擎的基礎(chǔ)是Sort（排序）和Shuffle（混洗）
? Tez提供了多種Input戴卜、Output逾条、Task和Sort的實(shí)現(xiàn)
? Input實(shí)現(xiàn)
LocalMergedInput（多個(gè)文件本地合并后作為輸入）
ShuffledMergedInput（遠(yuǎn)程拷貝數(shù)據(jù)且合并后作為輸入）
? Output實(shí)現(xiàn)
InMemorySortedOutput（內(nèi)存排序后輸出）
LocalOnFileSorterOutput（本地磁盤(pán)排序后輸出）OnFileSortedOutput（磁盤(pán)排序后輸出）
? Task實(shí)現(xiàn)
RunTimeTask
? Sort實(shí)現(xiàn)
DefaultSorter（本地?cái)?shù)據(jù)排序）
InMemoryShuffleSorter（遠(yuǎn)程拷貝數(shù)據(jù)并排序）
Tez On Yarn 優(yōu)勢(shì)：
1、 運(yùn)行在Yarn之上投剥，充分利用Yarn的資源管理和容錯(cuò)等功能
2师脂、 提供了豐富的數(shù)據(jù)流 dataflow api
3、 擴(kuò)展性良好的 Input-Processor-Output 運(yùn)行時(shí)模型
4江锨、 動(dòng)態(tài)生成物理數(shù)據(jù)流關(guān)系
啟動(dòng)的不是Application Master 而是 DAG APlication Master
Tez Application Master
? Tez ApplicationMaster直接源于MapReduce的ApplicationMaster吃警，重用了大部分機(jī)制和代碼
? 功能
? 數(shù)據(jù)切分和作業(yè)分解
? 任務(wù)調(diào)度
? 與ResourceManager進(jìn)行通信，為DAG作業(yè)申請(qǐng)資源
? 與NodeManager進(jìn)行通信啄育，啟動(dòng)DAG作業(yè)中的任務(wù)
? 監(jiān)控DAG作業(yè)的運(yùn)行過(guò)程酌心，確保它快速運(yùn)行結(jié)束
? 每個(gè)DAGAppMaster負(fù)責(zé)管理一個(gè)DAG作業(yè)
? DAGAppMaster優(yōu)先為那些不依賴任何頂點(diǎn)的任務(wù)申請(qǐng)資源
? DAG中的一個(gè)頂點(diǎn)由一定數(shù)目的任務(wù)組成
? 一旦一個(gè)頂點(diǎn)中所有任務(wù)運(yùn)行完成，則認(rèn)為該頂點(diǎn)運(yùn)行結(jié)束
Tez優(yōu)化技術(shù)
1挑豌、 如果每個(gè)作業(yè)都啟動(dòng)一個(gè)Application Master安券，性能將會(huì)很低。
2氓英、 Application Master緩沖池：作業(yè)提交到AMPoolServer服務(wù)上侯勉，預(yù)啟動(dòng)若干個(gè)Application Master，形成一個(gè)Application Master緩沖池
3债蓝、 預(yù)先啟動(dòng)Container：Application Master啟動(dòng)時(shí)可以預(yù)先啟動(dòng)若干個(gè)Container
Container重用：
任務(wù)運(yùn)行完成后壳鹤，Application Master不會(huì)馬上注銷所使用的Container，而是將它重新分配給其他未運(yùn)行的任務(wù)饰迹。
Tez應(yīng)用場(chǎng)景：
1芳誓、 直接編寫(xiě)應(yīng)用程序
2、 Tez提供一套通用編程接口
3啊鸭、 適合編寫(xiě)有依賴關(guān)系的作業(yè)
4锹淌、 優(yōu)化Pig、Hive等引擎->
5赠制、 下一代Hive Stinger
好處1：避免查詢語(yǔ)句轉(zhuǎn)換成過(guò)多的MR作業(yè)后產(chǎn)生大量不必要的網(wǎng)絡(luò)和磁盤(pán)IO
好處2：更加智能的任務(wù)處理引擎
Tez與其他系統(tǒng)對(duì)比
? 與Oozie對(duì)比
? Oozie是工作流調(diào)度系統(tǒng)赂摆，按照用戶定義好的作業(yè)依賴關(guān)系調(diào)度作業(yè)
? Oozie只是一種作業(yè)依賴關(guān)系表達(dá)和調(diào)度框架，邏輯上并沒(méi)有將有依賴關(guān)系的作業(yè)合并成一個(gè)作業(yè)來(lái)優(yōu)化I/O讀寫(xiě)
? 與MapReduce對(duì)比
? MapReduce只是一種簡(jiǎn)單的數(shù)據(jù)處理模型
? Tez可以包含任意多個(gè)數(shù)據(jù)處理階段
? Tez可作為MapReduce之下的數(shù)據(jù)處理引擎
? Tez與MapReduce編程接口完全兼容
流式計(jì)算框架 Storm
1钟些、 流式計(jì)算指的是被處理的數(shù)據(jù)像流水一樣不斷流入系統(tǒng)烟号，而系統(tǒng)需要針對(duì)每條數(shù)據(jù)進(jìn)行實(shí)時(shí)處理和計(jì)算，并永不停止（直到用戶顯式殺死進(jìn)程）
2政恍、 傳統(tǒng)做法：由消息隊(duì)列和消息處理者組成的實(shí)時(shí)處理網(wǎng)絡(luò)進(jìn)行實(shí)時(shí)計(jì)算汪拥，缺乏自動(dòng)化，缺乏健壯性篙耗，伸縮性差
Storm典型應(yīng)用場(chǎng)景
1迫筑、 廣告；
2宗弯、 分布式rpc：由于storm的處理組件是分布式的脯燃，而且處理延遲極低，所以可以作為一個(gè)通用的分布式rpc框架來(lái)使用
360：Storm在實(shí)時(shí)網(wǎng)絡(luò)攻擊檢測(cè)和分析的應(yīng)用和改進(jìn) 集群規(guī)模：46個(gè)集群蒙保，9000個(gè)節(jié)點(diǎn)辕棚，每個(gè)結(jié)點(diǎn)2-4個(gè)slot 利用云存儲(chǔ)的空閑資源 應(yīng)用：50多個(gè)業(yè)務(wù)，100多個(gè)topology
實(shí)時(shí)日志統(tǒng)計(jì)邓厕、網(wǎng)頁(yè)分析逝嚎、圖片處理、人臉識(shí)別邑狸、……..
每天處理約120TB 200億條
Stom 計(jì)算框架：
Master（Nimbus） 通過(guò)Zookeeper 與 slaves（Supervisor）進(jìn)行通信懈糯，master掛了，supervisor仍然可以重新工作单雾，只是任務(wù)不可以重新提交作業(yè)赚哗，一個(gè)supervisor可以運(yùn)行多個(gè)worker，一個(gè)worker可以運(yùn)行多個(gè)executor硅堆，一個(gè)executor可以運(yùn)行多個(gè)task屿储。
每個(gè)應(yīng)用程序有一個(gè)spout 數(shù)據(jù)源（web 服務(wù)器，kafka）渐逃，實(shí)時(shí)的將數(shù)據(jù)推送給blot（類似于map reduce）够掠，blot之間可以存在依賴關(guān)系。整個(gè)依賴關(guān)系稱之為topology
Hadoop MRv1.0 Storm
系統(tǒng)服務(wù) JobTracker(master) Nimbus(master Zookeeper)
TaskTracker(slave) Supervisor(slave)
Child(啟動(dòng)Task) Worker(啟動(dòng)Task)
應(yīng)用程序名稱 Job Topology
編程模型 Map-Reduce Spout/Blot
Shuffle Stream Grouping
1茄菊、 Nimbus：負(fù)責(zé)資源分配和任務(wù)調(diào)度
2疯潭、 Supervisor：負(fù)責(zé)接受nimbus分配的任務(wù)赊堪，啟動(dòng)和停止屬于自己管理的worker進(jìn)程
3、 Worker：運(yùn)行具體處理組件邏輯的進(jìn)程
4竖哩、 Task：worker中每一個(gè)spout/bolt的線程稱為一個(gè)task哭廉。在storm0.8之后，task不再與物理線程對(duì)應(yīng)相叁，同一個(gè)spout/bolt的task可能會(huì)共享一個(gè)物理線程遵绰，該線程稱為executor
5、 Topology：storm中運(yùn)行的一個(gè)實(shí)時(shí)應(yīng)用程序增淹；各個(gè)組件間的消息流動(dòng)形成邏輯上的一個(gè)拓?fù)浣Y(jié)構(gòu)
6椿访、 Spout：在一個(gè)topology中產(chǎn)生源數(shù)據(jù)流的組件；通常情況下spout會(huì)從外部數(shù)據(jù)源中讀取數(shù)據(jù)虑润，然后轉(zhuǎn)換為topology內(nèi)部的源數(shù)據(jù)成玫；Spout是一個(gè)主動(dòng)的角色，其接口中有個(gè)nextTuple()函數(shù)端辱，storm框架會(huì)不停地調(diào)用此函數(shù)梁剔，用戶只要在其中生成源數(shù)據(jù)即可
7、 Bolt：在一個(gè)topology中接受數(shù)據(jù)然后執(zhí)行處理的組件舞蔽；Bolt可以執(zhí)行過(guò)濾荣病、函數(shù)操作、合并渗柿、寫(xiě)數(shù)據(jù)庫(kù)等任何操作个盆；Bolt是一個(gè)被動(dòng)的角色，其接口中有個(gè)execute(Tupleinput)函數(shù),在接受到消息后會(huì)調(diào)用此函數(shù)朵栖，用戶可以在其中執(zhí)行自己想要的
8颊亮、 Tuple：一次消息傳遞的基本單元；本來(lái)應(yīng)該是一個(gè)key-value的map陨溅，但是由于各個(gè)組件間傳遞的tuple的字段名稱已經(jīng)事先定義好终惑，所以tuple中只要按序填入各個(gè)value就行了，所以就是一個(gè)value list
9门扇、 Stream：源源不斷傳遞的tuple就組成了stream
10雹有、 stream grouping：即消息的partition方法；Storm中提供若干種實(shí)用的grouping方式臼寄，包括shuffle, fields hash, all, global, none, direct和localOrShuffle等
Storm On Yarn
運(yùn)行的不是短作業(yè) 而是服務(wù) 霸奕，將master和slave運(yùn)行在Storm Application Master上，通過(guò)Yarn將Nimbus和Supervisor部署在Yarn集群中吉拳，部署之后质帅，Strom的client可以直接連接Storm Application Master 里的Nimbus，使用一個(gè)普通的Storm集群一樣使用Storm，該Storm是通過(guò)Yarn啟動(dòng)煤惩，
? Storm ApplicationMaster初始化時(shí)嫉嘀，將在同一個(gè)Container中啟動(dòng)Storm Nimbus和Storm Web UI兩個(gè)服務(wù)
? 根據(jù)待啟動(dòng)的Supervisor數(shù)目向ResourceManager申請(qǐng)資源
? ApplicationMaster將請(qǐng)求一個(gè)節(jié)點(diǎn)上所有資源然后啟動(dòng)Supervisor服務(wù)，也就是說(shuō)盟庞，當(dāng)前Supervisor將獨(dú)占節(jié)點(diǎn)而不會(huì)與其他服務(wù)共享節(jié)點(diǎn)資源吃沪，這種情況下可避免其他服務(wù)對(duì)Storm集群的干擾
? Storm ApplicationMaster還會(huì)啟動(dòng)一個(gè)Thrift Server以處理來(lái)自YARN-Storm Client端的各種請(qǐng)求
Storm On Yarn 優(yōu)勢(shì)
? 彈性計(jì)算資源
? Storm可與YARN上其他應(yīng)用程序（比如MapReduce批處理應(yīng)用程序）共享整個(gè)集群中的資源
? 當(dāng)Storm負(fù)載驟增時(shí)汤善，可動(dòng)態(tài)為它增加計(jì)算資源
? 當(dāng)負(fù)載減小時(shí)什猖，可釋放部分資源，從而將這些資源暫時(shí)分配給負(fù)載更重的批處理應(yīng)用程序
? 共享底層存儲(chǔ)
? Storm可與運(yùn)行在YARN上的其他框架共享底層的一個(gè)HDFS存儲(chǔ)系統(tǒng)
? 避免多個(gè)集群帶來(lái)的維護(hù)成本
? 避免數(shù)據(jù)跨集群拷貝帶來(lái)的網(wǎng)絡(luò)開(kāi)銷和時(shí)間延遲
? 支持多版本
? 可同時(shí)將多個(gè)Storm版本運(yùn)行YARN上红淡，避免一個(gè)版本一個(gè)集群帶來(lái)的維護(hù)成本
內(nèi)存計(jì)算框架Spark
Spark是什么：
? Spark是一種與Hadoop相似的開(kāi)源集群計(jì)算環(huán)境
? Spark基于MR算法實(shí)現(xiàn)的分布式計(jì)算不狮，擁有Hadoop MR的優(yōu)點(diǎn)，不同的是結(jié)果保存在內(nèi)存中
? Spark是一個(gè)針對(duì)超大數(shù)據(jù)集合的低延遲的集群分布式計(jì)算系統(tǒng)在旱，比MapReduce快40倍左右
? Spark 是在 Scala 語(yǔ)言中實(shí)現(xiàn)的摇零，它將 Scala 用作其應(yīng)用程序框架
Spark兼容Hadoop的API，能夠讀寫(xiě)Hadoop的HDFS HBASE 順序文件等
傳統(tǒng)Hadoop：
Spark：
Spark優(yōu)勢(shì)
? 輕
? Spark 0.6核心代碼有2萬(wàn)行
? Spark很好地利用了Hadoop和Mesos的基礎(chǔ)設(shè)施
? 快
? Spark對(duì)小數(shù)據(jù)集能達(dá)到亞秒級(jí)的延遲
? 靈
? Spark提供了不同層面的靈活性
? 巧
? 巧在借勢(shì)和借力
Spark與Hadoop對(duì)比
? Spark的中間數(shù)據(jù)放到內(nèi)存中桶蝎，對(duì)于迭代運(yùn)算效率更高
? Spark更適合于迭代運(yùn)算比較多的ML和DM運(yùn)算驻仅。因?yàn)樵赟park里面，有RDD的抽象概念
? Spark提供多種數(shù)據(jù)集操作類型
? Transformations
包括map, filter, flatMap, sample, groupByKey, reduceByKey, union,join,cogroup,mapValues,sort,partionBy等
? Actions
包括Count, collect, reduce, lookup, save等
? 編程模型比Hadoop更靈活登渣，用戶可以命名噪服，物化，控制中間結(jié)果的存儲(chǔ)胜茧、分區(qū)
? Spark不適用那種異步細(xì)粒度更新?tīng)顟B(tài)的應(yīng)用
? 可用性
? 容錯(cuò)性
Shark – Hive On Spark SparkSQL-DataFrame
? Shark基本上就是在Spark的框架基礎(chǔ)上提供和Hive一樣的H iveQL命令接口
? Shark使用了Hive的API來(lái)實(shí)現(xiàn)query Parsing和 Logic Plan generation
? 通過(guò)配置Shark參數(shù)粘优，Shark可以自動(dòng)在內(nèi)存中緩存特定的RDD，實(shí)現(xiàn)數(shù)據(jù)重用呻顽，進(jìn)而加快特定數(shù)據(jù)集的檢索
? Shark通過(guò)UDF用戶自定義函數(shù)實(shí)現(xiàn)特定的數(shù)據(jù)分析學(xué)習(xí)算法雹顺，使得SQL數(shù)據(jù)查詢和運(yùn)算分析能結(jié)合在一起
Spark Streaming
? 構(gòu)建在Spark上處理Stream數(shù)據(jù)的框架
? Spark的低延遲執(zhí)行引擎（100ms+）可以用于實(shí)時(shí)計(jì)算
? 相比基于Record的其它處理框架（如Storm），RDD數(shù)據(jù)集更容易做高效的容錯(cuò)處理
? 基本原理是將Stream數(shù)據(jù)分成小的時(shí)間片斷（幾秒）廊遍，以類似batch批量處理的方式來(lái)處理這小部分?jǐn)?shù)據(jù)
? 使得它可以同時(shí)兼容批量和實(shí)時(shí)數(shù)據(jù)處理的邏輯和算法
Spark核心概念-RDD
? 為什么會(huì)產(chǎn)生RDD嬉愧？
? 解決傳統(tǒng)MapReduce 迭代計(jì)算式要進(jìn)行大量的磁盤(pán)IO操作
? RDD：Resilient Distributed Dataset 彈性分布數(shù)據(jù)集
? RDD是一個(gè)只讀的，可分區(qū)的分布式數(shù)據(jù)集喉前，這個(gè)數(shù)據(jù)集的全部或部分可以緩存在內(nèi)存中没酣，在多次計(jì)算間重用
? RDD是一種有容錯(cuò)機(jī)制的特殊集合，可以分布在集群的節(jié)點(diǎn)上被饿，以函數(shù)式編程操作集合的方式四康，進(jìn)行各種并行操作
? RDD可以cache到內(nèi)存中，每次對(duì)RDD數(shù)據(jù)集的操作之后的結(jié)果狭握，都可以存放到內(nèi)存中
? 實(shí)質(zhì)是一種更為通用的迭代并行計(jì)算框架闪金，用戶可以顯示的控制計(jì)算的中間結(jié)果，然后將其自由運(yùn)用于之后的計(jì)算
RDD存儲(chǔ)與分區(qū)
? 用戶可以選擇不同的存儲(chǔ)級(jí)別存儲(chǔ)RDD以便重用
? 當(dāng)前RDD默認(rèn)是存儲(chǔ)于內(nèi)存，但當(dāng)內(nèi)存不足時(shí)哎垦，RDD會(huì)spill到disk
? RDD在需要進(jìn)行分區(qū)把數(shù)據(jù)分布于集群中時(shí)會(huì)根據(jù)每條記錄Key進(jìn)行分區(qū)囱嫩，以此保證兩個(gè)數(shù)據(jù)集在Join時(shí)能高效
Lineage 血統(tǒng)
? 為了保證RDD中數(shù)據(jù)的魯棒性，RDD數(shù)據(jù)集通過(guò)所謂的血統(tǒng)關(guān)系(Lineage) 記住了它是如何從其它RDD中演變過(guò)來(lái)的
? RDD的Lineage記錄的是粗顆粒度的特定數(shù)據(jù)變換（Transformation）操作（filter, map, join etc.)行為
? 當(dāng)這個(gè)RDD的部分分區(qū)數(shù)據(jù)丟失時(shí)漏设，它可以通過(guò)Lineage獲取足夠的信息來(lái)重新運(yùn)算和恢復(fù)丟失的數(shù)據(jù)分區(qū)
RDD容錯(cuò)機(jī)制：
? 兩種方式：數(shù)據(jù)檢查點(diǎn)和記錄更新（默認(rèn)）
? 只記錄單個(gè)塊上執(zhí)行的單個(gè)操作墨闲，然后創(chuàng)建某個(gè)RDD的變換序列（血統(tǒng)）存儲(chǔ)下來(lái)
? RDD的容錯(cuò)機(jī)制又稱“血統(tǒng)”容錯(cuò)
? 如何表達(dá)父RDD和子RDD之間的依賴關(guān)系？
? 依賴關(guān)系可以分兩種郑口，窄依賴和寬依賴
? 依賴關(guān)系分類的兩個(gè)特性
? 計(jì)算子RDD的方式不同
? 數(shù)據(jù)恢復(fù)的方式不同
對(duì)于寬依賴鸳碧，要在適當(dāng)時(shí)機(jī)設(shè)置數(shù)據(jù)檢查點(diǎn)
? RDD只能從持久存儲(chǔ)或通過(guò)Transformations操作產(chǎn)生，對(duì)于丟失部分?jǐn)?shù)據(jù)分區(qū)只需根據(jù)它的lineage就可重新計(jì)算出來(lái)犬性，而不需要做特定的Checkpoint
? RDD的不變性瞻离，可以實(shí)現(xiàn)類Hadoop MapReduce的推測(cè)式執(zhí)行
? RDD的數(shù)據(jù)分區(qū)特性，可以通過(guò)數(shù)據(jù)的本地性來(lái)提高性能
? RDD都是可序列化的乒裆，在內(nèi)存不足時(shí)可自動(dòng)降級(jí)為磁盤(pán)存儲(chǔ)
RDD內(nèi)部設(shè)計(jì)
? 源數(shù)據(jù)分割后的數(shù)據(jù)塊套利，源代碼中的splits變量
? 關(guān)于“血統(tǒng)”的信息，源碼中的dependencies變量
? 一個(gè)計(jì)算函數(shù)（該RDD如何通過(guò)父RDD計(jì)算得到）鹤耍，源碼中的iterator(split)和compute函數(shù)
? 一些關(guān)于如何分塊和數(shù)據(jù)存放位置的元信息肉迫，如源碼中的partitioner和preferredLocations
操作RDD：
? 如何獲取RDD
? 從共享的文件系統(tǒng)獲取（如：HDFS）
? 通過(guò)已存在的RDD轉(zhuǎn)換
? 將已存在scala集合（只要是Seq對(duì)象）并行化稿黄，通過(guò)調(diào)用SparkContext的parallelize方法實(shí)現(xiàn)
? 改變現(xiàn)有RDD的持久性喊衫；RDD是懶散，短暫的
? 操作RDD的兩個(gè)動(dòng)作
? Actions （ 如： count, collect, save等）
返回結(jié)果或把RDD數(shù)據(jù)寫(xiě)到存儲(chǔ)系統(tǒng)中抛猖；
Actions是觸發(fā)Spark啟動(dòng)計(jì)算的動(dòng)因
? Transformation（ 如：map, filter, groupBy, join等）
根據(jù)數(shù)據(jù)集創(chuàng)建一個(gè)新的數(shù)據(jù)集格侯，計(jì)算后返回一個(gè)新RDD；
Transformations操作是Lazy的
窄依賴和寬依賴
RDD數(shù)據(jù)模型 ：
把RDD當(dāng)簡(jiǎn)單元素的Transformation操作類別
? 輸入輸出一對(duì)一(element-wise)的算子财著，且結(jié)果RDD分區(qū)結(jié)構(gòu)不變
? 主要是map联四、flatMap等
? 輸入輸出一對(duì)一，但結(jié)果RDD的分區(qū)結(jié)構(gòu)發(fā)生了變化
? 如union（兩個(gè)RDD合為一個(gè)）撑教、coalesce（分區(qū)減少）
? 從輸入中選擇部分元素的算子
? 如filter朝墩、distinct、subtract和sample
針對(duì)Key-Value的Transformation操作類別
? 對(duì)單個(gè)RDD做element-wise運(yùn)算
? 如mapValues
? 對(duì)單個(gè)RDD重排
? 如sort伟姐、partitionBy
? 對(duì)單個(gè)RDD基于key進(jìn)行重組和reduce
? 如groupByKey收苏、reduceByKey
? 對(duì)兩個(gè)RDD基于key進(jìn)行join和重組
? 如join、cogroup
RDD數(shù)據(jù)模型
Spark 調(diào)度框架
Spark的分布部署方式
? Apache Spark支持三種分布式部署方式
? Standalone
? Spark on YARN
? Spark on mesos
? Standalone實(shí)現(xiàn)了容錯(cuò)性和資源管理
? 另外兩種實(shí)現(xiàn)了部分容錯(cuò)性和資源管理交由同一的資源管理系統(tǒng)完成
Standalone模式
? 可單獨(dú)部署到一個(gè)集群中愤兵，無(wú)需依賴任何其他資源管理系統(tǒng)
? Spark在standalone模式下是沒(méi)有任何單點(diǎn)故障問(wèn)題的鹿霸，這是借助zookeeper實(shí)現(xiàn)的
? Spark standalone與MapReduce架構(gòu)比較
? 都是由master/slaves服務(wù)組成的
? 各個(gè)節(jié)點(diǎn)上的資源被抽象成粗粒度的slot，有多少slot就能同時(shí)運(yùn)行多少task
Spark On Mesos
? 官方推薦模式秆乳，Spark運(yùn)行在Mesos上會(huì)比運(yùn)行在YARN上更加靈活懦鼠，更加自然
? 兩種調(diào)度模式：粗粒度和細(xì)粒度
? 粗粒度模式（Coarse-grained Mode）
? 每個(gè)應(yīng)用程序的運(yùn)行環(huán)境由一個(gè)Dirver和若干個(gè)Executor組成
? 每個(gè)Executor占用若干資源钻哩，內(nèi)部可運(yùn)行多個(gè)Task
? 應(yīng)用程序運(yùn)行之前，申請(qǐng)好全部資源肛冶，運(yùn)行結(jié)束后街氢，回收這些資源
? 細(xì)粒度模式（Fine-grained Mode）
? 思想是按需分配
? 啟動(dòng)executor，但每個(gè)executor占用資源僅僅是自己運(yùn)行所需的資源
? mesos會(huì)為每個(gè)executor動(dòng)態(tài)分配資源
? 單個(gè)Task運(yùn)行完之后可以馬上釋放對(duì)應(yīng)的資源
? 每個(gè)Task會(huì)匯報(bào)狀態(tài)給Mesos slave和Mesos Master
Spark On Yarn模式
多進(jìn)程VS多線程
? MapReduce采用了多進(jìn)程模型睦袖，便于細(xì)粒度控制每個(gè)任務(wù)占用的資源珊肃，但會(huì)消耗較多的啟動(dòng)時(shí)間
? Spark同節(jié)點(diǎn)上的任務(wù)以多線程的方式運(yùn)行在一個(gè)JVM進(jìn)程中
? 多線程好處
? 任務(wù)啟動(dòng)速度快
? 有利于共享內(nèi)存, 非常適合內(nèi)存密集型任務(wù)
? 避免了每個(gè)任務(wù)重復(fù)申請(qǐng)資源帶來(lái)的時(shí)間開(kāi)銷
? 不足
? 會(huì)出現(xiàn)嚴(yán)重的資源爭(zhēng)用，難以細(xì)粒度控制每個(gè)任務(wù)占用資源
MapReduce多進(jìn)程模型
? 每個(gè)Task運(yùn)行在一個(gè)獨(dú)立的JVM進(jìn)程中
? 可單獨(dú)為不同類型的Task設(shè)置不同的資源量馅笙，目前支持內(nèi)存和CPU兩種資源
? 每個(gè)Task都要經(jīng)歷“申請(qǐng)資源—> 運(yùn)行Task –> 釋放資源”的過(guò)程
Spark多線程模型
? 每個(gè)節(jié)點(diǎn)上可以運(yùn)行一個(gè)或多個(gè)Executor服務(wù)
? 每個(gè)Executor配有一定數(shù)量的slot
? 每個(gè)Executor單獨(dú)運(yùn)行在一個(gè)JVM進(jìn)程中伦乔，每個(gè)Task則是運(yùn)行在Executor中的一個(gè)線程
? 同一個(gè)Executor內(nèi)部的Task可共享內(nèi)存
? 將Spark運(yùn)行在Hadoop上，本質(zhì)上是將Spark運(yùn)行在Hadoop YARN上
? 之所以不采用Mesos而是YARN延蟹，是因?yàn)閅ARN擁有強(qiáng)大的社區(qū)支持评矩，且逐步已經(jīng)成為資源管理系統(tǒng)中的標(biāo)準(zhǔn)
spark-shell 是一個(gè)spark application，運(yùn)行時(shí)需要向資源管理器申請(qǐng)資源
Spark Standalone Mode的運(yùn)行
? 資源調(diào)度
? Spark Standalone Cluster支持FIFO方式調(diào)度阱飘，不過(guò)，允許多個(gè)并發(fā)用戶
? 監(jiān)控和日志
? 通過(guò)Web UI來(lái)監(jiān)控集群
? 日志：$SPARK_HOME/spark/logs
? 和Hadoop并用
? Spark可以作為獨(dú)立的服務(wù)虱颗，在已有的Hadoop集群設(shè)備上并行沥匈，并通過(guò)hdfs://URL存取Hadoop數(shù)據(jù)
Spark優(yōu)勢(shì)
1、 克服MR在迭代式計(jì)算和交互式計(jì)算方面的不足
2忘渔、 引入RDD（Resilient Distributed DataSets）數(shù)據(jù)表示模型
3高帖、 RDD是一個(gè)有容錯(cuò)機(jī)制，可以被并行操作的數(shù)據(jù)集合畦粮，能夠被緩存到內(nèi)存或磁盤(pán)上散址。
基于Spark on Yarn 的淘寶數(shù)據(jù)挖掘平臺(tái)
Spark On Yarn
與MR Tez 非常類似
1、 通過(guò)Yarn-Spark客戶端Client提交 Spark Submission Spark Application 提交至Resources Manager
2宣赔、 Resources Manager找到程序主類和資源需求之后為Application Master申請(qǐng)資源
3预麸、 申請(qǐng)資源之后與Node Manager發(fā)送命令啟動(dòng)Spark Application Master
4、 在 Spark Application Master內(nèi)部啟動(dòng)Spark Container 里面有一個(gè)Cluster Scheduler 和web UI
5儒将、 啟動(dòng)之后Application Master向Resource Manager申請(qǐng)資源吏祸，然后向Node Manager發(fā)出命令，啟動(dòng)Spark作業(yè)的Executor（StandaloneExecutorBackend）钩蚊，Executor里會(huì)有 很多Task贡翘，Cluster Scheduler向Executor調(diào)度很多Task執(zhí)行，執(zhí)行完成之后砰逻，Spark作業(yè)執(zhí)行完畢鸣驱。
Hbase On Yarn ： Hoya hortonworks
Impala On Yarn：LLAMA
Kafka On Yarn：kafka-yarn kkasravi
MapReduce2.0 & Yarn
一個(gè)MR應(yīng)用程序的成功運(yùn)行需要若干個(gè)模塊：
1、 任務(wù)管理（由各個(gè)應(yīng)用程序管理）和資源調(diào)度（每個(gè)應(yīng)用程序都需要蝠咆，Yarn統(tǒng)一管理）
2踊东、 任務(wù)驅(qū)動(dòng)模塊 MapTask ReduceTask
3、 用戶代碼 Mapper Reducer
Yarn是一個(gè)資源管理系統(tǒng)，只負(fù)責(zé)資源管理和調(diào)度递胧，MapReduce只是運(yùn)行在Yarn上的一個(gè)應(yīng)用程序碑韵，Yarn 對(duì)比于 Android MapReduce只是一個(gè) app
MapReduce2.0組成：
Yarn（整個(gè)集群只有一個(gè)）Spark可以用、Storm也可以用 公用模塊
MRAppMaster 一個(gè)應(yīng)用程序一個(gè)
用戶代碼Mapper Reducer
MapReduce 1.0 與 MapReduce2.0區(qū)別：
MapReduce1.0是一個(gè)獨(dú)立的系統(tǒng)缎脾，直接運(yùn)行在Linux之上
MapReduce2.0是運(yùn)行在Yarn上的計(jì)算框架祝闻，且可與多種框架同時(shí)一起運(yùn)行在Yarn上。
2.0沒(méi)有JobTracker 遗菠、 TaskTracker 這樣的服務(wù) 必須依托于Yarn來(lái)運(yùn)行
