[CTE] 透過分層命名空間 (HNS)為 Cloud Storage 帶來檔案系統最佳化
終於可以把 GCS 當作 file system 用啦 ~
📌 一句話摘要
簡單來說 Cloud Storage 底層的儲存本質就是一個鍵值的物件儲存，
並沒有檔案系統般的階層概念。
這讓一些常見的檔案管理操作，例如重命名資料夾，變得不太方便
(資料夾下的每個物件都要執行一次 複製 → 刪除舊檔)。
有了 HNS 的支援，那就只是變更一下 parent node 彈指般簡單的事情，高效節能。
📌 引言
雲存儲最近宣佈了一個新的桶創建選項——層次命名空間 (HNS)，該選項優化了檔案夾結構、資源和操作。
現有的雲存儲桶採用平面命名空間，其中所有對象都存儲在一個邏輯層次中。檔案夾在 UI 和 CLI 中通過 “/” 前綴模擬，但不受雲存儲資源支援，也不能通過 API 顯式訪問。
若要通過重新命名路徑來 “移動” 檔案夾，在現有的雲存儲桶中，每個模擬檔案夾下的對象需要單獨複製和刪除，且這一過程是非原子的。
使用層次命名空間的桶具有由 API 支援的存儲檔案夾資源，新的 “重新命名檔案夾” 操作將以元數據操作的方式遞歸重新命名檔案夾及其內容。對於需要檔案系統層次結構和語義的應用程序，應考慮啟用層次命名空間。
結合 Cloud Storage FUSE 使用 HNS，可以增強機器學習模型迭代等用例的性能和可靠性。然而，HNS 必須在創建桶時啟用，且不支援某些雲存儲功能，如對象版本控制、桶鎖定、對象保留鎖定和對象 ACL。
📌 關鍵好處
性能提升：HNS 桶具有優化的存儲佈局，提供更高的初始桶每秒查詢率（QPS），對象讀寫操作的吞吐量提升可達 8 倍。
檔案導向增強：HNS 支援面向檔案導向存儲的應用程序的新 API，如 Hadoop 或 AI/ML 工作負載，提升了這些工作負載的性能、恢復力和便利性。
平台支援：HNS 桶支援現有雲存儲對象 API 和大部分雲存儲功能，並與 Hadoop/Spark 和 Cloud Storage FUSE 整合。
📌 使用場景
Hadoop 基礎的處理：如 Hadoop、Spark 和 Hive 工作負載，傳統上期望檔案系統存儲結構和基於時間的檔案分區。
檔案導向的工作負載處理：如批次分析或高性能計算，通常結構化為包含多個檔案的分區，HNS 有助於檔案夾管理和快速便捷的檔案夾重新命名操作。
AI 和 ML 處理工具：如 TensorFlow、Pandas、JAX 和 PyTorch，期望檔案語義，HNS 結合 Cloud Storage FUSE 使用，可以提升性能和可靠性。
📌 其他考量
在 HNS 公開預覽期間，該功能僅用於非生產工作負載，且尚不支援軟刪除或自動分類功能。公共預覽期間無附加費用，但在 GA 時，將對啟用層次命名空間的桶和檔案夾相關操作收取額外費用。
這是新的系列文支線 `[CTE]` 全名 CloudTechExchange，由於筆者之一在雲端產業工作，所以會 follow 一些雲服務的新知 (尤其是 Google Cloud)，藉由這個系列文把一些新的用法或是好的架構記錄下來。
這個系列也會同步搶先發布在 X 上面的 CloudTech Exchange 社群，有興趣的朋友可以加入: https://twitter.com/i/communities/1543741207137816576