本篇內(nèi)容介紹了“Spark 3.0怎么實(shí)現(xiàn)event logs滾動(dòng)”的有關(guān)知識，在實(shí)際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

成都創(chuàng)新互聯(lián)堅(jiān)持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：做網(wǎng)站、成都網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時(shí)代的昌寧網(wǎng)站設(shè)計(jì)、移動(dòng)媒體設(shè)計(jì)的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

事件日志滾動(dòng)

首先必須使用 Spark 3.0，同時(shí)將 spark.eventLog.rolling.enabled 設(shè)置為 true(默認(rèn)是 false)。那么  Spark 在 writeEvent 的時(shí)候會判斷當(dāng)前在寫的 event log 文件大小加上現(xiàn)在新來的事件日志大小總和是否大于  spark.eventLog.rolling.maxFileSize 參數(shù)配置的值，如果滿足將啟動(dòng) event log roll 操作。

事件日志壓縮

所謂事件日志壓縮就是將多個(gè)滾動(dòng)出來的事件日志文件合并到一個(gè)壓縮的文件中。日志壓縮涉及到的參數(shù)有  spark.history.fs.eventLog.rolling.maxFilesToRetain 和  spark.history.fs.eventLog.rolling.compaction.score.threshold。第一個(gè)參數(shù)的意思是進(jìn)行  Compaction 之后需要保存多少個(gè) event logs 為不壓縮的狀態(tài)，這個(gè)參數(shù)的默認(rèn)值是 Int.MaxValue。也就是默認(rèn)其實(shí)不啟用事件日志  Compaction，所有 event logs 都將不會被 Compaction 到一個(gè)文件里面。

需要注意的：

• event logs 的 Compaction 操作是在 Spark 歷史服務(wù)器端進(jìn)行的，而且是在 Spark 歷史服務(wù)器檢查到有新的事件日志寫到  spark.eventLog.dir 參數(shù)配置的目錄中，這時(shí)候?qū)?yīng) Spark 作業(yè)的 event logs 將可能進(jìn)行 compact 操作。

• event logs 的 Compaction 操作可能會刪除一些沒用的事件日志，關(guān)于刪除的邏輯請看下一小結(jié)。這樣經(jīng)過 Compaction  操作之后，新生成的壓縮文件大小將會變小。

• 一個(gè) Spark 作業(yè)最多只會有一個(gè) Compact 文件，文件的后綴是 .compact。已經(jīng)有 compact 之后的合并文件在下一次進(jìn)行  compact 的時(shí)候會被讀出來和需要被 compact 的文件再一次合并，然后寫到新的 compact 文件里。

• 已經(jīng)被選中進(jìn)行 compact 的 event logs 在執(zhí)行完 compact 之后會被刪除。

核心思想

整個(gè) event logs 滾動(dòng)項(xiàng)目應(yīng)該可以大致分為兩個(gè)階段：

• 第一個(gè)階段就是支持 event logs 滾動(dòng)以及 event logs Compaction，這個(gè)在 SPARK-28594 里面，已經(jīng)合并到  Spark 3.0 代碼中。

• 第二個(gè)階段是采用 AppStatusListener 使用的方法，即把 event logs 持久化到底層的 KVStore 中，并支持從  KVStore 把 event logs restore 出來，這個(gè)可以參見 SPARK-28870，這個(gè)還在開發(fā)中。

階段一

支持 event log 滾動(dòng)的隱層含義是支持刪除舊的事件日志，要不然光支持滾動(dòng)不支持刪除，只是解決了單個(gè) event log  文件的大小，解決不了整個(gè)作業(yè) event log 總和大小。

為了保證刪除舊的事件日志之后 event logs 仍然可以被 Spark 歷史服務(wù)器重放，我們需要定義出哪些事件日志是可以刪除的。

拿 Streaming  作業(yè)來說，每個(gè)批次都是運(yùn)行不同的作業(yè)。如果我們想刪除一些事件日志，在大多數(shù)情況下，我們都會保存最近一些批次作業(yè)的事件日志，因?yàn)檫@些事件日志有助于我們分析剛剛遇到的問題。換句話說，刪除那些比較舊的作業(yè)對應(yīng)的事件日志是比較安全的，而且是比較可行的。這個(gè)在  SQL 查詢的作業(yè)來說一樣是適用的。

目前 Spark 在內(nèi)存中會維護(hù)一些 liveExecutors、liveRDDs、liveJobs、liveStages 以及 liveTasks  等信息，當(dāng) Spark 歷史服務(wù)器觸發(fā) compact 操作的時(shí)候，會讀取需要 compact 的事件日志文件， 然后根據(jù)前面的  liveExecutors、liveRDDs、liveJobs、liveStages 以及 liveTasks  等信息判斷哪些事件需要?jiǎng)h除，哪些事件需要保留。滿足 EventFilter 定義的 Event 會被保留，不滿足的就刪除，具體可以參見 EventFilter  的 applyFilterToFile 方法實(shí)現(xiàn)。

階段二

AppStatusListener 會利用外部 KVStore 來存儲事件日志，所以社區(qū)建議利用現(xiàn)有特性在底層 KVStore 中保留最多數(shù)量的  Jobs、Stages 以及 SQL 執(zhí)行。為了存儲對象到 KVStore 以及從 KVStore 恢復(fù)對象，社區(qū)采用的方法是將 KVStore 中存儲的對象  dump 到一個(gè)文件中，這個(gè)稱為 snapshot。

從空間使用的角度來看，這個(gè)想法非常有效，因?yàn)樵?POC 中，只需 5MB 內(nèi)存就可以將 KVStore 中的數(shù)據(jù) dump 到文件中，其中回放了8.4GB  的事件日志。結(jié)果看起來很令人驚訝，但是很有意義，根據(jù)這個(gè)機(jī)制，在大多數(shù)情況下，dump 數(shù)據(jù)到文件需要的內(nèi)存大小不太可能發(fā)生顯著變化。

需要注意的是，快照里面的內(nèi)容與當(dāng)前事件日志文件的內(nèi)容是不同的。因?yàn)檫@個(gè)快照文件是從 KVStore dump  出來的，這些對象不會按創(chuàng)建的順序?qū)懭?。我們可以壓縮這些對象以節(jié)省空間和 IO  成本。在分析某個(gè)問題時(shí)，新產(chǎn)生的事件日志可能沒什么用，這就需要讀取和操作之前的事件日志文件。為了支持這種情況，需要將基本的 listener events  編寫為原始格式，然后滾動(dòng)事件日志文件，然后再將舊的事件日志保存到快照中，兩種格式的文件共存。這樣就滿足我們之前的需求。由于快照的存在，事件日志的總體大小不會無限增長。

新的方案中 event log 是如何存儲的呢

之前每個(gè) Spark 作業(yè)的 event log 都是保存在單個(gè)文件里面，如果事件日志沒有完成，會使用 .inprogress 后綴表示。新的 event  log 方案會為每個(gè) Spark 作業(yè)創(chuàng)建一個(gè)目錄來保存，因?yàn)槊總€(gè) Spark  作業(yè)可能會生成多個(gè)事件日志文件。事件日志的文件夾名稱格式為：eventlog_v2_appId(_)。在事件日志文件夾里面存儲的是對應(yīng)作業(yè)的事件日志，日志文件名稱格式為：events__(_)(.)。

為了說明，我這里進(jìn)行了一些測試，/data/iteblog/eventlogs 這個(gè)目錄就是 spark.eventLog.dir  參數(shù)設(shè)置的值，下面是這個(gè)目錄下的內(nèi)容：

iteblog@www.iteblog.com:/data/iteblog/eventlogs| ⇒  ll total 0 drwxrwx---  15 iteblog  wheel   480B  3  9 14:26 eventlog_v2_local-1583735123583 drwxrwx---   7 iteblog  wheel   224B  3  9 14:50 eventlog_v2_local-1583735259373  iteblog@www.iteblog.com:/data/iteblog/eventlogs/eventlog_v2_local-1583735259373| ⇒  ll total 416 -rw-r--r--  1 iteblog  wheel     0B  3  9 14:27 appstatus_local-1583735259373.inprogress -rwxrwx---  1 iteblog  wheel    64K  3  9 14:50 events_2_local-1583735259373.compact -rwxrwx---  1 iteblog  wheel   102K  3  9 14:50 events_3_local-1583735259373 -rwxrwx---  1 iteblog  wheel   374B  3  9 14:50 events_4_local-1583735259373

可以看到，當(dāng) Spark 作業(yè)還沒有完成的時(shí)候，會存在一個(gè) appstatus_local-1583735259373.inprogress  的空文件，真正的事件日志是寫到 events_x_local-1583735259373 文件里面。

“Spark 3.0怎么實(shí)現(xiàn)event logs滾動(dòng)”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！