欧美一区二区三区老妇人-欧美做爰猛烈大尺度电-99久久夜色精品国产亚洲a-亚洲福利视频一区二区

Spark生產(chǎn)作業(yè)容錯(cuò)能力的負(fù)面影響有哪些

這篇文章主要講解了“Spark生產(chǎn)作業(yè)容錯(cuò)能力的負(fù)面影響有哪些”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來(lái)研究和學(xué)習(xí)“Spark生產(chǎn)作業(yè)容錯(cuò)能力的負(fù)面影響有哪些”吧！

創(chuàng)新互聯(lián)公司是一家專注于網(wǎng)站建設(shè)、做網(wǎng)站和綿陽(yáng)主機(jī)托管的網(wǎng)絡(luò)公司，有著豐富的建站經(jīng)驗(yàn)和案例。

1. Spark TaskLocality

在 Spark 中數(shù)據(jù)本地性通過(guò) TaskLocality 來(lái)表示，有如下幾個(gè)級(jí)別，

  • PROCESS_LOCAL

  • NODE_LOCAL

  • NO_PREF

  • RACK_LOCAL

  • ANY

從上到下數(shù)據(jù)本地性依次遞減。

Spark 在執(zhí)行前通過(guò)數(shù)據(jù)的分區(qū)信息進(jìn)行計(jì)算 Task 的 Locality，Task 總是會(huì)被優(yōu)先分配到它要計(jì)算的數(shù)據(jù)所在節(jié)點(diǎn)以盡可能地減少網(wǎng)絡(luò) IO。這個(gè)計(jì)算的過(guò)程通過(guò) spark.locality.wait 默認(rèn)為3s，控制這個(gè)計(jì)算的過(guò)程。

2. Spark 內(nèi)部容錯(cuò)

原理這里不細(xì)講，簡(jiǎn)而言之就是重試。Spark 規(guī)定了同一個(gè) Job 中同一個(gè) Stage 連續(xù)失敗重試的上限（spark.stage.maxConsecutiveAttempts），默認(rèn)為4，也規(guī)定了一個(gè) Stage 中 同一個(gè) Task 可以失敗重試的次數(shù)（spark.task.maxFailures），默認(rèn)為4。當(dāng)其中任何一個(gè)閾值達(dá)到上限，Spark 都會(huì)使整個(gè) Job 失敗，停止可能的“無(wú)意義”的重試。

3. 數(shù)據(jù)本地性和容錯(cuò)的沖突

我們首先來(lái)看一個(gè)例子，如圖所示，圖為 Spark Stage 頁(yè)面下 Task Page 的詳細(xì)視圖。

  • 第一列表示該 Task 進(jìn)行了4次重試，所以這個(gè) Task 對(duì)應(yīng)的 Job 也因此失敗了。

  • 第三列表示該 Task 的數(shù)據(jù)本地性，都是 NODE_LOCAL 級(jí)別，對(duì)于一個(gè)從HDFS讀取數(shù)據(jù)的任務(wù)，顯然獲得了最優(yōu)的數(shù)據(jù)本地性

  • 第四列表示的是 Executor ID，我們可以看到我們?nèi)蝿?wù)的重試被分配到ID 為5和6兩個(gè) Executor 上

  • 第五列表示我們運(yùn)行這些重試的 Task 所在的 Executor 所在的物理機(jī)地址，我們可以看到他們都被調(diào)度到了同一個(gè)

  • 最后列表示每次重試失敗的錯(cuò)誤棧

3.1 問(wèn)題一：?jiǎn)蝹€(gè) Task 重試為什么失敗？

結(jié)合硬件層面的排查，發(fā)現(xiàn)是 NodeManager 物理節(jié)點(diǎn)上掛在的 /mnt/dfs/4，出現(xiàn)硬件故障導(dǎo)致盤只讀，ShuffleMapTask 在即將完成時(shí)，將index文件和data文件commit時(shí)，獲取index的臨時(shí)文件時(shí)候發(fā)生FileNotFoundException。   

java.io.FileNotFoundException: /mnt/dfs/4/yarn/local/usercache/da_haitao/appcache/application_1568691584183_1953115/blockmgr-1b6553f2-a564-4b31-a4a6-031f21c9c30f/0a/shuffle_96_2685_0.index.82594412-1f46-465e-a067-2c5e386a978e (No such file or directory)    at java.io.FileOutputStream.open0(Native Method)    at java.io.FileOutputStream.open(FileOutputStream.java:270)    at java.io.FileOutputStream.<init>(FileOutputStream.java:213)    at java.io.FileOutputStream.<init>(FileOutputStream.java:162)    at org.apache.spark.shuffle.IndexShuffleBlockResolver.writeIndexFileAndCommit(IndexShuffleBlockResolver.scala:144)    at org.apache.spark.shuffle.sort.UnsafeShuffleWriter.closeAndWriteOutput(UnsafeShuffleWriter.java:245)    at org.apache.spark.shuffle.sort.UnsafeShuffleWriter.write(UnsafeShuffleWriter.java:190)    at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:96)    at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:53)    at org.apache.spark.scheduler.Task.run(Task.scala:109)

3.2 問(wèn)題二：為什么該 Task 的4次重試都在同一個(gè)物理節(jié)點(diǎn)？

這是由于 Driver 在調(diào)度該 Task 的時(shí)候進(jìn)行了數(shù)據(jù)本地性的運(yùn)算，而且在  spark.locality.wait 默認(rèn)為3s的時(shí)間約束內(nèi)成功獲得了NODE_LOCAL級(jí)別的數(shù)據(jù)本地性，故而都調(diào)度到了同一個(gè)  NodeManger 物理節(jié)點(diǎn)。

3.3 問(wèn)題三：為什么總是“本地重試”，不是“異地重試”？
這個(gè)過(guò)程從邏輯上講，其實(shí)已經(jīng)不是“本地重試”，而恰恰是“異地重試”了。這我們可以從4次的重試的 Executor ID 上進(jìn)行判斷，第0、1和3次是在 ID 6上進(jìn)行的，而第2次是在 ID 5上發(fā)生的。但由于ID 5和6都在同一個(gè) NodeManger 節(jié)點(diǎn)，所以我們看起來(lái)像是“本地重試”。另一個(gè)原因就是上面所說(shuō)的數(shù)據(jù)本地性的成功解析，所以這些 Task 的每次重試都高概率的來(lái)到這個(gè)節(jié)點(diǎn)。  
所有 Spark Task 級(jí)別的重試從邏輯上都應(yīng)該屬于“異地重試”，他們都需要通過(guò) Driver 重新調(diào)度到新的 Executor 進(jìn)行重試。我們所觀測(cè)到的“本地”和“異地”是屬于“現(xiàn)象”而非“本質(zhì)”，影響這種現(xiàn)象的條件有比如下面幾個(gè)（不一定全面）：1. 數(shù)據(jù)本地性 2. Executor 由于 NodeLabel 限制，只在若干有限的物理機(jī)上分配 3. ResourceManager 調(diào)度時(shí)剛好把所有的 Executor 都分配到某個(gè)節(jié)點(diǎn)上。
3.4 問(wèn)題5：為什么4次失敗都操作同一個(gè)壞的盤？
該 NodeManger 實(shí)際上有/mnt/dfs/{0-11}， 一共12塊盤，從物理檢查上看，整個(gè)過(guò)程中也只有/mnt/dfs/4有異常告警，那為啥 Spark 這么傻？這么多好盤不用，專挑一塊壞的盤死磕？
我們可以先看下出錯(cuò)的文件，我們包這個(gè)文件分成5個(gè)部分來(lái)看，  
  
  
  1. /mnt/dfs/4/yarn/local/2. usercache/da_haitao/appcache/application_1568691584183_1953115/ blockmgr-1b6553f2-a564-4b31-a4a6-031f21c9c30f/3. 0a/4. shuffle_96_2685_0.index5. .82594412-1f46-465e-a067-2c5e386a978e
  • 第一行，是 Yarn NodeManger 所配置的LOCAL_DIR的一部分，完整的應(yīng)該包括12塊盤
  • 第二行，是 Spark 生成的 BlockManger 的根目錄之一，其他盤符下也有類似的一個(gè)目錄
  • 第三行，是一個(gè)根目錄下的一級(jí)子目錄，數(shù)量由 spark.diskStore.subDirectories 默認(rèn)為64控制
  • 第四行，Spark Shuffle 過(guò)程產(chǎn)生的兩個(gè)重要的文件之一，一個(gè)是數(shù)據(jù)文件 .data 結(jié)尾，另一個(gè)就是這個(gè)與之對(duì)應(yīng)的 .index 文件。96是 ShuffleID 表標(biāo)識(shí)是哪個(gè)Shuffle 過(guò)程，2685是 MapID 對(duì)應(yīng)的是 一個(gè)RDD 所以有分區(qū)中其中一個(gè)的順序號(hào)， 而0是一個(gè)固定值，原本表示是ReduceID，Spark Sort Based Shuffle 的實(shí)現(xiàn)不需要依賴這個(gè)值，所以被固定為了0。通過(guò)Shuffle ID和 MapId，Shufle Write 階段就可以生成類似shuffle_96_2685_0.index這樣的文件，而Shuffle Read 階段也可以通過(guò)兩個(gè)ID 定位到這個(gè)文件。
  • 第五行， 是Index文件的對(duì)應(yīng)臨時(shí)文件的UUID標(biāo)識(shí)。
基于這樣的邏輯，對(duì)于某次Shuffle 過(guò)程的某個(gè)分區(qū)（Partition）的最終輸出文件名其實(shí)是可以預(yù)測(cè)的也是固定的，比如我們這個(gè) case 中，第96次shuffle的第2685分區(qū)的 index 文件的文件名即為shuffle_96_2685_0.index。
Spark 在寫(xiě)和讀這個(gè)文件的時(shí)候，基于相同的定位邏輯（算法）來(lái)保證依賴關(guān)系，  
第一步確定根目錄，Spark 通過(guò)文件名的hash絕對(duì)值與盤符數(shù)的模，作為索引卻確定根目錄  
  scala> math.abs("shuffle_96_2685_0.index".hashCode) % 12res0: Int = 6
而根目錄的數(shù)組對(duì)于一個(gè) Executor 的這個(gè)生命周期內(nèi)而言是確定的，它是一個(gè)由簡(jiǎn)單隨機(jī)算法將所有路徑打散的一個(gè)固定數(shù)組。所以一旦文件名稱確定，Executor 不換的話，根目錄一定是確定的。所以都固定的去訪問(wèn)/mnt/dfs/4這個(gè)壞盤。  
但這只解釋了一個(gè) Executor 所被分配 Task 失敗的原因，我們的 Task 還在不同的 executor 上進(jìn)行過(guò)嘗試。
3.5 問(wèn)題5：為什么兩個(gè) Executor 上的重試都失敗了？
其實(shí)這個(gè)問(wèn)題只是概率的問(wèn)題, Spark 用類似下面算法打亂所有LOCAL_DIRS的配置，如下面的的簡(jiǎn)單測(cè)試，這種碰撞的概率還是極高的，我們ID 5，6，的 Executor 下 DiskBlockManager 包含的 localDirs(6)應(yīng)該都對(duì)應(yīng)于 /mnt/dfs/4 這個(gè)壞盤。  
scala> def randomizeInPlace[T](arr: Array[Int], rand: java.util.Random = new java.util.Random): Array[Int] = {     |     for (i <- (arr.length - 1) to 1 by -1) {     |       val j = rand.nextInt(i + 1)     |       val tmp = arr(j)     |       arr(j) = arr(i)     |       arr(i) = tmp     |     }     |     arr     |   }randomizeInPlace: [T](arr: Array[Int], rand: java.util.Random)Array[Int]scala> randomizeInPlace(res11)res23: Array[Int] = Array(3, 2, 4, 1)
scala> randomizeInPlace(res11)res24: Array[Int] = Array(2, 3, 4, 1)
scala> randomizeInPlace(res11)res25: Array[Int] = Array(2, 1, 3, 4)
scala> randomizeInPlace(res11)res26: Array[Int] = Array(4, 2, 1, 3)
scala> randomizeInPlace(res11)res27: Array[Int] = Array(2, 3, 4, 1)

感謝各位的閱讀，以上就是“Spark生產(chǎn)作業(yè)容錯(cuò)能力的負(fù)面影響有哪些”的內(nèi)容了，經(jīng)過(guò)本文的學(xué)習(xí)后，相信大家對(duì)Spark生產(chǎn)作業(yè)容錯(cuò)能力的負(fù)面影響有哪些這一問(wèn)題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！

網(wǎng)站欄目：Spark生產(chǎn)作業(yè)容錯(cuò)能力的負(fù)面影響有哪些
文章起源：http://chinadenli.net/article46/jigheg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供全網(wǎng)營(yíng)銷推廣、外貿(mào)網(wǎng)站建設(shè)、Google、企業(yè)網(wǎng)站制作、網(wǎng)頁(yè)設(shè)計(jì)公司、做網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)

外貿(mào)網(wǎng)站建設(shè)