一、痛點 & 挑戰(zhàn)

在分析業(yè)務痛點和挑戰(zhàn)之前，先要清楚業(yè)務現狀。

1、現狀概覽

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

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

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

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

• 系統(tǒng)復雜度：

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

• 動態(tài)變化：

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

• 專業(yè)知識缺乏：

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

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

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

3、挑戰(zhàn)：復雜的優(yōu)化場景和目標

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

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

4、業(yè)務優(yōu)化場景需求分析

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

• 穩(wěn)定性優(yōu)化:

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

• 隊列阻塞解決:

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

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

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

注意：如參數調優(yōu)未能解決阻塞問題，需與調度系統(tǒng)協(xié)同，將任務調度至合適時段，以徹底解決阻塞問題。

• 計算健康分提升:

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

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

• 成本優(yōu)化:

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

Quota 充分利用型：

CPU 型優(yōu)化：可增加虛擬核或物理核，但由于增加虛擬核可能導致超發(fā)，為保障隊列穩(wěn)定性，建議增加物理核。

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

二、自動化解決方案

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

1、解決方案：實時規(guī)則引擎

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

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

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

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

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

2、解決方案：實時監(jiān)控 & 自適應調整

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

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

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

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

三、實踐 & 收益

接下來復盤一個具體的優(yōu)化案例。

1、優(yōu)化實踐：隊列優(yōu)化前后效果

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

2、收益分析：隊列優(yōu)化收益指標

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

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

3、收益概覽：業(yè)務隊列普通策略優(yōu)化效果

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

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

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

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

四、結論 & 展望

1、自動化方案優(yōu)勢 & 局限性

自動化方案的優(yōu)勢包括：

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

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

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

2、未來發(fā)展與挑戰(zhàn)

最后來看一下未來的發(fā)展規(guī)劃和可能面對的挑戰(zhàn)。

發(fā)展重點：

（1）元數據閉環(huán)多產品化：

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

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

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

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

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

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

（3）結合規(guī)則引擎與算法優(yōu)化：

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

預見挑戰(zhàn)：

（1）適應變化的數據環(huán)境：

面對大數據領域的快速進展，持續(xù)優(yōu)化自動化解決方案以適應不斷變化的數據環(huán)境。

（2）提升算法性能：

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

（3）保障系統(tǒng)的可解釋性和可控性：

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