NAVER 是一家多元化的互聯網公司，擁有韓國最大的搜索引擎并在人工智能、自動駕駛等高科技領域積極投入。

在搭建 AI 平臺時，NAVER 評估了公有云平臺的存儲產品、Alluxio 以及高性能專用存儲產品等多種選項后，最終決定采用 JuiceFS。通過使用JuiceFS，NAVER 成功地將內部存儲資源升級為高性能、適應 AI 工作負載的存儲解決方案。

AiSuite 是 NAVER 開發者所使用的人工智能平臺，它支持 NAVER 的各種服務的開發和運維。

AiSuite 提供基于 Kubernetes 的容器環境，用于高效管理成本高昂的 GPU 資源。它支持 Kubeflow，不僅便于 AI 模型的開發，還能整合模型訓練和部署服務的完整 AI 工作流程。此外，AiSuite 還支持使用集成了公司內部數據平臺 Kubeflow 工作流組件。

在建設 AI 平臺時，最大的挑戰就是提供適合 AI 工作負載的存儲。隨著大型語言模型（LLM）的普及，為了生成優質的 AI 模型，所需數據的規模越來越大，且分布式學習需要多個節點能夠同時訪問數據。此外，還應能夠輕松應用像?Llama 2、MPT?等迅速出現的各種大型語言模型開源項目。
適用于 AI 平臺的存儲需求如下：

• 必須能夠處理大規模數據；

• 為了進行重復的訓練，高性能是必須的；

• 必須能作為 Kubernetes 持久卷（persistent volume）使用，即支持?Kubernetes CSI Driver；

• 為了確保能夠直接使用各種開源軟件和庫而無需進行任何修改，存儲系統應具備 POSIX 兼容性；

• 對于分布式學習和大規模服務，必須支持多個進程同時訪問（參考?ReadWriteMany, ReadOnlyMany）；

• 必須確保數據的一致性；

• 運維工作應當盡可能小。

尋找能夠滿足所有這些要求的存儲解決方案并非易事。云平臺如?AWS EFS?和?Google Filestore?等服務與這些要求相似。但是，這些服務與 AWS S3 或 Google Cloud Storage 等對象存儲服務相比，它們的成本要高得多（標準費率下 EFS和 AWS S3 有10倍的差異）。此外，由于 AiSuite 是在 NAVER 內部部署的，因此無法使用 AWS、GCP 等外部云存儲服務。我們也可以引入一些專用的存儲解決方案，如?DDN EXAScaler，但這會帶來高昂的成本。本文將介紹為解決這些問題所進行的探討以及引入新存儲解決方案的經驗。

01 存儲方案選型

我們曾考慮引入像?GlusterFS、CephFS?這樣的開源解決方案，但由此會帶來比較大的運維負擔。

我們希望能夠使用 NAVER 內部現有資源可支持的存儲解決方案。?NAVER 內部現有的存儲方案情況如下：

• NAVER 的 C3 HDFS（Hadoop 分布式文件系統）可以處理大規模數據。但是，由于 HDFS 不支持 Kubernetes CSI Driver，因此無法將其用作 Kubernetes 的持久卷；

• NAVER 的對象存儲 nubes 也可以處理大規模數據，并支持 CLI、REST、S3、POSIX 等多種接口。但是，由于對象存儲的特性，它并不完全支持 POSIX API。此外，由于不支持 Kubernetes -- CSI Driver，因此也不能將其用作 Kubernetes 的持久卷；

• Ceph RBD 不支持?ReadWriteMany, ReadOnlyMany，因此無法在多個 Pod 中同時訪問；

• NFS 可以簡單設置，但存在擴展性和高可用性（HA）的問題；

• Local Path?將數據存儲在 Kubernetes 節點的磁盤上。盡管訪問速度快，但不支持多用戶同時訪問。此外，由于存儲的數據位于各個節點上，因此需要進行特定的調度或在應用程序級別實現相關功能。

初步方案：引入 Alluxio

為了在 AiSuite 中快速且輕松地使用在 Hadoop 集群中處理并存儲在 HDFS 上的數據，我們引入了?Alluxio。但 Alluxio 在我們的場景中存在以下問題：

不完全的 POSIX 兼容性

雖然可以將 Alluxio 用作 Kubernetes 持久卷，但它不支持某些 POSIX API，例如符號鏈接、截斷、fallocate、追加、xattr 等。例如，在掛載 Alluxio 的路徑 /data 后，追加操作將失敗，如下所示：

$?cd?/data/
$?echo?"appended"?>>?myfile.txt
bash:?echo:?write?error:?File?exists??

許多 AI 開源軟件和庫默認實現為假設數據位于本地文件系統上。如果不支持某些 POSIX API，可能無法正常工作。因此，在使用 Alluxio 的情況下，有時需要將數據復制到?ephemeral storage?后再使用。這樣做會導致 AI 開發變得不便和低效。

數據不一致

Alluxio 更類似于現有存儲系統上的一個緩存層，并非一個獨立的存儲解決方案。當底層存儲采用 HDFS 時，直接對 HDFS 進行更改而沒有經過 Alluxio，可能會引起 Alluxio 與HDFS 數據的不同步。

在 Alluxio 中，可以設置與原始存儲數據同步的時間間隔。更多詳細信息，請參考?UFS Metadata Sync。但是，如果同步過于頻繁，會對原始存儲產生過多的元數據請求。AiSuite 運行了一個以 HDFS 作為原始存儲的 Alluxio 實例，以便與基于 Hadoop 的數據平臺進行交互。但是，頻繁同步導致管理 HDFS 元數據的?NameNode?負載增加。

運維壓力

Alluxio 需要運行一個由 master 和 worker 服務器組成的單獨集群，這也帶來了一定的運維壓力。不僅如此，由于 AiSuite 的所有用戶都共享這個系統，一旦出現問題，可能會影響到所有用戶。

為什么選擇使用 JuiceFS

JuiceFS?是一種分布式文件系統，采用“數據”與“元數據”分離存儲的架構，文件數據本身會被切分保存在對象存儲（例如 Amazon S3），而元數據則可以保存在 Redis、MySQL、TiKV、SQLite 等多種數據庫中，這使得企業能夠利用現有存儲和數據庫。

接下來，我會詳細介紹 JuiceFS，并解釋為什么選擇應用 JuiceFS。

配置

元數據引擎（Metadata Engine）：負責管理文件的元數據（文件名、大小等）。可以使用多種數據庫，如 Redis、TiKV、MySQL/MariaDB、PostgreSQL 等（文檔：如何設置元數據）。

數據存儲（Data Storage）：實際存儲數據的地方。可以使用多種存儲，包括 S3、OpenStack Swift、Ceph、MinIO、HDFS 等（文檔：如何設置對象存儲）；客戶端（Client）：與元數據引擎、數據存儲進行交互，執行文件 I/O 操作。支持多種接口，適用于不同的環境；JuiceFS 的元數據和數據存儲能夠使用現有存儲和數據庫，并且可適配 Kubernetes 環境。例如，只要準備好了 S3 對象存儲和 Redis，就可以通過 JuiceFS 創建一個高性能且功能豐富的存儲解決方案。這也是 JuiceFS 吸引我們的原因。使用 NAVER 內部支持的存儲和數據庫，可以方便地搭建存儲系統。

特性

JuiceFS 支持并發訪問，同時支持 POSIX 和 Kubernetes 環境。滿足前面提到的用于 AI 平臺的存儲要求，具體特性如下：

• POSIX 兼容：可像本地文件系統一樣使用；
• HDFS 兼容：支持?HDFS API，可用于 Spark、Hive等數據處理框架；
• S3 兼容：通過啟用?S3 網關，可以使用 S3 兼容接口進行訪問；
• 云原生：支持?CSI Driver，可用于 Kubernetes 持久卷；
• 分布式：可在多個服務器上同時共享；
• 強一致性：提交的更改立即在所有服務器上生效；
• 出色性能：詳細信息請參閱性能基準測試；
• 數據安全：支持數據加密；
• 文件鎖定：支持 BSD 鎖（flock）和 POSIX 鎖（fcntl）；
• 數據壓縮：支持?LZ4,?Zstandard，可節省存儲空間。

存儲原理

JuiceFS 引入了以下概念來處理文件，目的是為了彌補分布式存儲在物理上的分散性和對象存儲中對象難以修改的缺點。

• Chunk：每個文件被劃分為 64MB 大小的 Chunk 進行管理。大文件可以根據偏移量并行讀取或寫入，這對于處理大規模數據非常有效；

• Slice：每個 Chunk 由一個或多個 Slice 組成。每次寫入時都會創建一個新的 Slice，它們可以與同一個 Chunk 的其他 Slice 重疊。在讀取 Chunk 時，會優先讀取最新的 Slice。為了避免過多的 Slice 導致讀取性能下降，會定期將它們合并為一個。這使得 JuiceFS 能夠靈活地修改文件，解決了對象存儲在數據修改方面的限制；

• Block：在實際存儲中，Slice 被劃分為基礎大小為 4MB（最大可達 16MB）的 Block 進行存儲。Chunk 和 Slice 主要是邏輯概念，而實際存儲中可見的數據單位是 Block。通過分割為較小的 Block 并進行并行處理，JuiceFS 彌補了分布式對象存儲遠程且較慢的特點；

元數據引擎管理著諸如文件名、文件大小等元數據。此外，它還包含了文件與實際存儲數據之間的映射信息。

緩存

JuiceFS 為了提高性能，采用了多個層級的緩存。在讀取請求時，首先嘗試從內核頁緩存、客戶端進程緩存和本地磁盤緩存中讀取數據。若這些緩存未命中，則會從遠端存儲中讀取所需數據。從遠端存儲中獲取的數據隨后會被異步地存儲在各級緩存中，以便未來能更快速地訪問同樣的數據。

02 Alluxio vs JuiceFS

早期引入的 Alluxio 并沒有滿足我們所需的存儲要求。那么 JuiceFS 呢？以下是對 Alluxio 和 JuiceFS 進行比較的表格。

JuiceFS 和 Alluxio 都支持多種接口，并可以通過緩存來提高性能。與 Alluxio 相比，JuiceFS 具有以下優點：

完全兼容 POSIX

Alluxio 在某些 POSIX API 上提供有限支持。而 JuiceFS 能夠完全支持 POSIX 標準，因此可以像本地文件系統一樣使用。這意味著，無需修改存儲在 JuiceFS 中的訓練數據和代碼，就可以使用各種 AI 開源工具和庫。下面是 POSIX 兼容性測試?pjdfstest?的結果。與AWS EFS 和 Google Filestore 相比，JuiceFS 在支持 POSIX 方面表現更佳。

強一致性

Alluxio 更接近于對原始存儲進行緩存，而 JuiceFS 是一個獨立的存儲系統。在 JuiceFS 中，元數據由元數據引擎管理，不依賴于外部系統。數據存儲僅用于存放 Block 數據。因此，不會像 Alluxio 那樣出現與原始存儲不同步的問題。

減輕運維負擔

Alluxio 需要運行和維護 master 和 worker 服務器，這增加了一定的運維負擔。此外，因為Alluxio被所有用戶共享，一旦發生故障，可能會對所有用戶造成影響。JuiceFS 可以直接利用現有熟悉的存儲和數據庫作為元數據引擎和數據存儲，僅需 JuiceFS 客戶端即可運行，無需部署獨立服務器。此外，每個用戶都可以獨立配置自己的元數據引擎和數據存儲，從而避免相互干擾。

03 如何使用 JuiceFS 構建存儲方案

使用 JuiceFS，需要準備一個用作元數據引擎的數據庫和對象存儲。如前所述，JuiceFS 支持多種數據庫和對象存儲。為了減輕運維負擔，我們使用了 NAVER 現有的平臺。

如下圖所示，AiSuite 通過以下內部平臺使用 JuiceFS。

元數據引擎

在 NAVER，可以使用?nBase-ARC?Redis 服務或通過 MySQL 支持來設置元數據引擎。如果是進行開發和測試，也可以通過?Helm chart?直接安裝并使用 Redis、PostgreSQL 等。JuiceFS 默認每小時將元數據自動備份到數據存儲中，且備份周期是可配置的。因此，即使元數據引擎的數據丟失，也可以進行恢復，但由于元數據備份周期的設定，仍有可能會有部分數據丟失。有關詳細信息，請參考元數據備份和恢復。

數據存儲

可以使用 NAVER 內部的 HDFS 或 nubes Object Storage 存儲大規模數據。利用這些資源，可以進行大容量且穩定的數據存儲。

nubes

nubes?是 NAVER 的對象存儲。JuiceFS 本身不直接支持 nubes，但可以通過使用具有 MinIO 接口的 nubes-s3-proxy 來訪問。

HDFS

HDFS?是 JuiceFS 默認支持的存儲系統。但是，為了在大規模、多租戶的 HDFS 中應用 Kerberos，需要進行以下改進：

支持 Kerberos keytab 文件

NAVER 內部的 HDFS 應用了 Kerberos。因此，當 JuiceFS 使用 HDFS 時，需要進行 Kerberos 認證。原先的 JuiceFS 是通過設置 KRB5CCNAME 環境變量為?credential cache?進行 HDFS 認證。但這個方式會在一定時間后過期失效。為解決這一問題，進行了改進，可以通過設置 KRB5KEYTAB、KRB5PRINCIPAL 環境變量使用 keytab 文件。（參見?JuiceFS issue #3283）

支持 base64 編碼的 keytab 文件

AiSuite 是一個多租戶 Kubernetes 集群，共享給多個用戶，目標是允許每個用戶使用自己選擇的元數據引擎和數據存儲來運行 JuiceFS。用戶需要自己編寫?Kubernetes Secret，設置訪問元數據引擎和數據存儲的路徑和認證信息。但是，KRB5KEYTAB 僅是一個文件路徑，并不能讓用戶傳遞實際的 keytab 文件。為解決這個問題，進行了改進，允許通過設置 KRB5KEYTAB_BASE64 環境變量使用 base64 編碼的 keytab 文件字符串。（參見?JuiceFS issue #3817）

支持用戶指定的 HDFS 路徑

NAVER 內部的 HDFS 由多個用戶共享，每個用戶僅在分配給他們的 HDFS 路徑上擁有權限。但是，原來的 JuiceFS 無法指定用于數據存儲的 HDFS 路徑，因此總是必須將數據存儲在 root 目錄下，這導致用戶遇到了沒有權限訪問的路徑問題。為解決這個問題，進行了改進，允許用戶設置自己的 HDFS 路徑。（參見?JuiceFS issue #3526）

支持 HDFS 路徑 hdfs://nameservice

NAVER 內部的 HDFS 為了大規模運營，采用了?HDFS Federation，由多個 NameNode 和 Namespace 組成。原本的 JuiceFS 需要直接指定 NameNode 路徑，如 nn1.example.com:8020，這對用戶來說確認和設置很不方便。為了解決這個問題，進行了改進，現在可以像 hdfs://nameservice 這樣設置 Namespace。（參見?JuiceFS issue #3576）

CSI Driver

AiSuite 是一個多租戶 Kubernetes 集群，每個用戶通過?Kubernetes namespace?進行區分。如果用戶間共享 JuiceFS，可能會相互影響，降低穩定性并增加運維難度。因此，我們的目標是使每個用戶都能單獨準備自己的元數據引擎和數據存儲，并獨立使用 JuiceFS。此外，為了減輕運維負擔并提高用戶便利性，支持?Dynamic Volume Provisioning，使用戶無需管理員介入，就能直接定義和使用 PVC（PersistentVolumeClaim）。為此，需要進行以下改進：

支持模板 Secret

用戶需要創建?Secret，以設置各自準備的元數據引擎和數據存儲的訪問路徑和認證信息。然后，需要在?StorageClass?中設置以引用這些 Secret。這些設置的 Secret 會被用于 Dynamic Volume Provisioning。但是，原有的 JuiceFS CSI Driver 只能在 StorageClass 中設置一個固定的 Secret。為解決這一問題，進行了改進，允許通過 ${pvc.name}, ${pvc.namespace}, ${pvc.annotations['']} 等方式，從用戶創建的 PVC 中引用 Secret。（參見?JuiceFS CSI Driver issue #698）

支持 Secret Finalizer

用戶的 Secret 不僅在創建 PVC 時使用，還在刪除 PVC 時用于刪除 JuiceFS 數據。如果在刪除 PVC 之前關聯的 Secret 被移除，JuiceFS 數據將不會被清理，而會持續留存。為了防止這個問題，在 PVC 被刪除之前，設置?Finalizer?以防止關聯的 Secret 被移除。在 StorageClass 的?parameters?中設置 secretFinalizer: "true" 可以啟用此功能。（參見?JuiceFS CSI Driver issue #707）

支持根據 PVC 元數據設置 mountOptions

AiSuite 中存在多種 AI 工作負載，如 AI 學習、服務和數據處理等。為了實現最優性能，根據工作類型可能需要單獨配置 JuiceFS。例如，在使用只讀數據進行 AI 訓練的情況下，可以通過添加 --open-cache 設置來提高讀取性能。有關詳細信息，請參考客戶端內存中的元數據緩存。原先的 JuiceFS 只能應用 StorageClass 中固定的配置。現在進行了改進，允許根據用戶創建的 PVC 進行設置，例如使用 ${.PVC.namespace}, ${.PVC.name}, ${.PVC.labels.foo}, ${.PVC.annotations.bar} 這樣的方法。（參見?JuiceFS CSI Driver issue）

04 JuiceFS 應用方案

為了在 Kubernetes 中支持 JuiceFS，管理員需要部署 JuiceFS CSI Driver，而用戶則需要定義自己的 Secret 和 PVC。在多租戶 Kubernetes 環境 AiSuite 中，將詳細說明如何部署和提供 JuiceFS，包括具體的示例。

部署方法

安裝 JuiceFS CSI Driver 后，可以按照標準 Kubernetes 卷的使用方式進行操作，支持通過 Helm 或 kubectl 進行安裝。有關詳細信息，請參考?JuiceFS CSI Driver 安裝指南。進行部署需要 Kubernetes 管理員權限。為了讓每個用戶使用自己的元數據引擎和數據存儲，StorageClass 設置如下。

apiVersion:?storage.k8s.io/v1??
kind:?StorageClass??
metadata:??
??name:?juicefs
provisioner:?csi.juicefs.com??
parameters:??
??#配置系統以便用戶可以引用自己創建的?Secret
??#用戶需要在?PVC?'csi.juicefs.com/secret-name'注釋中設置Secret的名稱
??csi.storage.k8s.io/provisioner-secret-name:?${pvc.annotations['csi.juicefs.com/secret-name']}
??csi.storage.k8s.io/provisioner-secret-namespace:?${pvc.namespace}
??csi.storage.k8s.io/node-publish-secret-name:?${pvc.annotations['csi.juicefs.com/secret-name']}
??csi.storage.k8s.io/node-publish-secret-namespace:?${pvc.namespace}
??csi.storage.k8s.io/controller-expand-secret-name:?${pvc.annotations['csi.juicefs.com/secret-name']}
??csi.storage.k8s.io/controller-expand-secret-namespace:?${pvc.namespace}
??juicefs/clean-cache:?"true"
??#激活?secretFinalizer，以防止用戶定義的?Secret?被隨意刪除
??secretFinalizer:?"true"
??#通過指定?pathPattern來設置路徑，可以掛載所需的路徑
??#用戶可以在?PVC?'csi.juicefs.com/subdir'注釋中設置所需的路徑
??pathPattern:?"${.PVC.annotations.csi.juicefs.com/subdir}"
allowVolumeExpansion:?true??
reclaimPolicy:?Delete??
mountOptions:??
??#允許用戶根據需要設置各自的選項
??#用戶可以在PVC的'csi.juicefs.com/additional-mount-options'注釋中設置所需的JuiceFS選項。
??-?${.PVC.annotations.csi.juicefs.com/additional-mount-options}

使用方法

用戶需要為自己準備的元數據引擎和數據存儲創建 Secret，包括路徑和認證信息等。

apiVersion:?v1??
kind:?Secret??
metadata:??
?name:?myjfs
type:?Opaque??
stringData:??
?#JuiceFS文件系統名稱。
?name:?myjfs
?#MINIO_ROOT_USER
?access-key:?user
?#MINIO_ROOT_PASSWORD
?secret-key:?password
?#元數據引擎 Redis 路徑
?metaurl:?redis://:@redis.user1.svc.cluster.local:6379/0
?#minio
?storage:?minio
?#bucket1
?bucket:?http://nubes-s3-proxy.user1.svc.cluster.local:10000/bucket1
?#https://juicefs.com/docs/community/command_reference/#format
?format-options:?trash-days=0,block-size=16384

定義 PVC。此外，需要設置以下注釋（annotation）：

• csi.juicefs.com/secret-name：指定引用的 Secret 名稱；

• csi.juicefs.com/subdir：如果是新的卷，則指定 PVC 名稱。如果需要掛載已存在的 JuiceFS 路徑，則可以指定所需的路徑；

• csi.juicefs.com/additional-mount-options：可以添加適合工作負載的 JuiceFS 掛載選項。有關詳細信息，請參考掛載指南。

apiVersion:?v1??
kind:?PersistentVolumeClaim??
metadata:??
?name:?myjfs
?annotations:
???csi.juicefs.com/secret-name:?myjfs?#?之前創建的Secret名稱
???csi.juicefs.com/subdir:?myjfs?#?在JuiceFS文件系統中的路徑
???csi.juicefs.com/additional-mount-options:?"writeback,upload-delay=1m"?#?如果需要，可以添加JuiceFS的配置
spec:??
?accessModes:
?-?ReadWriteMany
?resources:
???requests:
?????storage:?100Gi
?storageClassName:?juicefs

創建 Secret 和 PVC 后，可以像使用普通卷一樣使用它們。下面是一個將之前創建的 myjfs PVC 掛載到 /data 上的 Pod 示例。

apiVersion:?v1??
kind:?Pod??
metadata:??
?name:?example
spec:??
?containers:
?-?name:?app
...
???volumeMounts:
???-?mountPath:?/data
?????name:?juicefs-pv
?volumes:
?-?name:?juicefs-pv
???persistentVolumeClaim:
?????claimName:?myjfs

05 性能測試

JuiceFS 性能基準測試如下所示，與?EFS,?S3FS?相比，其性能更高。

我們需要驗證當使用 nubes 對象存儲和 HDFS 作為數據存儲時的性能表現。由于 JuiceFS 的性能可能會根據所使用的數據存儲類型而有所差異，我們還需關注由于使用 UserSpace 中的 Fuse 而可能出現的性能降低。特別是需要檢驗因 JuiceFS Fuse 引起的性能下降情況。測試的主要目的是確定，相比直接使用數據存儲，JuiceFS 是否會導致性能下降。如果性能差異不顯著，那么我們可以在保持性能的同時支持 POSIX 兼容性、并發訪問等多項功能。

順序讀寫

參考?Fio Standalone Performance Test，按照以下方式進行了測試：

• 元數據引擎使用 Redis；

• 在單個節點上使用?fio?進行測試時，調整 --numjobs 選項；

• 單節點的最大網絡帶寬為 1200MB/s，即此測試的可能最高值；

• 由于 Object Storage 基本上不支持 POSIX，因此沒有使用 fio，而是采用了針對 nubes Object Storage 性能優化的其他方法，僅測量 read(1 job), write(1 job) 項目；

• JuiceFS 設置中，塊大小設置為 16MB，其他選項使用默認值；

• 沒有使用 JuiceFS 緩存，僅進行了讀寫新數據的測試；

• 對于 Alluxio，由于在執行 fio 時出現“fio: posix_fallocate fails: Not supported”等錯誤而導致失敗，因此在測試中被排除了。

測試結果如下：

• 在讀取方面，與單獨的 nubes 相比，JuiceFS+nubes 和 JuiceFS+hdfs 的性能更好，并且隨著并發數量的增加而提升。這可能是因為通過 Chunk 進行的并發讀取更為有利；

• 在寫入方面，與單獨的 nubes 相比，JuiceFS+nubes 和 JuiceFS+hdfs 的性能相似或略低。并發數量增加時，性能會降低。這可能是由于多個 Slice 帶來的負擔所致。

文件創建

此次測試比較了創建 1 萬個小文件所需的時間。測量使用 nubes 作為數據存儲時處理元數據的性能，并與 JuiceFS 進行比較。

• 元數據引擎使用 Redis；

• 測量了在 10 個進程中使用 cp 命令復制 100 字節文件 1 萬個時的每秒文件創建數；

• 由于 Object Storage 基本上不支持 POSIX，因此沒有使用 cp，而是采用了針對 nubes Object Storage 性能優化的其他方法來測量 nubes 項；

• 也測量了設置了 JuiceFS 的 writeback 選項的情況。此選項首先在本地進行數據更新，然后異步保存到數據存儲。更多詳細信息，請參考?client-write-cache。

測試結果如下：

• nubes 和 juicefs+nubes 之間沒有顯著差異。這意味著使用 nubes 作為數據存儲的 JuiceFS 不會導致性能下降；

• 與 HDFS 配合使用時， JuiceFS+hdfs 和 alluxio 似乎與 HDFS 的元數據處理性能，即 NameNode 的性能趨于一致；

• 使用 writeback 選項可實現數十倍的性能提升。然而，啟用 writeback 選項可能導致數據丟失，因此適用于臨時數據的場景。

測試結論

JuiceFS 的性能基本上取決于存儲數據設備的性能。它能夠支持 POSIX 兼容性且無性能損失、還能支持并發訪問等功能。

在某些工作負載和使用情況下，JuiceFS 的性能有時甚至可能優于數據存儲設備的原始性能。盡管本文未進行測試，但讀取緩存數據時，因為是從本地磁盤讀取，因此有可能提高性能。寫入臨時數據時，應用 writeback 選項也可以提升性能。

JuiceFS 支持多種可根據工作負載進行調整的緩存選項。更多詳細信息，請參考?cache。

06 小結

企業內部存儲 + JuiceFS

在 AiSuite 中，我們利用公司內部支持的 HDFS 和 nubes 對象存儲來構建 JuiceFS。這樣既能為 AI 工作負載提供適合的存儲，又能減輕運維負擔。對于前文中評估的企業內部存儲，可以總結如下：

在 AiSuite 中，相比于 HDFS，更推薦使用 nubes Object Storage 用作數據存儲。這是因為在 HDFS 中，如果文件數量眾多，會對管理 HDFS 元數據的 NameNode 造成負擔。而 JuiceFS 會將文件分割成小的 Block 來存儲，從而在 HDFS 中產生大量文件。即使是最大可設置的 Block 大小 16MB，為了存儲 1TB 數據，也需要創建超過 62,500 個文件。雖然考慮過將最大 Block 大小提升至 64MB，但 Block 變大可能會導致效率低下。更多詳細信息，請參考?Increase the maximum of blockSize to 64MB。

優勢

在 AI 平臺 AiSuite 中，我們評估了 JuiceFS 作為 AI 工作負載的存儲解決方案的可行性。JuiceFS 具有以下多種優勢：

• 可以使用大容量、可共享（ReadWriteMany, ReadOnlyMany）卷；

• 高性能（緩存），可以替代 hostPath、local-path。可以輕松實現有狀態應用的云原生轉換；

• 在 AI 分布式學習中，可以作為共享的工作區、checkpoint、日志存儲；

• 能夠處理 AI 學習過程中所需的大量小文件（HDFS/Alluxio 的替代品）；

• 可利用企業內部的 HDFS、nubes Object Storage 存儲，降低運維負擔；

• 通過用戶各自的數據存儲和元數據引擎運行，互不影響；

• 支持多種數據存儲和元數據引擎，適用于大多數 k8s 環境；

• 可以替代高成本的共享存儲，如 AWS EFS、Google filestore、DDN exascaler。

通過使用 JuiceFS，能夠將企業內部傳統的存儲轉換為具有高性能和多功能的、適合 AI 工作負載的存儲。JuiceFS 支持多種存儲和多種數據庫。這篇文章主要介紹了在 NAVER 內部的 on-premise 環境中的應用案例，但它也可以應用于 AWS、Google Cloud 等公共云環境。希望這篇文章能對面臨類似問題的用戶提供幫助。

希望這篇內容能夠對你有一些幫助，如果有其他疑問歡迎加入 JuiceFS 社區與大家共同交流。

總結

以上是生活随笔為你收集整理的韩国国民搜索 NAVER：为 AI 平台引入存储方案 JuiceFS的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。