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