Spark：reduce和reduceByKey之間的語義差異

Question

在Spark的文檔中，它說RDDs方法reduce需要一個關聯的AND交換二進制函數。

但是，方法reduceByKey僅需要關聯二進制函數。

sc.textFile("file4kB", 4)

我做了一些測試，顯然這是我得到的行為。 為何如此區別？ 為什么reduceByKey確保二進制函數總是以某種順序應用（以適應缺乏可交換性），而reduce則不然？

例如，如果加載一些（小）文本有4個分區（最小）：

val r = sc.textFile("file4k", 4)

然后：

r.reduce(_ + _)

返回一個字符串，其中的部分並不總是以相同的順序，而：

r.map(x => (1,x)).reduceByKey(_ + _).first

始終返回相同的字符串（其中所有內容的順序與原始文件中的順序相同）。

（我用r.glom檢查r.glom ，文件內容確實分布在4個分區上，沒有空分區）。

Answer 1

就我而言，這是文檔中的錯誤，您看到的結果只是偶然的。 實踐，其他資源和對代碼的簡單分析表明，傳遞給reduceByKey函數reduceByKey應該是關聯的， reduceByKey應該是可交換的。

練習 - 雖然看起來訂單在本地模式下保留，但在群集上運行Spark（包括獨立模式）時不再是這樣。
其他資源 - 使用 AmpCamp 3中的 Spark引用數據探索：

在Spark中有一個名為reduceByKey的方便方法，正是這種模式。 請注意，reduceByKey的第二個參數確定要使用的reducer數。 默認情況下，Spark假定reduce函數是可交換和關聯的，並在映射器端應用組合器。
code - reduceByKey使用combineByKeyWithClassTag實現並創建ShuffledRDD 。 由於Spark在洗牌后不保證訂單，因此恢復它的唯一方法是將部分元數據附加到部分縮減的記錄中。 據我所知，沒有發生這樣的事情。

在側面說明reduce因為它在PySpark中實現將使用僅可交換的功能正常工作。 它當然只是一個實現的細節，而不是合同的一部分。

Answer 2

根據代碼文檔，最近更新/更正。 （感謝@ zero323）：

reduceByKey使用關聯和可交換的reduce函數合並每個鍵的值。 在將結果發送到reducer之前，這也將在每個映射器上本地執行合並，類似於MapReduce中的“組合器”。

事實上它實際上是一個像@ zero323這樣的文檔錯誤在他的回答中指出。

您可以檢查以下指向代碼的鏈接以確保：