為什么從 databricks spark 筆記本（hadoop fileUtils）寫入 DBFS 裝載位置比寫入 DBFS 根位置慢 13 倍？

Question

Databricks notebook 需要 2 個小時才能寫入 /dbfs/mnt（blob 存儲）。 同樣的作業需要 8 分鍾才能寫入 /dbfs/FileStore。

我想了解為什么兩種情況下的寫入性能不同。 我也想知道 /dbfs/FileStor 使用哪個后端存儲？

我知道 DBFS 是可擴展 object 存儲之上的抽象。 在這種情況下，/dbfs/mnt/blobstorage 和 /dbfs/FileStore/ 應該花費相同的時間。

問題陳述：

源文件格式：.tar.gz

平均大小：10 mb

tar.gz 文件數量：1000

每個 tar.gz 文件包含大約 20000 個 csv 個文件。

需求：解壓tar.gz文件，寫入CSV個文件到blob存儲/中間存儲層做進一步處理。

解壓並寫入安裝位置（附截圖）：

在這里，我使用 hadoop FileUtil 庫和 unTar function 來解壓縮並將 CSV 文件寫入目標存儲（/dbfs/mnt/ - blob 存儲）。 使用 2 個工作節點（每個 4 個核心）集群完成作業需要 1.50 小時。

解壓並寫入 DBFS Root FileStore：這里我使用 hadoop FileUtil 庫和 unTar function 解壓並寫入 CSV 文件到目標存儲（/dbfs/FileStore/），只需 8 分鍾即可完成 2 個工作節點（4 核）的作業每個）集群。

問題：為什么寫入 DBFS/FileStore 或 DBFS/databricks/driver 比寫入 DBFS/mnt 存儲快 15 倍？

DBFS 根目錄（/FileStore、/databricks-datasets、/databricks/driver）在后端使用什么存儲和文件系統？ 每個子文件夾的大小限制是多少？

Answer 1

可能有多種因素影響，但需要更多信息來調查：

• 你的/mnt掛載點可能指向另一個區域的 blob 存儲，所以你有更高的延遲
• 您正在為您的 blob 存儲設置節流，例如，如果其他集群對它進行大量讀/寫或列表操作 - 這可能會導致重試 Spark 任務（如果您有任何任務，請檢查 Spark UI有錯誤）。 另一方面， /FileStore位於未加載的專用 blob 存儲（所謂的DBFS Root ）中。

通常，對於 DBFS Root，使用 Azure Blob 存儲，而不是 ADLS。 具有分層命名空間的 ADLS 有額外的操作開銷，因為它需要檢查權限等。這也會影響性能。

但要解決該問題，最好打開支持票，因為它可能需要后端調查。

PS 請注意，DBFS Root 應該只用於臨時數據，因為它只能從工作區訪問，所以你不能與其他工作區或其他消費者共享數據。