Azure Data Lake Storage 使用階層式命名空間，提供物件儲存規模與價格的檔案系統效能。 此功能將帳號內的物件與檔案集合組織成目錄與巢狀子目錄的階層，類似您電腦上的檔案系統。 啟用階層命名空間後，儲存帳號能提供物件儲存的可擴展性與成本效益，以及分析引擎與框架熟悉的檔案系統語意。
階層命名空間的優勢
在blob資料上實作階層命名空間的檔案系統，提供以下好處：
原子性目錄操作： 物件儲存體會採用在物件名稱中加入斜線 (/) 以表示路徑區段的慣例，藉此模擬目錄階層。 雖然此慣例可用於組織物件，但對於移動、重新命名或刪除目錄等操作則無任何協助。 如果沒有真正的目錄，應用程式就必須處理可能數百萬個單獨的 blob 才能達到目錄層級的工作。 相反地，階層命名空間會藉由更新單一項目 (父目錄) 來處理這些工作。
這種優化對許多大數據分析框架尤其重要。 像 Hive 和 Spark 這類工具通常會先將輸出寫入暫存位置，然後在作業完成時將該位置重新命名。 若沒有階層式命名空間，此重新命名操作通常會比分析過程本身花費更長時間。 較低的作業延遲等於較低的分析工作負載擁有權總成本 (TCO)。
熟悉的介面風格： 開發者和使用者都了解檔案系統。 當你搬到雲端時，不需要學習新的儲存範式，因為 Data Lake Storage 會暴露出與大小電腦相同的檔案系統介面。
物件儲存過去不支援階層命名空間的原因之一，是階層命名空間限制了擴展性。 然而，Data Lake Storage 的階層命名空間是線性擴展的，且不會降低資料容量或效能。
決定是否啟用階層式命名空間
當你在帳號啟用階層命名空間後，就無法再把它還原回平面命名空間。 因此，請根據您物件存放區工作負載的本質，考慮啟用階層命名空間是否合理。 若要評估在工作負載、應用程式、成本、服務整合、工具、功能和檔上啟用階層命名空間的影響，請參閱使用 Azure Data Lake Storage 功能升級 Azure Blob 儲存體。
某些工作負載可能無法因啟用階層命名空間而受益。 例如備份、映像儲存，以及其他將物件組織與物件本身分開儲存的應用程式（例如，在獨立的資料庫中）。
此外，雖然對 Blob 儲存功能和 Azure 服務生態系統的支援持續成長，但某些功能與 Azure 服務尚未在擁有階層命名空間的帳號中獲得支援。 請參閱已知問題。
受益於階層命名空間的工作負載
一般而言，針對會操作目錄的檔案系統所設計的儲存工作負載，應啟用階層式命名空間。 此條件涵蓋所有分析處理工作負載。 需要高度組織的資料集也從啟用階層式命名空間中受益。
使用 TCO 分析來判斷是否啟用階層式命名空間。 一般而言，儲存加速帶來的工作負載延遲改善，會使其占用運算資源的時間縮短。 由於階層式命名空間支援對目錄進行原子操作，許多工作負載的延遲可能會有所改善。 在許多工作負載中，運算資源佔總成本的85% 以上，因此即使工作負載延遲有適度的降低，也能節省大量TCO。 即使啟用階層命名空間會提高儲存體成本，但由於計算成本降低，TCO 仍會降低。
若想分析擁有固定命名空間與階層命名空間的帳號在資料儲存價格、交易價格及儲存容量預留定價上的差異，請參閱 Azure Data Lake Storage 定價。
要啟用階層式命名空間，請參見建立一個用於 Azure Data Lake Storage（新帳號）的儲存帳號，或以 Azure Data Lake Storage 能力升級 Azure Blob 儲存體（現有帳號）。
下一步
- 在您建立新儲存體帳戶之後啟用階層命名空間。 請參閱建立儲存體帳戶以與 Azure Data Lake Storage 搭配使用。
- 在現有的儲存體帳戶上啟用階層命名空間。 請參閱使用 Azure Data Lake Storage 功能升級 Azure Blob 儲存體。