在使用 Apache Spark 的時候，作業會以分散式的方式在不同的節點上執行;特別是當叢集的規模很大時，叢集的節點出現各種問題是很常見的，比如某個磁碟出現問題等。我們都知道 ApacheSpark 是一個高效能、容錯的分散式計算框架，一旦它知道某個計算所在的機器出現問題(比如磁碟故障)，它會依據之前生成的 lineage 重新排程這個 Task。

我們現在來考慮下下面的場景：

• 有個節點上的磁碟由於某些原因出現間歇性故障，導致某些扇區不能被讀取。假設我們的 Spark 作業需要的資料正好就在這些扇區上，這將會導致這個 Task 失敗。

• 這個作業的 Driver 獲取到這個資訊，知道 Task 失敗了，所以它會重新提交這個 Task。

• Scheduler 獲取這個請求之後，它會考慮到資料的本地性問題，所以很可能還是把這個 Task 分發到上述的機器，因為它並不知道上述機器的磁碟出現了問題。

• 因為這個機器的磁碟出現問題，所以這個 Task 可能一樣失敗。然後 Driver 重新這些操作，最終導致了 Spark 作業出現失敗!

上面提到的場景其實對我們人來說可以通過某些措施來避免。但是對於 Apache Spark 2.2.0 版本之前是無法避免的，不過高興的是，來自 Cloudera 的工程師解決了這個問題：引入了黑名單機制 Blacklist(詳情可以參見SPARK-8425，具體的設計文件參見Design Doc for Blacklist Mechanism)，並且隨著 Apache Spark 2.2.0 版本釋出，不過目前還處於實驗性階段。

黑名單機制其實是通過維護之前出現問題的執行器(Executors)和節點(Hosts)的記錄。當某個任務(Task)出現失敗，那麼黑名單機制將會追蹤這個任務關聯的執行器以及主機，並記下這些資訊;當在這個節點排程任務出現失敗的次數超過一定的數目(預設為2)，那麼排程器將不會再將任務分發到那臺節點。排程器甚至可以殺死那臺機器對應的執行器，這些都可以通過相應的配置實現。

我們可以通過 Apache Spark WEB UI 介面看到執行器的狀態(Status)：如果執行器處於黑名單狀態，你可以在頁面上看到其狀態為 Blacklisted ，否則為 Active。如下圖所示：

擁有了黑名單機制之後，上面場景的問題就可以很好的解決。

目前黑名單機制可以通過一系列的引數來控制，主要如下：

因為黑名單機制目前還處於實驗性狀態，所以上面的一些引數可能會在後面的 Spark 中有所修改。

結語

感謝您的觀看，如有不足之處，歡迎批評指正。

如果有對大資料感興趣的小夥伴或者是從事大資料的老司機可以加群：

658558542    

歡迎大家交流分享，學習交流，共同進步。（裡面還有大量的免費資料，幫助大家在成為大資料工程師，乃至架構師的路上披荊斬棘！）

最後祝福所有遇到瓶頸的大資料程式設計師們突破自己，祝福大家在往後的工作與面試中一切順利。