目錄
概述
批處理爲主，流處理爲輔--微批
Apache Spark 是專爲大規模數據處理而設計的快速通用的計算引擎。Spark是UC Berkeley AMP lab (加州大學伯克利分校的AMP實驗室)所開源的類Hadoop MapReduce的通用並行框架，Spark，擁有Hadoop MapReduce所具有的優點；但不同於MapReduce的是——Job中間輸出結果可以保存在內存中，從而不再需要讀寫HDFS，因此Spark能更好地適用於數據挖掘與機器學習等需要迭代的MapReduce的算法。
Spark 是一種與Hadoop相似的開源集羣計算環境，但是兩者之間還存在一些不同之處，這些有用的不同之處使Spark在某些工作負載方面表現得更加優越，換句話說，Spark啓用了內存分佈數據集，除了能夠提供交互式查詢外，它還可以優化迭代工作負載。
Spark是在Scala語言中實現的，它將Scala用作其應用程序框架。與Hadoop不同，Spark和Scala能夠緊密集成，其中的Scala可以像操作本地集合對象一樣輕鬆地操作分佈式數據集。
儘管創建Spark是爲了支持分佈式數據集上的迭代作業，但是實際上它是對Hadoop的補充，可以在Hadoop文件系統中並行運行。通過名爲Mesos的第三方集羣框架可以支持此行爲。
Spark是一種包含流處理能力的下一代批處理框架,與Hadoop的MapReduce引擎基於各種相同原則開發而來的Spark主要側重於通過完善的內存計算和處理優化機制加快批處理工作負載的運行速度。Spark可作爲獨立集羣部署（需要相應存儲層的配合），或可與Hadoop集成並取代MapReduce引擎（也可以與hadoop中MapReduce兼容）MapReduce屬於Hadoop生態系統之一，Spark則屬於BDAS（伯克利分析棧）生態系統之一。BDAS包含了Spark，shark（spark SQL爲Shark的升級版），BlinkDB，Spark Streaming
本次採用安裝包：spark-2.3.0-bin-hadoop2.7.tgz
spark-2.3.0的改變：
1）Spark runs on Java 8+, Python 2.7+/3.4+ and R 3.1+. For the Scala API, Spark 2.3.0 uses Scala 2.11. You will need to use a compatible Scala version (2.11.x)
spark2.3運行環境：java8，Python2.7+/3.4，R 3.1 Scala2.11
2）Note that support for Java 7, Python 2.6 and old Hadoop versions before 2.6.5 were removed as of Spark 2.2.0. Support for Scala 2.10 was removed as of 2.3.0支持Java7，Python2.6和hadoop2.6.5之前版本已經在spark2.2移除2.3支持的是scala2.11
3）spark融合的API：Scala，Java，Python，R，SQL,Built-in Function
4）spark依賴於（可在運行）：Mesos，Yarn，Kubernetes
spark架構圖，如下圖：
Cluster Manager：在standalone模式中即爲Master主節點，控制整個集羣，監控worker。在YARN模式中爲資源管理器
Worker節點：從節點，負責控制計算節點，啓動Executor或者Driver。
Driver： 運行Application 的main()函數Executor：執行器，是爲某個Application運行在worker node上的一個進程
spark運行流程圖
1.構建Spark Application的運行環境，啓動SparkContext
2.SparkContext向資源管理器（可以是Standalone，Mesos，Yarn）申請運行Executor資源，並啓動StandaloneExecutorbackend
3.Executor向SparkContext申請Task
4.SparkContext將應用程序分發給Executor
5.SparkContext構建成DAG圖，將DAG圖分解成Stage、將Taskset發送給Task Scheduler，最後由Task Scheduler將Task發送給Executor運行
6.Task在Executor上運行，運行完釋放所有資源
Spark運行特點
1.每個Application獲取專屬的executor進程，該進程在Application期間一直駐留，並以多線程方式運行Task。這種Application隔離機制是有優勢的，無論是從調度角度看（每個Driver調度他自己的任務），還是從運行角度看（來自不同Application的Task運行在不同JVM中），當然這樣意味着Spark Application不能跨應用程序共享數據，除非將數據寫入外部存儲系統
2.Spark與資源管理器無關，只要能夠獲取executor進程，並能保持相互通信就可以了
3.提交SparkContext的Client應該靠近Worker節點（運行Executor的節點），最好是在同一個Rack裏，因爲Spark Application運行過程中SparkContext和Executor之間有大量的信息交換
4.Task採用了數據本地性和推測執行的優化機制
Spark與hadoop：
Hadoop有兩個核心模塊，分佈式存儲模塊HDFS和分佈式計算模塊Mapreduce；spark本身並沒有提供分佈式文件系統，因此spark的分析大多依賴於Hadoop的分佈式文件系統HDFS Hadoop的Mapreduce與spark都可以進行數據計算，而相比於Mapreduce，spark的速度更快並且提供的功能更加豐富。
spark組件、功能介紹
Spark Core：
包含Spark的基本功能；尤其是定義RDD的API、操作以及這兩者上的動作。其他Spark的庫都是構建在RDD和Spark Core之上的
MLlib：數據處理和機器學習的算法庫
構建在apache spark之上，一個專門針對大量數據處理的通用的、快速的引擎。是spark的可以擴展的機器學習庫，由以下部分組成：通用的學習算法和工具類，包括分類，迴歸，聚類，協同過濾，降維，當然也包括調優的部分。
MLlib使用了線性代數包 Breeze, 它依賴於netlib-java和jblas。netlib-java 和 jblas 需要依賴native Fortran routines。
所以你需要安裝安裝方法在這個鏈接中：https://github.com/mikiobraun/jblas/wiki/Missing-Libraries，如果你的
集羣的節點中沒有安裝native Fortran routines。MLlib 會拋出一個link error，如果沒有安裝native Fortran routines。
RDD
Resilient Distributed Datasets：彈性分佈式數據集，它具備像MapReduce等數據流模型的容錯特性，並且允許開發人員在
大型集羣上執行基於內存的計算。現有的數據流系統對兩種應用的處理並不高效：一是迭代式算法，這在圖應用和機器學習領域 很常見；二是交互式數據挖掘工具。這兩種情況下，將數據保存在內存中能夠極大地提高性能。爲了有效地實現容錯，RDD提供 了一種高度受限的共享內存，即RDD是隻讀的，並且只能通過其他RDD上的批量操作來創建。儘管如此，RDD仍然足以表示很多類型的計算，包括MapReduce和專用的迭代編程模型（如Pregel）等。
RDD是隻讀的、分區記錄的集合：RDD只能基於在穩定物理存儲中的數據集和其他已有的RDD上執行確定性操作來創建。這些確定性操作稱之爲轉換，如map、filter、groupBy、join（轉換不是程開發人員在RDD上執行的操作）
RDD不需要物化。RDD含有如何從其他RDD衍生（即計算）出本RDD的相關信息（即Lineage），據此可以從物理存儲的數據計算出相應的RDD分區。
RDD作爲數據結構，本質上是一個只讀的分區記錄集合。一個RDD可以包含多個分區，每個分區就是一個dataset片段。
RDD可以相互依賴。如果RDD的每個分區最多隻能被一個Child RDD的一個分區使用，則稱之爲narrow dependency（狹窄依賴）；
若多個Child RDD分區都可以依賴，則稱之爲wide dependency。不同的操作依據其特性，可能會產生不同的依賴。例如map操作會產生narrow dependency，而join操作則產生wide dependency。
GraphX
GraphX是構建在Spark之上的圖計算框架，它使用RDD來存儲圖數據，並提供了實用的圖操作方法。由於RDD的與生俱來的特性，GraphX高效地實現了圖的分佈式存儲和處理，可以應用於社交網絡等大規模的圖計算場景。GraphX在圖頂點信息和邊信息存儲上做了優化，使得圖計算框架性能相對於原生RDD實現得以較大提升，接近或到達GraphLab等專業圖計算平臺的性能。GraphX最大的貢獻是，在Spark之上提供一棧式數據解決方案，可以方便且高效地完成圖計算的一整套流水作業。
控制圖、並行圖操作和計算的一組算法和工具的集合。GraphX擴展了RDD API，包含控制圖、創建子圖、訪問路徑上所有頂點的操作
Spark SQL(shark升級版)
Spark SQL is Apache Spark's module for working with structured(結構) data SparkSQL的前身是Shark，給熟悉RDBMS但又不理解MapReduce的技術人員提供快速上手的工具，Hive應運而生，它是當時唯一運行在Hadoop上的SQL-on-Hadoop工具。但是MapReduce計算過程中大量的中間磁盤落地過程消耗了大量的I/O，降低的運行效率，爲了提高SQL-on-Hadoop的效率，大量的SQL-on-Hadoop工具開始產生，其中表現較爲突出的是：①MapR的Drill②Cloudera的Impala
③Shark。其中Shark是伯克利實驗室Spark生態環境的組件之一，它修改了內存管理、物理計劃、執行三個模塊，並使之能運行在
Spark引擎上，從而使得SQL查詢的速度得到10-100倍的提升。
但是，隨着Spark的發展，對於野心勃勃的Spark團隊來說，Shark對於Hive的太多依賴（如採用Hive的語法解析器、查詢優化器等等），制約了Spark的One Stack Rule Them All的既定方針，制約了Spark各個組件的相互集成，所以提出了SparkSQL項目。SparkSQL拋棄原有Shark的代碼，汲取了Shark的一些優點，如內存列存儲（In-Memory Columnar Storage）、Hive兼容性等，重新開發了SparkSQL代碼；由於擺脫了對Hive的依賴性，SparkSQL無論在數據兼容、性能優化、組件擴展方面都得到了極大的方便，真可謂“退一步，海闊天空”。
提供通過Apache Hive的SQL變體Hive查詢語言（HiveQL）與Spark進行交互的API。每個數據庫表被當做一個RDD，Spark SQL查詢被轉換爲Spark操作。
Shark(類似Hive)
Spark Streaming
Spark Streaming 是Spark核心API的一個擴展，可以實現高吞吐量的、具備容錯機制的實時流數據的處理。支持從多種數
據源獲取數據，包括Kafk、Flume、Twitter、ZeroMQ、Kinesis 以及TCP sockets，從數據源獲取數據之後，可以使用
諸如map、reduce、join和window等高級函數進行復雜算法的處理。最後還可以將處理結果存儲到文件系統，數據庫和
現場儀表盤。在“One Stack rule them all”的基礎上，還可以使用Spark的其他子框架，如集羣學習、圖計算等，對
流數據進行處理。Spark的各個子框架，都是基於核心Spark的，Spark Streaming在內部的處理機制是，接收實時流的數據，
並根據一定的時間間隔拆分成一批批的數據，然後通過Spark Engine處理這些批數據，最終得到處理後的一批批結果數據。
對應的批數據，在Spark內核對應一個RDD實例，因此，對應流數據的DStream可以看成是一組RDDs，即RDD的一個序列。通俗點理解的話，在流數據分成一批一批後，通過一個先進先出的隊列，然後 Spark Engine從該隊列中依次取出一個個批數據，把批數據 封裝成一個RDD，然後進行處理，這是一個典型的生產者消費者模型，對應的就有生產者消費者模型的問題，即如何協調生產速率和消費速率。
對實時數據流進行處理和控制。Spark Streaming允許程序能夠像普通RDD一樣處理實時數據。
Kafka
一種高吞吐量的分佈式發佈訂閱消息系統，它可以處理消費者規模的網站中的所有動作流數據。這種動作（網頁瀏覽，搜索和其他用戶的行動）是在現代網絡上的許多社會功能的一個關鍵因素。 這些數據通常是由於吞吐量的要求而通過處理日誌和日誌聚合來解決。 對於像Hadoop的一樣的日誌數據和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka的目的是通過Hadoop的並行加載機制來統一線上和離線的消息處理，也是爲了通過集羣來提供實時的消費。
Kafka有如下特下：
通過O(1)的磁盤數據結構提供消息的持久化，這種結構對於即使數以TB的消息存儲也能夠保持長時間的穩定性能。
高吞吐量：即使是非常普通的硬件Kafka也可以支持每秒數百萬的消息。支持通過Kafka服務器和消費機集羣來分區消息。
支持Hadoop並行數據加載。
SparkR
sparkR在spark2.0裏面，RDD後端代碼位於org.apache.spark.rdd中，R語言相關的位於org.apache.spark.api.r中。
SparkR是一個R語言包，它提供了輕量級的方式使得可以在R語言中使用Apache Spark。在Spark 1.4中，SparkR實現了分佈式的data frame，支持類似查詢、過濾以及聚合的操作（類似於R中的data frames：dplyr)，但是這個可以操作大規模的數據集。使用spark的兩種方式：
1.在sparkR的shell中交互式使用sparkR
2.在R腳本中使用
例： if (nchar(Sys.getenv("SPARK_HOME")) < 1) {
Sys.setenv(SPARK_HOME = "/home/spark")
}
library(SparkR, lib.loc = c(file.path(Sys.getenv("SPARK_HOME"), "R", "lib")))
sc <- sparkR.init(master = "spark://10.137",sparkEnvir = list(spark.driver.memory="3g"))
Mesos
Apache下的開源分佈式資源管理框架，它被稱爲是分佈式系統的內核。
優點：
1.資源管理策略Dominant Resource Fairness(DRF), 這是Mesos的核心，也是我們把Mesos比作分佈式系統Kernel的根本原因。通俗講，Mesos能夠保證集羣內的所有用戶有平等的機會使用集羣內的資源，這裏的資源包括CPU，內存，磁盤等等。很多人拿Mesos跟k8s相比，我對k8s瞭解不深，但是，我認爲這兩者側重點不同不能做比較，k8s只是負責容器編排而不是集羣資源管理。不能因爲都可以管理docker，我們就把它們混爲一談。
2.輕量級。相對於 Yarn，Mesos 只負責offer資源給framework，不負責調度資源。這樣，理論上，我們可以讓各種東西使用Mesos集羣資源，而不像yarn只拘泥於hadoop，我們需要做的是開發調度器（mesos framework）。
3.提高分佈式集羣的資源利用率：這是一個 generic 的優點。從某些方面來說，所有的集羣管理工具都是爲了提高資源利用率。VM的出現，催生了IaaS；容器的出現，催生了k8s, Mesos等等。簡單講，同樣多的資源，我們利用IaaS把它們拆成VM 與 利用k8s/Mesos把它們拆成容器，顯然後者的資源利用率更高。(這裏我沒有討論安全的問題，我們假設內部子網環境不需要考慮這個。)
缺點：
1.門檻太高。只部署一套Mesos，你啥都幹不了，爲了使用它，你需要不同的mesos framework，像Marathon，chronos，spark等等。或者自己寫framework來調度Mesos給的資源，這讓大家望而卻步。
2.目前對stateful service的支持不夠。Mesos集羣目前無法進行數據持久化。即將發佈的0.23版本增加了persistent resource和dynamic reserver，數據持久化問題將得到改善。
3.髒活累活不會少。Team在使用Mesos前期很樂觀，認爲搞定了Mesos，我們的運維同學能輕鬆很多。然而，根本不是那麼回事兒，集羣節點的優化，磁盤，網絡的設置，等等這些，Mesos是不會幫你乾的。使用初期，運維的工作量不僅沒有減輕，反而更重了。
4.Mesos項目還在緊鑼密鼓的開發中，很多功能還不完善。譬如，集羣資源搶佔還不支持。
Kubernetes
Kubernetes（k8s）是自動化容器操作的開源平臺，這些操作包括部署，調度和節點集羣間擴展。如果你曾經用過Docker容器技術部署容器，那麼可以將Docker看成Kubernetes內部使用的低級別組件。Kubernetes不僅僅支持Docker，還支持Rocket，這是另一種容器技術。
使用Kubernetes可以：
自動化容器的部署和複製
隨時擴展或收縮容器規模
將容器組織成組，並且提供容器間的負載均衡
很容易地升級應用程序容器的新版本
提供容器彈性，如果容器失效就替換它，等等...
yarn
Apache Hadoop YARN （Yet Another Resource Negotiator，另一種資源協調者）是一種新的 Hadoop 資源管理器，它是一個通用資源管理系統，可爲上層應用提供統一的資源管理和調度，它的引入爲集羣在利用率、資源統一管理和數據共享等方面帶來了巨大好處。
Yarn的優點：
1.大大減小了 JobTracker（也就是現在的 ResourceManager）的資源消耗，並且讓監測每一個 Job 子任務 (tasks) 狀態的程序分佈式化了，更安全、更優美。
2.在新的 Yarn 中，ApplicationMaster 是一個可變更的部分，用戶可以對不同的編程模型寫自己的 AppMst，讓更多類型的編程模型能夠跑在 Hadoop 集羣中，可以參考 hadoop Yarn 官方配置模板中的 mapred-site.xml 配置。
3.對於資源的表示以內存爲單位 ( 在目前版本的 Yarn 中，沒有考慮 cpu 的佔用 )，比之前以剩餘 slot 數目更合理。
4.老的框架中，JobTracker 一個很大的負擔就是監控 job 下的 tasks 的運行狀況，現在，這個部分就扔給
ApplicationMaster 做了，而 ResourceManager 中有一個模塊叫做 ApplicationsMasters( 注意不是 ApplicationMaster)，
它是監測 ApplicationMaster 的運行狀況，如果出問題，會將其在其他機器上重啓。
5.Container 是 Yarn 爲了將來作資源隔離而提出的一個框架。這一點應該借鑑了 Mesos 的工作，目前是一個框架，僅僅提供
java 虛擬機內存的隔離,hadoop 團隊的設計思路應該後續能支持更多的資源調度和控制,既然資源表示成內存量，那就沒
有了之前的 map slot/reduce slot 分開造成集羣資源閒置的尷尬情況。
YARN的核心思想：
將JobTracker和TaskTracker進行分離，它由下面幾大構成組件：
a. 一個全局的資源管理器 ResourceManager
b.ResourceManager的每個節點代理 NodeManager
c. 表示每個應用的 ApplicationMaster
d. 每一個ApplicationMaster擁有多個Container在NodeManager上運行
Spark常用術語
1)Application
Appliction都是指用戶編寫的Spark應用程序，其中包括一個Driver功能的代碼和分佈在集羣中多個節點上運行的Executor代碼
2)Driver
Spark中的Driver即運行上述Application的main函數並創建SparkContext，創建SparkContext的目的是爲了準備Spark應用程序的運行環境，在Spark中有SparkContext負責與ClusterManager通信，進行資源申請、任務的分配和監控等，當Executor部分運行完畢後，Driver同時負責將SparkContext關閉，通常用SparkContext代表Driver
3)Executor
某個Application運行在worker節點上的一個進程， 該進程負責運行某些Task， 並且負責將數據存到內存或磁盤上，每個Application都有各自獨立的一批Executor， 在Spark on Yarn模式下，其進程名稱爲CoarseGrainedExecutor Backend。一個CoarseGrainedExecutor Backend有且僅有一個Executor對象， 負責將Task包裝成taskRunner,並從線程池中抽取一個空閒線程運行Task， 這個每一個CoarseGrainedExecutor Backend能並行運行Task的數量取決於分配給它的cpu個數
4)Cluter Manager
指的是在集羣上獲取資源的外部服務。目前有三種類型:
Standalon : spark原生的資源管理，由Master負責資源的分配
Apache Mesos:與hadoop MR兼容性良好的一種資源調度框架
Hadoop Yarn: 主要是指Yarn中的ResourceManager
5)Worker
集羣中任何可以運行Application代碼的節點，在Standalone模式中指的是通過slave文件配置的Worker
節點，在Spark on Yarn模式下就是NoteManager節點
6)Task
被送到某個Executor上的工作單元，但hadoopMR中的MapTask和ReduceTask概念一樣，是運行Application
的基本單位，多個Task組成一個Stage，而Task的調度和管理等是由TaskScheduler負責
7)Job
包含多個Task組成的並行計算，往往由Spark Action觸發生成， 一個Application中往往會產生多個Job
8)Stage
每個Job會被拆分成多組Task， 作爲一個TaskSet， 其名稱爲Stage，Stage的劃分和調度是有DAGScheduler
來負責的，Stage有非最終的Stage（Shuffle Map Stage）和最終的Stage（Result Stage）兩種，Stage的
邊界就是發生shuffle的地方
9)DAGScheduler
根據Job構建基於Stage的DAG 
（Directed Acyclic Graph有向無環圖)，
並提交Stage給TASkScheduler。 其劃分
Stage的依據是RDD之間的依賴的關係找出
開銷最小的調度方法
10)TASKSedulter
將TaskSET提交給worker運行，每個Executor運行什麼Task就是在此處分配的. TaskScheduler維護所有TaskSet，當Executor向Driver發生心跳時TaskScheduler會根據資源剩餘情況分配相應的Task。另外，TaskScheduler還維護着所有Task的運行標籤，重試失敗的Task。
11)在不同運行模式中任務調度器具體爲：
Spark on Standalone模式爲TaskScheduler
YARN-Client模式爲YarnClientClusterScheduler
YARN-Cluster模式爲YarnClusterScheduler
術語總結：
Job=多個stage，Stage=多個同種task Task分爲ShuffleMapTask和ResultTask
Dependency分爲：
ShuffleDependency
NarrowDependency
Spark運行模式
概述
Spark的運行模式多種多樣，靈活多變，部署在單機上時，既可以用本地模式運行，也可以用僞分佈模式運行，而當以分佈式集羣的方式部署時，也有衆多的運行模式可供選擇，這取決於集羣的實際情況，底層的資源調度即可以依賴外部資源調度框架，也可以使用Spark內建的Standalone模式。
對於外部資源調度框架的支持，目前的實現包括相對穩定的Mesos模式，以及hadoop YARN模式
本地模式：常用於本地開發測試，本地還分別 local 和 local cluster
1)standalone: 獨立集羣運行模式
Standalone模式使用Spark自帶的資源調度框架採用Master/Slaves的典型架構，選用ZooKeeper來實現Master的HA
框架結構圖如下：
該模式主要的節點有Client節點、Master節點和Worker節點。其中Driver既可以運行在Master節點上中，也可以運行在本地Client端。當用spark-shell交互式工具提交Spark的Job時，Driver在Master節點上運行；當使用spark-submit工具提交Job或者在Eclips、IDEA等開發平臺上使用”new SparkConf.setManager(“spark://master:7077”)”方式運行Spark任務時，Driver是運行在本地Client端上的。
運行過程如下圖：
1.SparkContext連接到Master，向Master註冊並申請資源（CPU Core 和Memory）
2.Master根據SparkContext的資源申請要求和Worker心跳週期內報告的信息決定在哪個Worker上分配資源，然後在該Worker上獲取資源，然後啓動StandaloneExecutorBackend
3.StandaloneExecutorBackend向SparkContext註冊；
4.SparkContext將Applicaiton代碼發送給StandaloneExecutorBackend；並且SparkContext解析Applicaiton代碼，構建DAG圖，並提交給DAG Scheduler分解成Stage（當碰到Action操作時，就會催生Job；每個Job中含有1個或多個Stage，Stage一般在獲取外部數據和shuffle之前產生），然後以Stage（或者稱爲TaskSet）提交給Task Scheduler，Task Scheduler負責將Task分配到相應的Worker，最後提交給StandaloneExecutorBackend執行；
5.StandaloneExecutorBackend會建立Executor線程池，開始執行Task，並向SparkContext報告，直至Task完成
6.所有Task完成後，SparkContext向Master註銷，釋放資源
2)Spark on YARN：在yarn上運行
Spark on YARN模式根據Driver在集羣中的位置分爲兩種模式：
YARN-Client模式
YARN-Cluster（或稱爲YARN-Standalone模式）
A.Yarn-Client模式中：
Driver在客戶端本地運行，這種模式可以使得Spark Application和客戶端進行交互，因爲Driver在客戶端，所以可以通過webUI訪問Driver的狀態，默認是http://hadoop1:4040訪問，而YARN通過http://hadoop1:8088訪問
YARN-client的工作流程步驟爲:
a.Spark Yarn Client向YARN的ResourceManager申請啓動Application Master。同時在SparkContent
初始化中將創建DAGScheduler和TASKScheduler等，由於我們選擇的是Yarn-Client模式，程序會選擇
YarnClientClusterScheduler和YarnClientSchedulerBackend
b.ResourceManager收到請求後，在集羣中選擇一個NodeManager，爲該應用程序分配第一個Container，
要求它在這個Container中啓動應用程序的ApplicationMaster，與YARN-Cluster區別的是在該
ApplicationMaster不運行SparkContext，只與SparkContext進行聯繫進行資源的分派
c.Client中的SparkContext初始化完畢後，與ApplicationMaster建立通訊，向ResourceManager
註冊，根據任務信息向ResourceManager申請資源（Container）
d.一旦ApplicationMaster申請到資源（也就是Container）後，便與對應的NodeManager通信，要求
它在獲得的Container中啓動CoarseGrainedExecutorBackend，CoarseGrainedExecutorBackend啓
動後會向Client中的SparkContext註冊並申請Task
e.client中的SparkContext分配Task給CoarseGrainedExecutorBackend執行，CoarseGrainedExecutorBackend
運行Task並向Driver彙報運行的狀態和進度，以讓Client隨時掌握各個任務的運行狀態，從而可以在任務
失敗時重新啓動任務
f.應用程序運行完成後，Client的SparkContext向ResourceManager申請註銷並關閉自己
B.Spark Cluster模式
在YARN-Cluster模式中，當用戶向YARN中提交一個應用程序後，YARN將分兩個階段運行該應用程序：
第一個階段是把Spark的Driver作爲一個ApplicationMaster在YARN集羣中先啓動；
第二個階段是由ApplicationMaster創建應用程序，然後爲它向ResourceManager申請資源，
並啓動Executor來運行Task，同時監控它的整個運行過程，直到運行完成
YARN-cluster的工作流程分爲以下幾個步驟:
a.Spark Yarn Client向YARN中提交應用程序，包括ApplicationMaster程序、啓動ApplicationMaster的命令、需要在Executor中運行的程序等
b.ResourceManager收到請求後，在集羣中選擇一個NodeManager，爲該應用程序分配第一個Container，要求它在這個Container中啓動應用程序的ApplicationMaster，其中ApplicationMaster進行SparkContext等的初始化
c.ApplicationMaster向ResourceManager註冊，這樣用戶可以直接通過ResourceManage查看應用程序的運行狀態，然後它將採用輪詢的方式通過RPC協議爲各個任務申請資源，並監控它們的運行狀態直到運行結束
d.一旦ApplicationMaster申請到資源（也就是Container）後，便與對應的NodeManager通信，要求它在
獲得的Container中啓動CoarseGrainedExecutorBackend，CoarseGrainedExecutorBackend啓動後會向ApplicationMaster中的SparkContext註冊並申請Task。這一點和Standalone模式一樣，只不過SparkContext在Spark Application中初始化時，使用CoarseGrainedSchedulerBackend配合YarnClusterScheduler進行任務的調度，其中YarnClusterScheduler只是對TaskSchedulerImpl的一個簡單包裝，增加了對Executor的等待邏輯等
e.ApplicationMaster中的SparkContext分配Task給CoarseGrainedExecutorBackend執行，CoarseGrainedExecutorBackend運行Task並向ApplicationMaster彙報運行的狀態和進度，以讓ApplicationMaster隨時掌握各個任務的運行狀態，從而可以在任務失敗時重新啓動任務
f.應用程序運行完成後，ApplicationMaster向ResourceManager申請註銷並關閉自己
Spark Client 和 Spark Cluster的區別:
理解YARN-Client和YARN-Cluster深層次的區別之前先清楚一個概念：Application Master。在YARN中，每個Application實例都有一個ApplicationMaster進程，它是Application啓動的第一個容器。它負責和ResourceManager打交道並請求資源，獲取資源之後告訴NodeManager爲其啓動Container。從深層次的含義講YARN-Cluster和YARN-Client模式的區別其實就是ApplicationMaster進程的區別YARN-Cluster模式下，Driver運行在AM(Application Master)中，它負責向YARN申請資源，並監督作業的運行狀況。當用戶提交了作業之後，就可以關掉Client，作業會繼續在YARN上運行，因而
YARN-Cluster模式不適合運行交互類型的作業
YARN-Client模式下，Application Master僅僅向YARN請求Executor，Client會和請求的Container通信來調度他們工作，也就是說Client不能離開
RDD運行流程
RDD在Spark中運行大概分爲以下三步：
1.創建RDD對象
2.DAGScheduler模塊介入運算，計算RDD之間的依賴關係，RDD之間的依賴關係就形成了DAG
3.每一個Job被分爲多個Stage。劃分Stage的一個主要依據是當前計算因子的輸入是否是確定的，
如果是則將其分在同一個Stage，避免多個Stage之間的消息傳遞開銷
以下面一個按 A-Z 首字母分類，查找相同首字母下不同姓名總個數的例子來看一下 RDD 是如何運行起來的
創建 RDD 上面的例子除去最後一個 collect 是個動作，不會創建 RDD 之外，前面四個轉換都
會創建出新的 RDD 。因此第一步就是創建好所有 RDD( 內部的五項信息 )？
創建執行計劃 Spark 會盡可能地管道化，並基於是否要重新組織數據來劃分 階段 (stage) ，
例如本例中的 groupBy() 轉換就會將整個執行計劃劃分成兩階段執行。最終會產生一個
DAG(directed acyclic graph ，有向無環圖 ) 作爲邏輯執行計劃
調度任務將各階段劃分成不同的任務 (task) ，每個任務都是數據和計算的合體。在進行下一階段前，當前階段的所有任務都要執行完成。因爲下一階段的第一個轉換一定是重新組織數據的，所以必須等當前階段所有結果數據都計算出來了才能繼續
Spark安裝配置
1)Scala定義
Scala是一門多範式（multi-paradigm）的編程語言，設計初衷是要集成面向對象編程和函數式編程的各種特性。
Scala 運行在Java虛擬機上，併兼容現有的Java程序。Scala 源代碼被編譯成Java字節碼，所以它可以運行於JVM之上，並可以調用現有的Java類庫。
2）安裝scala
因爲Spark的配置依賴與Scala，所以先要配置Scala。把scala-2.12.5.tgz移動到/usr/software目錄下
tar -xvf scala-2.12.5.tgz
解壓之後出現目錄：scala-2.12.5
配置scala環境變量（每臺都裝）
vim /etc/profile
export SCALA_HOME=/usr/software/scala-2.12.5
export PATH=${SCALA_HOME}/bin:$PATH
source profile
驗證scala是否安裝成功：scala -version
Scala code runner version 2.12.5 -- Copyright 2002-2018, LAMP/EPFL and Lightbend, Inc.
配置scala開機自啓：vim ~/.bashrc
JAVA_HOME=/usr/software/java/jdk1.8.0_152
HADOOP_HOME=/usr/software/hadoop-3.0.1
SCALA_HOME=/usr/software/scala-2.12.5
CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar
PATH=$JAVA_HOME/bin:$HADOOP_HOME/bin:$SCALA_HOME/bin:$PATH
export JAVA_HOME HADOOP_HOME SCALA_HOME CLASSPATH PATH
保存退出
把scala-2.12.5移動到其它機器：
scp -r /usr/software/scala-2.12.5 hadoop02@hadoop02:/home/hadoop02
將scala-2.12.5移動到/usr/software目錄下copy完之後在每臺機器上配置環境變量：/etc/profile和.bashrc兩個文件
3)安裝配置spark
離線下載安裝包：spark-2.3.0-bin-hadoop2.7.tgz
tar -xvf spark-2.3.0-bin-hadoop2.7.tgz
出現目錄：spark-2.3.0-bin-hadoop2.7
目錄重命名：mv spark-2.3.0-bin-hadoop2.7 /usr/software/spark
配置環境變量（每臺機器都需要配置）
vim /etc/profile
export SPARK_HOME=/usr/software/spark
export PATH=${SPARK_HOME}/bin:$PATH
source /etc/profile
配置spark-env.sh
cd /usr/software/spark/conf
cp spark-env.sh.template spark-env.sh
vim spark-env.sh
export JAVA_HOME=/usr/software/java/jdk1.8.0_152
export SCALA_HOME=/usr/software/scala-2.12.5
export HADOOP_HOME=/usr/software/hadoop-3.0.1
export HADOOP_CONF_DIR=$HADOOP_HOME/etc/hadoop
export SPARK_HOME=/usr/software/spark
export SPARK_MASTER_IP=hadoop01
export SPARK_EXECUTOR_MEMORY=2G
export SPARK_MASTER_WEBUI_PORT=8085
保存退出
配置$SPARK_HOME/conf/slaves
cd /usr/software/spark/conf
cp slaves.template slaves
vim slaves
hadoop01
hadoop02
hadoop03
hadoop04
hadoop05
保存退出
把配置好的spark複製到其它節點
scp -r /usr/software/spark hadoop02@hadoop02:/home/hadoop02
將spark移動到/usr/software目錄下，配置spark環境變量：vim /etc/profile
4)啓動spark
啓動spark要確保hadoop已經成功啓動！！！
用jps確認
cd /usr/software/spark
sbin/start-all.sh sbin/stop-all.sh
啓動後，jps查看，hadoop01作爲主機多出兩個進程，其它機器多出一個進程
Spark簡易測試：
輸入URL：http://hadoop01:8085/，查看webUI：
spark簡易測試：
爲了避免麻煩這裏我們使用spark-shell，做一個簡單的worcount的測試
用於在測試hadoop的時候我們已經在hdfs上存儲了測試的源文件，下面就是直接拿來用就好了！
cd /usr/software/spark/bin
spark-shell
Spark的shell作爲一個強大的交互式數據分析工具，提供了一個簡單的方式學習API。它可以使用
Scala(在Java虛擬機上運行現有的Java庫的一個很好方式)或Python。
在scala>後輸入
val file=sc.textFile("hdfs://mycluster1/input/words.txt")
val rdd = file.flatMap(line => line.split(" ")).map(word => (word,1)).reduceByKey(_+_)
rdd.collect()
rdd.foreach(println)
測試成功後錄入： :quit
