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

對(duì)于大數(shù)據(jù)離線任務(wù)來(lái)說(shuō)，由于流轉(zhuǎn)服務(wù)節(jié)點(diǎn)較多、技術(shù)棧要求較高、數(shù)據(jù)采集難度大、指標(biāo)復(fù)雜難懂等一系列原因，造成業(yè)務(wù)方對(duì)任務(wù)的掌控力非常差：不清楚異常出現(xiàn)在哪；不確定任務(wù)是否可以優(yōu)化、如何優(yōu)化。

目前大數(shù)據(jù)基礎(chǔ)設(shè)施組開發(fā)了一款EasyEagle產(chǎn)品，并通過(guò)其中的任務(wù)全鏈路診斷模塊，幫助用戶去解決上述的問(wèn)題。

本篇文章大致介紹任務(wù)全鏈路診斷模塊，通過(guò)部分案例和數(shù)據(jù)，幫助用戶更好的了解該功能模塊能帶來(lái)什么樣的收益，以及如何簡(jiǎn)單的使用。本篇文章僅涉及計(jì)算資源vcore的優(yōu)化，對(duì)于異常定位會(huì)有其他文章進(jìn)行介紹。

1什么是任務(wù)全鏈路診斷？

任務(wù)全鏈路，指的是任務(wù)從提交到產(chǎn)出結(jié)束，整個(gè)生命周期內(nèi)流轉(zhuǎn)的各個(gè)服務(wù)、節(jié)點(diǎn)的集合。

診斷，指的是將上述整個(gè)鏈路，按照已有的運(yùn)維經(jīng)驗(yàn)和特征進(jìn)行抽象劃分，細(xì)分成不同檢查項(xiàng)進(jìn)行診斷定位。

總結(jié)起來(lái)就是：將任務(wù)從提交到產(chǎn)出結(jié)束（包括各個(gè)流轉(zhuǎn)節(jié)點(diǎn)以及流轉(zhuǎn)服務(wù)），抽象并劃分成不同階段，并對(duì)上述各個(gè)階段細(xì)分不同的檢查項(xiàng)進(jìn)行診斷定位，提供相關(guān)專業(yè)化的優(yōu)化以及解決建議，提高業(yè)務(wù)方對(duì)任務(wù)運(yùn)行過(guò)程的掌控，包括任務(wù)運(yùn)行效率的提升以及資源利用率的提升。

2對(duì)業(yè)務(wù)能產(chǎn)生什么價(jià)值？

主要的價(jià)值其實(shí)就一點(diǎn)：增加業(yè)務(wù)方對(duì)任務(wù)的掌控能力。這里的掌控能力主要分以下幾個(gè)方面：

資源：指的是資源申請(qǐng)和實(shí)際使用是否合理，利用率是否正常

效率：任務(wù)運(yùn)行效率是否可以提升，是否可以加快產(chǎn)出

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

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

在目前的系統(tǒng)中，業(yè)務(wù)方提交任務(wù)之后，直至結(jié)束，對(duì)任務(wù)的整個(gè)運(yùn)行完全屬于一個(gè)摸黑狀態(tài)。任務(wù)全鏈路診斷就能解決這種摸黑狀態(tài)，并且提升業(yè)務(wù)方上述幾個(gè)方面的掌控能力，達(dá)到降本增效的目的。

說(shuō)到這里，可能有的小伙伴會(huì)問(wèn)，這是真的嗎？那我們就直接貼圖以及數(shù)據(jù)來(lái)展示~

目前內(nèi)部我們針對(duì)音樂(lè)進(jìn)行了一次任務(wù)計(jì)算資源的優(yōu)化，優(yōu)化時(shí)間范圍為0-7點(diǎn)（業(yè)務(wù)高峰期），優(yōu)化任務(wù)數(shù)量為前200的任務(wù)，總體統(tǒng)計(jì)數(shù)據(jù)均只包含該時(shí)間段（0-7點(diǎn)）。

整體優(yōu)化效果如圖：

在針對(duì)0-7點(diǎn)的前200任務(wù)優(yōu)化后，vcore的資源水位下降如上所示。

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

單個(gè)任務(wù)的優(yōu)化效果如圖：

單個(gè)任務(wù)的優(yōu)化效果如上所示，不言而喻。

看到這里，小伙伴對(duì)于任務(wù)全鏈路診斷這塊對(duì)于業(yè)務(wù)方是否能帶來(lái)收益，是否還有疑問(wèn)？

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

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

任務(wù)準(zhǔn)備階段，主要是指資源的初始化、本地化等一系列的前期準(zhǔn)備。涉及到y(tǒng)arn的調(diào)度、資源、本地節(jié)點(diǎn)、hdfs等。

任務(wù)運(yùn)行階段，主要是指任務(wù)按照既定邏輯運(yùn)行。

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

針對(duì)每個(gè)階段，我們?cè)俑鶕?jù)內(nèi)部運(yùn)維相關(guān)經(jīng)驗(yàn)以及特征，抽象劃分成不同的檢查項(xiàng)對(duì)其進(jìn)行診斷。如果診斷出異常，會(huì)附加相關(guān)的標(biāo)簽。標(biāo)簽會(huì)攜帶異常原因、異常表象、優(yōu)化建議等。

看到這里，大家可能會(huì)有個(gè)疑問(wèn)：任務(wù)根據(jù)標(biāo)簽按照優(yōu)化建議優(yōu)化后，就能加快產(chǎn)出、提高資源的利用率嗎？

答案是可以的。因?yàn)槊總€(gè)檢查項(xiàng)的評(píng)判標(biāo)準(zhǔn)都是時(shí)長(zhǎng)和資源，所有的優(yōu)化最終的表現(xiàn)都可以通過(guò)時(shí)長(zhǎng)和資源兩個(gè)維度進(jìn)行衡量。

下面我們會(huì)詳細(xì)說(shuō)明下各個(gè)階段的檢查項(xiàng)劃分。

3.1 任務(wù)準(zhǔn)備階段

針對(duì)這一階段，我們對(duì)其進(jìn)行了抽象劃分，分為如下各個(gè)檢查項(xiàng)：

該階段，我們通過(guò)對(duì)不同類型container的狀態(tài)機(jī)變化的間隔時(shí)長(zhǎng)，進(jìn)行檢查項(xiàng)劃分。上述的各個(gè)檢查項(xiàng)，也可以關(guān)聯(lián)相關(guān)節(jié)點(diǎn)和服務(wù)。

在這之前，這個(gè)階段基本上對(duì)于所有的業(yè)務(wù)方來(lái)說(shuō)，甚至開發(fā)，都是屬于完全不了解、不掌控的階段。實(shí)際監(jiān)控后，發(fā)現(xiàn)很多任務(wù)在該階段都存在問(wèn)題。

目前在產(chǎn)品中，我們將其檢查項(xiàng)提取成4組標(biāo)簽，展示如下：

上述檢查項(xiàng)的優(yōu)化，主要帶來(lái)的是任務(wù)產(chǎn)出時(shí)長(zhǎng)的優(yōu)化。這里我們簡(jiǎn)單的舉一個(gè)例子來(lái)說(shuō)明下我們是如何做的。

AM分配耗時(shí)過(guò)長(zhǎng)

以AM分配耗時(shí)這個(gè)檢查項(xiàng)為例，判斷的依據(jù)如下：

獲取任務(wù)該檢查項(xiàng)的耗時(shí)

與集群AM分配速率以及該任務(wù)此檢查項(xiàng)的歷史水平進(jìn)行對(duì)比

如發(fā)現(xiàn)不匹配集群的分配速率或超出歷史統(tǒng)計(jì)模型設(shè)置的上限，則檢查任務(wù)提交隊(duì)列的資源水位

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

如該檢查項(xiàng)異常，業(yè)務(wù)方可以根據(jù)給出的相關(guān)建議進(jìn)行處理，加快任務(wù)的產(chǎn)出。

3.2 任務(wù)運(yùn)行階段

針對(duì)這一階段，我們也將spark任務(wù)進(jìn)行了一個(gè)大概的抽象，如下所示：

該階段，我們主要通過(guò)實(shí)時(shí)統(tǒng)計(jì)分析spark的event指標(biāo)進(jìn)行檢查項(xiàng)的診斷。

當(dāng)前此階段檢查項(xiàng)的劃分還處于增長(zhǎng)的狀態(tài)，目前大致已有20余項(xiàng)，部分檢查項(xiàng)標(biāo)簽如下所示：

上述檢查項(xiàng)的優(yōu)化，為什么能帶來(lái)資源利用率的提升以及運(yùn)行效率的提升？我們以幾個(gè)簡(jiǎn)單的檢查項(xiàng)來(lái)舉例說(shuō)明一下。

（1）Input Task數(shù)量檢查

該檢查項(xiàng)主要是針對(duì)input階段task數(shù)量過(guò)多，但是input數(shù)據(jù)量不大的情況（這里不大，是指的小于等于目前我們?cè)\斷配置的閾值，一般默認(rèn)為128Mb）。

在目前生產(chǎn)環(huán)境中，我們發(fā)現(xiàn)很多input階段的stage存在10W+的task在運(yùn)行。這里很多人會(huì)認(rèn)為，這些任務(wù)應(yīng)該會(huì)很快產(chǎn)出，任務(wù)沒(méi)啥問(wèn)題。

但是我們通過(guò)實(shí)際的數(shù)據(jù)分析后發(fā)現(xiàn)以下規(guī)則：

input階段的stage存在巨量的task，一般會(huì)伴隨GC檢查項(xiàng)異常，GC耗時(shí)占整個(gè)stage運(yùn)行時(shí)長(zhǎng)超過(guò)10%以上

相同任務(wù)相同階段的task處理數(shù)據(jù)量增加，并不會(huì)使task的運(yùn)行時(shí)長(zhǎng)呈現(xiàn)等比例的增長(zhǎng)。因?yàn)檎{(diào)度開銷以及序列化會(huì)有部分消耗，另外input階段網(wǎng)絡(luò)以及磁盤IO對(duì)task運(yùn)行時(shí)長(zhǎng)的影響較大

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

因此針對(duì)input階段的stage，存在巨量的task運(yùn)行并不是一個(gè)很好的主意。

針對(duì)該檢查項(xiàng)，我們一般會(huì)建議用戶將spark.sql.files.maxPartitionBytes配置提高，例如由默認(rèn)的128Mb提高至512Mb。我們可以簡(jiǎn)單的計(jì)算下，大致對(duì)于該階段的stage資源以及時(shí)長(zhǎng)能節(jié)約多少：

原先每個(gè)task處理數(shù)據(jù)量：128Mb

原先input階段stage的task數(shù)量：16w

該任務(wù)同時(shí)最大task運(yùn)行數(shù)量：2w

原先一輪task運(yùn)行耗時(shí)：t

現(xiàn)每個(gè)task處理數(shù)據(jù)量：512Mb

現(xiàn)input階段stage的task數(shù)量：4w

該任務(wù)同時(shí)最大task運(yùn)行數(shù)量：2w

數(shù)據(jù)量增長(zhǎng)后，task耗時(shí)增長(zhǎng)倍數(shù)：2.5(數(shù)據(jù)量提升4倍后，大致為2-3倍的耗時(shí)增加)

資源：

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

如果算上GC耗時(shí)的降低，該階段vcore資源下降比例應(yīng)為：40%+

時(shí)長(zhǎng)：

該階段運(yùn)行時(shí)長(zhǎng)下降比例：37.5% = (16w/2w * t - 4w/2w * 2.5t) / (16w/2w * t)

如果算上GC耗時(shí)的降低，該階段運(yùn)行時(shí)長(zhǎng)同樣下降比例應(yīng)為：40%+

（2）ExecutorCores空跑檢查

該檢查項(xiàng)主要是針對(duì)Executor只有少量的core在運(yùn)行task，其他大量的core在空跑的情況。

在目前的生產(chǎn)環(huán)境中，我們發(fā)現(xiàn)一些任務(wù)存在Executor只有不到一半的core在運(yùn)行task，其他的core均在空跑。造成這個(gè)現(xiàn)象的原因，主要是Spark任務(wù)在運(yùn)行過(guò)程中每個(gè)Stage的task數(shù)量均會(huì)變化，若某個(gè)Stage的task數(shù)量驟減，且該數(shù)量小于當(dāng)前可用的core數(shù)量，在認(rèn)為每個(gè)task占用一個(gè)core的情況下，會(huì)存在大量Exeucotors的core出現(xiàn)空跑。因?yàn)樵诋?dāng)前生產(chǎn)環(huán)境中，一個(gè)Executors經(jīng)常會(huì)被分配4個(gè)core，若其中只有一個(gè)core被占用，那么這個(gè)executors既不會(huì)被釋放，且另外的3個(gè)core也處于空跑浪費(fèi)的情況。

該現(xiàn)象會(huì)造成任務(wù)大量的占用集群的vcore計(jì)算資源，但是卻沒(méi)有使用，降低任務(wù)以及該集群的資源利用率。

針對(duì)該檢查項(xiàng)，我們一般會(huì)建議用戶將spark.executor.cores降低一半，以及將spark.locality.wait.process配置調(diào)大以保證更多的task能分配至一個(gè)executor中。我們也可以簡(jiǎn)單的計(jì)算下，該操作大致對(duì)于該階段的stage資源能節(jié)約多少：

原該stage運(yùn)行的executor數(shù)量：2000

原每個(gè)executor配置的vcore數(shù)量：4

現(xiàn)該stage運(yùn)行的executor數(shù)量：2000

現(xiàn)每個(gè)executor配置的vcore數(shù)量：2

資源：

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

3.3 任務(wù)產(chǎn)出階段

任務(wù)產(chǎn)出階段，目前診斷的比較簡(jiǎn)單。主要通過(guò)數(shù)據(jù)量、時(shí)長(zhǎng)的統(tǒng)計(jì)，來(lái)判斷是否存在問(wèn)題。如果存在問(wèn)題，關(guān)聯(lián)hdfs以及metastore進(jìn)行問(wèn)題的進(jìn)一步定位。

在此不進(jìn)一步進(jìn)行介紹了。

4業(yè)務(wù)方是怎么使用這塊功能并優(yōu)化的？

在目前的EasyEagle產(chǎn)品中，業(yè)務(wù)方進(jìn)行上述的優(yōu)化操作其實(shí)非常簡(jiǎn)單。根據(jù)任務(wù)運(yùn)行概覽中的可優(yōu)化任務(wù)列表展示的優(yōu)化建議進(jìn)行相關(guān)處理即可，如下所示：

該列表目前暫時(shí)只能展示所選標(biāo)簽下的任務(wù)列表（已排序，按照該標(biāo)簽打分進(jìn)行排序）。后續(xù)版本將會(huì)以任務(wù)維度，通過(guò)任務(wù)運(yùn)行時(shí)長(zhǎng)以及資源消耗排序展示任務(wù)全部異常標(biāo)簽。

業(yè)務(wù)方在點(diǎn)擊具體app id時(shí)，可以跳轉(zhuǎn)至任務(wù)的全鏈路診斷詳情頁(yè)面，該頁(yè)面會(huì)將任務(wù)全部的異常檢查項(xiàng)進(jìn)行展示，并會(huì)歷史相關(guān)數(shù)據(jù)進(jìn)行對(duì)比展示。讓用戶也進(jìn)一步了解優(yōu)化前后的資源、時(shí)長(zhǎng)情況。

051背不足思考

業(yè)務(wù)方的確可以非常方便的通過(guò)可優(yōu)化任務(wù)列表獲取相關(guān)任務(wù)以及優(yōu)化建議，但是優(yōu)化操作其實(shí)對(duì)于用戶并不友好，需要用戶進(jìn)行手動(dòng)配置修改。

平臺(tái)側(cè)對(duì)于周期提交的任務(wù)，是否可以通過(guò)目前我們EasyEagle提供的優(yōu)化建議，進(jìn)行自動(dòng)的配置調(diào)優(yōu)，而不依賴用戶手動(dòng)性的行為？