Spark I/O 與 S3

Question

閱讀以下內容 https://blog.duyet.net/2021/04/spark-kube.netes-performance-tuning.html

使用 S3 的 I/O

append 數據到現有數據集的時間更長，特別是，所有 Spark 作業都已完成，但您的命令尚未完成，這是因為驅動程序節點正在將任務的 output 文件從作業臨時目錄移動到最終目標目錄-by-one ，這在雲存儲（例如 S3）中很慢。

啟用此優化：spark.hadoop.mapreduce.fileoutputcommitter.algorithm.version=2

• 我想檢查大膽的說法是否屬實。 我從來沒有聽說過 Spark Driver 用 S3 寫文件/控制寫。 當然，不是 HDFS 集群，而且 Spark Driver 確實需要從 S3 讀取數據。 我的知識是執行器將數據寫入 rest 或 KAFKA 的數據，即使在 AWS 上運行 Spark 也是如此。 但是，大概我錯了，或者不是？

• 如果為真，ADLS2 也一樣嗎？

評論“我遇到了同樣的問題，我發現將內容寫入臨時 HDFS 目錄並使用諸如 s3-dist-cp 之類的命令將內容移動到 S3 更快”不是我要問的.

Answer 1

寫那篇文章的人並沒有完全理解整個工作提交問題，並且具有危險的誤導性。

1. 作業：查詢/rdd 寫入的整個執行
2. 任務嘗試在不同的進程上執行工作； 在本地生成 output。 TA 可能會失敗，因此這是孤立完成的。
3. 任務提交將任務嘗試的工作提升為作業的工作。 必須是原子的，所以如果一個任務在中途失敗（或者更糟的是，來自 spark 驅動程序的分區但繼續進行），另一個任務嘗試可能會被執行並提交。
4. job commit接受已提交任務的所有工作（未提交/失敗任務中沒有任何工作）並提升最終目錄。

v1 提交算法包括

1. 任務提交：將任務嘗試 src 樹重命名為作業嘗試目錄（在 _tmp/ 下）。 依賴於 dir 重命名是 (1) 原子和 (2) 快速。 s3 的要求都不滿足
2. 工作提交。 列出所有任務嘗試目錄樹，將目錄/文件重命名為目標，一個接一個。 期望上市和重命名是快速的。

v2 提交算法是

1. Task commit：列出task attempt src tree中的所有文件，並一一重命名為dest dir。 這不是原子的，不符合spark的要求。
2. 工作承諾。 寫入 0 字節 _SUCCESS 文件。

博客作者指出 v1 的作業提交速度很慢是正確的。 真正的問題不是性能，而是正確性，因為任務提交在 s3 上不是原子的。

但是，v2到處都是不正確的，即使在 hdfs 上也是如此，因為 v2 任務提交是非原子的。 這就是為什么即使速度更快，您也不應該使用它。 任何地方。 真的。

那么對於 s3，如果你想將數據寫入經典的“目錄樹”布局

• ASF spark/hadoop 版本：使用內置於最新 hadoop-aws 版本中的 s3a 提交者。 閱讀 hadoop 文檔以了解操作方法。
• EMR 使用 EMR S3 提交器。

這兩者都通過將文件作為 S3 分段上傳寫入最終目的地來避免重命名，但直到作業提交才完成上傳。 這使得作業提交更快，因為它只不過是列出/加載由每個任務嘗試創建的單個清單文件（其中列出了其未完成的上傳），然后發布完成。 沒有重命名，並要求任務提交是一個 JSON 文件的 PUT，快速且原子。

如果為真，ADLS2 也一樣嗎？

v1 在那里工作，雖然列表很慢並且重命名不是很好，它比 HDFS 慢一點。它可以在作業提交的負載下進行限制，並出現奇怪的“古怪”失敗，其中重命名被報告為 503/throttle 但實際上采取地方...這使 revoer 變得復雜。

Hadoop 3.3.5+ 添加了一個 Intermediate Manifest committer 以提高 Azure 和 Google GCS 的性能。 這些還通過在任務提交中編寫清單來提交工作。 作業提交是這些的並行化列表/加載，然后並行化重命名。 將其視為 v3 提交算法。

• GCS：任務提交變得原子化且快速（其目錄重命名為非原子 O(files)，這就是 v1 不安全的原因）
• ABFS：確實在任務提交中列出，因此避免了作業提交（時間，IOP），重命名是並行的但速率有限（規模）並且通過記錄源文件的 etags，能夠從節流相關的重命名失敗誤報中恢復（即如果 dest 文件存在並且 etag==source etag 一切都很好）

最后，還有雲優先格式：Iceberg、delta lake、Hudi，這些通過在某處編寫單個清單文件以原子方式提交作業； 查詢計划成為列出/加載清單文件鏈的工作，從而識別要處理的數據文件。 這些被所有從事spark/hive雲性能問題工作的人廣泛認可為未來。 如果你能使用這些，你的生活會更好。

延伸閱讀：

• spark 文檔：安全快速地將工作提交到雲存儲中。
• 與“S3A 提交者”一起將工作提交給 S3
• 使用經 EMRFS S3 優化的提交程序
• 零重命名提交者：對象存儲作為 Apache Hadoop 和 Spark 的目的地
• Azure 和谷歌雲存儲的清單提交者
• 清單提交者協議

在出現故障時將工作提交到持久存儲的整個機制是分布式計算的一個迷人部分。 如果您閱讀了零重命名提交者論文，最后一章實際上討論了生產中仍然出錯的地方。 事后看來，這是比當時更好的讀物。 每個人都應該記錄他們的生產問題。