智能供應(yīng)鏈預(yù)測的應(yīng)用

智能供應(yīng)鏈預(yù)測的應(yīng)?全?轉(zhuǎn)載僅供??學(xué)習(xí)使?，主要是算法在物流場景下的應(yīng)?落地1背景前段時間京東公開了?向第?個??年的戰(zhàn)略規(guī)劃，表?京東將全??向技術(shù)化，??發(fā)展??智能和機(jī)器??動化技術(shù)，將過去傳統(tǒng)?式構(gòu)筑的優(yōu)勢全?升級。京東Y事業(yè)部順勢成?，該事業(yè)部將以服務(wù)泛零售為核?，著重智能供應(yīng)能?的打造，核?使命是利???智能技術(shù)來驅(qū)動零售?新。1.1.京東的供應(yīng)鏈京東?直致?于通過互聯(lián)?電商建?需求側(cè)與供給側(cè)的精準(zhǔn)?效匹配，供應(yīng)鏈管理是零售聯(lián)調(diào)中的核?能?，是零售平臺能?的關(guān)鍵體現(xiàn)，也是供應(yīng)商與京東緊密合作的紐帶，更是未來京東智能化商業(yè)體布局中的核?環(huán)節(jié)。?前京東在全國范圍內(nèi)的倉庫數(shù)量已超過700個，按功能可劃分為RDC、FDC、?件中?倉、?件衛(wèi)星倉、圖書倉和城市倉等等。RDC（RegionalDistributionCenter）即區(qū)域分發(fā)中?，可理解為?級倉庫，向供貨商采購的商品會優(yōu)先送往這?，?般設(shè)置在中?城市，覆蓋范圍?。FDC（ForwardDistributionCenter）即區(qū)域運(yùn)轉(zhuǎn)中?，可理解為?級倉庫，覆蓋?些中?型城市及邊遠(yuǎn)地區(qū)，通常會根據(jù)需求將商品從RDC調(diào)配過來。結(jié)合??智能、?數(shù)據(jù)等技術(shù)，京東?先從供貨商那?合理采購定量的商品到RDC，再根據(jù)實(shí)際需求調(diào)配到FDC，然后運(yùn)往離客戶最近的配送站，最后快遞員將商品帶到客戶?中。這只是京東供應(yīng)鏈體系中?個普通的場景，但正因?yàn)橛羞@樣的體系，使得京東對?戶的響應(yīng)速度??提?，?戶體驗(yàn)??提升。1.1.京東供應(yīng)鏈優(yōu)化?戶體驗(yàn)提升的同時也伴隨著?量資?的投?和成本的提?，成本必須得到控制，整個體系才能發(fā)揮出最?的價值，于是對供應(yīng)鏈的優(yōu)化就顯得?關(guān)重要了。京東?打建?供應(yīng)連體系的那?天起，就不斷地進(jìn)?改進(jìn)和優(yōu)化，并且努?深?到供應(yīng)鏈的每?個環(huán)節(jié)。優(yōu)化其實(shí)是?門運(yùn)籌學(xué)問題，需考慮在各種決策?標(biāo)之間如何平衡以達(dá)到最?收益，在這個過程中需要考慮很多問題，把這些考慮清楚，問題就容易解決了。舉?個簡單的例?：1.商品補(bǔ)貨：考慮在什么時間，給哪個RDC采購什么商品，采購量是多少？2.商品調(diào)撥：考慮在什么時間，給哪個FDC調(diào)配什么商品，調(diào)配量是多少？3.倉儲運(yùn)營：在?促來臨之際，倉庫和配送站要增配多少??、多少輛貨車？雖然看上去這些問題都很容易回答，但仔細(xì)想想?yún)s?很難給出答案，原因就在于想要做到精確不是那么容易的事情，就拿補(bǔ)貨來說，補(bǔ)的太多會增加庫存成本，補(bǔ)的太少會增加缺貨成本，只有合理的補(bǔ)貨量才能做到成本最低。1.1.預(yù)測技術(shù)在京東供應(yīng)鏈的作?借助機(jī)器學(xué)習(xí)、?數(shù)據(jù)等相關(guān)技術(shù)，京東在很多供應(yīng)鏈優(yōu)化問題上都已經(jīng)實(shí)現(xiàn)系統(tǒng)化，由系統(tǒng)?動給出優(yōu)化建議，并與?產(chǎn)系統(tǒng)相連接，實(shí)現(xiàn)全流程?動化。在這?有?項(xiàng)技術(shù)起著?關(guān)重要的低層?撐作?--預(yù)測技術(shù)。據(jù)粗略估算，1%的預(yù)測準(zhǔn)確度的提升可以節(jié)約數(shù)倍的運(yùn)營成本。怎樣理解預(yù)測在供應(yīng)鏈優(yōu)化中的作?呢?拿商品補(bǔ)貨舉例，?家公司為了保證庫房不缺貨，可能會頻繁的從供貨商那?補(bǔ)充?量商品，這樣做雖然不會缺貨，但可能會造成更多賣不出去的商品積壓在倉庫中，從?使商品的周轉(zhuǎn)率降低，庫存成本增加。反之，這家公司有可能為了追求零庫存?補(bǔ)很少的商品，但這就可能出現(xiàn)嚴(yán)重的缺貨問題，從?使現(xiàn)貨率降低，嚴(yán)重影響?戶體驗(yàn)，缺貨成本增加。于是問題就來了，要補(bǔ)多少商品才合適，什么時間補(bǔ)貨，這就需要權(quán)衡考慮了，最終?的是要使庫存成本和缺貨成本達(dá)到?個平衡?？紤]?下極端情況，等庫存降到零時再去補(bǔ)貨，這時供貨商接到補(bǔ)貨通知后將貨物運(yùn)往倉庫。但是這么做有個問題，因?yàn)檫\(yùn)送過程需要時間，這段時間庫房就缺貨了。那怎么辦呢?就是利?預(yù)測技術(shù)。利?預(yù)測我們可以計算出未來商品在途的這段時間?銷量?概是多少，然后我們讓倉庫保證這個量，低于這個量就給供貨商下達(dá)補(bǔ)貨通知，于是問題得以解決?？??之，預(yù)測技術(shù)在這?發(fā)揮了重要的作?，成為關(guān)鍵的?個環(huán)。1.京東預(yù)測系統(tǒng)1.預(yù)測系統(tǒng)介紹預(yù)測系統(tǒng)在整個供應(yīng)鏈體系中處在最底層并且起到?個?撐的作?，?持上層的多個決策優(yōu)化系統(tǒng)，?這些決策優(yōu)化系統(tǒng)利?精準(zhǔn)的預(yù)測數(shù)據(jù)結(jié)合運(yùn)籌學(xué)技術(shù)得出最優(yōu)的決策，并將結(jié)果提供給更上層的業(yè)務(wù)執(zhí)?系統(tǒng)或是業(yè)務(wù)?直接使?。?前，預(yù)測系統(tǒng)主要?持三?業(yè)務(wù)：銷量預(yù)測、單量預(yù)測和GMV預(yù)測。其中銷量預(yù)測主要?持商品補(bǔ)貨、商品調(diào)撥；單量預(yù)測主要?持倉庫、站點(diǎn)的運(yùn)營管理；GMV預(yù)測主要?持銷售部門計劃的定制。銷量預(yù)測按照不同維度?可以分為RDC采購預(yù)測、FDC調(diào)撥預(yù)測、城市倉調(diào)撥預(yù)測、?建倉補(bǔ)貨預(yù)測、全球購銷量預(yù)測和圖書促銷預(yù)測等；單量預(yù)測?可分為庫房單量預(yù)測、配送中?單量預(yù)測和配送站單量預(yù)測等（在這?“單量”并?指?戶所下訂單的量，?是將訂單拆單后流轉(zhuǎn)到倉庫中的單量。例如?個?戶的訂單中包括3件物品，其中兩個?件品和?個?件品，在京東的供應(yīng)鏈環(huán)節(jié)中可能會將其中兩個?件品組成?個單投放到?件倉中，?將那個?件單獨(dú)?個單投放到?件倉中，單量指的是拆單后的量）；GMV預(yù)測?持到商品粒度。1.1.預(yù)測系統(tǒng)架構(gòu)整體架構(gòu)從?下依次是：數(shù)據(jù)源輸?層、基礎(chǔ)數(shù)據(jù)加?層、核?業(yè)務(wù)層、數(shù)據(jù)輸出層和下游系統(tǒng)。?先從外部數(shù)據(jù)源獲取我們所需的業(yè)務(wù)數(shù)據(jù)，然后對基礎(chǔ)數(shù)據(jù)進(jìn)?加?清洗，再通過時間序列、機(jī)器學(xué)習(xí)等??智能技術(shù)對數(shù)據(jù)進(jìn)?處理分析，最后計算出預(yù)測結(jié)果并通過多種途徑推送給下游系統(tǒng)使?。1.數(shù)據(jù)源輸?層：京東數(shù)據(jù)倉庫中存儲著我們需要的?部分業(yè)務(wù)數(shù)據(jù)，例如訂單信息、商品信息、庫存信息等等。?對于促銷計劃數(shù)據(jù)則?部分來?于采銷?員通過Web系統(tǒng)錄?的信息。除此之外還有??部分?jǐn)?shù)據(jù)通過?本形式直接上傳到HDFS中。2.基礎(chǔ)數(shù)據(jù)加?層：在這?層主要通過Hive對基礎(chǔ)數(shù)據(jù)進(jìn)??些加?清洗，去掉不需要的字段，過濾不需要的維度并清洗有問題的數(shù)據(jù)。3.核?業(yè)務(wù)層：這層是系統(tǒng)的的核?部分，橫向看?可分為三層：特征構(gòu)建、預(yù)測算法和預(yù)測結(jié)果加??？v向看是由多條業(yè)務(wù)線組成，彼此之間不發(fā)?任何交集。特征構(gòu)建：將之前清洗過的基礎(chǔ)數(shù)據(jù)通過近?步的處理轉(zhuǎn)化成標(biāo)準(zhǔn)格式的特征數(shù)據(jù)，提供給后續(xù)算法模型使?。核?算法：利?時間序列分析、機(jī)器學(xué)習(xí)等??智能技術(shù)進(jìn)?銷量、單量的預(yù)測，是預(yù)測系統(tǒng)中最為核?的部分。預(yù)測結(jié)果加?：預(yù)測結(jié)果可能在格式和?些特殊性要求上不能滿?下游系統(tǒng)，所以還需要根據(jù)實(shí)際情況對其進(jìn)?加?處理，?如增加標(biāo)準(zhǔn)差、促銷標(biāo)識等額外信息。1.預(yù)測結(jié)果輸出層：將最終預(yù)測結(jié)果同步回京東數(shù)據(jù)倉庫、MySql、HBase或制作成JSF接?供其他系統(tǒng)遠(yuǎn)程調(diào)?。2.下游系統(tǒng)：包括下游任務(wù)流程、下游Web系統(tǒng)和其他系統(tǒng)。1.預(yù)測系統(tǒng)核?介紹1.預(yù)測系統(tǒng)核?層技術(shù)選型預(yù)測系統(tǒng)核?層技術(shù)主要分為四層：基礎(chǔ)層、框架層、?具層和算法層基礎(chǔ)層：HDFS?來做數(shù)據(jù)存儲，Yarn?來做資源調(diào)度，BDP（BigDataPlatform）是京東??研發(fā)的?數(shù)據(jù)平臺，我們主要?它來做任務(wù)調(diào)度。框架層：以SparkRDD、SparkSQL、Hive為主，MapReduce程序占??部分，是原先遺留下來的，?前正逐步替換成SparkRDD。選擇Spark除了對性能的考慮外，還考慮了Spark程序開發(fā)的?效率、多語?特性以及對機(jī)器學(xué)習(xí)算法的?持。在Spark開發(fā)語?上我們選擇了Python，原因有以下三點(diǎn)：1.Python有很多不錯的機(jī)器學(xué)習(xí)算法包可以使?，?起Spark的MLlib，算法的準(zhǔn)確度更?。我們?GBDT做過對?，發(fā)現(xiàn)xgboost?MLlib??提供的提升樹模型預(yù)測準(zhǔn)確度?出?概5%~10%。雖然直接使?Spark?帶的機(jī)器學(xué)習(xí)框架會節(jié)省我們的開發(fā)成本，但預(yù)測準(zhǔn)確度對于我們來說?關(guān)重要，每提升1%的準(zhǔn)確度，就可能會帶來成本的成倍降低。2.我們的團(tuán)隊(duì)中包括開發(fā)?程師和算法?程師，對于算法?程師??他們更擅長使?Python進(jìn)?數(shù)據(jù)分析，使?Java或Scala會有不?的學(xué)習(xí)成本。3.對?其他語?，我們發(fā)現(xiàn)使?Python的開發(fā)效率是最?的，并且對于?個新?，學(xué)習(xí)Python?學(xué)習(xí)其他語?更加容易。?具層：???我們會結(jié)合??業(yè)務(wù)有針對性的開發(fā)?些算法，另???我們會直接使?業(yè)界?較成熟的算法和模型，這些算法都封裝在第三?Python包中。我們?較常?的包有xgboost、numpy、pandas、sklearn、scipy和hyperopt等Xgboost：它是GradientBoostingMachine的?個C++實(shí)現(xiàn)，xgboost最?的特點(diǎn)在于，它能夠?動利?CPU的多線程進(jìn)?并?，同時在算法上加以改進(jìn)提?了精度。numpy：是Python的?種開源的數(shù)值計算擴(kuò)展。這種?具可?來存儲和處理?型矩陣，?Python??的嵌套列表結(jié)構(gòu)要?效的多（該結(jié)構(gòu)也可以?來表?矩陣）。pandas：是基于NumPy的?種?具，該?具是為了解決數(shù)據(jù)分析任務(wù)?創(chuàng)建的。Pandas納?了?量庫和?些標(biāo)準(zhǔn)的數(shù)據(jù)模型，提供了?效地操作?型數(shù)據(jù)集所需的?具。sklearn：是Python重要的機(jī)器學(xué)習(xí)庫，?持包括分類、回歸、降維和聚類四?機(jī)器學(xué)習(xí)算法。還包含了特征提取、數(shù)據(jù)處理和模型評估三?模塊。scipy：是在NumPy庫的基礎(chǔ)上增加了眾多的數(shù)學(xué)、科學(xué)以及?程計算中常?的庫函數(shù)。例如線性代數(shù)、常微分?程數(shù)值求解、信號處理、圖像處理和稀疏矩陣等等。算法層：我們?到的算法模型?常多，原因是京東的商品品類齊全、業(yè)務(wù)復(fù)雜，需要根據(jù)不同的情況采?不同的算法模型。我們有?個獨(dú)?的系統(tǒng)來為算法模型與商品之間建?匹配關(guān)系，有些?較復(fù)雜的預(yù)測業(yè)務(wù)還需要使?多個模型。我們使?的算法總體上可以分為三類：時間序列、機(jī)器學(xué)習(xí)和結(jié)合業(yè)務(wù)開發(fā)的?些獨(dú)有的算法。1.機(jī)器學(xué)習(xí)算法主要包括GBDT、LASSO和RNN：GBDT：是?種迭代的決策樹算法，該算法由多棵決策樹組成，所有樹的結(jié)論累加起來做最終答案。我們?它來預(yù)測?銷量，但歷史規(guī)律不明顯的商品。RNN：這種?絡(luò)的內(nèi)部狀態(tài)可以展?動態(tài)時序?為。不同于前饋神經(jīng)?絡(luò)的是，RNN可以利?它內(nèi)部的記憶來處理任意時序的輸?序列，這讓它可以更容易處理如時序預(yù)測、語?識別等。LASSO：該?法是?種壓縮估計。它通過構(gòu)造?個罰函數(shù)得到?個較為精煉的模型，使得它壓縮?些系數(shù)，同時設(shè)定?些系數(shù)為零。因此保留了?集收縮的優(yōu)點(diǎn)，是?種處理具有復(fù)共線性數(shù)據(jù)的有偏估計。?來預(yù)測低銷量，歷史數(shù)據(jù)平穩(wěn)的商品效果較好。1.時間序列主要包括ARIMA和Holtwinters：ARIMA：全稱為?回歸積分滑動平均模型，于70年代初提出的?個著名時間序列預(yù)測?法，我們?它來主要預(yù)測類似庫房單量這種平穩(wěn)的序列。Holtwinters：?稱三次指數(shù)平滑算法，也是?個經(jīng)典的時間序列算法，我們?它來預(yù)測季節(jié)性和趨勢都很明顯的商品。1.結(jié)合業(yè)務(wù)開發(fā)的獨(dú)有算法包括WMAStockDT、SimilarityModel和NewProduct等：WMAStockDT：庫存決策樹模型，?來預(yù)測受庫存狀態(tài)影響較?的商品。SimilarityModel：相似品模型，使?指定的同類品數(shù)據(jù)來預(yù)測某商品未來銷量。NewProduct：新品模型，顧名思義就是?來預(yù)測新品的銷量。1.1.預(yù)測系統(tǒng)核?流程

預(yù)測核?流程主要包括兩類：以機(jī)器學(xué)習(xí)算法為主的流程和以時間序列分析為主的流程。1.以機(jī)器學(xué)習(xí)算法為主的流程如下：特征構(gòu)建：通過數(shù)據(jù)分析、模型試驗(yàn)確定主要特征，通過?系列任務(wù)?成標(biāo)準(zhǔn)格式的特征數(shù)據(jù)。模型選擇：不同的商品有不同的特性，所以?先會根據(jù)商品的銷量?低、新品舊品、假節(jié)?敏感性等因素分配不同的算法模型。特征選擇：對?批特征進(jìn)?篩選過濾不需要的特征，不同類型的商品特征不同。樣本分區(qū)：對訓(xùn)練數(shù)據(jù)進(jìn)?分組，分成多組樣本，真正訓(xùn)練時針對每組樣本?成?個模型?件。?般是同類型商品被分成?組，?如按品類維度分組，這樣做是考慮并?化以及模型的準(zhǔn)確性。模型參數(shù)：選擇最優(yōu)的模型參數(shù)，合適的參數(shù)將提?模型的準(zhǔn)確度，因?yàn)樾枰獙Σ煌膮?shù)組合分別進(jìn)?模型訓(xùn)練和預(yù)測，所以這?步是?常耗費(fèi)資源。模型訓(xùn)練：待特征、模型、樣本都確定好后就可以進(jìn)?模型訓(xùn)練，訓(xùn)練往往會耗費(fèi)很長時間，訓(xùn)練后會?成模型?件，存儲在HDFS中。模型預(yù)測：讀取模型?件進(jìn)?預(yù)測執(zhí)?。多模型擇優(yōu)：為了提?預(yù)測準(zhǔn)確度，我們可能會使?多個算法模型，當(dāng)每個模型的預(yù)測結(jié)果輸出后系統(tǒng)會通過?些規(guī)則來選擇?個最優(yōu)的預(yù)測結(jié)果。預(yù)測值異常攔截：我們發(fā)現(xiàn)越是復(fù)雜且不易解釋的算法越容易出現(xiàn)極個別預(yù)測值異常偏?的情況，這種預(yù)測偏??法結(jié)合歷史數(shù)據(jù)進(jìn)?解釋，因此我們會通過?些規(guī)則將這些異常值攔截下來，并且??個更加保守的數(shù)值代替。模型評價：計算預(yù)測準(zhǔn)確度，我們通常?使?mapd來作為評價指標(biāo)。誤差分析：通過分析預(yù)測準(zhǔn)確度得出?個誤差在不同維度上的分布，以便給算法優(yōu)化提供參考依據(jù)。1.以時間序列分析為主的預(yù)測流程如下：?成歷史時序：將歷史銷量、價格、庫存等數(shù)據(jù)按照規(guī)定格式?成時序數(shù)據(jù)。節(jié)假?因?：計算節(jié)假?與銷量之間的關(guān)系，?來平滑節(jié)假?對銷量影響。周?因?：計算周?到周?這7天與銷量的關(guān)系，?來平滑周?對銷量的影響。促銷因?：計算促銷與銷量之間的關(guān)系，?來平滑促銷對銷量的影響。因?平滑：歷史銷量是不穩(wěn)定的，會受到節(jié)假?、促銷等影響，在這種情況下進(jìn)?預(yù)測有很?難度，所以需要利?之前計算的各類因?對歷史數(shù)據(jù)進(jìn)?平滑處理。時序預(yù)測：在?個相對平穩(wěn)的銷量數(shù)據(jù)上通過算法進(jìn)?預(yù)測。因?疊加：結(jié)合未來節(jié)假?、促銷計劃等因素對預(yù)測結(jié)果進(jìn)?調(diào)整。1.1.Spark在預(yù)測核?層的應(yīng)?我們使?SparkSQL和SparkRDD相結(jié)合的?式來編寫程序，對于?般的數(shù)據(jù)處理，我們使?Spark的?式與其他?異，但是對于模型訓(xùn)練、預(yù)測這些需要調(diào)?算法接?的邏輯就需要考慮?下并?化的問題了。我們平均?個訓(xùn)練任務(wù)在?天處理的數(shù)據(jù)量?約在500G左右，雖然數(shù)據(jù)規(guī)模不是特別的龐?，但是Python算法包提供的算法都是單進(jìn)程執(zhí)?。我們計算過，如果使??臺機(jī)器訓(xùn)練全部品類數(shù)據(jù)需要?個星期的時間，這是?法接收的，所以我們需要借助Spark這種分布式并?計算框架來將計算分?jǐn)偟蕉鄠€節(jié)點(diǎn)上實(shí)現(xiàn)并?化處理。我們實(shí)現(xiàn)的?法很簡單，?先需要在集群的每個節(jié)點(diǎn)上安裝所需的全部Python包，然后在編寫Spark程序時考慮通過某種規(guī)則將數(shù)據(jù)分區(qū)，?如按品類維度，通過groupByKey操作將數(shù)據(jù)重新分區(qū)，每?個分區(qū)是?個樣本集合并進(jìn)?獨(dú)?的訓(xùn)練，以此達(dá)到并?化。流程如下圖所?：

偽碼如下：sc.textFile("...").map(lambdax:repartitionBy(x)).groupByKey().map(lambdax:train(x)).saveAsPickleFile("...")repartitionBy?法即設(shè)置?個重分區(qū)的邏輯返回(K,V)結(jié)構(gòu)RDD，train?法是訓(xùn)練數(shù)據(jù)，在train?法??會調(diào)?Python算法包接?。saveAsPickleFile是SparkPython獨(dú)有的?個Action操作，?持將RDD保存成序列化后的sequnceFile格式的?件，在序列化過程中會以10個?批的?式進(jìn)?處理，保存模型?件?常適合。雖然原理簡單，但存在著?個難點(diǎn)，即以什么樣的規(guī)則進(jìn)?分區(qū)，key應(yīng)該如何設(shè)置。為了解決這個問題我們需要考慮?個??，第?就是哪些數(shù)據(jù)應(yīng)該被聚合到?起進(jìn)?訓(xùn)練，第?就是如何避免數(shù)據(jù)傾斜。針對第?個問題我們做了如下?點(diǎn)考慮：1.被分在?個分區(qū)的數(shù)據(jù)要有?定的相似性，這樣訓(xùn)練的效果才會更好，?如按品類分區(qū)就是個典型例?。2.分析商品的特性，根據(jù)特性的不同選擇不同的模型，例如?銷商品和低銷商品的預(yù)測模型是不?樣的，即使是同?模型使?的特征也可能不同，?如對促銷敏感的商品就需要更多與促銷相關(guān)特征，相同模型相同特征的商品應(yīng)傾向于分在?個分區(qū)中。針對第?個問題我們采?了如下的?式解決：1.對于數(shù)據(jù)量過?的分區(qū)進(jìn)?隨機(jī)抽樣選取。2.對于數(shù)據(jù)量過?的分區(qū)還可以做?次拆分，?如圖書?說這個品類數(shù)據(jù)量明顯?于其他品類，于是就可以分析?說品類下的?品類數(shù)據(jù)量分布情況，并將?品類合并成新的?個分區(qū)。3.對于數(shù)據(jù)量過?這種情況則需要考慮進(jìn)??個分區(qū)數(shù)據(jù)的合并處理?？傊畬τ诤髢煞N處理?式可以單獨(dú)通過?個Spark任務(wù)定期運(yùn)?，并將這種分區(qū)規(guī)則保存。1.結(jié)合圖解Spark書進(jìn)?應(yīng)?與優(yōu)化《圖解Spark：核?技術(shù)與案例實(shí)戰(zhàn)》?書以Spark2.0版本為基礎(chǔ)進(jìn)?編寫，系統(tǒng)介紹了Spark核?及其?態(tài)圈組件技術(shù)。其內(nèi)容包括Spark?態(tài)圈、實(shí)戰(zhàn)環(huán)境搭建和編程模型等，重點(diǎn)介紹了作業(yè)調(diào)度、容錯執(zhí)?、監(jiān)控管理、存儲管理以及運(yùn)?架構(gòu)，同時還介紹了Spark?態(tài)圈相關(guān)組件，包括了SparkSQL的即席查詢、SparkStreaming的實(shí)時流處理、MLlib的機(jī)器學(xué)習(xí)、GraphX的圖處理和Alluxio的分布式內(nèi)存?件系統(tǒng)等。下?介紹京東預(yù)測系統(tǒng)如何進(jìn)?資源調(diào)度，并描述如何使?Spark存儲相關(guān)知識進(jìn)?系統(tǒng)優(yōu)化。1.1.結(jié)合系統(tǒng)中的應(yīng)?在圖解Spark書的第六章描述了Spark運(yùn)?架構(gòu)，介紹了Spark集群資源調(diào)度?般分為粗粒度調(diào)度和細(xì)粒度調(diào)度兩種模式。粗粒度包括了獨(dú)?運(yùn)?模式和Mesos粗粒度運(yùn)?模式，在這種情況下以整個機(jī)器作為分配單元執(zhí)?作業(yè)，該模式優(yōu)點(diǎn)是由于資源長期持有減少了資源調(diào)度的時間開銷，缺點(diǎn)是該模式中?法感知資源使?的變化，易造成系統(tǒng)資源的閑置，從?造成了資源浪費(fèi)。?細(xì)粒度包括了Yarn運(yùn)?模式和Mesos細(xì)粒度運(yùn)?模式,該模式的優(yōu)點(diǎn)是系統(tǒng)資源能夠得到充分利?，缺點(diǎn)是該模式中每個任務(wù)都需要從管理器獲取資源，調(diào)度延遲較?、開銷較?。由于京東Spark集群屬于基礎(chǔ)平臺，在公司內(nèi)部共享這些資源，所以集群采?的是Yarn運(yùn)?模式，在這種模式下可以根據(jù)不同系統(tǒng)所需要的資源進(jìn)?靈活的管理。在YARN-Cluster模式中，當(dāng)?戶向YARN集群中提交?個應(yīng)?程序后，YARN集群將分兩個階段運(yùn)?該應(yīng)?程序：第?個階段是把Spark的SparkContext作為ApplicationMaster在YARN集群中先啟動；第?個階段是由ApplicationMaster創(chuàng)建應(yīng)?程序，然后為它向ResourceManager申請資源，并啟動Executor來運(yùn)?任務(wù)集，同時監(jiān)控它的整個運(yùn)?過程，直到運(yùn)?完成。下圖為Yarn-Cluster運(yùn)?模式執(zhí)?過程：1.1.結(jié)合系統(tǒng)的優(yōu)化我們都知道?數(shù)據(jù)處理的瓶頸在IO。我們借助Spark可以把迭代過程中的數(shù)據(jù)放在內(nèi)存中，相?MapReduce寫到磁盤速度提?近兩個數(shù)量級；另外對于數(shù)據(jù)處理過程盡可能避免Shuffle，如果不能避免則Shuffle前盡可能過濾數(shù)據(jù)，減少Shuffle數(shù)據(jù)量；最后，就是使??效的序列化和壓縮算法。在京東預(yù)測系統(tǒng)主要就是圍繞這些環(huán)節(jié)展開優(yōu)化，相關(guān)Spark存儲原理知識可以參見圖解Spark書第五章的詳細(xì)描述。

由于資源限制，分配給預(yù)測系統(tǒng)的Spark集群規(guī)模并不是很?,在有限的資源下運(yùn)?Spark應(yīng)?程序確實(shí)是?個考驗(yàn)，因?yàn)樵谶@種情況下經(jīng)常會出現(xiàn)諸如程序計算時間太長、找不到Executor等錯誤。我們通過調(diào)整參數(shù)、修改設(shè)計和修改程序邏輯三個??進(jìn)?優(yōu)化：1.1.1.4.2.1參數(shù)調(diào)整2.減少num-executors，調(diào)?executor-memory，這樣的?的是希望Executor有?夠的內(nèi)存可以使?。3.查看?志發(fā)現(xiàn)沒有?夠的空間存儲?播變量，分析是由于Cache到內(nèi)存?的數(shù)據(jù)太多耗盡了內(nèi)存，于是我們將Cache的級別適當(dāng)調(diào)成MEMORY_ONLY_SER和DISK_ONLY。4.針對某些任務(wù)關(guān)閉了推測機(jī)制，因?yàn)橛行┤蝿?wù)會出現(xiàn)暫時?法解決的數(shù)據(jù)傾斜問題，并?節(jié)點(diǎn)出現(xiàn)問題。5.調(diào)整內(nèi)存分配，對于?個Shuffle很多的任務(wù)，我們就把Cache的內(nèi)存分配?例調(diào)低，同時調(diào)?Shuffle的內(nèi)存?例。1.1.4.2.2修改設(shè)計參數(shù)的調(diào)整雖然容易做，但往往效果不好，這時候需要考慮從設(shè)計的?度去優(yōu)化：1.原先在訓(xùn)練數(shù)據(jù)之前會先讀取歷史的?個?甚??年的數(shù)據(jù)，對這些數(shù)據(jù)進(jìn)?合并、轉(zhuǎn)換等?系列復(fù)雜的處理，最終?成特征數(shù)據(jù)。由于數(shù)據(jù)量龐?，任務(wù)有時會報錯。經(jīng)過調(diào)整后當(dāng)天只處理當(dāng)天數(shù)據(jù)，并將結(jié)果保存到當(dāng)?分區(qū)下，訓(xùn)練時按天數(shù)需要讀取多個分區(qū)的數(shù)據(jù)做union操作即可。2.將“模型訓(xùn)練”從每天執(zhí)?調(diào)整到每周執(zhí)?，將“模型參數(shù)選取”從每周執(zhí)?調(diào)整到每?執(zhí)?。因?yàn)檫@兩個任務(wù)都?分消耗資源，并且屬于不需要頻繁運(yùn)?，這么做雖然準(zhǔn)確度會略微降低，但都在可接受范圍內(nèi)。3.通過拆分任務(wù)也可以很好的解決資源不夠?的問題?？梢詸M向拆分，?如原先是將100個品類數(shù)據(jù)放在?個任務(wù)中進(jìn)?訓(xùn)練，調(diào)整后改成每10個品類提交?次Spark作業(yè)進(jìn)?訓(xùn)練。這樣雖然整體執(zhí)?時間變長，但是避免了程序異常退出，保證任務(wù)可以執(zhí)?成功。除了橫向還可以縱向拆分，即將?個包含10個Stage的Spark任務(wù)拆分成兩個任務(wù)，每個任務(wù)包含5個Stage，中間數(shù)據(jù)保存到HDFS中。1.1.修改程序邏輯為了進(jìn)?步提?程序的運(yùn)?效率，通過修改程序的邏輯來提?性能，主要是在如下??進(jìn)?了改進(jìn)：避免過多的Shuffle、減少Shuffle時需要傳輸?shù)臄?shù)據(jù)和處理數(shù)據(jù)傾斜問題等。1避免過多的Shuffle1.Spark提供了豐富的轉(zhuǎn)換操作，可以使我們完成各類復(fù)雜的數(shù)據(jù)處理?作，但是也正因?yàn)槿绱宋覀冊趯慡park程序的時候可能會遇到?個陷阱，那就是為了使代碼變的簡潔過分依賴RDD的轉(zhuǎn)換操作，使本來僅需?次Shuffle的過程變?yōu)榱藞?zhí)?多次。我們就曾經(jīng)犯過這樣?個錯誤,本來可以通過?次groupByKey完成的操作卻使?了兩回。業(yè)務(wù)邏輯是這樣的：我們有三張表分別是銷量（s）、價格（p）、庫存（v），每張表有3個字段：商品id（sku_id）、品類id（category）和歷史時序數(shù)據(jù)（data），現(xiàn)在需要按sku_id將s、p、v數(shù)據(jù)合并，然后再按category再合并?次，最終的數(shù)據(jù)格式是：[category，[[sku_id,s,p,v],[sku_id,s,p,v],[…]，[…]]]。?開始我們先按照sku_id+category作為key進(jìn)??次groupByKey，將數(shù)據(jù)格式轉(zhuǎn)換成[sku_id,category,[s，p,v]]，然后按category作為key再groupByKey?次。后來我們修改為按照category作為key只進(jìn)??次groupByKey，因?yàn)?個sku_id只會屬于?個category，所以后續(xù)的map轉(zhuǎn)換??只需要寫?些代碼將相同sku_id的s、p、v數(shù)據(jù)group到?起就可以了。兩次groupByKey的情況：修改后變?yōu)?次groupByKey的情況：1.多表join時，如果key值相同，則可以使?union+groupByKey+flatMapValues形式進(jìn)?。?如：需要將銷量、庫存、價格、促銷計劃和商品信息通過商品編碼連接到?起，?開始使?的是join轉(zhuǎn)換操作，將?個RDD彼此join在?起。后來發(fā)現(xiàn)這樣做運(yùn)?速度?常慢，于是換成union+groypByKey+flatMapValue形式，這樣做只需進(jìn)??次Shuffle，這樣修改后運(yùn)?速度?以前快多了。實(shí)例代碼如下：rdd1=rdd1.mapValues(lambdax:(1,x))rdd2=rdd2.mapValues(lambdax:(2,x))rdd3=rdd3.mapValues(lambdax:(3,x))defdispatch(seq):vbuf,wbuf,xbuf=[],[],[]for(n,v)inseq:ifn==1:vbuf.append(v)elifn==2:wbuf.append(v)elifn==3:xbuf.append(v)return[(v,w,x)forvinvbufforwinwbufforxinxbuf]new_rdd=sc.union([rdd1,rdd3,rdd3]).groupByKey().flatMapValues(lambdax:dispatch(x))1.如果兩個RDD需要在groupByKey后進(jìn)?join操作，可以使?cogroup轉(zhuǎn)換操作代替。?如，將歷史銷量數(shù)據(jù)按品類進(jìn)?合并，然后再與模型?件進(jìn)?join操作，流程如下：[sku_id,category,sales]->[category,[[sku_id,sales],[…]]]->[category,[[[sku_id,sales],[…]],[model1,model2]]]使?cogroup后，經(jīng)過?次Shuffle就可完成了兩步操作，性能?幅提升。2.減少Shuff