計算資源vcore的優化不同于內存優化，vcore嚴重影響著任務的運行效率。如何在保證任務運行效率不變甚至提高的情況下，能進一步優化vcore的利用率？我們需要對任務做出全面的分析，給出不同的優化策略。這篇文章主要圍繞任務運行階段，介紹任務全鏈路診斷針對任務不同檢查項異常給予的優化策略，以及帶來的收益。

對于大數據離線任務來說，由于流轉服務節點較多、技術棧要求較高、數據采集難度大、指標復雜難懂等一系列原因，造成業務方對任務的掌控力非常差：不清楚異常出現在哪；不確定任務是否可以優化、如何優化。

目前大數據基礎設施組開發了一款EasyEagle產品，并通過其中的任務全鏈路診斷模塊，幫助用戶去解決上述的問題。

本篇文章大致介紹任務全鏈路診斷模塊，通過部分案例和數據，幫助用戶更好的了解該功能模塊能帶來什么樣的收益，以及如何簡單的使用。本篇文章僅涉及計算資源vcore的優化，對于異常定位會有其他文章進行介紹。

1什么是任務全鏈路診斷？

任務全鏈路，指的是任務從提交到產出結束，整個生命周期內流轉的各個服務、節點的集合。

診斷，指的是將上述整個鏈路，按照已有的運維經驗和特征進行抽象劃分，細分成不同檢查項進行診斷定位。

總結起來就是：將任務從提交到產出結束（包括各個流轉節點以及流轉服務），抽象并劃分成不同階段，并對上述各個階段細分不同的檢查項進行診斷定位，提供相關專業化的優化以及解決建議，提高業務方對任務運行過程的掌控，包括任務運行效率的提升以及資源利用率的提升。

2對業務能產生什么價值？

主要的價值其實就一點：增加業務方對任務的掌控能力。這里的掌控能力主要分以下幾個方面：

資源：指的是資源申請和實際使用是否合理，利用率是否正常

效率：任務運行效率是否可以提升，是否可以加快產出

異常定位：異常在哪，如何解決

配置：配置是否合理，不合理的配置如何修改

在目前的系統中，業務方提交任務之后，直至結束，對任務的整個運行完全屬于一個摸黑狀態。任務全鏈路診斷就能解決這種摸黑狀態，并且提升業務方上述幾個方面的掌控能力，達到降本增效的目的。

說到這里，可能有的小伙伴會問，這是真的嗎？那我們就直接貼圖以及數據來展示~

目前內部我們針對音樂進行了一次任務計算資源的優化，優化時間范圍為0-7點（業務高峰期），優化任務數量為前200的任務，總體統計數據均只包含該時間段（0-7點）。

整體優化效果如圖：

在針對0-7點的前200任務優化后，vcore的資源水位下降如上所示。

對于一個只有5.3w的vcore的集群而言，前200的任務占集群43%的資源，能夠達到上述的優化效果，還是非常可觀的，并且音樂業務方本身對于任務的優化情況就較好。

單個任務的優化效果如圖：

單個任務的優化效果如上所示，不言而喻。

看到這里，小伙伴對于任務全鏈路診斷這塊對于業務方是否能帶來收益，是否還有疑問？

3任務全鏈路診斷我們是怎么做的？

首先，我們將任務生命周期大致分為三個階段，如下所示：

任務準備階段，主要是指資源的初始化、本地化等一系列的前期準備。涉及到yarn的調度、資源、本地節點、hdfs等。

任務運行階段，主要是指任務按照既定邏輯運行。

任務產出階段，主要是指任務具體邏輯運行完畢后，數據持久化或其他的一系列操作。涉及到hdfs、metastore等。

針對每個階段，我們再根據內部運維相關經驗以及特征，抽象劃分成不同的檢查項對其進行診斷。如果診斷出異常，會附加相關的標簽。標簽會攜帶異常原因、異常表象、優化建議等。

看到這里，大家可能會有個疑問：任務根據標簽按照優化建議優化后，就能加快產出、提高資源的利用率嗎？

答案是可以的。因為每個檢查項的評判標準都是時長和資源，所有的優化最終的表現都可以通過時長和資源兩個維度進行衡量。

下面我們會詳細說明下各個階段的檢查項劃分。

3.1 任務準備階段

針對這一階段，我們對其進行了抽象劃分，分為如下各個檢查項：

該階段，我們通過對不同類型container的狀態機變化的間隔時長，進行檢查項劃分。上述的各個檢查項，也可以關聯相關節點和服務。

在這之前，這個階段基本上對于所有的業務方來說，甚至開發，都是屬于完全不了解、不掌控的階段。實際監控后，發現很多任務在該階段都存在問題。

目前在產品中，我們將其檢查項提取成4組標簽，展示如下：

上述檢查項的優化，主要帶來的是任務產出時長的優化。這里我們簡單的舉一個例子來說明下我們是如何做的。

AM分配耗時過長

以AM分配耗時這個檢查項為例，判斷的依據如下：

獲取任務該檢查項的耗時

與集群AM分配速率以及該任務此檢查項的歷史水平進行對比

如發現不匹配集群的分配速率或超出歷史統計模型設置的上限，則檢查任務提交隊列的資源水位

如該隊列資源水位已滿，則告知業務方由于隊列資源不足造成；如該隊列資源水位正常，但是AM資源已滿，則告知業務方由于AM資源不足造成，建議修改AM資源配比

如該檢查項異常，業務方可以根據給出的相關建議進行處理，加快任務的產出。

3.2 任務運行階段

針對這一階段，我們也將spark任務進行了一個大概的抽象，如下所示：

該階段，我們主要通過實時統計分析spark的event指標進行檢查項的診斷。

當前此階段檢查項的劃分還處于增長的狀態，目前大致已有20余項，部分檢查項標簽如下所示：

上述檢查項的優化，為什么能帶來資源利用率的提升以及運行效率的提升？我們以幾個簡單的檢查項來舉例說明一下。

（1）Input Task數量檢查

該檢查項主要是針對input階段task數量過多，但是input數據量不大的情況（這里不大，是指的小于等于目前我們診斷配置的閾值，一般默認為128Mb）。

在目前生產環境中，我們發現很多input階段的stage存在10W+的task在運行。這里很多人會認為，這些任務應該會很快產出，任務沒啥問題。

但是我們通過實際的數據分析后發現以下規則：

input階段的stage存在巨量的task，一般會伴隨GC檢查項異常，GC耗時占整個stage運行時長超過10%以上

相同任務相同階段的task處理數據量增加，并不會使task的運行時長呈現等比例的增長。因為調度開銷以及序列化會有部分消耗，另外input階段網絡以及磁盤IO對task運行時長的影響較大

這種含有巨量task的stage，不可能一輪就能運行完畢

因此針對input階段的stage，存在巨量的task運行并不是一個很好的主意。

針對該檢查項，我們一般會建議用戶將spark.sql.files.maxPartitionBytes配置提高，例如由默認的128Mb提高至512Mb。我們可以簡單的計算下，大致對于該階段的stage資源以及時長能節約多少：

原先每個task處理數據量：128Mb

原先input階段stage的task數量：16w

該任務同時最大task運行數量：2w

原先一輪task運行耗時：t

現每個task處理數據量：512Mb

現input階段stage的task數量：4w

該任務同時最大task運行數量：2w

數據量增長后，task耗時增長倍數：2.5(數據量提升4倍后，大致為2-3倍的耗時增加)

資源：

該階段vcore資源下降比例：37.5% = (2w * 16w/2w * t - 2w * 4w/2w * 2.5t) / (2w * 16w/2w * t)

如果算上GC耗時的降低，該階段vcore資源下降比例應為：40%+

時長：

該階段運行時長下降比例：37.5% = (16w/2w * t - 4w/2w * 2.5t) / (16w/2w * t)

如果算上GC耗時的降低，該階段運行時長同樣下降比例應為：40%+

（2）ExecutorCores空跑檢查

該檢查項主要是針對Executor只有少量的core在運行task，其他大量的core在空跑的情況。

在目前的生產環境中，我們發現一些任務存在Executor只有不到一半的core在運行task，其他的core均在空跑。造成這個現象的原因，主要是Spark任務在運行過程中每個Stage的task數量均會變化，若某個Stage的task數量驟減，且該數量小于當前可用的core數量，在認為每個task占用一個core的情況下，會存在大量Exeucotors的core出現空跑。因為在當前生產環境中，一個Executors經常會被分配4個core，若其中只有一個core被占用，那么這個executors既不會被釋放，且另外的3個core也處于空跑浪費的情況。

該現象會造成任務大量的占用集群的vcore計算資源，但是卻沒有使用，降低任務以及該集群的資源利用率。

針對該檢查項，我們一般會建議用戶將spark.executor.cores降低一半，以及將spark.locality.wait.process配置調大以保證更多的task能分配至一個executor中。我們也可以簡單的計算下，該操作大致對于該階段的stage資源能節約多少：

原該stage運行的executor數量：2000

原每個executor配置的vcore數量：4

現該stage運行的executor數量：2000

現每個executor配置的vcore數量：2

資源：

該階段vcore資源下降比例：50% = (2000 * 4 - 2000 * 2) / (2000 * 4)

3.3 任務產出階段

任務產出階段，目前診斷的比較簡單。主要通過數據量、時長的統計，來判斷是否存在問題。如果存在問題，關聯hdfs以及metastore進行問題的進一步定位。

在此不進一步進行介紹了。

4業務方是怎么使用這塊功能并優化的？

在目前的EasyEagle產品中，業務方進行上述的優化操作其實非常簡單。根據任務運行概覽中的可優化任務列表展示的優化建議進行相關處理即可，如下所示：

該列表目前暫時只能展示所選標簽下的任務列表（已排序，按照該標簽打分進行排序）。后續版本將會以任務維度，通過任務運行時長以及資源消耗排序展示任務全部異常標簽。

業務方在點擊具體app id時，可以跳轉至任務的全鏈路診斷詳情頁面，該頁面會將任務全部的異常檢查項進行展示，并會歷史相關數據進行對比展示。讓用戶也進一步了解優化前后的資源、時長情況。

051背不足思考

業務方的確可以非常方便的通過可優化任務列表獲取相關任務以及優化建議，但是優化操作其實對于用戶并不友好，需要用戶進行手動配置修改。

平臺側對于周期提交的任務，是否可以通過目前我們EasyEagle提供的優化建議，進行自動的配置調優，而不依賴用戶手動性的行為？