論文鏈接：https://www.vldb.org/pvldb/vol17/p3759-shi.pdf

引言

近年來 Spark 已經成為離線大數據處理引擎的事實標準，廣泛用于數據倉庫、數據湖、機器學習等領域。在字節跳動內部每天運行百萬級別的 Spark 離線作業，Shuffle 量高達 500PB，CPU 資源需求達到千萬級別。隨著業務的快速發展，用戶對計算資源的需求越來越大，除了增加物理資源之外，如何提高線上 Spark 作業的資源使用效率也是我們亟需解決的問題。

在對線上 Spark 作業做了統計分析發現作業的 CPU & Memory 利用率都低于 50%（利用率指作業實際使用的資源占實際申請資源的比例）；作業的 Data Scan Time 加上 Shuffle Read Block Time 占據了整個運行時間的 45% 左右。從上述指標可以看出，線上 Spark 作業有非常大的資源優化空間，資源使用效率不高的原因主要有以下 3 個方面：

• Slow IO

Slow HDFS IO：離線數據存儲在 HDFS 集群，經常會出現作業讀取 HDFS 慢，導致 CPU/Memory 等待 IO 而處于空閑狀態。

Slow Shuffle IO：線上部署了 External Shuffle Service(ESS)，Shuffle 量非常大（每天超 500PB，一些作業達幾百 TB）， ESS 的穩定性是一個比較大的挑戰，經常出現很高的 Shuffle Read Block Time 導致 CPU/Memroy 空閑，而且會有大量的 FetchFailure 導致 Stage 頻繁 Retry 重算，也浪費了大量資源。

• 粗粒度的資源控制

資源申請：Spark 作業在運行過程中不同的 Stage 對資源的需求不一樣，雖然 Spark 通過 Dynamic Resource Allocation (DRA) 提供了橫向伸縮的能力，但是在縱向資源伸縮方面 Spark 提供的 ResourceProfile 方案并不成熟字節并未采取，導致大量作業運行不同的 Stage 的時候產生資源浪費的情況。

資源使用：Spark 引擎在一些算子的 Spill 策略上并不能很好的控制內存的使用，在一些場景下還會導致 OOM 問題，通過完善 Spill 策略合理利用磁盤可以降低運行中內存的使用，從而節省內存資源。

• 不合理的作業參數

字節內部 Spark 用戶很多，每天運行的作業可以達到 180w+，通過手工調參的方式，一方面浪費測試資源以及人力成本，另一方面需要對 Spark 機制比較熟悉才能有比較好的效果，所以目前線上整體上存在很多不合理的作業參數，導致資源利用率低，或者 Shuffle 不穩定（AQE 相關參數不合理）。

針對以上問題字節跳動基礎架構-基礎技術-批式計算和應用研究中心團隊與上海交通大學的數據通信與數據工程實驗室合作，基于線上的實際情況從三個方面進行了系統性的優化，包括多機制的 Shuffle 優化（穩定資源 External Shuffle Service 增強、混部資源自研 Remote Shuffle Service）、細粒度的資源申請和運行時資源使用控制、規則+算法兩個階段的自動參數調優。經此優化后可以實現大規模上量 50萬+ 作業，日均節省百萬級 CPU 核、PB 級內存。

系統概覽

我們提出了一套資源提效的治理框架，如下圖所示在該框架中，貫穿整個 Spark 作業運行周期的優化包含如下三個方面，分別對應解決引言中的三個問題。

• Multi-Mechanism Shuffle Service

字節內部使用開源 ESS 承載作業 Shuffle，ESS 的機制需部署在 Spark 作業運行的計算資源節點上，在大規模以及復雜的計算資源類型的背景下，Shuffle 穩定性一直是個挑戰。針對不同的計算資源類型，我們提出了不同的 Shuffle 優化方案，大大提升了 Shuffle 穩定性，減少了 Shuffle IO 等待導致的資源空閑以及 Stage 重算導致的資源浪費。

• Fine-Grained Resource Control

在 Spark 引擎層面提供了細粒度的資源申請和使用控制的優化，增加了相關配置參數，結合后續的自動調參，大大提升了資源利用率。

• Two-Stage Configuration Auto Tuning

我們針對周期性調度作業設計了基于規則和基于算法的兩階段自動調參系統，大大降低了人工調參成本，覆蓋了線上大規模的作業，可以讓作業快速收斂到合理的參數運行。

多機制 Shuffle 服務

在 K8s 統一資源池的背景下，字節內部逐漸下線 YARN，將 Spark 作業遷移到 K8s，如系統概覽中的圖所示，Spark 在 K8s 上的計算資源大體可以分為兩大類：

• Dedicated Cluster

• 獨占計算資源會掛載 SSD 作為 Shuffle 數據盤，磁盤能力（吞吐/ IOPS）比較強，提供給高優作業使用。

• Mixed Cluster

• 低優 Spark 作業也使用了很多混部資源，包括在離線混部/ HDFS 混部等，這些計算資源的磁盤能力相對比較差。

開源的 ESS 部署在上述兩種類型的集群中，穩定性都遇到了非常大的挑戰，特別是混部集群，為此我們一種多機制的 Shuffle Service 優化，針對不同類型的集群提供對應的解決方案。

Enhanced External Shuffle Service (ESS)

雖然 SSD 獨占集群磁盤能力強，但是在大規模作業以及 Shuffle 量的背景下，ESS 穩定性依然受到很多挑戰，為此我們進行了一系列優化。

Request Throttling

ESS 服務是被集群上運行的所有 Spark 共享，它在集群的每個節點上都部署了 Shuffle Service 服務進程，該服務進程面向該節點上運行的所有 Spark 作業提供 Shuffle Read 服務，所以個別異常作業就會影響整個集群的 Shuffle 穩定性。線上一般有兩種異常情況的作業對 ESS 服務節點產生比較大的壓力，主要有以下原因影響穩定性：

• Shuffle 規模本身很大的作業，會產生大量的 Chunk Fetch 請求；
• Shuffle 規模不大，但是相關參數不合理造成 Shuffle Read 階段有大量的小于 20KB 的 Chunk Fetch 請求。

異常作業限流基于這些場景，避免異常作業影響整個集群的 Shuffle 穩定性。主要為以下功能：

1. 每個 ESS 節點上會定期監控請求延遲，當延遲超過一定閾值后，該節點會開啟 ESS 限流；
2. 開啟限流的節點將會定期監控節點上所有注冊的 Shuffle 應用的 Fetch 請求量，當任何應用的請求量超過所分配的流量時，該應用將會受到限流；
3. ESS 節點上的應用受到限流后，所允許堆積的請求量會有限制，如果該應用堆積的請求量超過閾值，則暫時不能發送新的 Fetch 請求。

Executor Rolling

我們從歷史統計數據中觀察到，Shuffle 讀取速度慢與節點上寫入的 Shuffle 數據量之間存在高度相關性。其中， Shuffle 寫入量排名前五位的節點，這貢獻了半數的 Shuffle 慢讀取數量，而排名前兩位的節點則占據了 35% 的慢讀取。為了防止 Shuffle 數據集中在某些節點上，避免慢 Shuffle 讀取，研發 Executor 滾動（Executor Rolling）策略，將 Shuffle 寫入的數據更均勻地分布在集群中的節點上。主要功能如下：

1. 在 Shuffle 過程中，記錄每個 Executor 的 Shuffle 寫入大小；
2. 當某個 Executor 寫入大小超過預定的閾值時，釋放該 Executor 并請求新的 Executor；
3. 同時調度器的調度策略也有助于更均勻地分配分配的容器。

Executor rolling 流程

Cloud Shuffle Service (CSS)

對于混合集群，開發了一種基于推送的遠程 Shuffle 服務——CSS，它允許計算和存儲解耦，從而消除混部集群中對本地磁盤的依賴，并提高了混合集群中 Shuffle 的可靠性。CSS 整體架構如下：

CSS 架構概覽

1. Cluster Manager 負責集群的資源分配，并維護集群 Worker 和 Application 狀態，它可以通過 Zookeeper 或者本地磁盤保存這些信息，達到具有 High Availability 的服務。
2. CSS Workers 支持兩種寫入模式，分別是磁盤模式和 HDFS 模式。目前常用的是磁盤模式，每個分區的數據會寫入兩個不同的 Worker 節點，以實現數據冗余。
3. CSS Manager Client 位于 Spark driver 端 ，主要負責與 Cluster Manager 的心跳聯系以及 Application Lifecycle。作業啟動時，也會向 Cluster Manager 申請 Worker。Shuffle Stage 的過程也會統計 Shuffle Stage 的元數據以及 Shuffle 的進展。
4. CSS Worker Client 是一個接入了 Spark Shuffle API 的組件，允許任何 Spark 作業可以直接使用 CSS 而無需額外配置。每個 Executor 會使用 ShuffleClient 進行讀寫。Shuffle Client 負責寫入時候的雙寫，在讀的時候，它可以向任何一個存有數據的 Worker 去讀取這些數據，如果其中一個 Worker 讀取失敗的話，也會自動切換到另一個 Worker 上，并對多讀的數據進行去重。

CSS 具有以下關鍵特性來提升性能和穩定性：

• Push Based Shuffle 模式將相同分區的數據推送到同一組工作節點，這些數據在刷新到磁盤前會與所有緩存在內存中的數據合并寫入，從而允許 Shuffle Read 階段對每個分區數據進行順序讀取；
• Partition Groups 功能允許將多個分區的 Shuffle 數據批量推送，從而減少 I/O 請求；
• 快速內存備份功能，通過內存雙寫與異步刷盤，以較低成本提高容錯力，避免 Stage 失敗帶來的重試成本；
• 負載均衡功能，Cluster Manager 通過周期性收集的集群指標對 Worker 節點資源進行分配。

CSS 開源地址：https://github.com/bytedance/CloudShuffleService

細粒度資源控制

Spark 對于資源的分配（CPU、MEM）不夠細致，使得資源利用率不夠高，且容易出現 OOM。為此我們采取了一些措施提供細粒度的資源控制：

• 增加 Millicores 和 MemoryBurst 參數在配置階段更細粒度的申請資源；
• 優化支持 Spill 的算子和 Spill 模式，減少內存無序爭搶，利用集群的 Disk 資源。

Resource Allocation Control

字節內部的 Spark 作業，使用自研的 Yarn On Kubernetes 框架，綜合考慮了云原生的趨勢和穩定性的要求。該框架的資源調度協議保留了 Yarn 的協議，而在資源調度底層使用的 Kubernetes。為了提升 Spark 作業的資源利用率修改了Spark on Yarn 的參數與交互協議，從而支持細粒度的 CPU 和 Mem 配置。同時， 通過算子 Spill 增強 Spark 已有的內存管理模式。

CPU 資源控制

我們主要是通過在 Executor 內部 Task 運行并發度不變但是降低實際的 CPU 申請值的方式來提升 CPU 利用率。在開源社區版本的 Spark 中，spark.executor.cores 有兩個含義，既代表 Executor 向資源調度系統（YARN，Kubernetes）申請的 Cores 數，同時也代表在 Executor 內部任務運行的并發度，一個 Task 運行至少需要 1 Core。我們在 Spark 中引入了一個新的參數——spark.executor.millicores，該參數被設置時實際創建的 Executor 的 CPU Request 會使用該參數的值，spark.executor.cores 只代表 Executor 中 Task 的并發度。為了保證作業的運行速度，在降低 CPU Request 的同時需要設置一個較大的 CPU Limit，但為了避免過高的超發，我們在實踐中沒有暴露參數給用戶直接設置 CPU Limit，而是在不同的集群設置了各自的超發系數，默認情況下 Limit 會設置成 Request 的兩倍。

Memory 資源控制

Spark Executor 使用的內存可以大致分成兩部分：堆內內存和 Overhead，在默認的 onHeap 模式下，大部分的運行時使用的內存都在堆內，且這部分內存被 JVM 所管理，缺少彈性。調整堆內內存的風險很高，容易引發 OOM 異常。而 Overhead 的使用更靈活，調整 Overhead 的風險更低。我們新增了 spark.executor.memoryBurst.ratio 參數，允許 Spark 申請 Executor 時，按照該參數設置的比例降低 Overhead 內存的 Request 申請，Limit 保持不變。

資源控制示例

Resource Usage Control

Spark 對作業的內存管理比較粗糙，容器運行的時候多個算子盡可能將內存用滿，只有當內存不足的時候才會觸發 spill 操作，數據溢寫到磁盤。這種無序的內存爭搶是作業 OOM 的主要原因。而線上集群磁盤利用率并不高，完全有足夠的空間支持把更多的數據溢寫到磁盤。

為此，我們對 Spark 已有的內存管理模式做了改進，覆蓋更多算子的 Spill，包括 UnsafeExternalSorter、HashAggregateExec。同樣的，我們在 Spark 原有的 Force Spill by Number of Records 模式上，增加了多種算子級別的 Spill 模式：Force Spill by Memory used, Allow Spill by Memory used, Allow Spill by Fraction of memory used。

通過 Spill 機制的改進，我們可以精確控制 Spark Operators 使用的內存，從而確保內存的分配和釋放更加高效。

兩階段自動調參

Spark 作業的配置參數對資源利用率有著顯著影響。然而在生產環境中，對每個作業進行參數調優實驗是不切實際的。因此我們專門為周期性作業建立了一套 Online Tuning Pipeline，充分利用運行時的指標數據。與預先調優參數不同，我們從默認或用戶定義的參數（通常是次優的）開始，并記錄每個作業的運行指標。隨后對這些指標進行分析，以改進下一次作業執行的參數。為了實現在線調優的快速穩定收斂，我們開發了一種如下圖所示的兩階段配置自動調優方法。第一階段是基于規則的調優，利用由 Spark 專家手動編寫的規則，從而避免了低效的探索。第二階段是基于算法的調優，改進了貝葉斯優化算法以提高穩定性，旨在找到更優的參數，同時將生產環境中發生 OOM（內存不足）故障的概率降至最低。

Online Tuning Pipeline

上圖展示了 Spark Tuning Framework 的工作流程與該框架包含的四個組件：

1. Tunning API 控制器負責與數據平臺和最終用戶進行交互，記錄每個任務的優化配置，供用戶查詢任務監控數據。
2. JobAnalyzer 是一個 FlinkJob 消費 Spark 運行過程中的 Event log 數據以及調度系統的其他數據來實時生成任務的運行指標。
3. Rule-Based Tuning：由若干啟發式算法構成，輸入作業的運行指標，該規則樹會按照啟發式規則在樹中的關系最終生成推薦參數。
4. Algorithm-Based Tuning：針對在線調參的安全性要求進行特別優化的貝葉斯優化算法，該算法根據歷史參數的運行情況生成性能更優的推薦參數。

Rule-Based Tuning

每個任務通過聚合生成上一節所展示的指標后，我們就得到了一個任務大致的畫像，例如這個任務有多少個 Task，輸入了多少數據，平均和最大的 CPU 利用率如何等。我們依賴這些指標嘗試使用啟發式算法對作業的參數進行調優，在實踐中由于針對啟發式算法越來越多，我們使用了一個規則樹來描述規則與規則之間的關系。

這些規則調整的參數可以分為三類：對于 CPU 和 內存來說，啟發式規則最基本的方式可以描述為當平均利用率和最大利用率較低時，就在任務并發度不變的前提下降低對應的資源申請量，當利用率過高時，就增大對應資源的申請量；Shuffle 優化如上文所講，導致 Shuffle 問題的主要原因是 ESS 存在大量的隨機 IO，使用更優的參數可以有效的減少隨機 IO 次數。啟發式規則會觀察作業每個 Stage 的 Partition 數量，當 Partition 數量遠大于任務能申請到的 Core 的數量時，會被認為該并發度是不必要的。

Algorithm-Based Tuning

為了應對那些無法通過啟發式規則調優有效優化的作業，我們開發了一種基于算法的調優方法，采用了貝葉斯優化算法。目標是找到能最小化參數評估函數的配置。為了提升利用率，評估指標 f(x) 定義成為 CPU 和內存利用率乘積的倒數。我們選擇高斯過程 (GP) 作為目標函數的替代模型。

在這個模型中，Expected Improvement(EI) 通常被用作為采集函數。它衡量了未見參數 x， 可能帶來的期望改進。作業下一次運行的推薦參數，x* 可以通過最小化采集函數獲得。為了求解這個優化問題，我們使用遺傳算法，以便對參數空間進行高效且有針對性的探索。

算法調優能夠更高效且有針對性地探索參數空間，在提升 Spark 作業資源利用率的同時確保穩定性。符號說明如下：

實驗及成果

這部分內容將從穩定性、性能和資源利用率的角度分析并回答以下問題：

• Shuffle 服務提升了多少性能？
• 資源控制如何幫助提高穩定性和利用率？
• 通過配置調優可以節省多少資源？
• 這些技術在生產環境中的優勢是什么？

Enhanced ESS and CSS Evaluations

我們評估了多機制 Shuffle 服務帶來的效果，包括通過生產工作負載評估增強型 ESS 的穩定性，以及使用 TPC-DS Benchmark 評估 CSS 的性能。

Enhanced ESS

Request Throttling 功能通過其在生產集群中的表現進行評估。下圖展示了請求節流對在一段時間內向 ESS 節點發送大量 Shuffle 請求的作業的影響。當由于 Shuffle 請求數量增加導致 ESS 服務器的 Shuffle 延遲開始惡化時，請求節流對貢獻最多 Shuffle 請求的作業生效，減少該作業發送的后續 Shuffle 請求數量。在幾分鐘內，ESS 能夠完成其排隊的請求處理，Shuffle 延遲很快恢復正常。

Executor Rolling 功能也在生產集群上進行了評估，比較了啟動執行器滾動前后的磁盤使用情況。選擇執行器滾動啟動前的 2023 年 1 月的一天和啟動后的 2024 年 1 月的一天的磁盤使用數據，如下圖所示隨著業務的增長，每臺物理機上 Shuffle 的中位數磁盤使用量從 0.7TB 增加到 1.2TB，平均值從 1.8TB 增加到 2.6TB，而最大值從 48TB 降低到 23TB。第 99 百分位數略有下降。因此可以得出結論，啟動執行器滾動后，磁盤使用更加均勻，避免了大量 Shuffle 數據寫入少數執行器的情況。

CSS

本實驗在一個 40 節點的集群上進行，該集群配備了 Intel Xeon Gold 6130 CPUs @ 2.10GHz、64GB * 16 的 DRAM、16 個 13TB 的 HDD 以及 2 個 25GB 的網絡接口卡。

CSS 遠程 Shuffle 集群部署在一個 9 節點的集群上，配備了 Intel Xeon Gold 6230 CPUs @ 2.10GHz、64GB * 16 的 DRAM、12 個 13TB 的 HDD 以及 2 個 25GB 的網絡接口卡

以確保所有 Shuffle 服務從集群中獲得類似的資源分配，實驗也開啟了 Spark Dynamic Executor Allocation，且作業 Executor 源配置相同。

我們用 1TB TPC-DS Benchmark 評估了三種 Shuffle 服務：ESS、Magnet（Spark 3.2 的 Push-based Shuffle 服務）和 CSS 的執行時間和資源利用率。如上圖顯示，CSS 在某些 SQL 查詢中相比 ESS 和 Magnet 提高了超過 10% 的速度，在近 30% 的查詢中觀察到了顯著的性能提升。下表顯示 CSS 相對于 ESS 將總執行時間減少了 0.4 小時，相對于 Magnet 減少了 1.3 小時。此外，與 Magnet 和 CSS 相比，CPU 和內存的分配和使用顯著減少。

CSS 通過在內存中緩存分區數據，并在超過塊大小閾值時刷新數據塊，從而優于 Magnet。此外，Magnet 相比 ESS 表現出性能下降，因為在合并結果接收和映射任務完成時的塊合并過程中，Magnet 會增加額外的等待時間，這在處理較小的 Shuffle 數據量時尤其不利。

Resource Control Evaluations

我們也評估了細粒度資源控制的效果。然而，需要注意的是，這些功能的有效性依賴于配置參數的正確設置和調優。因此，優化結果是兩階段配置調優方法和這些功能的結合。這些功能提供了配置細粒度資源的能力，而兩階段配置調優方法則最大化了這些功能的優勢。

Resource Allocation Control

在 milliCores 實施之前，通過 Shuffle 優化和規則配置調優，我們將約 240,000 個作業的平均 CPU 利用率提高到 56%。2023 年 8 月，我們引入 milliCores 并與參數調優一起發布。從 2023 年 7 月到 2024 年 2 月的一批生產作業，總數量從 21 萬 增加到 36 萬。與此同時，啟用作業的數量從 0 增加到 35 萬，平均 CPU 利用率上升至 94.8%。這表明 milliCores 在提高資源效率方面發揮了關鍵作用。

如下圖所示，我們量化了 memoryBurst 實施帶來的內存分配減少。該特性于 2023 年 10 月推出，此后啟用作業的數量逐漸從 3000+ 增加到 47 萬。到 2024 年 1 月底，實現了每天 55 PB·h 的內存分配節省。這些發現突顯了 memoryBurst 特性在降低內存需求和節省資源方面的有效性。

Resource Usage Control

Spill 優化在生產作業中被廣泛使用，我們分析了幾個典型作業，以評估帶來的改進：

• 數據倉庫作業：在進行大量 Shuffle 寫入操作的情況下，Spill 優化使分配的內存減少了 55%（從 3.2TB 降至 1.45TB），實際內存使用減少了 56%（從 1.21TB 降至 0.53TB）。
• 以 Shuffle Read 為主的作業：Spill 優化顯著減少了階段中的 OOM 任務數量，從 7000+ 減少到 27，同時執行時間從 29 分鐘減少到 11 分鐘。內存使用量顯著下降 65%（從 23.1TB 降至 8.16TB）。
• Sort 作業：內存分配從 330TB 降至 214TB，實際內存使用從 300TB 降至 129TB，減少了 57%。作業持續時間保持相對穩定，從 2.1 小時變為 2.2 小時。磁盤溢出的觸發機制從僅在內存達到滿容量時觸發，轉變為一旦內存達到 1GB 閾值就定期觸發。

Configuration Tuning Evaluations

基于規則和算法的參數調優方法都已在生產環境中部署。以下展示了各種調優方法相關的種資源利用分析結果，其中利用率是通過將總資源使用量除以總資源分配量來計算的。

Rule-Based Tuning

規則基礎調優方法在整個在線過程中經過了多次迭代和優化

• 第一階段 （2022 年 7 月）主要通過調整原有的 CPU 與內存參數來管理作業資源分配。CPU 利用率從 2023 年 3 月前的 51% 上升到 2023 年 3 月后的 59%，內存利用率從 43% 提升至 46%。
• 第二階段和第三階段（2023 年 8 月和 2023 年 10 月）中，隨著 milliCores 和 memoryBurst 的實施與調整，CPU 和內存利用率顯著提升，且調優作業數量增加。隨著規則的優化，所有調優作業的 CPU 利用率達到了 90%，內存利用率達到了 52%，涵蓋了近三分之一的生產作業，并帶來了顯著的改進。

Algorithm-Based Tuning

算法調優方法在生產環境中是作為 Rule-based 調優的補充。對于一些在線 Spark 作業，出于穩定性考慮，可能不會進行規則基礎調優，或者規則可能未涵蓋當前作業的狀態，因此作業可能未得到調優或調優效果不顯著。在這種情況下，這些作業會轉交給算法基礎調優，以進一步提高資源利用率。

下圖展示了由算法基礎調優調整的作業的在線性能。從 2023 年 12 月末起，算法基礎調優接管了約 3000 個作業。在算法介入之前，這批作業的利用率較低，平均 CPU 和內存利用率分別徘徊在 31% 和 21% 左右。經過算法調優后，這些作業的 CPU 和內存利用率逐漸提高，最終穩定在 58% 和 45% 左右。

Two-Stage Tuning

下圖展示了一個項目中所有作業的利用率變化，約 5% 的作業在 2023 年 12 月之后由算法調優接管。因此，曲線前半部分表示項目僅使用規則調優的結果，而后半部分則表示規則兩種調優結合的結果。可以觀察到，在僅使用規則調優和采用兩階段組合的情況下，CPU 利用率變化不大，因為這批作業在使用規則調優時已經具有較高的 CPU 利用率。然而在內存利用率方面，前者約為 21%，而后者約為 26%，有顯著的改進。這是因為這 5% 的作業內存使用比例相對較高，經過算法進一步優化后，內存利用率顯著提升。

算法調優可以進一步提升規則調優獲得的結果。然而，由于其時間消耗大且調優速度較慢，算法基礎調優需要與規則基礎調優結合使用，以在生產環境中實現更好的效果。

Overall Tuning Performance

本文提出的技術經過了廣泛的迭代、優化和部署。我們將通過兩年的數據對這些技術在提升字節跳動大規模 Spark 工作負載資源效率方面的效果進行了統計分析。

上圖展示了 2022 年至 2023 年所有 Spark 作業資源效率的提升情況。總體提升情況如下：

• 在 CPU 利用率方面，通過規則配置調優的迭代優化，利用率從 2022 年的 48% 提升到 2023 年的 60%，隨后隨著 milliCores 特性的引入，利用率進一步上升到超過 70%；
• 內存利用率通過規則配置調優從 2022 年的 43.3% 提高到 46%，并通過 memoryBurst 特性進一步提升至接近 50%；
• Shuffle 方面，Shuffle Block Ratio，表示等待 Shuffle 的時間比例，最初在 2022 年 1 月約為 14%，通過 Enhanced ESS 和 CSS 在 Shuffle 速度和穩定性方面的增強減少到約 4%-6%，隨后通過參數調優進一步降低至 2%。

整體上，我們服務的用戶數量從 9000+ 增加到 1.4 萬，優化的作業數量從 25 萬激增至 53 萬。相應地，CPU 利用率超過 60% 的作業的日均數量從 2023 年 3 月的 15 萬 增加到 2024 年 2 月的 30 萬 以上，而內存利用率超過 50% 的作業也達到了約 15 萬。CPU 和內存資源分配的日均節省峰值分別達到 100 萬 核/日和 4.6 PB/日。此外，作業執行時間也顯著減少，在 2024 年 2 月減少了約 11 分鐘，占此前平均作業執行時間的 31%。

作者介紹：

• 程航，畢業于新加坡國立大學，21年加入字節，現任字節跳動大數據開發工程師，專注大數據分布式計算領域，主要負責 Spark 內核開發及字節自研 Shuffle Service 開發，現主要負責分布式機器學習框架相關的開發。
• 魏中佳，畢業于電子科技大學，18年加入字節，現任字節跳動大數據開發工程師，專注大數據分布式計算領域，主要負責 Spark 內核開發及字節自研 Shuffle Service 開發，現主要負責數據湖相關的開發。