丨內(nèi)存視角一如何最大化的使用效率

第5講中講過(guò)的LabelEncoding。在LabelEncoding的業(yè)務(wù)場(chǎng)中，我們需要對(duì)用戶特征做Encoding。依據(jù)模板中字符串及其索引位置，我們的任務(wù)1234//模板文//用體育-籃球-NBA-湖軍事--實(shí)現(xiàn)的代碼如下所示，注意啦，這里的代碼是第5講中優(yōu)化后的版本代代123456789輸入?yún)?shù)：模板文件路徑字符返回值//函數(shù)定字符串對(duì)應(yīng)的索valfindIndex:(String)=>(String)=>Int{(filePath)valsource=Source.fromFile(filePath,"UTF-8")vallines=source.getLines().toArrayvalap=lines.zip(0until(interest)=>}ap.getOrElse(interest,-valpartFunc=，fndIndex函數(shù)的主體邏輯比較簡(jiǎn)單，就是模板文件和構(gòu)建p映射，以及查找用戶并返回索引。不過(guò)，findIndex數(shù)義成階函這樣，當(dāng)板文件為實(shí)參調(diào)用這個(gè)高階函數(shù)的時(shí)候，我們會(huì)得到一個(gè)內(nèi)置了Mapu，最后在千億樣本上調(diào)用partuc利用高階函數(shù)，我們就避免了讓Execuor中的每一個(gè)k去模板文件，以及從頭構(gòu)建Map字典這種執(zhí)行低效的做法。在運(yùn)行時(shí)，這個(gè)函數(shù)在Driver端會(huì)被封裝到一個(gè)又一個(gè)的Task中去，隨后Driver把這些Task分發(fā)到Executor，Executor接收到任務(wù)之后，交由線程池去執(zhí)行（調(diào)度系統(tǒng)的內(nèi)容可以回顧第5講）。這個(gè)時(shí)候，每個(gè)Task就像是一架架小飛機(jī)，攜帶著代碼“乘客”和數(shù)據(jù)“行李”，從Driver飛往Executor。Task小飛機(jī)在Executor機(jī)場(chǎng)著陸之后，代碼“乘客”乘坐出租車(chē)或是機(jī)場(chǎng)大巴，去往JVMstack；數(shù)據(jù)“行李”則由專人堆放在JVMHeap，也就是我們常說(shuō)的堆內(nèi)內(nèi)存。回顧Labelencoding中的findIndex函數(shù)不難發(fā)現(xiàn)，其中大部分都是代碼“乘客”，唯一的數(shù)據(jù)“行李”是名為sear ap的Map字典。像這樣用戶自定義的數(shù)據(jù)結(jié)構(gòu)，消耗的內(nèi)存區(qū)域就是堆內(nèi)內(nèi)存的UserMemory（Spark對(duì)內(nèi)存區(qū)域的劃分內(nèi)容可以回顧一下第7講）。UserMemory性能隱回顧到這里，你覺(jué)得findIndex函數(shù)有沒(méi)有性能隱患呢？你可以先自己思考一下，有了答的“燃油”，這里的“燃油”指的是Task分發(fā)過(guò)程中帶來(lái)的網(wǎng)絡(luò)開(kāi)銷(xiāo)。其次，因?yàn)槊考苄★w機(jī)著陸之后，都會(huì)在Executor的“旅客行李專區(qū)”UserMemory寄存上這份同樣的數(shù)據(jù)“行李”，所以，UserMemory需要確保有足夠的空間可以寄存所有旅客的行那么，UserMemory到底需要準(zhǔn)備出多大的內(nèi)存空間才行呢？我們不妨來(lái)算一算。這樣的攜帶的數(shù)據(jù)結(jié)構(gòu)的生命周期也就告一段落。因此，在Task的數(shù)量統(tǒng)計(jì)上，我們不一個(gè)Executor需要處理多少個(gè)Task，只需要關(guān)注它在同一時(shí)間可以并行處理的Task數(shù)量，也就是Executor的線程池大小即可。我們，Executor線程池大小由spark.executor.cores和spark.task.cpus這兩個(gè)參數(shù)#threads接下來(lái)是估算數(shù)據(jù)“行李”大小，由于searap并不是分布式數(shù)據(jù)集，因此我們不必采用先CacheSpark行計(jì)劃統(tǒng)計(jì)信息的方式。對(duì)于這Java據(jù)結(jié)構(gòu)，我們完全可以在REPL中，通過(guò)Java的常規(guī)方法估算數(shù)據(jù)大小，估算得到的searap小#size好啦！現(xiàn)在，我們可以算出，UserMemory至少需要提供#threads*#size這么大的內(nèi)存空間，才能支持分布式任務(wù)完成計(jì)算。但是，對(duì)于UserMemory內(nèi)存區(qū)域來(lái)說(shuō)，使用#threads*#size的空間去重復(fù)同樣的數(shù)據(jù)，本身就是降低了內(nèi)存的利用率。那么，我們?cè)撛趺词〉?threads*#size的內(nèi)存消耗呢？仔細(xì)觀察findIndex函數(shù)，我們不難發(fā)現(xiàn)，函數(shù)的計(jì)算邏輯有兩點(diǎn)。一是模板文件、創(chuàng)建Map映射字典；二是以給定字符串對(duì)字典進(jìn)行查找，并返回查找結(jié)果。顯然，千億樣本轉(zhuǎn)換的需求是其中的第二個(gè)環(huán)節(jié)。既然如此，我們完全可以把創(chuàng)建好的Map字典封裝成廣播變量，然后分發(fā)到各個(gè)Executors中去。有了廣播變量的幫忙，凡是發(fā)往同一個(gè)Executor的Task小飛機(jī)，都無(wú)需親自攜帶數(shù)據(jù)“行李”，這些大件行李會(huì)由“廣播快遞公司”派貨機(jī)專門(mén)發(fā)往各個(gè)Executors，Driver每個(gè)Executors間，都有一班這樣的貨運(yùn)專線。思路說(shuō)完了，優(yōu)化后的代碼如代代1廣播變量實(shí)現(xiàn)方4456789valsource=Source.fromFile(filePath,"UTF-8")vallines=source.getLines().toArrayval ap=lines.zip(0untilval ap=//在Dataset ap.value.getOrElse("體育-籃球-NBA-湖人",-上面代碼的實(shí)現(xiàn)思路很簡(jiǎn)單：第一步還是模板文件、創(chuàng)建Map字典；第二步，Map字典封裝為廣播變量。這樣一來(lái)，在對(duì)千億樣本進(jìn)行轉(zhuǎn)換時(shí)，我們直接通 ap.value廣播變量?jī)?nèi)容，然后，通過(guò)調(diào)用Map字典的getOrElse方法來(lái)我們發(fā)現(xiàn)，Task小飛機(jī)的代碼“乘客”了！小飛機(jī)之前需要攜帶函數(shù)findIndex，現(xiàn)在則換成了一位“的乘客”：一個(gè)廣播變量并調(diào)用其getOrElse方法的函數(shù)。由于這位“的乘客”將大件行李托運(yùn)給了“廣播快遞公司”的貨機(jī)，因此，Task小飛機(jī)著陸后，沒(méi)有任何“行李”需要寄存到UserMemory。換句話說(shuō)，優(yōu)化后的版本不會(huì)對(duì)UserMemory內(nèi)存區(qū)域進(jìn)行占用，所以第一種實(shí)現(xiàn)方式中#threads*#size的內(nèi)存消耗就可以省掉了。StorageMemory規(guī)回顧系統(tǒng)那一講，我們，Spark系統(tǒng)主要有3個(gè)服務(wù)對(duì)象，分別是Shuffle間文件、RDD廣播變量。它們Executor的BlockManager行管理，對(duì)于數(shù)據(jù)在內(nèi)存和磁盤(pán)中的，BlockManager利用MemoryStore和DiskStore進(jìn)行抽象和封裝。那么，廣播變量所攜帶的數(shù)據(jù)內(nèi)容會(huì)物化到MemoryStore中去，以Executor為粒度為所有Task提供唯一的一份數(shù)據(jù)拷貝。MemoryStore產(chǎn)生的內(nèi)存占用會(huì)被記入到Memory的賬上。因此，廣播變量消耗的就是StorageMemory內(nèi)存區(qū)域的分發(fā)和以Executor為粒度，因此每個(gè)Executor消耗的內(nèi)存空間，就是 ap一份數(shù)據(jù)拷貝的大小。 ap的大小我們剛剛計(jì)算過(guò)就是#size明確了StorageMemory內(nèi)存區(qū)域的具體消耗之后，我們自然可以根據(jù)（spark.executor.memory–300MB）*spark.memory.fraction*spark.memory.storageFraction有針對(duì)性地調(diào)節(jié)相關(guān)的內(nèi)存配置項(xiàng)。 Memory、UserMemory、StorageMemory和ExecutionMemory這4個(gè)區(qū)域。預(yù)留內(nèi)存固定為300MB，不用理會(huì)，其他3個(gè)區(qū)域需要你去規(guī)預(yù)估內(nèi)存占首先，我們來(lái)說(shuō)內(nèi)存占用的預(yù)估，主要分為三步第一步，計(jì)算UserMemory內(nèi)存消耗。我們先匯總應(yīng)用中包含的自定義數(shù)據(jù)結(jié)構(gòu)，并估算這些對(duì)象的總大小#size，然后用#size乘以Executor的線程池大小，即可得到UserMemory區(qū)域的內(nèi)存消耗#User。第二步，計(jì)算StorageMemory的內(nèi)存消耗。我們先匯總應(yīng)用中涉及的廣播變量和分布式數(shù)據(jù)集緩存，分別估算這兩類對(duì)象的總大小，分別記為#bc、#cache。另外，我中的Executors總數(shù)記作#E。這樣，每個(gè)Executor中StorageMemory區(qū)域的內(nèi)存消耗的就是：#Storage=#bc+#cache/#E。第三步，計(jì)算執(zhí)行內(nèi)存的消耗。學(xué)習(xí)上一講，我們知道執(zhí)行內(nèi)存的消耗與多個(gè)因素有關(guān)。第一個(gè)因素是Executor#thread，第二個(gè)因素是數(shù)據(jù)分片大小，而數(shù)據(jù)分片大小取決于數(shù)據(jù)集尺寸#dtat#每個(gè)Exeutor算為：xeuon=hreds*set/#。調(diào)整內(nèi)存配置得到這3內(nèi)存區(qū)域的預(yù)估大小#User、#Storage、#Execution后，調(diào)整相關(guān)的內(nèi)存配置項(xiàng)就是一件水到渠成的事情（由（spark.executor.memory–300MB）*spark.memory.fraction*spark.memory.storageFraction）可知），這里我們也可以分為3步。首先，根據(jù)定義，spark.memory.fraction可以由（#Storage+（#User+#Storage+#Execution）計(jì)算得到同理，spark.memory.storageFraction數(shù)值應(yīng)該參考（#Storage）/（#Storage最后，對(duì)于xecutorspark.exector.meory個(gè)內(nèi)存區(qū)域的總消耗，也就是300MB+User+torage+ecution。不過(guò)，我們要注意，利用這個(gè)計(jì)算的前提是，不同內(nèi)存區(qū)域的占比與不同類型的數(shù)據(jù)消耗一致。合理劃分Spark的內(nèi)存區(qū)域，是同時(shí)提升CPU內(nèi)存利用率的基礎(chǔ)。因此，掌握內(nèi)第一步是預(yù)估內(nèi)存占用求出UserMemory區(qū)域的內(nèi)存消耗，為：#User=#size乘以Executor線程池的求出每個(gè)Executor中StorageMemory區(qū)域的內(nèi)存消耗，為：#Storage=+#cache/#E求出執(zhí)行內(nèi)存區(qū)域的內(nèi)存消耗，為：#Execution=#threads*#dataset/#N第二步是調(diào)整內(nèi)存配置項(xiàng)：根據(jù)得到的3個(gè)內(nèi)存區(qū)域的預(yù)估大小#User、#Storage、#Execution，去調(diào)整（spark.executor.memory–300MB）*spark.memory.fraction*spark.memory.storageFraction中涉及的所有配置項(xiàng)。spark.memory.fraction可以由（#Storage+#Execution）/（#User+#Storage+#Execution）計(jì)算得到。spark.memory.storageFraction數(shù)值應(yīng)該參考（#Storage）/（#Storagespark.executor.memory的設(shè)置，可以通過(guò)300MB+#User+#Storage+#Execution得到。這里，我還想多說(shuō)幾句，內(nèi)劃兩終歸最終到的和目是確保不同內(nèi)存區(qū)域的占比與不同類型的數(shù)據(jù)消耗保持一致，從而實(shí)現(xiàn)內(nèi)存利用率的最大化。你知道估算Java對(duì)象大小的方法有哪些嗎？不同的方法又有哪些優(yōu)、劣勢(shì)呢期待在留言區(qū)看到你的思考和答案，我們下 科技所有 不得售賣(mài)。頁(yè)面已增加防盜追蹤，將依 其上一 14|CPU視角：如何高效地利用下一 16|內(nèi)存視角（二）：如何有效避免Cache言精選留言言展是UserMemory中的數(shù)據(jù)卻不行。廣播變量這個(gè)“貨物”的具體地址，lockMaager會(huì)幫忙記錄，所以“后來(lái)的人如果需要廣播變量，它能從lockManage那里迅速地知道廣播變量在哪里（哪個(gè)u。但是，UserMemory也好，Storage、Executionmemory也罷，他們本質(zhì)上就是JVMheap。JVMheap雖然也會(huì)記錄對(duì)象對(duì)應(yīng)的地址，但是，它沒(méi)有辦法區(qū)分，兩份數(shù)據(jù)，在內(nèi)容7展4問(wèn)題一：UserMemory、ExecutionMemory、StorageMemory是屬于Spark自身對(duì)內(nèi)存區(qū)域的劃分，但Spark的executor實(shí)際上又是一個(gè)JVM，假如我把UserMemoryUserMemoryutionMemory、StorageMemoryOOM展問(wèn)題一：你說(shuō)的沒(méi)錯(cuò)，不管是哪片內(nèi)存區(qū)域，實(shí)際上都是JMp的一部分。回答你的問(wèn)題：如果User空間不足，但是rky（rage+Executin）空閑，會(huì)不會(huì)OOM？對(duì)于這種情況，即使你自定的數(shù)據(jù)結(jié)構(gòu)其實(shí)超過(guò)了User，但實(shí)際上，并不會(huì)立即報(bào)OOM，rk對(duì)于堆內(nèi)內(nèi)存的預(yù)估，沒(méi)有那么精確。這里有些c，對(duì)于rk劃定的各種“線”，也就是通過(guò)配置項(xiàng)設(shè)置的不同區(qū)域的百分比，它類似于一種“軟限制”，也就是建議你遵守它劃出的一道道“線”，但如果你沒(méi)有遵守，強(qiáng)行“跨線”，只要其他區(qū)域還有空間，你真的搶占了，rk即，即使是紅燈，只要沒(méi)有機(jī)動(dòng)車(chē)通行，咱