共用方式為

Azure Data Lake Storage 階層命名空間

  • 發行項

允許 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 定價。

下一步