本文主要給大家介紹隱藏在華為云EI(企業(yè)智能)數(shù)據湖探索服務(以下簡稱DLI)背后的核心計算引擎——Spark。華為云EI數(shù)據湖探索服務團隊在Spark之上做了大量的性能優(yōu)化與服務化改造，但其本質還是脫離不了Spark的核心概念與思想，本文從以下幾點闡述，讓讀者快速對Spark有一個直觀的認識，玩轉DLI。

　　　Spark的誕生及優(yōu)勢

　　2009年，Spark誕生于伯克利大學AMPLab，誕生之初是屬于伯克利大學的研究性項目。于2010年開源，2013年成為Apache開源項目，經過幾年的發(fā)展逐漸取代了Hadoop，成為了開源社區(qū)炙手可熱的大數(shù)據處理平臺。

　　Spark官方的解釋：“Spark是用于大規(guī)模數(shù)據處理的統(tǒng)一分析引擎“，把關鍵詞拆開來看，“大規(guī)模數(shù)據”指的是Spark的使用場景是大數(shù)據場景;“統(tǒng)一”主要體現(xiàn)在將大數(shù)據的編程模型進行了歸一化，同時滿足多種類型的大數(shù)據處理場景(批處理、流處理、機器學習等)，降低學習和維護不同大數(shù)據引擎的成本;“分析引擎”表明Spark聚焦在計算分析，對標的是Hadoop中的MapReduce，對其模型進行優(yōu)化與擴展。

　　Spark為了解決MapReduce模型的優(yōu)化和擴展，我們先探討一下MapReduce存在的問題，然后分析Spark在MapReduce之上的改進。

　　(1)MapReduce中間結果落盤，計算效率低下

　　隨著業(yè)務數(shù)據不斷增多，業(yè)務邏輯不斷多樣化，很多ETL和數(shù)據預處理的工作需要多個MapReduce作業(yè)才能完成，但是MapReduce作業(yè)之間的數(shù)據交換需要通過寫入外部存儲才能完成，這樣會導致頻繁地磁盤讀寫，降低作業(yè)執(zhí)行效率。

　　Spark設計之初，就想要解決頻繁落盤問題。Spark只在需要交換數(shù)據的Shuffle階段(Shuffle中文翻譯為“洗牌”，需要Shuffle的關鍵性原因是某種具有共同特征的數(shù)據需要最終匯聚到一個計算節(jié)點上進行計算)才會寫磁盤，其它階段，數(shù)據都是按流式的方式進行并行處理。

　　(2)編程模型單一，場景表達能力有限

　　MapReduce模型只有Map和Reduce兩個算子，計算場景的表達能力有限，這會導致用戶在編寫復雜的邏輯(例如join)時，需要自己寫關聯(lián)的邏輯，如果邏輯寫得不夠高效，還會影響性能。

　　與MapReduce不同，Spark將所有的邏輯業(yè)務流程都抽象成是對數(shù)據集合的操作，并提供了豐富的操作算子，如：join、sortBy、groupByKey等，用戶只需要像編寫單機程序一樣去編寫分布式程序，而不用關心底層Spark是如何將對數(shù)據集合的操作轉換成分布式并行計算任務，極大的簡化了編程模型

　　　Spark的核心概念

　　Spark中最核心的概念是RDD(Resilient Distributed Dataset) – 彈性分布式數(shù)據集，顧名思義，它是一個邏輯上統(tǒng)一、物理上分布的數(shù)據集合，Spark通過對RDD的一系列轉換操作來表達業(yè)務邏輯流程，就像數(shù)學中對一個向量的一系列函數(shù)轉換。Spark通過RDD的轉換依賴關系生成對任務的調度執(zhí)行的有向無環(huán)圖，并通過任務調度器將任務提交到計算節(jié)點上執(zhí)行，任務的劃分與調度是對業(yè)務邏輯透明的，極大的簡化了分布式編程模型，RDD也豐富了分布式并行計算的表達能力。

　　RDD上的操作分為Transformation算子和Action算子。Transformation算子用于編寫數(shù)據的變換過程，是指邏輯上組成變換過程。Action算子放在程序的最后一步，用于對結果進行操作，例如：將結果匯總到Driver端(collect)、將結果輸出到HDFS(saveAsTextFile)等，這一步會真正地觸發(fā)執(zhí)行。

　　常見的Transformation算子包括：map、filter、groupByKey、join等，這里面又可以分為Shuffle算子和非Shuffle算子，Shuffle算子是指處理過程需要對數(shù)據進行重新分布的算子，如：groupByKey、join、sortBy等。常見的Action算子如：count、collect、saveAsTextFile等

　　如下是使用Spark編程模型編寫經典的WordCount程序：

　　Spark程序中涉及到幾個概念，Application、Job、Stage、Task。每一個用戶寫的程序對應于一個Application，每一個Action生成一個Job(默認包含一個Stage)，每一個Shuffle算子生成一個新的Stage，每一個Stage中會有N個Task(N取決于數(shù)據量或用戶指定值)。

　　　Spark的架構設計

　　前面講述了Spark 核心邏輯概念，那么Spark的任務是如何運行在分布式計算環(huán)境的呢?接下來我們來看看開源框架Spark的架構設計。

　　Spark是典型的主從(Master- Worker)架構，Master 節(jié)點上常駐 Master守護進程，負責管理全部的 Worker 節(jié)點。Worker 節(jié)點上常駐 Worker 守護進程，負責與 Master 節(jié)點通信并管理 Executor。

　　Spark程序在客戶端提交時，會在Application的進程中啟動一個Driver。看一下官方對Driver的解釋“The process running the main() function of the application and creating the SparkContext”。

　　我們可以把Master和Worker看成是生產部總部老大(負責全局統(tǒng)一調度資源、協(xié)調生產任務)和生產部分部部長(負責分配、上報分部的資源，接收總部的命令，協(xié)調員工執(zhí)行任務)，把Driver和Executor看成是項目經理(負責分配任務和管理任務進度)和普通員工(負責執(zhí)行任務、向項目經理匯報任務執(zhí)行進度)。

　　項目經理D to 總部老大M：Hi，老大，我剛接了一個大項目，需要你通知下面的分部部長W安排一些員工組成聯(lián)合工作小組。

　　總部老大M to 分部部長W：最近項目經理D接了一個大項目，你們幾個部長都安排幾個員工，跟項目經理D一起組成一個聯(lián)合工作小組。

　　分部部長W to 員工E：今天把大家叫到一起，是有個大項目需要各位配合項目經理D去一起完成，稍后會成立聯(lián)合工作小組，任務的分配和進度都直接匯報給項目經理D。

　　項目經理D to 員工E：從今天開始，我們會一起在這個聯(lián)合工作小組工作一段時間，希望我們好好配合，把項目做好。好，現(xiàn)在開始分配任務…

　　員工E to 項目經理D：你分配的xxx任務已完成，請分配其它任務。

　　項目所有任務都完成后，項目經理D to 總部老大M：Hi，老大，項目所有的任務都已經完成了，聯(lián)合工作小組可以解散了，感謝老大的支持。

特別提醒：本網內容轉載自其他媒體，目的在于傳遞更多信息，并不代表本網贊同其觀點。其原創(chuàng)性以及文中陳述文字和內容未經本站證實，對本文以及其中全部或者部分內容、文字的真實性、完整性、及時性本站不作任何保證或承諾，并請自行核實相關內容。本站不承擔此類作品侵權行為的直接責任及連帶責任。如若本網有任何內容侵犯您的權益，請及時聯(lián)系我們，本站將會在24小時內處理完畢。