溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章給大家介紹EMR Spark引擎是如何做到在存算分離下寫性能提升10倍以上的，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。
隨著大數據技術架構的演進，存儲與計算分離的架構能更好的滿足用戶對降低數據存儲成本，按需調度計算資源的訴求，正在成為越來越多人的選擇。相較 HDFS，數據存儲在對象存儲上可以節約存儲成本，但與此同時，對象存儲對海量文件的寫性能也會差很多。
MapReduce(EMR) 是騰訊云的一個云端托管的彈性開源泛 Hadoop 服務，支持 Spark、Hbase、Presto、Flink、Druid 等大數據框架。
近期，在支持一位 EMR 客戶時，遇到典型的存儲計算分離應用場景。客戶使用了 EMR 中的 Spark 組件作為計算引擎，數據存儲在對象存儲上。在幫助客戶技術調優過程中，發現了 Spark 在海量文件場景下寫入性能比較低，影響了架構的整體性能表現。
在深入分析和優化后，我們最終將寫入性能大幅提升，特別是將寫入對象存儲的性能提升了 10 倍以上，加速了業務處理，獲得了客戶好評。
下面將介紹在存儲計算分離架構中， EMR Spark 計算引擎如何提升在海量文件場景下的寫性能。
Apache Spark 是專為大規模數據處理而設計的快速通用的計算引擎，可用來構建大型的、低延遲的數據分析應用程序。Spark 是 UC Berkeley AMP lab (加州大學伯克利分校的 AMP 實驗室)所開源的類 Hadoop MapReduce 的通用并行框架，Spark 擁有 Hadoop MapReduce 所具有的優點。
與 Hadoop 不同，Spark 和 Scala 能夠緊密集成，其中的 Scala 可以像操作本地集合對象一樣輕松地操作分布式數據集。盡管創建 Spark 是為了支持分布式數據集上的迭代作業，但是實際上它是對 Hadoop 的補充，可以在 Hadoop 文件系統中并行運行，也可以運行在云存儲之上。
在這次技術調優過程中，我們研究的計算引擎是 EMR 產品中的 Spark 組件，由于其優異的性能等優點，也成為越來越多的客戶在大數據計算引擎的選擇。
存儲上，客戶選擇的是對象存儲。在數據存儲方面，對象存儲擁有可靠，可擴展和更低成本等特性，相比 Hadoop 文件系統 HDFS，是更優的低成本存儲方式。海量的溫冷數據更適合放到對象存儲上，以降低成本。
在 Hadoop 的生態中，原生的 HDFS 存儲也是很多場景下必不可少的存儲選擇，所以我們也在下文加入了與 HDFS 的存儲性能對比。
回到我們想解決的問題中來，先來看一組測試數據，基于 Spark-2.x 引擎，使用 SparkSQL 分別對 HDFS、對象存儲寫入 5000 文件，分別統計執行時長：
從測試結果可以看出，寫入對象存儲耗時是寫入 HDFS 的 29 倍，寫入對象存儲的性能要比寫入 HDFS 要差很多。而我們觀察數據寫入過程，發現網絡 IO 并不是瓶頸，所以需要深入剖析一下計算引擎數據輸出的具體過程。
先通過下圖理解一下 Spark 作業執行過程中數據流轉的主要過程：
首先，每個 task 會將結果數據寫入底層文件系統的臨時目錄 _temporary/task_[id]，目錄結果示意圖如下所示：
到此為止，executor 上的 task 工作其實已經結束，接下來將交由 driver，將這些結果數據文件 move 到 hive 表最終所在的 location 目錄下，共分三步操作：
第一步，調用 OutputCommiter 的 commitJob 方法做臨時文件的轉存和合并：
通過上面示意圖可以看到，commitJob 會將 task_[id] 子目錄下的所有數據文件 merge 到了上層目錄 ext-10000。
接下來如果是 overwrite 覆蓋寫數據模式，會先將表或分區中已有的數據移動到 trash 回收站。
在完成上述操作后，會將第一步中合并好的數據文件，move 到 hive 表的 location，到此為止，所有數據操作完成。
有了上面對 Spark 數據流的分析，現在需要定位性能瓶頸在 driver 端還是 executor 端？觀察作業在 executor 上的耗時：
發現作業在 executor 端執行時長差異不大，而總耗時卻差異卻非常大， 這說明作業主要耗時在 driver 端。
在 driver 端有 commitJob、trashFiles、moveFiles 三個操作階段，具體是在 driver 的哪些階段耗時比較長呢？
我們通過 spark-ui 觀察 Thread dump (這里通過手動刷新 spark-ui 或者登錄 driver 節點使用 jstack 命令查看線程堆棧信息)，發現這三個階段都比較慢， 下面我們來分析這三部分的源碼。
Spark 使用的是 Hadoop 的 FileOutputCommitter 來處理文件合并操作， Hadoop 2.x 默認使用 mapreduce.fileoutputcommitter.algorithm.version=1，使用單線程 for 循環去遍歷所有 task 子目錄，然后做 merge path 操作，顯然在輸出文件很多情況下，這部分操作會非常耗時。
特別是對對象存儲來說，rename 操作并不僅僅是修改元數據，還需要去 copy 數據到新文件。
trashFiles 操作是單線程 for 循環來將文件 move 到文件回收站，如果需要被覆蓋寫的數據比較多，這步操作會非常慢。
與前面問題類似，在 moveFiles 階段也是采用了單線程 for 循環方式來 move 文件。
Spark 引擎寫海量文件性能瓶頸在Driver端；
在 Driver 的 CommitJob、TrashFiles、MoveFiles 三個階段執行耗時都比較長；
三個階段耗時長的原因都是因為單線程循環挨個處理文件；
對象存儲的 rename 性能需要拷貝數據，性能較差，導致寫海量文件時耗時特別長。
可以看到社區版本大數據計算引擎在處理對象存儲的訪問上還在一定的性能問題，主要原因是大多數數據平臺都是基于 HDFS 存儲，而 HDFS 對文件的 rename 只需要在 namenode 上修改元數據，這個操作是非常快的，不容易碰到性能瓶頸。
而目前數據上云、存算分離是企業降低成本的重要考量，所以我們分別嘗試將 commitJob、trashFiles、moveFile 代碼修改成多線程并行處理文件，提升對文件寫操作性能。
基于同樣的基準測試，使用 SparkSQL 分別對 HDFS、對象存儲寫入 5000 個文件，我們得到了優化后的結果如下圖所示：
最終寫 HDFS 性能提升 41%，寫對象存儲性能提升 1100% ！
關于EMR Spark引擎是如何做到在存算分離下寫性能提升10倍以上的就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
