具有小 I/O 的慢速 Spark 階段
如果您有在 I/O 不多的情況下運行緩慢的過程，這可能是由下列原因所造成：
- 讀取許多小型檔案
- 撰寫許多小型檔案
- 慢 UDF（秒）
- 笛卡兒聯結
- 爆炸聯結
幾乎所有的問題都可以使用 SQL DAG 來識別。
開啟 SQL DAG
若要開啟 SQL DAG，請向上捲動至作業頁面的頂端，然後點擊 [相關聯的 SQL 查詢] ：
您現在應該會看到 DAG。 如果沒有，請捲動一點，您應該會看到它：
在繼續之前，請先了解並熟悉 DAG 的結構及時間分配的情況。 DAG 中的某些節點有有用的時間資訊，而其他節點則沒有。 例如，此區塊花費 2.1 分鐘，甚至提供階段標識碼：
這個節點要求您開啟它，才會看到它所花的 1.4 分鐘時間。
這些時間是累計的，因此它是所有工作所花費的總時間，而不是時鐘時間。 但它仍然非常有用，因為它們與時鐘時間和成本相互關聯。
了解 DAG 中耗時的位置是有幫助的。
讀取許多小型檔案
如果您注意到有某位掃描操作員花了很多時間，請開啟並查看他所讀取的檔案數目：
如果您正在讀取數萬個檔案或更多檔案，您可能會有一個小的檔案問題。 您的檔案應該不小於 8MB。 小型檔案問題通常是因為在過多欄位或高基數欄位上進行分割所造成。
如果您很幸運，您可能只需要執行 OPTIMIZE。 不論怎樣，您都需要重新考慮 檔案配置。
創建許多小型檔案
如果您看到寫入需要很長的時間，請開啟它，並尋找檔案數目，以及寫入的數據量：
如果您正在撰寫數萬個檔案或更多檔案，您可能會有一個小的檔案問題。 您的檔案應該不小於 8MB。 小型檔案問題通常是因為分割太多數據行或高基數數據行所造成。 您必須重新考慮 檔案配置，或開啟 優化寫入。
慢速UDF（使用者定義函數）
如果您知道您有 UDF，或在 DAG 中看到類似這樣的內容，您可能會遇到 UDF 執行緩慢的狀況：
如果您認為您正遭受此問題，請嘗試批注您的 UDF，以查看它如何影響管線的速度。 如果 UDF 確實是花費時間的地方，則您最好的選擇是使用原生函式重寫 UDF。 如果這不可能，請考慮在執行您的UDF的階段中，任務的數目。 如果它小於叢集的核心數目，請在使用 UDF 之前，先 repartition() 您的數據框架：
(df
.repartition(num_cores)
.withColumn('new_col', udf(...))
)
UDF 也可能因為記憶體問題而受到影響。 請考慮每個工作可能都必須將分割區中的所有數據載入記憶體中。 如果此數據太大，則情況可能會變得非常緩慢或不穩定。 重新分割也可以藉由讓每個工作更小來解決此問題。
笛卡兒聯結
如果您在 DAG 中看到笛卡兒聯結或巢狀循環聯結，您應該知道這些聯結非常昂貴。 請確定這是您想要的，看看是否有另一種方式。
爆炸聯結或爆炸
如果您看到一些數據列進入一個節點，而出現更多數量的數據列，您可能遇到了 exploding join 或 explode() 的問題。
