一、痛點 & 挑戰

在分析業務痛點和挑戰之前，先要清楚業務現狀。

1、現狀概覽

字節跳動數據平臺目前使用了 1 萬多個任務執行隊列，支持 DTS、HSQL、Spark、Python、Flink、Shell 等 50 多種類型的任務。

自動計算治理框架目前已經完成了離線任務的接入，包括 HSQL、Hive to X 的 DTS任務、AB test 和底層通過 Spark 引擎執行的任務，涉及到上千個隊列，國內可優化的任務的任務優化覆蓋率達到 60% 以上。另外實時任務的優化也在同步推進。

2、痛點：手動調參常?問題

在手動調參的過程中，我們常常面臨以下困境：

• 系統復雜度：

大數據計算系統與數據處理架構涵蓋多種技術和組件，對其參數的調整需深刻理解各組件的運作機制及其相互依賴。以 Spark 為例，其擁有上百個適用于不同場景的參數，而這些參數可能互相影響，增加了調優的難度。過去，我們通常依賴單一任務模板進行少量參數調整，雖然此法能讓單項任務搶占資源，卻難以保證整體業務的及時性和穩定性。

• 動態變化：

計算環境、數據量和業務需求可能隨時變動，這要求調優工作需具備高度的靈活性和適應性，以迅速應對各種變化。

• 專業知識缺乏：

通常由數據分析師來執行優化任務，但他們更側重于業務場景而非底層邏輯。因此，我們希望通過自動化方案沉淀專業知識，提供一站式解決方案。

• 一致性與可重復性缺失：

不同人員操作可能導致不一致的結果，手動調優往往難以復現。例如，昨天的分區調優效果良好，但明天可能因數據量增加而導致內存溢出（OOM），后續運維包括復盤將需要投入大量時間成本。

3、挑戰：復雜的優化場景和目標

針對業務方的優化需求，通常包括提高系統穩定性、降低運營成本、解決任務阻塞及提升系統健康度等多個方面。為選擇最適合的優化策略，需深入理解以下幾個常見場景：

• 穩定性與健康度：提高穩定性通常意味著需要犧牲一些資源利用率以保障運行效率；而提升健康度則旨在追求較高的資源利用率，盡管可能會對運行效率產生一些影響。
• 成本優化：主要包括回收無效成本和最大化資源利用率兩個方向。由于業務方常存在大量未被充分利用的資源，我們需要協助他們提升任務的運行效率和縮短產出時間。
• 解決阻塞：通過調整算力和內存等參數來緩解阻塞。若參數調優無法完全解決阻塞問題，就需要與用戶協作，優化任務的調度時間。

4、業務優化場景需求分析

針對之前提及的優化場景，以下是一些具體的解決策略：

• 穩定性優化:

推薦資源配額應基于任務的實際使用量，同時為保障穩定性，將近 7 天的波動和失敗指標納入權重計算，確保推薦參數能適應業務的波動和增長。

• 隊列阻塞解決:

在 CPU 阻塞而內存正常時，維持總算力不變，減少物理核、增加虛擬核，并相應調整內存配額。

在 CPU 正常而內存阻塞時，降低總算力，從而降低任務申請的物理內存總量。

當 CPU 和內存同時阻塞時，適度降低算力或減少虛擬核，以保任務運行性能在預期范圍內。

注意：如參數調優未能解決阻塞問題，需與調度系統協同，將任務調度至合適時段，以徹底解決阻塞問題。

• 計算健康分提升:

CPU 利用率：對于小任務，可減少物理核、增加虛擬核。對普通和大任務，需評估是否調整算力，進而確定調優方向。

內存利用率：通常不宜將內存利用率設置過高以避免 OOM，首先按需分配資源，然后根據內存利用率調整虛擬核。例如，當利用率低于 50% 時，提升虛擬核。后期將支持 1/1000 核的微調以逼近理想的內存利用率閾值。內存調優涵蓋多個階段如 map、shuffle 和 reduce 等，每階段的處理性能和參數配置有所差異。遇到內存調優瓶頸時，可考慮進行 shuffle 優化。

• 成本優化:

Quota 回收型：實際使用量應低于申請量，如需回收 20%，則需確保空閑量超過 30% 的時間占比維持在 95% 以上，同時保有 10% 的可用余量。

Quota 充分利用型：

CPU 型優化：可增加虛擬核或物理核，但由于增加虛擬核可能導致超發，為保障隊列穩定性，建議增加物理核。

內存型優化：增加算力、減少物理核、增加虛擬核，以釋放更多內存資源，確保內存得到充分利用。

二、自動化解決方案

接下來講解針對上述場景的自動化解決方案。

1、解決方案：實時規則引擎

首先，我們介紹實時規則引擎及其功能：

• 參數實時推薦與應用：該引擎能夠實時收集 Yarn container、Spark event 和 Dtop status 等數據，通過基于 app ID 的聚合，統計所有核心與觀測指標，并將數據記錄至歷史數據庫中。在連續的 3-7 天觀測期內，引擎會根據收集到的數據進一步優化參數推薦，最終將推薦參數推送到 Spark 等執行引擎，并實時監控任務的執行情況。
• 啟發式規則的應用：利用基于規則樹的啟發式規則，針對不同的場景，我們可以設定不同的優化目標和閾值，為優化過程提供指導。
• 資源使用評估：通過分析最近 3-7 天的資源使用累積指標，實時規則引擎可以評估整體的資源波動情況，為進一步的優化提供數據支持。
• 穩定性與健康分策略：

普通策略：旨在保障系統的穩定性，通過分析實際的資源使用量來提供參數推薦。

激進策略：著眼于提高資源利用率，不斷探索任務的性能邊界，同時能自適應地應對OOM 風險，保障系統的運行效率。

為確保系統的穩定運行，一旦任務實例失敗，實時規則引擎會自動將參數回滾至上一個穩定版本。若連續失敗多次，則暫停該任務的優化過程，直至任務恢復穩定運行。我們每周會對失敗案例進行復盤分析，以持續優化和改進實時規則引擎的性能和準確性。

2、解決方案：實時監控 & 自適應調整

我們還實施了一系列實時監控和自適應調整方案，以增強 Spark 等底層引擎的性能和穩定性：

• OOM 自適應處理：針對易發生 OOM 的任務，我們將其調度至獨立的 executor，讓其獨享 container 資源，從而在不增加總資源的前提下，減緩 OOM 的發生，保障任務的穩定運行。
• Shuffle 溢寫分裂管理：我們設定了每個容器的 Shuffle 磁盤寫入量閾值。一旦寫入量超過閾值，系統會自動分裂出新的容器，避免單個容器的溢寫，同時減輕 ESS 的壓力。
• Shuffle 分級限流機制：根據任務的優先級，分配不同的查詢處理速率（QPS）。高優先級任務將獲得更多的 QPS，而低優先級任務的 QPS 會相應限制，以防止 ESS 服務過載，確保高優先級任務的順利執行。
• 節點黑名單優化：為了降低任務失敗率，我們實現了節點黑名單機制。當節點因特定失敗原因被標記時，任務會盡量避免在該節點上執行。我們還提供了設置黑名單節點數量上限的功能，防止過多節點被拉黑，影響整個集群的可用性。
• 失敗回滾與參數管理：當任務實例失敗時，系統會自動將參數回滾至上一個穩定版本。若連續失敗兩次，系統會自動抹除推薦參數并暫停優化，以避免對任務造成進一步的干擾。這種機制有助于降低業務波動對執行的風險，同時減少人工干預的成本。

3、DataLeap 一站式的治理解決方案

最后還有產品側的一站式解決方案，用戶可以快速發起治理。系統界面可以看到每個用戶當前可治理的資源量等信息，可以批量或者單個開啟優化，可以選擇激進或普通策略，支持小文件優化，系統會根據業務場景自動適配。在做優化方案的同時，系統就會預估出成本和收益。

三、實踐 & 收益

接下來復盤一個具體的優化案例。

1、優化實踐：隊列優化前后效果

本例的隊列在優化前的每天 10 點前都處于超發狀態，導致任務阻塞非常嚴重，很多任務長期處于等待狀態。優化后的資源申請量明顯降低，申請量和使用量之間的 gap 趨向理想范圍，由于減輕了內存超發，使 OOM 問題得到改善，讓平臺使用更少的成本和資源做了更多的事情。

2、收益分析：隊列優化收益指標

由于每個用戶對于底層的理解程度不同，如果按單個任務、單個用戶去優化，很難保障人力成本和時間成本。而通過平臺的自動化解決方案，就可以保證所有業務、隊列都可以達到一個非常好的預期效果。

如上圖所示，該隊列一共有 1900 多個任務，優化完成后，CPU 申請量減少 3.5%、使用量減少 6.2%、利用率提升 46.3%，內存申請量減少 30.6%、使用量減少 21.8%、利率提升 24%，所有任務的平均運行時長減少了 1.7 分鐘，每 PB 數據 CPU 節約近百元、內存節約百元以上。

3、收益概覽：業務隊列普通策略優化效果

穩定策略對于內存使用率的目標是 75%-80%，已完成優化的 TOP20 隊列普遍提升了20%，CPU 使用率普遍達到了 70%-80%，整體運行時長也有提升。

另外還有一些激進策略、深度優化和成本優化策略，可以幫助大部分業務在資源利用率和運行效率之間尋求平衡。

4、收益概覽：增量小文件合并

增量小文件合并是在 reduce 階段，會把產出不合理的文件進一步合并，這個操作導致線上 2000 多個任務的平均運行時間增加了 18%，對當前任務來說是負向收益。但是合并完成后下游任務讀取數據性能比之前提高很多，對整個隊列、集群來說是長期正向收益。后續我們會爭取把小文件合并的性能損耗從 18% 降到 10% 以內。

四、結論 & 展望

1、自動化方案優勢 & 局限性

自動化方案的優勢包括：

• 效率提升：通過運用先進的算法和實時監控機制，自動化方案能夠迅速鎖定最優參數組合，從而提升調優效率。
• 準確性增強：能夠妥善處理參數間復雜的相互影響，為復雜系統呈現更為精準的調優結果，進一步提高調優的準確性。
• 人力成本節省：自動化方案減少了人力的投入，有助于降低企業及組織的運營成本。
• 實時監控與自適應調整：實時監控系統的狀態和性能，根據數據的變化自動做出調整，確保系統始終運行在最佳狀態。

然而，自動化方案也存在一些局限性：

• 算法依賴：方案的效果高度依賴于所選用的算法，選取合適的算法和優化策略成為關鍵。
• 可解釋性與可控性的局限：自動化方案可能會在可解釋性和可控性方面顯示出一些限制，增加了在特定情況下對系統理解和調整的難度。
• 特定場景的應對困難：在某些特定的場景下，自動化方案無法完全取代人工調優，仍需專業人員的參與和經驗。

2、未來發展與挑戰

最后來看一下未來的發展規劃和可能面對的挑戰。

發展重點：

（1）元數據閉環多產品化：

• 分級保障：實現 Pontus 和 Dorado 之間的元數據通信，針對服務等級協議(SLA)和核心鏈路節點，確保高優先級的穩定性和及時性。
• 隊列管理：明確在 Megatron 側為各業務配置的資源使用規則：

回溯管理：設定指定時段內回溯任務所能使用的資源上限。

用戶資源管理：通過設定單個用戶可使用的資源比例上限，以控制該用戶名下任務的可用計算力。

Ad-hoc 資源控制：在系統高負載時段，自動調整 adhoc 查詢的資源使用管控。

（2）用戶干預參數推薦：

提供固定值、最大/最小閾值、參數屏蔽等選項，允許用戶根據實際需求調整參數。

（3）結合規則引擎與算法優化：

通過集成規則引擎和算法優化，實現更為高效且準確的參數調優。

預見挑戰：

（1）適應變化的數據環境：

面對大數據領域的快速進展，持續優化自動化解決方案以適應不斷變化的數據環境。

（2）提升算法性能：

為實現更高效的自動化解決方案，持續研究和提升算法性能。

（3）保障系統的可解釋性和可控性：

在推進自動化的過程中，確保系統的可解釋性和可控性，以便用戶能夠理解并進行調整。