Spark 是字節(jié)跳動內部使用廣泛的計算引擎，已廣泛應用于各種大規(guī)模數(shù)據(jù)處理、機器學習和大數(shù)據(jù)場景。目前中國區(qū)域內每天的任務數(shù)已經(jīng)超過 150 萬，每天的 Shuffle 讀寫數(shù)據(jù)量超過 500 PB。同時某些單個任務的 Shuffle 數(shù)據(jù)能夠達到數(shù)百 TB 級別。
與此同時作業(yè)量與 Shuffle 的數(shù)據(jù)量還在增長，相比去年，今年的天任務數(shù)增加了 50 萬，總體數(shù)據(jù)量的增長超過了 200 PB，達到了 50% 的增長。Shuffle 是用戶作業(yè)中會經(jīng)常觸發(fā)的功能，各種 ReduceByKey、groupByKey、Join、sortByKey 和 Repartition 的操作都會使用到 Shuffle。所以在大規(guī)模的 Spark 集群內，Spark Shuffle 經(jīng)常會成為性能及穩(wěn)定性的瓶頸；Shuffle 的計算也會涉及到頻繁的磁盤和網(wǎng)絡 IO 操作，解決辦法是需要把所有節(jié)點的數(shù)據(jù)進行重新分區(qū)并組合。下文將詳細介紹字節(jié)跳動在 Spark Shuffle 云原生化方向的大規(guī)模演進實踐。
Spark Shuffle 原理介紹
在社區(qū)版 ESS 模式下默認使用的 Shuffle 模式的基本原理中，剛才提到 Shuffle 的計算會把數(shù)據(jù)進行重新分區(qū)，這里就是把 Map 的數(shù)據(jù)重新組合到所有的 Reducers 上。如果有 M 個 Mappers 和 R 個 Reducers，就會把 M Mappers 的 Partition 數(shù)據(jù)分區(qū)成后面 R Reducers 的 Partition。 Shuffle 的過程可以分為兩個階段— Shuffle Write 和 Shuffle Read。Shuffle Write 的時候，Mapper 會把當前的 Partition 按照 Reduce 的 Partition 分成 R 個新的 Partition 并排序后寫到本地磁盤上。生成的 Map Output 包含兩個文件：索引文件和按 Partition 排序后的數(shù)據(jù)文件。當所有的 Mappers 寫完 Map Output 后就會開始第二個階段—Shuffle Read 階段。這個時候每個 Reducer 會訪問所有包含它的 Reducer Partition 的 ESS并讀取對應 Reduce Partition 的數(shù)據(jù)。這里可能會請求到所有 Partition 所在的 ESS，直到這個 Reducer 獲取到所有對應的 Reduce Partition 的數(shù)據(jù)。
在Shuffle Fetch 階段，每個 ESS 會收到所有 Reducer 的請求并返回相應的數(shù)據(jù)。這將產生 M 乘 R 級別的網(wǎng)絡連接和隨機的磁盤讀寫 IO，涉及到大量的磁盤讀寫和網(wǎng)絡傳輸。這就是為什么 Shuffle 會對磁盤以及網(wǎng)絡 IO 的請求都特別頻繁的原因。
由于 Shuffle 對資源的需求和消耗都非常高，所以 CPU、磁盤和網(wǎng)絡開銷都很有可能是造成 Fetch Failure 的原因或 Shuffle 速度較慢的瓶頸。在字節(jié)跳動大規(guī)模的 Shuffle 場景中，同一個 ESS 節(jié)點可能需要同時服務多個商戶，而這些集群沒有進行 IO 的隔離，就可能會導致 Shuffle 成為用戶作業(yè)失敗的主要原因和痛點問題。
因此字節(jié)跳動從 2021 年初開始了 Spark Shuffle 的云原生化相關工作，Spark 作業(yè)與其他大數(shù)據(jù)生態(tài)開始了從Yarn G?del 的遷移。G?del 是字節(jié)跳動基于 Kubernetes 自研的調度器， 遷移時也提供了 Hadoop 上云的遷移方案——Yodel（Yarn on G?del），是一個完全兼容 Hadoop Yarn 的協(xié)議，目標是將所有大數(shù)據(jù)應用平滑地遷移到 Kubernetes 體系上。
在這套遷移工作中，ESS 也做了定制化的相關工作，完成了從之前 Yarn Node Manager 模式下的 Yarn Auxiliary Service 遷移至 Kubernetes DaemonSet 部署模方式的適配工作，并開始對 Shuffle 作業(yè)的遷移工作。歷時兩年，在 2023 年順利將所有大數(shù)據(jù)應用包括 Spark 應用都遷移到了如今的云原生生態(tài)上。
云原生化挑戰(zhàn)
在云原生化的遷移過程中，也遇到了很多挑戰(zhàn)：
-
首先，從 NM 遷移到 DaemonSet 的過程中，DaemonSet 上 ESS 的 CPU 有非常嚴格的限制，而在之前的 NM 模式下，ESS 基本上可以使用所有的 CPU 資源。所以在這個遷移實踐中，往往最開始設置的 ESS 的 CPU 資源是不夠的，需要經(jīng)過持續(xù)不斷的調整。后續(xù)，某些高優(yōu)集群甚至直接對 ESS 的 CPU 放開使用。
-
同時， DaemonSet 和 Pod 對 Spark 作業(yè)的 CPU 有更嚴格的限制。這也導致不少用戶的作業(yè)遷移到了新的架構后變得更加緩慢了。這是因為在之前的模式下，CPU 是有一定的超發(fā)的，因此需要對這個情況進行調整。我們在 Kubernetes 和 G?del 架構下開啟了 CPU Shares 模式，使用戶在遷移過程中感知不到性能上的差異。
-
另外，Pod 對內存的限制也非常嚴格，這導致 Shuffle Read 時無法使用空閑的 page cache 資源，從而導致 Shuffle Read 時 page cache 的命中率非常低。在這個過程中就會帶來更多的磁盤 IO 開銷，帶來整體性能變差。對此我們采取了適當?shù)拇胧?，通過適當開放 Pod 對 page cache 的使用，降低 Shuffle 在遷移后對性能的影響。
云原生化收益
完成遷移工作之后，我們成功地將所有的離線資源池完成統(tǒng)一，在調度層面能夠更友好地實施一些優(yōu)化和調度策略，從而提高整體的資源使用率。ESS Daemonset 相比于 Yarn Auxilary Service 也獲得了不少的收益。首先，ESS DaemonSet 被獨立出來成為一個服務，脫離與 NM 的緊耦合，減少了運維成本。另外，Kubernetes 和 Pod 對 ESS 資源的隔離也增加了 ESS 的穩(wěn)定性，這意味著 ESS 不會再受到其他作業(yè)或者節(jié)點上其它服務的影響。
云原生環(huán)境
云原生化后的 Spark 作業(yè)目前有兩個主要的運行環(huán)境：
-
穩(wěn)定資源集群環(huán)境。這些穩(wěn)定資源的集群主要以服務高優(yōu)和 SLA 的任務為主。部署的磁盤是性能比較好的 SSD 磁盤。對于這些穩(wěn)定資源集群，主要使用基于社區(qū)、深度定制化后的 ESS 服務；使用 SSD 磁盤、ESS 讀寫，也可以使用本地的高性能 SSD 磁盤；部署在 Daemonset 模式，G?del 架構下。
-
混部資源集群環(huán)境。這些集群主要服務于中低游的作業(yè)，以一些臨時查詢、調試或者測試任務為主。這些集群的資源主要都部署在 HDD 磁盤上，有些是通過線上資源出讓或與其他服務共用的或者其他線上服務共同部署的一些資源。這就會使集群的資源都不是獨占的，整體的磁盤性能以及儲存環(huán)境也都不是特別優(yōu)異。
穩(wěn)定資源場景
對于穩(wěn)定集群環(huán)境中因為存在較多的高優(yōu)作業(yè)，首要任務是提高這些作業(yè) Shuffle 的穩(wěn)定性，以及運行時的作業(yè)時長，以保證這些作業(yè)的 SLA。對此為了解決 Shuffle 的問題，對 ESS 深度定制了以下三方面能力：增強 ESS 的監(jiān)控/治理能力、增加 ESS Shuffle 的限流功能、增加 Shuffle 溢寫分裂功能。
ESS 深度定制
-
增強 ESS 的監(jiān)控及治理能力
-
監(jiān)控能力
在監(jiān)控方面，我們在使用開源版本的過程中發(fā)現(xiàn)現(xiàn)有的監(jiān)控不足以深度排查遇到的 Shuffle 問題和當前的 ESS 狀況。就導致沒有辦法快速定位是哪些節(jié)點造成的 Shuffle 問題，也沒有辦法感知到有問題的節(jié)點，因此，我們對監(jiān)控能力進行了一些增強。
首先，增加了監(jiān)控 Shuffle 慢和 Fetch Rate 能力的一些關鍵指標，包括 Queued Chunks 和 Chunk Fetch Rate。Queued Chunks 用于監(jiān)控當前請求 ESS 節(jié)點上請求的堆積，而 Chunk Fetch Rate 用于監(jiān)控這些節(jié)點上請求的流量。同時，我們還將 ESS 的 Metrics 指標接入了字節(jié)跳動的 Metrics 系統(tǒng)，使我們能夠通過系統(tǒng)提供的 Application 維度的指標快速定位 ESS 節(jié)點的堆積情況。在用戶界面 (UI) 方面，我們的改善是通過在 Stage 詳情頁加入兩個新功能，用于展示當前 Stage 里每個 Task Shuffle 遇到最慢的幾個節(jié)點 ，以及經(jīng)過 Stage 統(tǒng)計后所有 Task 遇到 Shuffle 次數(shù)最多的 top 節(jié)點。以上操作不僅方便了用戶查詢也可以利用這些指標進行相關大盤的搭建。
在擁有這些監(jiān)控與 UI 改善后，當用戶在 UI 上看到 Shuffle 慢的時候可以通過 UI 打開對應的 Shuffle 監(jiān)控。這方便用戶和我們快速定位導致 Shuffle 問題的 ESS 節(jié)點，并快速看到這些節(jié)點上的實際情況，從而快速定位這些堆積請求量是來自于哪些 Application。
新增的監(jiān)控也會在運行排查 Shuffle 問題時感知到 ESS 節(jié)點上實際的 Chunk 堆積、Latency 等關鍵指標。這在遇到 Shuffle 慢的情況下有助于更有效地實時采取措施。一旦定位到 Shuffle 問題，我們可以分析情況并提供治理方向和優(yōu)化。
-
治理能力
治理工作主要是通過 BatchBrain 系統(tǒng)實施。BatchBrain 是專門為 Spark 作業(yè)設計的一套智能作業(yè)調優(yōu)系統(tǒng)，它主要對作業(yè)數(shù)據(jù)進行采集，并進行離線與實時分析。這些采集的數(shù)據(jù)包括 Spark 本身的 Event Log、內部打入更詳細的 Timeline event 以及各種 Metrics 指標，包括對 ESS 加上的定制化 Shuffle 指標等。
在離線分析中主要需要對周期性作業(yè)進行治理，根據(jù)每個作業(yè)的歷史特征結合采集的數(shù)據(jù)，對這些作業(yè)的 Shuffle Stage 性能進行分析，并經(jīng)過多次迭代調整，最終提供一套適合的 Shuffle 參數(shù)，使這些作業(yè)在重新運行時可以對優(yōu)化后的 Shuffle 參數(shù)進行運行，從而獲得更好的性能和效果。
BatchBrain 在實時分析部分也可以利用之前添加的 Shuffle 指標進行自動掃描。用戶還可以通過 BatchBrain API 查詢他們集群內的作業(yè) Shuffle 狀況，以及有效定位遇到 Shuffle 堆積的節(jié)點和作業(yè)，并通過報警通知相關人員。如果發(fā)現(xiàn) Shuffle 慢是由于其他的作業(yè)或者異常作業(yè)導致的，用戶也可以直接采取治理動作，例如停止或者驅逐這些作業(yè)，以便為更高優(yōu)先級的作業(yè)騰出更多資源進行 Shuffle。
-
Shuffle 限流功能
通過 Shuffle 的監(jiān)控和治理，我們發(fā)現(xiàn)在 ESS 節(jié)點上遇到 Shuffle 慢的情況時，通常是因為某些任務的數(shù)據(jù)量過于龐大或者設置了不妥的參數(shù)，導致這些 Shuffle Stage 的 Mapper 和 Reducer 數(shù)量都異常地大。異常大量的 Mapper 和 Reducer 數(shù)量可能會導致 ESS 節(jié)點上出現(xiàn)大量的請求堆積，而這些請求的 chunk size 也可能非常小。有些異常作業(yè)的平均 Chunk Size 可能連 20 KB 都沒達到。這些作業(yè)對 ESS 發(fā)送很大的請求量，但 ESS 無法及時處理的情況可能最終會導致請求堆積，甚至引發(fā)作業(yè)的延遲或直接導致失敗。
針對這些現(xiàn)象，我們采取的解決方案是對 ESS 節(jié)點上每個 Application 的總請求量進行限制。當某個 Application 的 Fetch 請求達到了上限，ESS 將拒絕該 Application 發(fā)送的新 Fetch 請求，直到該 Application 等待現(xiàn)有請求的部分結束后才能繼續(xù)發(fā)送新的請求。這樣可以防止單個 Application 占用節(jié)點上過大的資源而導致 ESS 沒有辦法正常為其他作業(yè)請求提供服務的情況。也可以避免其他作業(yè)失敗或 Shuffle 速度變慢，緩解異?；虼笠?guī)模的 Shuffle 作業(yè)對集群 Shuffle 的負面影響。
-
Shuffle 限流功能的特征
-
在作業(yè)運行正常的時候，即使開始了限流功能，也不會對作業(yè)有任何影響。節(jié)點如果可以正常服務，是不需要觸發(fā)任何限流的。
-
只有當節(jié)點的負載超過可以承受的范圍時，Shuffle IO 超過設置的閾值后，才會啟動限流機制，減少異常任務可以向 ESS 發(fā)送的請求數(shù)量，減低這個 ESS 服務當前的壓力。由于這時候 ESS 服務的負載能力已經(jīng)超過了可承受的范圍，即使它收到這些請求，也無法正常返回這些請求，因此，限制異常任務過多的請求反而可能更好地提高這些任務本身的性能。
-
在限流的情況下，也會考慮作業(yè)的優(yōu)先級。對于高優(yōu)的任務，會允許更大的流量。
-
當限流生效后，如果發(fā)現(xiàn) ESS 的流量已經(jīng)恢復正常了將迅速解除限流。受限流的 Application 很快就可以恢復到之前的流量水平。
-
限流的詳細流程
限流功能主要在 ESS 服務端進行，每隔 5 秒在節(jié)點上進行 latency 指標的掃描，當這個 latency 指標超過設置的閾值時，會判定該節(jié)點的負載已經(jīng)超出能夠承受的負載了。接著會對 ESS 節(jié)點當前所有正在進行 Shuffle 的 Application 進行評估，判斷是否要開啟限流。利用之前加上的指標，可以統(tǒng)計近 5 分鐘這個節(jié)點上 Fetch 的總流量和 IO，根據(jù)總流量的上限，對每個 ESS 節(jié)點當前正在運行 Shuffle 的 Application 合理地分配每個 Application 的流量并進行限制。流量分配也會根據(jù) Application 的優(yōu)先級進行調整。如果有任何 Application 的 Shuffle 或者當前堆積的 Chunk Fetch Rate 已經(jīng)超過了其分配的流量，它們將受到限流，新發(fā)送的請求也會被拒絕，直到堆積的請求已經(jīng)部分解除為止。
對于限流的分配，也有一個分級系統(tǒng)。首先，根據(jù)當前節(jié)點上運行 Shuffle 的 Application 的數(shù)量進行分配，Application 的數(shù)量越多，每個 Application 可以分配到的流量就越少。當節(jié)點上 Application 數(shù)量比較少的時候，每個 Application 可以分配更多的流量。限流級別也會根據(jù)節(jié)點上的實際情況每 30 秒進行調整。
在限流的情況下，如果節(jié)點上的 latency 沒有改善，且 Shuffle 的總流量也沒有恢復，就會升級限流，對所有 Application 進行更嚴格的流量限制。相反，如果 latency 有好轉或者節(jié)點流量已經(jīng)在恢復，限流會得到降級或者甚至直接解除掉。最后，限流也會根據(jù)所有作業(yè)的優(yōu)先級進行適當調整。
-
效果及收益
Chunk 的堆積問題得到了明顯的減輕。由于受到限流的限制，異常任務引發(fā)的 Chunk 堆積情況有效的減少了，大大降低了集群中某些節(jié)點上出現(xiàn)大量請求堆積的情況。
另外，Latency 的狀況也得到了改善。在開啟限流前，我們經(jīng)常會看到集群中的節(jié)點出現(xiàn)高延遲的情況。而在啟用限流功能后，整體的 Latency 狀況得到了明顯緩解。通過減少無必要和無效的請求，以及對各種大型或異常任務對 ESS 節(jié)點發(fā)起的請求量進行限制，我們避免了這些異常大型任務對 ESS 服務負載的負面影響，減少了對其他高優(yōu)任務運行的影響。
-
Shuffle 溢寫分裂的功能
在分析一些慢 Shuffle 的作業(yè)時，我們也發(fā)現(xiàn)了另一個現(xiàn)象，一個作業(yè)中每個 Executor 寫 Shuffle 數(shù)據(jù)的數(shù)量可能非常不均衡。由于 ESS 使用了 Dynamic Allocation 機制，每個 Executor 的運行時長和分配的 Map Task 數(shù)量可能不同。這導致在作業(yè)運行期間，大量的 Shuffle 數(shù)據(jù)可能集中在少數(shù)的 Executor 上，導致 Shuffle 數(shù)據(jù)實際上都集中在少數(shù)節(jié)點上。
例如下圖中，我們發(fā)現(xiàn)有 5 個 Executor 的 Shuffle 寫入量超過了其他 Executor 的 10 倍以上。在這種情況下，Shuffle 的請求可能會集中在這幾個節(jié)點上，導致這幾個 ESS 節(jié)點的負載非常高，這也間接增加了 Fetch Failure 的可能性。
針對這種情況，我們提供的解決方案是控制每個容器或每個節(jié)點寫入磁盤的 Shuffle 數(shù)據(jù)總量。這個功能可以從兩個角度實現(xiàn)。首先，通過 Spark 本身來控制 Executor 的 Shuffle Write Size，也就是每個 Executor 在執(zhí)行 Shuffle 時寫入的最大數(shù)據(jù)量。每個 Executor 會計算其當前寫入的 Shuffle 數(shù)據(jù)量，并將這信息匯報給 Spark Driver。Spark Driver 可以使用 Exclude on Failure 機制主動將那些寫入數(shù)據(jù)已經(jīng)超出閾值的 Executor 排除在調度范圍之外，并回收這些 Executor。此外，我們還通過 G?del 調度器改善調度策略，盡量將新的 Executor 調度到其他節(jié)點，避免單個容器的 Shuffle 寫入數(shù)據(jù)過多，從而導致該節(jié)點的磁盤被填滿，或者在 Shuffle Fetch 階段數(shù)據(jù)集中在這幾個 ESS 節(jié)點上。
云原生優(yōu)化
同時，在云原生化上也做了一些 Executor 的調度以及功能的優(yōu)化。通過 G?del 調度器的策略，提升 Shuffle 能力，在調度 Executor 的時候可以盡量避免 Shuffle 負載高的一些節(jié)點，從而緩解這些節(jié)點遇到 Shuffle 問題的可能性。調度器也可以為 Executor 提供更完善的功能，驅逐磁盤壓力特別大的節(jié)點上的 Executor ，或在磁盤剩余空間不足的時候驅逐在磁盤上已經(jīng)寫入大量 Shuffle 的一些容器。 Spark Driver 對于 Executor 的 Shuffle 的控制與這些云原生的調度功能結合起來，可以將整體的 Shuffle 數(shù)據(jù)分散到更多的節(jié)點上，讓 Shuffle Fetch 的階段數(shù)據(jù)和請求量更加均衡。
效果
在線上開啟了上述深度定制的 Shuffle 優(yōu)化后，我們觀察到了顯著的效果。以下是來自三個高優(yōu)集群的一些運行數(shù)據(jù)，每天在這三個高優(yōu)集群中的任務總數(shù)可能超過 30 萬，但平均每天因為 Shuffle Fetch 失敗而最終失敗的作業(yè)總數(shù)平均在 20 到 30 左右，可以說達到了低于 1/10000 的失敗率。如上圖可以觀察到這三個高優(yōu)集群在優(yōu)化后的穩(wěn)定性都有了顯著的提升，也大幅度減少了用戶在 Shuffle 上遇到的問題。
混部資源場景
在混部集群場景的優(yōu)化中值得注意的是，F(xiàn)etch Failure 的情況通常比在穩(wěn)定資源環(huán)境中嚴重得多。每天平均的 Fetch Failure 次數(shù)非常高，主要原因是這些資源大多來自于線上資源空閑的出讓，它們的磁盤 IO 能力和磁盤空間都比較有限。此外，一些資源是與 HDFS 或其他服務混合部署的，由于磁盤 IOPS 和磁盤空間可能非常有限，這對集群的 Shuffle 性能影響較大，因此發(fā)生失敗的概率也較高?；觳抠Y源治理以降低作業(yè)的失敗率，確保作業(yè)的穩(wěn)定性為主要目標，同時需要提高整個集群的 Shuffle 性能，減少資源浪費。
對于混部資源的集群，主要的方案是自研的 Cloud Shuffle Service（CSS），通過提供一個遠端的 Shuffle 服務減少這些作業(yè)對本地磁盤的依賴。
CSS 功能介紹
-
Push Based Shuffle 模式，與剛才介紹的 ESS 的模式不同，在 Push Based Shuffle 模式下，不同 Mapper 的同一個 Reducer Partition 數(shù)據(jù)都會發(fā)送到一個共同的遠程服務上，在這個服務上進行合并，最后在某個 Worker 上寫一個或者多個文件，使得 Reduce 階段的時候可以通過 Sequential Read 模式讀取這些 Partition 數(shù)據(jù)，減少隨機 IO 的開銷。
-
支持 Partition Group 功能，它的作用是將多個分區(qū)數(shù)據(jù)分配到一個 Reducer Partition Group。這樣，在 Map 階段時 Mapper 可以通過 Batch Push 方式傳送數(shù)據(jù)，將批量數(shù)據(jù)直接傳輸?shù)綄謪^(qū)組的工作節(jié)點上，從而降低了批量模式下的 IO 開銷，提高批量模式的性能。
-
快速雙寫備份功能，由于使用的是 push based Shuffle 和聚合模式，所有的數(shù)據(jù)其實都聚集在一個 Worker 上，如果這個 Worker 數(shù)據(jù)丟失的話，等于所有的 Mapper 都要重新計算所對應的數(shù)據(jù)，因此對于 push 聚合的功能，使用一個雙寫備份是比較重要的。CSS 提高寫入的速度是通過采用了雙寫 In-memory 副本模式并進行異步刷盤，這樣Mapper 無需等待刷盤結束就可以繼續(xù)推送后續(xù)的數(shù)據(jù)。
-
負載均衡功能，CSS 通過一個 Cluster Manager 管理所有服務上的節(jié)點。Cluster Manager 會定期去采集和收取 CSS Worker 節(jié)點匯報的負載信息，當有新的 Application 提交的時候，它會進行資源的均衡分配，以確保 Shuffle Write 和 Shuffle Read 會優(yōu)先分配到集群上使用率較低的節(jié)點，從而實現(xiàn)集群中更好的 Shuffle 負載均衡。
整體架構
-
Cluster Manager 負責集群的資源分配，并維護集群 Worker 和 Application 狀態(tài)，它可以通過 Zookeeper 或者本地磁盤保存這些信息，達到具有有 High Availability 的服務。
-
Worker 支持兩種寫入模式，分別是磁盤模式和 HDFS 模式。目前常用的是磁盤模式，每個分區(qū)的數(shù)據(jù)會寫入兩個不同的 Worker 節(jié)點，以實現(xiàn)數(shù)據(jù)冗余。
-
CSS Master 位于 Spark driver 端 ，主要負責與 Cluster Manager 的心跳聯(lián)系以及 Application Lifecycle。作業(yè)啟動時，也會向 Cluster Manager 申請 Worker。 Shuffle Stage 的過程也會統(tǒng)計 Shuffle Stage 的元數(shù)據(jù)以及的進展。
-
Shuffle Client 是一個接入了 Spark Shuffle API 的組件，允許任何 Spark作業(yè)可以直接使用 CSS 而無需額外配置。每個 Executor 會使用 ShuffleClient 進行讀寫。Shuffle Client 負責寫入時候的雙寫，在讀的時候，它可以向任何一個存有數(shù)據(jù)的 Worker 去讀取這些數(shù)據(jù)，如果其中一個 Worker 讀取失敗的話，也會自動切換到另一個 Worker 上，并對多讀的數(shù)據(jù)進行去重。
讀寫過程
CSS 在寫入時，Worker 會直接發(fā)送數(shù)據(jù)，Mapper 會同時將數(shù)據(jù)發(fā)送到兩個 Worker，Worker 不會等到刷磁盤之后返回給 Mapper，而是異步返回給 Mapper 結果，如果遇到失敗，會在下一個請求再通知 Mapper。這時 Mapper 會重新跟節(jié)點申請新的兩個 Worker，重新推送傳送失敗的數(shù)據(jù)。讀的時候可以從任何一個節(jié)點讀取數(shù)據(jù)，通過 Map ID， Attempt ID 和 Batch ID 進行去重。
性能與未來演進
在 1TB 的 TPC-DS Benchmark 性能測試下，CSS 在 30% 以上的 Query 中得到了提升 。
作為一個遠端 Shuffle 服務 CSS 其實特別適合云原生化，支持彈性部署，或者支持更多的遠程儲蓄服務。目前 CSS 也是完成了開源，有興趣的朋友可以去 CSS 開源網(wǎng)站了解更多信息，也希望把后面的一些迭代和優(yōu)化同步到社區(qū)上。在未來云原生化的演進中需要支持彈性部署、支持遠程存儲服務等相關能力。文章來源：http://www.zghlxwxcb.cn/news/detail-760477.html
GitHub：github.com/bytedance/CloudShuffleService文章來源地址http://www.zghlxwxcb.cn/news/detail-760477.html
到了這里，關于字節(jié)跳動 Spark Shuffle 大規(guī)模云原生化演進實踐的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！
