Spark如何處理涉及JDBC數據源的故障場景？

Question

我正在編寫一個與Spark的JDBC數據源實現共享相似之處的數據源，我想問一下Spark如何處理某些故障情況。 據我了解，如果執行者在執行任務時死亡，Spark將使執行者復活並嘗試重新運行該任務。 但是，這在數據完整性和Spark的JDBC數據源API（例如df.write.format("jdbc").option(...).save() ）的上下文中如何發揮作用？

在的savePartition功能JdbcUtils.scala ，我們看到火花調用從數據庫URL生成的Java連接對象的提交和回滾功能/由用戶提供的憑證（見下文）。 但是，如果執行者在commit（）完成之后或調用rollback（）之前就去世了，Spark是否會嘗試重新運行任務並再次寫入相同的數據分區，從而在數據庫中創建重復的提交行？ 如果執行器在調用commit（）或rollback（）的過程中死亡，將會發生什么？

try {
    ...
    if (supportsTransactions) {
        conn.commit()
    }
    committed = true
    Iterator.empty
} catch {
    case e: SQLException =>
        ...
        throw e
} finally {
    if (!committed) {
        // The stage must fail.  We got here through an exception path, so
        // let the exception through unless rollback() or close() want to
        // tell the user about another problem.
        if (supportsTransactions) {
          conn.rollback()
        }
        conn.close()
    } else {
        ...
    }
}

Answer 1

出於上述原因，我不得不介紹一些重復數據刪除邏輯。 您可能最終會兩次提交相同的提交（或更多次）。

Answer 2

但是，如果執行者在commit（）完成之后或調用rollback（）之前就去世了，Spark是否會嘗試重新運行任務並再次寫入相同的數據分區，從而在數據庫中創建重復的提交行？

您會期望什么，因為Spark SQL（這是RDD API之上的高級API）對JDBC或所有其他協議的所有特性並不真正了解很多？ 更不用說基礎執行運行時，即Spark Core。

當您編寫諸如df.write.format(“jdbc”).option(...).save()類的結構化查詢時，Spark SQL使用類似於匯編的低級RDD API將其轉換為分布式計算。 由於它嘗試包含盡可能多的“協議”（包括JDBC），因此Spark SQL的DataSource API將大部分錯誤處理留給了數據源本身。

計划任務（不知道甚至不關心任務做什么）的Spark核心只是監視執行，如果任務失敗，它將嘗試再次執行（默認情況下直到3次失敗嘗試）。

因此，當您編寫自定義數據源時，您就知道演練，並且必須在代碼中處理此類重試。

處理錯誤的一種方法是使用TaskContext注冊任務偵聽器（例如addTaskCompletionListener或addTaskFailureListener ）。