這篇文章給大家介紹EMR Spark引擎是如何做到在存算分離下寫(xiě)性能提升10倍以上的，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對(duì)大家能有所幫助。

公司主營(yíng)業(yè)務(wù)：網(wǎng)站制作、網(wǎng)站設(shè)計(jì)、移動(dòng)網(wǎng)站開(kāi)發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競(jìng)爭(zhēng)能力。成都創(chuàng)新互聯(lián)公司是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開(kāi)放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對(duì)我們的高要求，感謝他們從不同領(lǐng)域給我們帶來(lái)的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會(huì)用頭腦與智慧不斷的給客戶帶來(lái)驚喜。成都創(chuàng)新互聯(lián)公司推出株洲免費(fèi)做網(wǎng)站回饋大家。

引言

隨著大數(shù)據(jù)技術(shù)架構(gòu)的演進(jìn)，存儲(chǔ)與計(jì)算分離的架構(gòu)能更好的滿足用戶對(duì)降低數(shù)據(jù)存儲(chǔ)成本，按需調(diào)度計(jì)算資源的訴求，正在成為越來(lái)越多人的選擇。相較 HDFS，數(shù)據(jù)存儲(chǔ)在對(duì)象存儲(chǔ)上可以節(jié)約存儲(chǔ)成本，但與此同時(shí)，對(duì)象存儲(chǔ)對(duì)海量文件的寫(xiě)性能也會(huì)差很多。

MapReduce(EMR) 是騰訊云的一個(gè)云端托管的彈性開(kāi)源泛 Hadoop 服務(wù)，支持 Spark、Hbase、Presto、Flink、Druid 等大數(shù)據(jù)框架。

近期，在支持一位 EMR 客戶時(shí)，遇到典型的存儲(chǔ)計(jì)算分離應(yīng)用場(chǎng)景?？蛻羰褂昧?EMR 中的 Spark 組件作為計(jì)算引擎，數(shù)據(jù)存儲(chǔ)在對(duì)象存儲(chǔ)上。在幫助客戶技術(shù)調(diào)優(yōu)過(guò)程中，發(fā)現(xiàn)了 Spark 在海量文件場(chǎng)景下寫(xiě)入性能比較低，影響了架構(gòu)的整體性能表現(xiàn)。

在深入分析和優(yōu)化后，我們最終將寫(xiě)入性能大幅提升，特別是將寫(xiě)入對(duì)象存儲(chǔ)的性能提升了 10 倍以上，加速了業(yè)務(wù)處理，獲得了客戶好評(píng)。

下面將介紹在存儲(chǔ)計(jì)算分離架構(gòu)中， EMR Spark 計(jì)算引擎如何提升在海量文件場(chǎng)景下的寫(xiě)性能。

一、問(wèn)題背景

Apache Spark 是專(zhuān)為大規(guī)模數(shù)據(jù)處理而設(shè)計(jì)的快速通用的計(jì)算引擎，可用來(lái)構(gòu)建大型的、低延遲的數(shù)據(jù)分析應(yīng)用程序。Spark 是 UC Berkeley AMP lab (加州大學(xué)伯克利分校的 AMP 實(shí)驗(yàn)室)所開(kāi)源的類(lèi) Hadoop MapReduce 的通用并行框架，Spark 擁有 Hadoop MapReduce 所具有的優(yōu)點(diǎn)。

與 Hadoop 不同，Spark 和 Scala 能夠緊密集成，其中的 Scala 可以像操作本地集合對(duì)象一樣輕松地操作分布式數(shù)據(jù)集。盡管創(chuàng)建 Spark 是為了支持分布式數(shù)據(jù)集上的迭代作業(yè)，但是實(shí)際上它是對(duì) Hadoop 的補(bǔ)充，可以在 Hadoop 文件系統(tǒng)中并行運(yùn)行，也可以運(yùn)行在云存儲(chǔ)之上。

在這次技術(shù)調(diào)優(yōu)過(guò)程中，我們研究的計(jì)算引擎是 EMR 產(chǎn)品中的 Spark 組件，由于其優(yōu)異的性能等優(yōu)點(diǎn)，也成為越來(lái)越多的客戶在大數(shù)據(jù)計(jì)算引擎的選擇。

存儲(chǔ)上，客戶選擇的是對(duì)象存儲(chǔ)。在數(shù)據(jù)存儲(chǔ)方面，對(duì)象存儲(chǔ)擁有可靠，可擴(kuò)展和更低成本等特性，相比 Hadoop 文件系統(tǒng) HDFS，是更優(yōu)的低成本存儲(chǔ)方式。海量的溫冷數(shù)據(jù)更適合放到對(duì)象存儲(chǔ)上，以降低成本。

在 Hadoop 的生態(tài)中，原生的 HDFS 存儲(chǔ)也是很多場(chǎng)景下必不可少的存儲(chǔ)選擇，所以我們也在下文加入了與 HDFS 的存儲(chǔ)性能對(duì)比。

回到我們想解決的問(wèn)題中來(lái)，先來(lái)看一組測(cè)試數(shù)據(jù)，基于 Spark-2.x 引擎，使用 SparkSQL 分別對(duì) HDFS、對(duì)象存儲(chǔ)寫(xiě)入 5000 文件，分別統(tǒng)計(jì)執(zhí)行時(shí)長(zhǎng)：

從測(cè)試結(jié)果可以看出，寫(xiě)入對(duì)象存儲(chǔ)耗時(shí)是寫(xiě)入 HDFS 的 29 倍，寫(xiě)入對(duì)象存儲(chǔ)的性能要比寫(xiě)入 HDFS 要差很多。而我們觀察數(shù)據(jù)寫(xiě)入過(guò)程，發(fā)現(xiàn)網(wǎng)絡(luò) IO 并不是瓶頸，所以需要深入剖析一下計(jì)算引擎數(shù)據(jù)輸出的具體過(guò)程。

二、Spark數(shù)據(jù)輸出過(guò)程剖析

1. Spark數(shù)據(jù)流

先通過(guò)下圖理解一下 Spark 作業(yè)執(zhí)行過(guò)程中數(shù)據(jù)流轉(zhuǎn)的主要過(guò)程：

首先，每個(gè) task 會(huì)將結(jié)果數(shù)據(jù)寫(xiě)入底層文件系統(tǒng)的臨時(shí)目錄 _temporary/task_[id]，目錄結(jié)果示意圖如下所示：

到此為止，executor 上的 task 工作其實(shí)已經(jīng)結(jié)束，接下來(lái)將交由 driver，將這些結(jié)果數(shù)據(jù)文件 move 到 hive 表最終所在的 location 目錄下，共分三步操作：

第一步，調(diào)用 OutputCommiter 的 commitJob 方法做臨時(shí)文件的轉(zhuǎn)存和合并：

通過(guò)上面示意圖可以看到，commitJob 會(huì)將 task_[id] 子目錄下的所有數(shù)據(jù)文件 merge 到了上層目錄 ext-10000。

接下來(lái)如果是 overwrite 覆蓋寫(xiě)數(shù)據(jù)模式，會(huì)先將表或分區(qū)中已有的數(shù)據(jù)移動(dòng)到 trash 回收站。

在完成上述操作后，會(huì)將第一步中合并好的數(shù)據(jù)文件，move 到 hive 表的 location，到此為止，所有數(shù)據(jù)操作完成。

2. 定位分析根因

有了上面對(duì) Spark 數(shù)據(jù)流的分析，現(xiàn)在需要定位性能瓶頸在 driver 端還是 executor 端？觀察作業(yè)在 executor 上的耗時(shí)：

發(fā)現(xiàn)作業(yè)在 executor 端執(zhí)行時(shí)長(zhǎng)差異不大，而總耗時(shí)卻差異卻非常大， 這說(shuō)明作業(yè)主要耗時(shí)在 driver 端。

在 driver 端有 commitJob、trashFiles、moveFiles 三個(gè)操作階段，具體是在 driver 的哪些階段耗時(shí)比較長(zhǎng)呢？

我們通過(guò) spark-ui 觀察 Thread dump (這里通過(guò)手動(dòng)刷新 spark-ui 或者登錄 driver 節(jié)點(diǎn)使用 jstack 命令查看線程堆棧信息)，發(fā)現(xiàn)這三個(gè)階段都比較慢， 下面我們來(lái)分析這三部分的源碼。

 

3. 源碼分析

（1）JobCommit階段

Spark 使用的是 Hadoop 的 FileOutputCommitter 來(lái)處理文件合并操作， Hadoop 2.x 默認(rèn)使用 mapreduce.fileoutputcommitter.algorithm.version=1，使用單線程 for 循環(huán)去遍歷所有 task 子目錄，然后做 merge path 操作，顯然在輸出文件很多情況下，這部分操作會(huì)非常耗時(shí)。

特別是對(duì)對(duì)象存儲(chǔ)來(lái)說(shuō)，rename 操作并不僅僅是修改元數(shù)據(jù)，還需要去 copy 數(shù)據(jù)到新文件。

（2）TrashFiles階段

trashFiles 操作是單線程 for 循環(huán)來(lái)將文件 move 到文件回收站，如果需要被覆蓋寫(xiě)的數(shù)據(jù)比較多，這步操作會(huì)非常慢。

（3）MoveFiles階段

與前面問(wèn)題類(lèi)似，在 moveFiles 階段也是采用了單線程 for 循環(huán)方式來(lái) move 文件。

4. 問(wèn)題小結(jié)

• Spark 引擎寫(xiě)海量文件性能瓶頸在Driver端；

• 在 Driver 的 CommitJob、TrashFiles、MoveFiles 三個(gè)階段執(zhí)行耗時(shí)都比較長(zhǎng)；

• 三個(gè)階段耗時(shí)長(zhǎng)的原因都是因?yàn)閱尉€程循環(huán)挨個(gè)處理文件；

• 對(duì)象存儲(chǔ)的 rename 性能需要拷貝數(shù)據(jù)，性能較差，導(dǎo)致寫(xiě)海量文件時(shí)耗時(shí)特別長(zhǎng)。 

三、優(yōu)化結(jié)果

可以看到社區(qū)版本大數(shù)據(jù)計(jì)算引擎在處理對(duì)象存儲(chǔ)的訪問(wèn)上還在一定的性能問(wèn)題，主要原因是大多數(shù)數(shù)據(jù)平臺(tái)都是基于 HDFS 存儲(chǔ)，而 HDFS 對(duì)文件的 rename 只需要在 namenode 上修改元數(shù)據(jù)，這個(gè)操作是非?？斓模蝗菀着龅叫阅芷款i。

而目前數(shù)據(jù)上云、存算分離是企業(yè)降低成本的重要考量，所以我們分別嘗試將 commitJob、trashFiles、moveFile 代碼修改成多線程并行處理文件，提升對(duì)文件寫(xiě)操作性能。

基于同樣的基準(zhǔn)測(cè)試，使用 SparkSQL 分別對(duì) HDFS、對(duì)象存儲(chǔ)寫(xiě)入 5000 個(gè)文件，我們得到了優(yōu)化后的結(jié)果如下圖所示：

最終寫(xiě) HDFS 性能提升 41%，寫(xiě)對(duì)象存儲(chǔ)性能提升 1100% ！

關(guān)于EMR Spark引擎是如何做到在存算分離下寫(xiě)性能提升10倍以上的就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到。

網(wǎng)頁(yè)標(biāo)題：EMRSpark引擎是如何做到在存算分離下寫(xiě)性能提升10倍以上的
URL地址：http://www.rwnh.cn/article16/jdgjgg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供外貿(mào)建站、網(wǎng)站改版、定制開(kāi)發(fā)、響應(yīng)式網(wǎng)站、服務(wù)器托管、企業(yè)網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)