Yarn
Yarn產(chǎn)生背景：
Yarn直接來自于MR1.0
MR1.0 問題：采用的是master slave結(jié)構(gòu)，master是JobTracker。Slave是TaskTracker、JobTracker整個集群只有一個，構(gòu)建調(diào)度和資源管理，兩個功能。每個節(jié)點上，可以通過一個TaskTracker控制本節(jié)點的資源管理和任務(wù)管理。每個TaskTracker通過心跳機制周期性的向JobTracker發(fā)送本節(jié)點的資源使用情況以及任務(wù)運行狀態(tài)，JobTracker會通過心跳應(yīng)答將新的命令或者任務(wù)發(fā)送至TaskTracker。
1、 JobTracker是一個性能瓶頸，既負(fù)責(zé)資源管理有負(fù)責(zé)作業(yè)調(diào)度，實際上，資源管理是所有的計算框架共有的一個模塊，不能將其寄宿在某一個特殊的計算框架中，另，作業(yè)調(diào)度模塊是與應(yīng)用層相關(guān)的，與通用的資源管理模塊分開。
2、 JobTracker是一個單點故障，一旦出現(xiàn)宕機，整個集群將無法正常使用，
3、 只支持Map Reduce這一種計算模型，如果希望支持Map-reduce-reduce這種計算框架，無法支持，需要修改JobTracker。
4、 MRv1.0 擴展性差、可靠性差、資源利用率低（MRv1采用了基于槽位的資源分配模型，槽位是一種粗粒度的資源劃分單位；通常一個任務(wù)不會用完槽位對應(yīng)的資源，且其他任務(wù)也無法使用這些空閑資源，無法支持多種計算框架）
Yarn安裝常見問題：
1、 運行APP時內(nèi)存不足：確保yarn-site.xml文件中的yarn.scheduler.maximum-allocation-mb參數(shù)大于mapred-site.xml中的yarn.app.mapreduce.am.resource.mb參數(shù)
2、 無法加載本地hadoop庫：
WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platform
如果要使用native library，只能從Hadoop源碼重新編譯生成binary安裝文件
只是想不輸出這個WARN信息的話，在core-site.xml中配置hadoop.native.lib的值為false即可
重新編譯方法：http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/NativeLibraries.html
Yarn產(chǎn)生背景-資源利用率
不同計算框架所在集群其資源利用率不均衡，導(dǎo)致整體的資源利用率很低。
引入中間層（資源管理層），管理所有節(jié)點上的資源，框架在使用之前首先申請資源，然后運行自己內(nèi)部的作業(yè)和任務(wù) ，通過引入資源管理層，可以有效解決資源利用率的問題，將公司的各種集群整合為一個大的集群，非常方便管理。
Yarn產(chǎn)生背景-運維成本：
如果采用 一個框架一個集群 的模式，則可能需要多個管理員管理這些集群，增加運維成本，共享模式通常需要少數(shù)管理員即可完成多個框架的統(tǒng)一管理。
Yarn產(chǎn)生背景-數(shù)據(jù)共享：
隨著數(shù)據(jù)量的暴增，跨集群間的數(shù)據(jù)移動不僅花費更多時間，硬件成本也會更大，共享集群模式可讓更多框架共享數(shù)據(jù)和硬件資源，將大大減小數(shù)據(jù)移動帶來的成本。
產(chǎn)生背景-總結(jié)：
源于MR1.0的缺陷：單點故障 性能瓶頸 擴展性受限 難以支持MR以外的計算
多計算框架各自為戰(zhàn)，數(shù)據(jù)共享困難：MR 離線計算框架 Storm實時計算框架 Spark 內(nèi)存計算框架
編程模型對比
第一代MR框架：編程模型
第二代框架：編程模型
編程模型對比：
為保證編程模型的向下兼容性，MRv2重用了MRv1中的編程模型和數(shù)據(jù)處理引擎，但運行環(huán)境被完全重寫
編程模型與數(shù)據(jù)處理引擎：
MapReduce應(yīng)用程序編程接口有兩套：新API（mapred）和舊API（mapreduce）
1、 采用MRv1舊API編寫的程序可直接運行在MRv2上；
2、 采用MRv1新API編寫的程序需要使用MRv2編程庫重新編譯并修改不兼容的參數(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 整個集群只有一個，一個可靠的節(jié)點。
1、 每個節(jié)點上可以負(fù)責(zé)該節(jié)點上的資源管理以及任務(wù)調(diào)度，Node Manager 會定時向Resource Manager匯報本節(jié)點上 的資源使用情況和任務(wù)運行狀態(tài)，
2、 Resource Manager會通過心跳應(yīng)答的機制向Node Manager下達(dá)命令或者分發(fā)新的任務(wù)，
3、 Yarn 將某一資源分配給該應(yīng)用程序后，應(yīng)用程序會啟動一個Application Master，
4、 Application Master為應(yīng)用程序負(fù)責(zé)向Resource Manager申請資源，申請資源之后，再和申請到的節(jié)點進(jìn)行通信，運行內(nèi)部任務(wù)。
兩層調(diào)度：
1、 第一層是Yarn中Resource Manager將資源分配（Driver Application Master所需要的資源）給各應(yīng)用程序，
2、 第二層是應(yīng)用程序（Application Master啟動后，向Resource Manager申請Container資源，即Executor運行所需要的資源）申請資源成功，ResourceManager將資源分配給內(nèi)部的各種任務(wù)，在對應(yīng)的節(jié)點上啟動Container以運行Application Master分發(fā)過來的任務(wù)。
Yarn中，任務(wù)會運行在Container的一個容器內(nèi)，封裝的是整個任務(wù)的運行環(huán)境，比如CPU、內(nèi)存等環(huán)境變量封裝在container中，在container中運行。
ResourceManager
全局資源管理器，整個集群只有一個，負(fù)責(zé)集群資源的統(tǒng)一調(diào)度和任務(wù)管理
主要由兩個組件構(gòu)成：資源調(diào)度器 Resource Scheduler 和應(yīng)用程序管理器(Applications Master -- ASM)
調(diào)度器：
1、 調(diào)度器根據(jù)容量、隊列等限制條件，將系統(tǒng)中的資源分配給各個正在運行的應(yīng)用程序
2、 不負(fù)責(zé)具體應(yīng)用程序的相關(guān)工作，比如監(jiān)控或跟蹤狀態(tài)
3、 不負(fù)責(zé)重新啟動失敗任務(wù)
4、 資源分配單位用“資源容器”（Resource Container）表示
5、 Container是一個動態(tài)資源分配單位，它將內(nèi)存、CPU、磁盤、網(wǎng)絡(luò)等資源封裝在一起，從而限定每個任務(wù)的資源量
6、 調(diào)度器是一個可拔插的組件，用戶可以自行設(shè)計
7、 Yarn提供了多種直接可用的調(diào)度器，比如Fair Scheduler、Capacity Scheduler等
應(yīng)用程序管理器：
負(fù)責(zé)管理整個系統(tǒng)的所有應(yīng)用程序
ResourceManager詳細(xì)功能：
1、 處理客戶端請求，
2、 啟動/監(jiān)控Application Master（每個應(yīng)用程序有一個，每個應(yīng)用程序的master負(fù)責(zé)該應(yīng)用程序的資源申請，任務(wù)調(diào)度，任務(wù)容錯等），
3、 監(jiān)控Node Manager（如果一個節(jié)點掛了，Resource Manager會將運行在該Node Manager上的任務(wù)通知Application master，讓application master觸發(fā)新的調(diào)度或者其他操作，），
4、 資源分配與調(diào)度。（集群中所有節(jié)點的資源統(tǒng)籌靈活的智能的分配給各個應(yīng)用程序）
Application Matser
用戶提交的每個應(yīng)用程序只有一個，負(fù)責(zé)應(yīng)用程序的管理
AM主要功能：
1、 與RM調(diào)度器協(xié)商以獲取資源（用Container表示）
2、 將得到的任務(wù)進(jìn)一步分配給內(nèi)部的任務(wù)
3、 與NM通信以啟動/停止任務(wù)
4、 監(jiān)控所有任務(wù)運行狀態(tài)，并在任務(wù)運行失敗時重新為任務(wù)申請資源以重啟任務(wù)
5、 YARN自帶的AM實現(xiàn)：一個用于演示AM編寫方法的示例程序distributedshell
詳細(xì)功能：
1、 數(shù)據(jù)切分，
2、 為應(yīng)用程序申請資源，并進(jìn)一步分配給內(nèi)部任務(wù)，
3、 任務(wù)監(jiān)控與容錯
Node Manager
整個集群有多個，負(fù)責(zé)單節(jié)點資源管理和使用，每個節(jié)點上的資源和任務(wù)管理器
詳細(xì)功能：
1、 定時向RM匯報本節(jié)點上的資源使用情況和各個Container的運行狀態(tài)
2、 單個節(jié)點上的資源管理和任務(wù)管理
3、 處理來自Resource Manager的命令（殺死任務(wù)或重啟節(jié)點等）
4、 處理來自Application Master的命令（啟動task等命令）
Container
是Yarn中的資源抽象，封裝了某個節(jié)點上的多維度資源，對任務(wù)運行環(huán)境的抽象
Yarn會為每個任務(wù)分配一個Container，且該任務(wù)只能使用該Container中描述的資源
Container不同于MRv1中的slot，是一個動態(tài)資源劃分單位，是根據(jù)應(yīng)用程序的需求動態(tài)生成的。
描述一系列信息：
1、 任務(wù)運行資源（節(jié)點、內(nèi)存、CPU），任務(wù)執(zhí)行在哪個節(jié)點，占用多少內(nèi)存，多少CPU
2、 任務(wù)啟動命令，
3、 任務(wù)運行環(huán)境，
4、 當(dāng)Yarn把一個資源（管理資源）2G內(nèi)存，一個CPU分配給一個應(yīng)用程序的時候，將運行資源的描述封裝為一個container，發(fā)送給Application master，application master根據(jù)資源的特點將資源分配給內(nèi)部的某一個task，之后再與node manager通信啟動container，進(jìn)而啟動task。
Yarn通信協(xié)議：
1、 RPC協(xié)議是連接各個組件的“大動脈”
2、 Yarn 采用的是拉式（pull-based）通信模型
3、 任何兩個需要相互通信的組件之間只有一個RPC協(xié)議
4、 對于任何一個RPC協(xié)議，通信雙方有一端是Client，另一端為Server，且Client總是主動連接Server的。
Yarn主要由以下幾個RPC協(xié)議組成：
1、 ApplicationClientProtocol：JobClient通過該RPC協(xié)議提交應(yīng)用程序、查詢應(yīng)用程序狀態(tài)等。
2、 ResourceManagerAdministratorProtocol：Admin通過該RPC協(xié)議更新系統(tǒng)配置文件，比如節(jié)點黑白名單，用戶隊列權(quán)限等
3、 ApplicationMasterProtocol：AM通過該RPC協(xié)議向RM注冊和撤銷自己，并為各個任務(wù)申請資源
4、 ContainerManagerProtocol：AM通過該RPC要求NM啟動或者停止Container，獲取各個Container的使用狀態(tài)等信息。
5、 ResourceTracker：NM通過該RPC協(xié)議向RM注冊，并定時發(fā)送心跳信息匯報當(dāng)前節(jié)點的資源使用情況和Container運行情況。
Yarn工作流程：
運行Yarn的應(yīng)用程序有兩類：短應(yīng)用程序和長應(yīng)用程序。
短應(yīng)用程序
指在一定時間內(nèi)可以運行完成并正常退出的應(yīng)用程序，比如MR作業(yè)
長應(yīng)用程序
是指不出意外，永不終止運行的應(yīng)用程序，通常是一些服務(wù)，Storm Service，HBase Service等。
當(dāng)用戶向Yarn提交一個應(yīng)用程序后，Yarn將分兩步執(zhí)行該應(yīng)用程序：首先啟動Application Master，然后由Application Master啟動應(yīng)用程序。
從并行編程的角度理解YARN
為快速處理一個大數(shù)據(jù)集，通常采用多線程并行編程
Yarn-總結(jié)資源管理系統(tǒng)：
對集群中各類資源進(jìn)行抽象；按照一定的策略，將資源分配給應(yīng)用程序或服務(wù)；采用一定的隔離機制防止應(yīng)用程序或者服務(wù)之間因資源搶占而相互干擾
引入YARN這一層后，各種計算框架可各自發(fā)揮自己的優(yōu)勢，并由YARN進(jìn)行統(tǒng)一管理。
云計算概念與Yarn：
三層服務(wù)：Infrastructure As A Service IaaS、PaaS和SaaS
1、 IaaS：基礎(chǔ)設(shè)施即服務(wù)。消費者通過Internet可以從完善的計算機基礎(chǔ)設(shè)施獲得服務(wù)
2、 PaaS：平臺即服務(wù)。PaaS是將軟件研發(fā)的平臺作為一種服務(wù)，以SaaS的模式提交給用戶
3、 SaaS：軟件即服務(wù)。 它是一種通過Internet提供軟件的模式，用戶無需購買軟件，而是向提供商租用基于Web的軟件，來管理企業(yè)經(jīng)營活動
YARN可以看作PaaS層，它能夠為不同類型的應(yīng)用程序提供統(tǒng)一的管理和調(diào)度
Yarn 運行過程剖析
（以下默認(rèn)為Yarn-Cluster模式）
- 用戶通過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端所需資源）通過調(diào)度器為Application Master尋找到匹配的資源，找到滿足條件的Node后，ResourceManager 發(fā)送命令給Node Manager，告訴Node Manager 需要多少資源以及CPU，要求其啟動Application Master進(jìn)程。（在集群中選擇一個滿足Driver資源請求的節(jié)點啟動Application Master進(jìn)程。）
- Node Manager在相應(yīng)的節(jié)點上啟動Application master。
- 應(yīng)用程序內(nèi)部的邏輯，若是Map-Reduce Application master應(yīng)用程序，Application master將作業(yè)按照數(shù)據(jù)切分為一個一個的Map和Reduce,之后匯總Map和Reduce總的需求（若是Spark Application Master，將Spark Job切分為跟多Stage，每個Stage會有很多Task，），然后和Resource Manager進(jìn)行通信，根據(jù)應(yīng)用提交時所指定的executor資源要求，通過心跳機制向Resource Manager申請資源，Resource Manager根據(jù)當(dāng)前節(jié)點的資源使用情況給Application Master分配資源（這些資源是一個動態(tài)分配過程），通過心跳應(yīng)答將在相應(yīng)的節(jié)點的資源分配給應(yīng)用程序。
- Application Master 根據(jù)Resource Manager分配給其的Executor 資源當(dāng)前任務(wù)的需求，與對應(yīng)的節(jié)點Node Manager進(jìn)行通信，啟動一個Task，
- Node Manager根據(jù)Application Master的描述（比如啟動命令、需要的外部jar包、環(huán)境變量是什么？），在已分配資源的相應(yīng)的Node上啟動這一任務(wù)，以container形式封裝這些任務(wù)。
Yarn容錯性
1、 ResourceManager：存在單點故障，但Zookeeper實現(xiàn)HA BakMaster
2、 NodeManager：
a. 失敗后，NM通過心跳將失敗任務(wù)的情況告訴RM，RM將失敗后任務(wù)告訴對應(yīng)的AM；
b. AM決定如何處理失敗的任務(wù)（大數(shù)據(jù)應(yīng)用場景下 有些任務(wù)的失敗 可以考慮丟棄）
3、 ApplicationMaster：
a. 失敗后，由RM負(fù)責(zé)重啟；
b. AM需處理內(nèi)部任務(wù)的容錯問題
4、 RMAPPMaster 會保存已經(jīng)運行完成的Task，重啟后無需重新運行。
Yarn 調(diào)度框架
雙層調(diào)度框架
1、 RM將資源分配給AM
2、 AM收到RM分配的資源后，根據(jù)資源的特點和任務(wù)的情況采用相關(guān)的調(diào)度策略進(jìn)一步分配給各個Task
基于資源預(yù)留的調(diào)度策略
1、 資源不夠時，會為Task預(yù)留，直到資源充足（犧牲資源利用率）
2、 與“all or nothing”策略不同（Apache Mesos 要么給他 要么不給他你 產(chǎn)生餓死情況）
Yarn資源調(diào)度器 --
多類型資源調(diào)度
1、 可以對多種類型的資源進(jìn)行調(diào)度，不同于MR1.0 基于slot進(jìn)行的調(diào)度
2、 將多維度的資源抽象為一維度的slot
3、 資源調(diào)度的過程就是把slot資源分配給Task的過程，
Yarn的調(diào)度資源
1、 直接調(diào)度的是CPU和內(nèi)存以及網(wǎng)絡(luò)資源，沒有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)度器對比：
? FifoScheduler
? 最簡單的調(diào)度器，按照先進(jìn)先出的方式處理應(yīng)用
? CapacityScheduler
? FifoScheduler的多隊列版本，每個隊列可以限制資源使用量
? 隊列間的資源分配以使用量作排列依據(jù)，使得容量小的隊列有競爭優(yōu)勢
? 使得hadoop應(yīng)用能夠被多用戶使用，且最大化整個集群資源的吞吐量
? 啟動容量調(diào)度器之后，調(diào)度器會從classpath中加載capacity-scheduler.xml文件，完成容量調(diào)度器的初始化
? FairScheduler
? 多隊列，多用戶共享資源。使得hadoop應(yīng)用能夠被多用戶公平地共享整個集群資源的調(diào)度器
? 根據(jù)隊列設(shè)定的最小共享量或者權(quán)重等參數(shù)，按比例共享資源
調(diào)度器的集群配置：
容量調(diào)度器參數(shù)定義和計算關(guān)系：
? 隊列容量=yarn.scheduler.capacity.<queue-path>.capacity/100
? 隊列絕對容量=父隊列的 隊列絕對容量隊列容量
? 隊列最大容量=yarn.scheduler.capacity.<queue-path>.maximum-capacity/100
? 隊列絕對最大容量=父隊列的 隊列絕對最大容量隊列最大容量
? 絕對資源使用比=使用的資源/全局資源
? 資源使用比=使用的資源/(全局資源 * 隊列絕對容量)
? 最小分配量=yarn.scheduler.minimum-allocation-mb
? 用戶上限=MAX(yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent,1/隊列用戶數(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隊列絕對容量)
? 單用戶最大提交應(yīng)用=最大提交應(yīng)用(用戶上限/100)用戶調(diào)整因子
? AM資源占比（AM可占用隊列資源最大的百分比)
? =yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent
? 如果為空，設(shè)置為yarn.scheduler.capacity.maximum-am-resource-percent
? 最大活躍應(yīng)用數(shù)量=全局總資源/最小分配量AM資源占比隊列絕對最大容量
? 單用戶最大活躍應(yīng)用數(shù)量=(全局總資源/最小分配量AM資源占比隊列絕對容量)用戶上限*用戶調(diào)整因子
? 本地延遲分配次數(shù)=yarn.scheduler.capacity.node-locality-delay<code>
多租戶資源調(diào)度器
1、 支持資源按比例分配
2、 支持層級隊列劃分方式（樹形結(jié)構(gòu)）
3、 支持資源搶占
資源分配模型：
Yarn 資源隔離方案
Yarn通過Resource Manager為應(yīng)用分配資源，Node Manager獲得相應(yīng)的資源在其節(jié)點上執(zhí)行Task，NodeManager 有責(zé)任為Task提供一個隔離的環(huán)境。
否咋，節(jié)點上所有的Task都在競爭資源，性能降低，服務(wù)質(zhì)量得不到保證。
支持CPU和內(nèi)存的兩種資源隔離
1、 內(nèi)存是一種決定生死的資源
2、 Cpu是一種影響快慢的資源
內(nèi)存隔離：
1、 基于線程監(jiān)控的方案：在每個節(jié)點上啟動一個監(jiān)控線程以對內(nèi)存的訪問和使用進(jìn)行監(jiān)控。一旦內(nèi)存的資源使用量超過了其所申請的資源量，其將被殺死。
2、 基于Cgroups的方案：
CPU隔離：
1、 默認(rèn)不對CPU資源進(jìn)行隔離：yarn將cpu的資源分配交給node manager所在的操作系統(tǒng)，由os對cpu資源進(jìn)行分配，
2、 基于Cgroups的方案：需要配置 默認(rèn)沒有打開
Yarn支持的調(diào)度語義：
應(yīng)用程序向yarn申請資源時，向Yarn表達(dá)出所需資源的方式所需的格式及相關(guān)標(biāo)準(zhǔn)，成為調(diào)度語義。申請資源、歸還資源
支持的語義：
1、 請求某個特定節(jié)點/機架上的特定資源量
2、 將某些節(jié)點加入或移除黑名單，不再為自己分配這些節(jié)點上的資源（可能某個節(jié)點不適合運行某種任務(wù)）
3、 請求歸還這些資源
不支持的語義：
1、 請求任意節(jié)點/機架上的特定資源量
2、 請求一組或幾組符合某種特質(zhì)的資源
3、 超細(xì)粒度資源
4、 動態(tài)調(diào)整Container資源（目前支持）
框架運行在Yarn上的好處：
1、 應(yīng)用程序部署變得更簡單：只需部署YARN服務(wù)，各類應(yīng)用不再自帶服務(wù)
2、 服務(wù)部署變得更簡單：用戶可以運行一個應(yīng)用程序的方式部署一套服務(wù)
3、 多版本共享集群資源：Cgroups隔離機制
4、 資源彈性管理：YARN可根據(jù)不同類型的應(yīng)用程序壓力情況，調(diào)整對應(yīng)的資源使用量，實現(xiàn)資源彈性管理
Yarn上的計算框架
Yarn主要的使用是運行高級 的計算框架，不是用戶寫一個程序直接與yarn交互，這種情況很少出現(xiàn)。直接與計算框架交互，將計算框架與yarn交互，用戶與計算框架進(jìn)行交互，應(yīng)用程序種類繁多，每種應(yīng)用程序類型都對應(yīng)一種計算框架，
Map map-reduce spark（stage） stage - DAG圖
Yarn設(shè)計目標(biāo)
通用的統(tǒng)一資源管理系統(tǒng)：同時運行長應(yīng)用程序和短應(yīng)用程序，
1、 長應(yīng)用程序：通常情況下，永不停止運行的程序 service Http Server
2、 短應(yīng)用程序：短時間 秒級 分鐘級 小時級 內(nèi)會結(jié)束運行的程序 MR Job Spark Job
以Yarn為核心的生態(tài)系統(tǒng)
在Yarn之上的，以MR為代表批處理應(yīng)用程序 交互式的Tez 在線online的Hbase
流處理 Storm Graph 圖計算框架 Spark內(nèi)存計算框架
運行在Yarn上的計算框架：
Map-Reduce 離線計算框架
Tez：DAG計算框架
Storm：流式計算框架
內(nèi)存計算框架：Spark
離線計算框架Map Reduce：
將計算過程分為兩個階段：Map和Reduce
Map階段并行處理輸入數(shù)據(jù)
Reduce階段對Map結(jié)果進(jìn)行匯總
Shuffle連接Map和Reduce兩個階段
Map Task將數(shù)據(jù)寫到本地磁盤
Reduce Task從每個Map Task上讀取一份數(shù)據(jù)
僅適合離線批處理
具有很好的容錯性和擴展性
適合簡單地批處理任務(wù)
缺點明顯：啟動開銷大、過多使用磁盤導(dǎo)致效率低下等
MapReduce On Yarn
- Client提交MR應(yīng)用程序至Yarn的Resource Manager的Applications Manager，
- Resource Manager的Applications Manager收到請求后找到一個節(jié)點Node Manager啟動Application Master（MR APP Mstr MapReduce中已經(jīng)實現(xiàn)好了），
- Application Master啟動成功后，會根據(jù)輸入數(shù)據(jù)的大小，將應(yīng)用程序切分為很多的MapTask 和Reduce Task，
- Application Master向Resource Manager的Resource Scheduler發(fā)送請求資源信息，，根據(jù)Task所需申請
- Resource Manager的Resource Scheduler會根據(jù)當(dāng)前資源的使用情況和任務(wù)狀態(tài)進(jìn)行資源的分配，產(chǎn)生一個心跳應(yīng)答，動態(tài)的將資源分配給Application Master
- Application Master獲得資源后，發(fā)送消息給Node Manager啟動task
- Node Manager啟動Container封裝Task
- Node Manager的Task啟動后會向Application Master 發(fā)送心跳，維護(hù)一個心跳信息，Application Master 通過心跳信息監(jiān)控各個Task的運行狀態(tài)。如果一段時間內(nèi)未接收到相關(guān)Task的心跳信息，則認(rèn)為該Task掛了，重新為Task申請資源，運行Task
DAG計算框架Tez
多個作業(yè)之間存在數(shù)據(jù)依賴關(guān)系，并形成一個依賴關(guān)系有向圖（Directed Acyclic Graph），該圖的計算稱為“DAG計算”
Apache Tez：基于Yarn 的DAG計算框架
? 直接源于MapReduce框架，核心思想是將Map和Reduce兩個操作進(jìn)一步拆分
? Map被拆分成Input、Processor、Sort、Merge和Output
? Reduce被拆分成Input、Shuffle、Sort、Merge、Processor和Output
? 分解后的元操作可以任意靈活組合，產(chǎn)生新的操作，這些操作經(jīng)過一些控制程序組裝后，可形成一個大的DAG作業(yè)
? 天生融入Hadoop 2.0中的資源管理平臺YARN
? Tez主要由兩部分組成
? 數(shù)據(jù)處理引擎
? DAGAppMaster
Tez數(shù)據(jù)處理引擎：
? Tez提供了6中可編程組件，實現(xiàn)了一些常見的算法和組件
? Input：對輸入數(shù)據(jù)源的抽象，類似于MR模型中的InputFormat，它解析輸入數(shù)據(jù)格式，并吐出一個個Key/value
? Output：對輸出數(shù)據(jù)源的抽象，類似于MR模型中的OutputFormat，它將用戶程序產(chǎn)生的Key/value寫入文件系統(tǒng)
? Partitioner：對數(shù)據(jù)進(jìn)行分片，類似于MR中的Partitioner
? Processor：對計算單元的抽象，它從一個Input中獲取數(shù)據(jù)，經(jīng)用戶定義的邏輯處理后，通過Output輸出到文件系統(tǒng)
? Task：對任務(wù)的抽象，每個Task由一個Input、Ouput和Processor組成
? Maser：管理各個Task的依賴關(guān)系，并按照依賴關(guān)系執(zhí)行他們
? Tez數(shù)據(jù)處理引擎實現(xiàn)了一些常見的組件
? Tez數(shù)據(jù)處理引擎的基礎(chǔ)是Sort（排序）和Shuffle（混洗）
? Tez提供了多種Input、Output、Task和Sort的實現(xiàn)
? Input實現(xiàn)
LocalMergedInput（多個文件本地合并后作為輸入）
ShuffledMergedInput（遠(yuǎn)程拷貝數(shù)據(jù)且合并后作為輸入）
? Output實現(xiàn)
InMemorySortedOutput（內(nèi)存排序后輸出）
LocalOnFileSorterOutput（本地磁盤排序后輸出）OnFileSortedOutput（磁盤排序后輸出）
? Task實現(xiàn)
RunTimeTask
? Sort實現(xiàn)
DefaultSorter（本地數(shù)據(jù)排序）
InMemoryShuffleSorter（遠(yuǎn)程拷貝數(shù)據(jù)并排序）
Tez On Yarn 優(yōu)勢：
1、 運行在Yarn之上，充分利用Yarn的資源管理和容錯等功能
2、 提供了豐富的數(shù)據(jù)流 dataflow api
3、 擴展性良好的 Input-Processor-Output 運行時模型
4、 動態(tài)生成物理數(shù)據(jù)流關(guān)系
啟動的不是Application Master 而是 DAG APlication Master
Tez Application Master
? Tez ApplicationMaster直接源于MapReduce的ApplicationMaster，重用了大部分機制和代碼
? 功能
? 數(shù)據(jù)切分和作業(yè)分解
? 任務(wù)調(diào)度
? 與ResourceManager進(jìn)行通信，為DAG作業(yè)申請資源
? 與NodeManager進(jìn)行通信，啟動DAG作業(yè)中的任務(wù)
? 監(jiān)控DAG作業(yè)的運行過程，確保它快速運行結(jié)束
? 每個DAGAppMaster負(fù)責(zé)管理一個DAG作業(yè)
? DAGAppMaster優(yōu)先為那些不依賴任何頂點的任務(wù)申請資源
? DAG中的一個頂點由一定數(shù)目的任務(wù)組成
? 一旦一個頂點中所有任務(wù)運行完成，則認(rèn)為該頂點運行結(jié)束
Tez優(yōu)化技術(shù)
1、 如果每個作業(yè)都啟動一個Application Master，性能將會很低。
2、 Application Master緩沖池：作業(yè)提交到AMPoolServer服務(wù)上，預(yù)啟動若干個Application Master，形成一個Application Master緩沖池
3、 預(yù)先啟動Container：Application Master啟動時可以預(yù)先啟動若干個Container
Container重用：
任務(wù)運行完成后，Application Master不會馬上注銷所使用的Container，而是將它重新分配給其他未運行的任務(wù)。
Tez應(yīng)用場景：
1、 直接編寫應(yīng)用程序
2、 Tez提供一套通用編程接口
3、 適合編寫有依賴關(guān)系的作業(yè)
4、 優(yōu)化Pig、Hive等引擎->
5、 下一代Hive Stinger
好處1：避免查詢語句轉(zhuǎn)換成過多的MR作業(yè)后產(chǎn)生大量不必要的網(wǎng)絡(luò)和磁盤IO
好處2：更加智能的任務(wù)處理引擎
Tez與其他系統(tǒng)對比
? 與Oozie對比
? Oozie是工作流調(diào)度系統(tǒng)，按照用戶定義好的作業(yè)依賴關(guān)系調(diào)度作業(yè)
? Oozie只是一種作業(yè)依賴關(guān)系表達(dá)和調(diào)度框架，邏輯上并沒有將有依賴關(guān)系的作業(yè)合并成一個作業(yè)來優(yōu)化I/O讀寫
? 與MapReduce對比
? MapReduce只是一種簡單的數(shù)據(jù)處理模型
? Tez可以包含任意多個數(shù)據(jù)處理階段
? Tez可作為MapReduce之下的數(shù)據(jù)處理引擎
? Tez與MapReduce編程接口完全兼容
流式計算框架 Storm
1、 流式計算指的是被處理的數(shù)據(jù)像流水一樣不斷流入系統(tǒng)，而系統(tǒng)需要針對每條數(shù)據(jù)進(jìn)行實時處理和計算，并永不停止（直到用戶顯式殺死進(jìn)程）
2、 傳統(tǒng)做法：由消息隊列和消息處理者組成的實時處理網(wǎng)絡(luò)進(jìn)行實時計算，缺乏自動化，缺乏健壯性，伸縮性差
Storm典型應(yīng)用場景
1、 廣告；
2、 分布式rpc：由于storm的處理組件是分布式的，而且處理延遲極低，所以可以作為一個通用的分布式rpc框架來使用
360：Storm在實時網(wǎng)絡(luò)攻擊檢測和分析的應(yīng)用和改進(jìn) 集群規(guī)模：46個集群，9000個節(jié)點，每個結(jié)點2-4個slot 利用云存儲的空閑資源 應(yīng)用：50多個業(yè)務(wù)，100多個topology
實時日志統(tǒng)計、網(wǎng)頁分析、圖片處理、人臉識別、……..
每天處理約120TB 200億條
Stom 計算框架：
Master（Nimbus） 通過Zookeeper 與 slaves（Supervisor）進(jìn)行通信，master掛了，supervisor仍然可以重新工作，只是任務(wù)不可以重新提交作業(yè)，一個supervisor可以運行多個worker，一個worker可以運行多個executor，一個executor可以運行多個task。
每個應(yīng)用程序有一個spout 數(shù)據(jù)源（web 服務(wù)器，kafka），實時的將數(shù)據(jù)推送給blot（類似于map reduce），blot之間可以存在依賴關(guān)系。整個依賴關(guān)系稱之為topology
Hadoop MRv1.0 Storm
系統(tǒng)服務(wù) JobTracker(master) Nimbus(master Zookeeper)
TaskTracker(slave) Supervisor(slave)
Child(啟動Task) Worker(啟動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ù)，啟動和停止屬于自己管理的worker進(jìn)程
3、 Worker：運行具體處理組件邏輯的進(jìn)程
4、 Task：worker中每一個spout/bolt的線程稱為一個task。在storm0.8之后，task不再與物理線程對應(yīng)，同一個spout/bolt的task可能會共享一個物理線程，該線程稱為executor
5、 Topology：storm中運行的一個實時應(yīng)用程序；各個組件間的消息流動形成邏輯上的一個拓?fù)浣Y(jié)構(gòu)
6、 Spout：在一個topology中產(chǎn)生源數(shù)據(jù)流的組件；通常情況下spout會從外部數(shù)據(jù)源中讀取數(shù)據(jù)，然后轉(zhuǎn)換為topology內(nèi)部的源數(shù)據(jù)；Spout是一個主動的角色，其接口中有個nextTuple()函數(shù)，storm框架會不停地調(diào)用此函數(shù)，用戶只要在其中生成源數(shù)據(jù)即可
7、 Bolt：在一個topology中接受數(shù)據(jù)然后執(zhí)行處理的組件；Bolt可以執(zhí)行過濾、函數(shù)操作、合并、寫數(shù)據(jù)庫等任何操作；Bolt是一個被動的角色，其接口中有個execute(Tupleinput)函數(shù),在接受到消息后會調(diào)用此函數(shù)，用戶可以在其中執(zhí)行自己想要的
8、 Tuple：一次消息傳遞的基本單元；本來應(yīng)該是一個key-value的map，但是由于各個組件間傳遞的tuple的字段名稱已經(jīng)事先定義好，所以tuple中只要按序填入各個value就行了，所以就是一個value list
9、 Stream：源源不斷傳遞的tuple就組成了stream
10、 stream grouping：即消息的partition方法；Storm中提供若干種實用的grouping方式，包括shuffle, fields hash, all, global, none, direct和localOrShuffle等
Storm On Yarn
運行的不是短作業(yè) 而是服務(wù) ，將master和slave運行在Storm Application Master上，通過Yarn將Nimbus和Supervisor部署在Yarn集群中，部署之后，Strom的client可以直接連接Storm Application Master 里的Nimbus，使用一個普通的Storm集群一樣使用Storm，該Storm是通過Yarn啟動，
? Storm ApplicationMaster初始化時，將在同一個Container中啟動Storm Nimbus和Storm Web UI兩個服務(wù)
? 根據(jù)待啟動的Supervisor數(shù)目向ResourceManager申請資源
? ApplicationMaster將請求一個節(jié)點上所有資源然后啟動Supervisor服務(wù)，也就是說，當(dāng)前Supervisor將獨占節(jié)點而不會與其他服務(wù)共享節(jié)點資源，這種情況下可避免其他服務(wù)對Storm集群的干擾
? Storm ApplicationMaster還會啟動一個Thrift Server以處理來自YARN-Storm Client端的各種請求
Storm On Yarn 優(yōu)勢
? 彈性計算資源
? Storm可與YARN上其他應(yīng)用程序（比如MapReduce批處理應(yīng)用程序）共享整個集群中的資源
? 當(dāng)Storm負(fù)載驟增時，可動態(tài)為它增加計算資源
? 當(dāng)負(fù)載減小時，可釋放部分資源，從而將這些資源暫時分配給負(fù)載更重的批處理應(yīng)用程序
? 共享底層存儲
? Storm可與運行在YARN上的其他框架共享底層的一個HDFS存儲系統(tǒng)
? 避免多個集群帶來的維護(hù)成本
? 避免數(shù)據(jù)跨集群拷貝帶來的網(wǎng)絡(luò)開銷和時間延遲
? 支持多版本
? 可同時將多個Storm版本運行YARN上，避免一個版本一個集群帶來的維護(hù)成本
內(nèi)存計算框架Spark
Spark是什么：
? Spark是一種與Hadoop相似的開源集群計算環(huán)境
? Spark基于MR算法實現(xiàn)的分布式計算，擁有Hadoop MR的優(yōu)點，不同的是結(jié)果保存在內(nèi)存中
? Spark是一個針對超大數(shù)據(jù)集合的低延遲的集群分布式計算系統(tǒng)，比MapReduce快40倍左右
? Spark 是在 Scala 語言中實現(xiàn)的，它將 Scala 用作其應(yīng)用程序框架
Spark兼容Hadoop的API，能夠讀寫Hadoop的HDFS HBASE 順序文件等
傳統(tǒng)Hadoop：
Spark：
Spark優(yōu)勢
? 輕
? Spark 0.6核心代碼有2萬行
? Spark很好地利用了Hadoop和Mesos的基礎(chǔ)設(shè)施
? 快
? Spark對小數(shù)據(jù)集能達(dá)到亞秒級的延遲
? 靈
? Spark提供了不同層面的靈活性
? 巧
? 巧在借勢和借力
Spark與Hadoop對比
? Spark的中間數(shù)據(jù)放到內(nèi)存中，對于迭代運算效率更高
? Spark更適合于迭代運算比較多的ML和DM運算。因為在Spark里面，有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é)果的存儲、分區(qū)
? Spark不適用那種異步細(xì)粒度更新狀態(tài)的應(yīng)用
? 可用性
? 容錯性
Shark – Hive On Spark SparkSQL-DataFrame
? Shark基本上就是在Spark的框架基礎(chǔ)上提供和Hive一樣的H iveQL命令接口
? Shark使用了Hive的API來實現(xiàn)query Parsing和 Logic Plan generation
? 通過配置Shark參數(shù)，Shark可以自動在內(nèi)存中緩存特定的RDD，實現(xiàn)數(shù)據(jù)重用，進(jìn)而加快特定數(shù)據(jù)集的檢索
? Shark通過UDF用戶自定義函數(shù)實現(xiàn)特定的數(shù)據(jù)分析學(xué)習(xí)算法，使得SQL數(shù)據(jù)查詢和運算分析能結(jié)合在一起
Spark Streaming
? 構(gòu)建在Spark上處理Stream數(shù)據(jù)的框架
? Spark的低延遲執(zhí)行引擎（100ms+）可以用于實時計算
? 相比基于Record的其它處理框架（如Storm），RDD數(shù)據(jù)集更容易做高效的容錯處理
? 基本原理是將Stream數(shù)據(jù)分成小的時間片斷（幾秒），以類似batch批量處理的方式來處理這小部分?jǐn)?shù)據(jù)
? 使得它可以同時兼容批量和實時數(shù)據(jù)處理的邏輯和算法
Spark核心概念-RDD
? 為什么會產(chǎn)生RDD？
? 解決傳統(tǒng)MapReduce 迭代計算式要進(jìn)行大量的磁盤IO操作
? RDD：Resilient Distributed Dataset 彈性分布數(shù)據(jù)集
? RDD是一個只讀的，可分區(qū)的分布式數(shù)據(jù)集，這個數(shù)據(jù)集的全部或部分可以緩存在內(nèi)存中，在多次計算間重用
? RDD是一種有容錯機制的特殊集合，可以分布在集群的節(jié)點上，以函數(shù)式編程操作集合的方式，進(jìn)行各種并行操作
? RDD可以cache到內(nèi)存中，每次對RDD數(shù)據(jù)集的操作之后的結(jié)果，都可以存放到內(nèi)存中
? 實質(zhì)是一種更為通用的迭代并行計算框架，用戶可以顯示的控制計算的中間結(jié)果，然后將其自由運用于之后的計算
RDD存儲與分區(qū)
? 用戶可以選擇不同的存儲級別存儲RDD以便重用
? 當(dāng)前RDD默認(rèn)是存儲于內(nèi)存，但當(dāng)內(nèi)存不足時，RDD會spill到disk
? RDD在需要進(jìn)行分區(qū)把數(shù)據(jù)分布于集群中時會根據(jù)每條記錄Key進(jìn)行分區(qū)，以此保證兩個數(shù)據(jù)集在Join時能高效
Lineage 血統(tǒng)
? 為了保證RDD中數(shù)據(jù)的魯棒性，RDD數(shù)據(jù)集通過所謂的血統(tǒng)關(guān)系(Lineage) 記住了它是如何從其它RDD中演變過來的
? RDD的Lineage記錄的是粗顆粒度的特定數(shù)據(jù)變換（Transformation）操作（filter, map, join etc.)行為
? 當(dāng)這個RDD的部分分區(qū)數(shù)據(jù)丟失時，它可以通過Lineage獲取足夠的信息來重新運算和恢復(fù)丟失的數(shù)據(jù)分區(qū)
RDD容錯機制：
? 兩種方式：數(shù)據(jù)檢查點和記錄更新（默認(rèn)）
? 只記錄單個塊上執(zhí)行的單個操作，然后創(chuàng)建某個RDD的變換序列（血統(tǒng)）存儲下來
? RDD的容錯機制又稱“血統(tǒng)”容錯
? 如何表達(dá)父RDD和子RDD之間的依賴關(guān)系？
? 依賴關(guān)系可以分兩種，窄依賴和寬依賴
? 依賴關(guān)系分類的兩個特性
? 計算子RDD的方式不同
? 數(shù)據(jù)恢復(fù)的方式不同
對于寬依賴，要在適當(dāng)時機設(shè)置數(shù)據(jù)檢查點
? RDD只能從持久存儲或通過Transformations操作產(chǎn)生，對于丟失部分?jǐn)?shù)據(jù)分區(qū)只需根據(jù)它的lineage就可重新計算出來，而不需要做特定的Checkpoint
? RDD的不變性，可以實現(xiàn)類Hadoop MapReduce的推測式執(zhí)行
? RDD的數(shù)據(jù)分區(qū)特性，可以通過數(shù)據(jù)的本地性來提高性能
? RDD都是可序列化的，在內(nèi)存不足時可自動降級為磁盤存儲
RDD內(nèi)部設(shè)計
? 源數(shù)據(jù)分割后的數(shù)據(jù)塊，源代碼中的splits變量
? 關(guān)于“血統(tǒng)”的信息，源碼中的dependencies變量
? 一個計算函數(shù)（該RDD如何通過父RDD計算得到），源碼中的iterator(split)和compute函數(shù)
? 一些關(guān)于如何分塊和數(shù)據(jù)存放位置的元信息，如源碼中的partitioner和preferredLocations
操作RDD：
? 如何獲取RDD
? 從共享的文件系統(tǒng)獲?。ㄈ纾篐DFS）
? 通過已存在的RDD轉(zhuǎn)換
? 將已存在scala集合（只要是Seq對象）并行化，通過調(diào)用SparkContext的parallelize方法實現(xiàn)
? 改變現(xiàn)有RDD的持久性；RDD是懶散，短暫的
? 操作RDD的兩個動作
? Actions （ 如： count, collect, save等）
返回結(jié)果或把RDD數(shù)據(jù)寫到存儲系統(tǒng)中；
Actions是觸發(fā)Spark啟動計算的動因
? Transformation（ 如：map, filter, groupBy, join等）
根據(jù)數(shù)據(jù)集創(chuàng)建一個新的數(shù)據(jù)集，計算后返回一個新RDD；
Transformations操作是Lazy的
窄依賴和寬依賴
RDD數(shù)據(jù)模型 ：
把RDD當(dāng)簡單元素的Transformation操作類別
? 輸入輸出一對一(element-wise)的算子，且結(jié)果RDD分區(qū)結(jié)構(gòu)不變
? 主要是map、flatMap等
? 輸入輸出一對一，但結(jié)果RDD的分區(qū)結(jié)構(gòu)發(fā)生了變化
? 如union（兩個RDD合為一個）、coalesce（分區(qū)減少）
? 從輸入中選擇部分元素的算子
? 如filter、distinct、subtract和sample
針對Key-Value的Transformation操作類別
? 對單個RDD做element-wise運算
? 如mapValues
? 對單個RDD重排
? 如sort、partitionBy
? 對單個RDD基于key進(jìn)行重組和reduce
? 如groupByKey、reduceByKey
? 對兩個RDD基于key進(jìn)行join和重組
? 如join、cogroup
RDD數(shù)據(jù)模型
Spark 調(diào)度框架
Spark的分布部署方式
? Apache Spark支持三種分布式部署方式
? Standalone
? Spark on YARN
? Spark on mesos
? Standalone實現(xiàn)了容錯性和資源管理
? 另外兩種實現(xiàn)了部分容錯性和資源管理交由同一的資源管理系統(tǒng)完成
Standalone模式
? 可單獨部署到一個集群中，無需依賴任何其他資源管理系統(tǒng)
? Spark在standalone模式下是沒有任何單點故障問題的，這是借助zookeeper實現(xiàn)的
? Spark standalone與MapReduce架構(gòu)比較
? 都是由master/slaves服務(wù)組成的
? 各個節(jié)點上的資源被抽象成粗粒度的slot，有多少slot就能同時運行多少task
Spark On Mesos
? 官方推薦模式，Spark運行在Mesos上會比運行在YARN上更加靈活，更加自然
? 兩種調(diào)度模式：粗粒度和細(xì)粒度
? 粗粒度模式（Coarse-grained Mode）
? 每個應(yīng)用程序的運行環(huán)境由一個Dirver和若干個Executor組成
? 每個Executor占用若干資源，內(nèi)部可運行多個Task
? 應(yīng)用程序運行之前，申請好全部資源，運行結(jié)束后，回收這些資源
? 細(xì)粒度模式（Fine-grained Mode）
? 思想是按需分配
? 啟動executor，但每個executor占用資源僅僅是自己運行所需的資源
? mesos會為每個executor動態(tài)分配資源
? 單個Task運行完之后可以馬上釋放對應(yīng)的資源
? 每個Task會匯報狀態(tài)給Mesos slave和Mesos Master
Spark On Yarn模式
多進(jìn)程VS多線程
? MapReduce采用了多進(jìn)程模型，便于細(xì)粒度控制每個任務(wù)占用的資源，但會消耗較多的啟動時間
? Spark同節(jié)點上的任務(wù)以多線程的方式運行在一個JVM進(jìn)程中
? 多線程好處
? 任務(wù)啟動速度快
? 有利于共享內(nèi)存, 非常適合內(nèi)存密集型任務(wù)
? 避免了每個任務(wù)重復(fù)申請資源帶來的時間開銷
? 不足
? 會出現(xiàn)嚴(yán)重的資源爭用，難以細(xì)粒度控制每個任務(wù)占用資源
MapReduce多進(jìn)程模型
? 每個Task運行在一個獨立的JVM進(jìn)程中
? 可單獨為不同類型的Task設(shè)置不同的資源量，目前支持內(nèi)存和CPU兩種資源
? 每個Task都要經(jīng)歷“申請資源—> 運行Task –> 釋放資源”的過程
Spark多線程模型
? 每個節(jié)點上可以運行一個或多個Executor服務(wù)
? 每個Executor配有一定數(shù)量的slot
? 每個Executor單獨運行在一個JVM進(jìn)程中，每個Task則是運行在Executor中的一個線程
? 同一個Executor內(nèi)部的Task可共享內(nèi)存
? 將Spark運行在Hadoop上，本質(zhì)上是將Spark運行在Hadoop YARN上
? 之所以不采用Mesos而是YARN，是因為YARN擁有強大的社區(qū)支持，且逐步已經(jīng)成為資源管理系統(tǒng)中的標(biāo)準(zhǔn)
spark-shell 是一個spark application，運行時需要向資源管理器申請資源
Spark Standalone Mode的運行
? 資源調(diào)度
? Spark Standalone Cluster支持FIFO方式調(diào)度，不過，允許多個并發(fā)用戶
? 監(jiān)控和日志
? 通過Web UI來監(jiān)控集群
? 日志：$SPARK_HOME/spark/logs
? 和Hadoop并用
? Spark可以作為獨立的服務(wù)，在已有的Hadoop集群設(shè)備上并行，并通過hdfs://URL存取Hadoop數(shù)據(jù)
Spark優(yōu)勢
1、 克服MR在迭代式計算和交互式計算方面的不足
2、 引入RDD（Resilient Distributed DataSets）數(shù)據(jù)表示模型
3、 RDD是一個有容錯機制，可以被并行操作的數(shù)據(jù)集合，能夠被緩存到內(nèi)存或磁盤上。
基于Spark on Yarn 的淘寶數(shù)據(jù)挖掘平臺
Spark On Yarn
與MR Tez 非常類似
1、 通過Yarn-Spark客戶端Client提交 Spark Submission Spark Application 提交至Resources Manager
2、 Resources Manager找到程序主類和資源需求之后為Application Master申請資源
3、 申請資源之后與Node Manager發(fā)送命令啟動Spark Application Master
4、 在 Spark Application Master內(nèi)部啟動Spark Container 里面有一個Cluster Scheduler 和web UI
5、 啟動之后Application Master向Resource Manager申請資源，然后向Node Manager發(fā)出命令，啟動Spark作業(yè)的Executor（StandaloneExecutorBackend），Executor里會有 很多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
一個MR應(yīng)用程序的成功運行需要若干個模塊：
1、 任務(wù)管理（由各個應(yīng)用程序管理）和資源調(diào)度（每個應(yīng)用程序都需要，Yarn統(tǒng)一管理）
2、 任務(wù)驅(qū)動模塊 MapTask ReduceTask
3、 用戶代碼 Mapper Reducer
Yarn是一個資源管理系統(tǒng)，只負(fù)責(zé)資源管理和調(diào)度，MapReduce只是運行在Yarn上的一個應(yīng)用程序，Yarn 對比于 Android MapReduce只是一個 app
MapReduce2.0組成：
Yarn（整個集群只有一個）Spark可以用、Storm也可以用 公用模塊
MRAppMaster 一個應(yīng)用程序一個
用戶代碼Mapper Reducer
MapReduce 1.0 與 MapReduce2.0區(qū)別：
MapReduce1.0是一個獨立的系統(tǒng)，直接運行在Linux之上
MapReduce2.0是運行在Yarn上的計算框架，且可與多種框架同時一起運行在Yarn上。
2.0沒有JobTracker 、 TaskTracker 這樣的服務(wù) 必須依托于Yarn來運行
