本篇文章為大家展示了如何解析Spark和MapReduce任務計算模型，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。
對于多進程，我們可以很容易控制它們能夠使用的資源，并且一個進程的失敗一般不會影響其他進程的正常運行，但是進程的啟動和銷毀會占用很多時間，同時該進程申請的資源在進程銷毀時也會釋放，這就造成了對資源的頻繁申請和釋放也是很影響性能的，這也是MapReduce廣為詬病的原因之一。
對于MapReduce處理任務模型，有如下特點：
3.可以通過JVM重用在一定程度上緩解MapReduce讓每個task動態申請資源且運行完后馬上釋放資源帶來的性能開銷
但是JVM重用并不是多個task可以并行運行在一個JVM進程中，而是對于同一個job，一個JVM上最多可以順序執行的task數目，這個需要配置參數mapred.job.reuse.jvm.num.tasks，默認1。
對于多線程模型的Spark正好與MapReduce相反，這也決定了Spark比較適合運行低延遲的任務。在Spark中處于同一節點上的task以多線程的方式運行在一個executor進程中，構建了一個可重用的資源池，有如下特點：
但是多線程模型有一個缺陷：同一節點的一個executor中多個task很容易出現資源征用。畢竟資源分配最細粒度是按照executor級別的，無法對運行在executor中的task做細粒度控制。這也導致在運行一些超大數據量的任務并且資源比較有限時，運行不太穩定。相比較而言，MapReduce更有利于這種大任務的平穩運行。
上述內容就是如何解析Spark和MapReduce任務計算模型，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
