先看下面一組圖表，出于降本增效、提高shuffle可用性/穩(wěn)定性、存儲架構(gòu)分離等因素的考慮，各大廠、工業(yè)界紛紛開始RemoteShuffleService研發(fā)，shuffle過程的新的實現(xiàn)趨勢，各廠方案遍地開花。

??shuffle動作指的是需要把數(shù)據(jù)從某個地方搬到另一個地方，一般在大數(shù)據(jù)框架下大家優(yōu)化的思路也是盡可能減少shuffle的動作，例如通過算子變化操作把多次shuffle歸為一次。

? ? ?用transform動作去替換action的動作取消shuffle的動作的產(chǎn)生，這些手段都是使用者基于某些框架去做的使用層面的優(yōu)化。

? ? ?拿Spark來說，除了使用Spark的時候會有很多優(yōu)化去解決使用層面的最佳實踐外，很多企業(yè)會直接動手修改Spark內(nèi)核自身，對shuffle機(jī)制進(jìn)行翻天覆地的改造，那么為啥企業(yè)最后都會去動shuffle呢？

? ? ?當(dāng)Spark程序在運行的時候，會有很多組件配合工作，例如Yarn做資源管理，NameNode負(fù)責(zé)數(shù)據(jù)元信息的處理，DataNode負(fù)責(zé)數(shù)據(jù)的傳輸，也就是當(dāng)一個Spark跑在Yarn集群上的時候。

? ? ? ?Spark會啟動自己的Driver，這個Driver所在位置也就是Yarn啟動Spark的時候定義的ApplicationMaster的節(jié)點，Spark自己的Executor會運行在Hadoop的DataNode上。

? ? ?假設(shè)一個Spark程序由10個節(jié)點共同運行的，需要做一個shuffle動作，例如group by，那么各個節(jié)點之間比如涉及到數(shù)據(jù)的傳輸和匯總，最終在一個節(jié)點上統(tǒng)計出最終的group by。

? ? ? 默認(rèn)情況下數(shù)據(jù)傳輸是有Executor這個jvm程序負(fù)責(zé)處理，也就是Executor進(jìn)程除了運行task，還要負(fù)責(zé)寫shuffle數(shù)據(jù)，給其他Executor提供shuffle數(shù)據(jù)。

? ? 如果這個時候當(dāng)Executor進(jìn)程任務(wù)過重，導(dǎo)致GC而不能為其他Executor提供shuffle數(shù)據(jù)時，會影響任務(wù)運行，導(dǎo)致整個集群不穩(wěn)定，基本就類似管理動作和數(shù)據(jù)傳輸動作放在一起了。

? ? ? 顯然這么明顯的問題，Spark不會留著不管，所以Spark提供了External shuffle Service，External shuffle Service是長期存在于NodeManager進(jìn)程中的一個輔助服務(wù)。

? ? ? ?通過該服務(wù)來抓取shuffle數(shù)據(jù)，減少了Executor的壓力，在Executor GC的時候也不會影響其他Executor的任務(wù)運行。

? ? ? ?既然有了External shuffle Service，各個大廠為什么還覺得不滿意，需要繼續(xù)優(yōu)化，像阿里的Spark Remote Shuffle Service，幾乎每家大廠都搞了自己的shuffle service 呢？

? ? ? ? 因為即便是External shuffle Service，他的數(shù)據(jù)依舊放在Executor的節(jié)點上，也就是被data node的節(jié)點負(fù)責(zé)管理，本質(zhì)上在傳輸?shù)臅r候會占據(jù)data node 的io，會影響其他獨立的yarn的程序，畢竟os層面來說io是多任務(wù)共享。

? ? ? ? ?其次當(dāng)企業(yè)數(shù)據(jù)量太大，用戶太多，會造成并發(fā)極速下降，隨著任務(wù)數(shù)量上來，臨時存儲容量訴求會大漲，對于這種固定集群，非純云原生的架構(gòu)來說彈性力度跟不上，另外分布式情況下隨著引入的因素越多，穩(wěn)定越差，最終會導(dǎo)致整個集群出現(xiàn)不健康的狀態(tài)。

? ? ? ? 再有就是很多Spark程序是跑在K8S上面，因此對這類Spark Shuffle需要依賴大量當(dāng)前節(jié)點的本地存儲的場景，天然就不友好，也和k8s的容錯機(jī)制不兼容，造成出現(xiàn)問題后，任務(wù)的整體恢復(fù)成本非常高。

歸納下來就是：

Spark社區(qū)在2019年其實也在開始思考這種場景的問題，進(jìn)行了一些討論：https://issues.apache.org/jira/browse/SPARK-25299?spm=a2c6h.12873639.0.0.3c4b194d4ExHWP

????該Issue主要希望解決的問題是在云原生環(huán)境下，Spark需要將Shuffle數(shù)據(jù)寫出到遠(yuǎn)程的服務(wù)中。但是我們經(jīng)過調(diào)研后發(fā)現(xiàn)Spark 3.0（之前的master分支）只支持了部分的接口，而沒有對應(yīng)的實現(xiàn)。該接口主要希望在現(xiàn)有的Shuffle代碼框架下，將數(shù)據(jù)寫到遠(yuǎn)程服務(wù)中。如果基于這種方式實現(xiàn)，比如直接將Shuffle以流的方式寫入到HDFS或者Alluxio等高速內(nèi)存系統(tǒng)，會有相當(dāng)大的性能開銷。

????所以各個大廠都在考慮從自身的角度，如何完美的把計算和數(shù)據(jù)傳輸真正切分開，這就誕生了在Spark基礎(chǔ)上還需要再次優(yōu)化shuffle的需求，那么一般大家怎么優(yōu)化呢？

????其實思路差不多，既然shuffle是用來做數(shù)據(jù)傳輸，傳輸?shù)膬?nèi)容是Executor計算出放在data node上的臨時文件，那么就在Executor寫入臨時文件的時候把它放到另外的地方去，讀取的時候讓其他節(jié)點從其他地方去讀就好了。

????這個其他地方就非常重要了，他需要解決高io，高并發(fā)，高性能，從而不影響整個程序進(jìn)行，另外因為是其他地方，所以自然也就解決了K8S場景下，對磁盤和數(shù)據(jù)存儲的訴求，可以極大的利用K8S的優(yōu)勢，進(jìn)行無縫的融合了，完美解決Spark on Kubernetes方案中對于本地磁盤的依賴。

????像阿里的Remote Shuffle Service，就是一個完整的緩存服務(wù)器：

? ? Spark RSS架構(gòu)包含三個角色: Master, Worker, Client。Master和Worker構(gòu)成服務(wù)端，Client以不侵入的方式集成到Spark ShuffleManager里（RssShuffleManager實現(xiàn)了ShuffleManager接口）。

實現(xiàn)流程是：

總體來講，RSS的設(shè)計要點總結(jié)為3個層面：

像其他大廠大家都差不多，優(yōu)化思路基本都是圍繞這個方向，大部分企業(yè)都有自己的存儲或者緩存系統(tǒng)，把shuffle對接到這類系統(tǒng)上也是合情合理，于是自然就催生了對spark的具體改造。