在量化投資領域，存儲系統的性能與可擴展性是支撐高效研究與計算任務的關鍵基礎。JuiceFS 已廣泛應用於多家頭部百億級量化私募機構，在回測與模型訓練等核心環節中支撐高性能、低成本、可彈性擴展的存儲體系。
本文將分享量化機構在存儲層面臨的核心挑戰以及 JuiceFS 的應對方案，並通過三個典型案例，分別聚焦成本優化、元數據性能提升與平滑上雲這三類需求。
01 量化行業的數據類型與存儲挑戰
首先我們先來了解下量化行業使用數據的模式。量化投研中的編程語言和數據處理工具種類繁多，包括 Python、R、Java、MATLAB 和 Conda 等，同時，所涉及的數據類型也非常豐富，如 CSV、Parquet、TXT、Excel 和 HDF 等。這要求存儲平台具備靈活性，能夠支持各種數據格式並高效存儲。
在量化投資中，數據的使用呈現出明顯的“讀多寫少”特徵。研究員頻繁地從統一的數據源中讀取數據，而數據的寫入和更新相對較少。各類行情數據、因子數據等通常被集中存儲，供所有研究員共享讀取。無論是因子研究還是交易策略開發，基礎數據都會被反覆訪問和使用。因此，存儲系統必須具備高效的讀取性能，以支持快速的數據訪問和分析需求。
這種數據使用模式在量化研究的核心任務——回測（Backtesting）中也得到了充分體現。在典型的回測流程中，研究員多次讀取歷史行情數據，構建因子、生成交易信號並驗證策略表現。穩定且預測能力強的因子會被納入因子庫，作為投資決策的重要依據。
由此，存儲系統面臨着一系列挑戰，主要體現在以下幾個方面：
首先，能夠處理多樣化的編程語言與數據處理工具。
量化投研的另一個挑戰是容量要求低而性能要求高。雖然存儲容量需求通常在幾十 TB 至幾百 TB，但對存儲系統的性能要求極高，特別是在吞吐量和 IOPS 上。由於量化任務涉及大量的機器學習和深度學習計算，存儲系統必須提供高效的順序讀吞吐量和快速的隨機讀 IOPS，才能支持數據的快速處理和分析。
雲環境的適應性也成為量化投研存儲的一個關鍵要求。隨着越來越多的量化團隊開始使用公有云或混合雲 構建技術平台，存儲系統需要具備高可用性、彈性擴展性以及靈活的資源管理能力，以滿足動態存儲需求，並能夠根據計算需求快速調整存儲資源。
與此同時，Kubernetes 已成為量化投研領域中資源編排的主流解決方案，因此存儲系統需要能夠與 Kubernetes 良好集成，支持 CSI 驅動。這一集成不僅提升了平台的靈活性和可擴展性，還使得存儲系統能夠在雲環境中更高效地管理資源。
最後，數據安全與權限控制是量化研究團隊的核心需求。在量化投研過程中，因子數據、交易策略等敏感信息的保護至關重要。存儲系統必須提供強大的模塊化訪問權限管理機制，保障數據的隱私與安全性。此外，隨着越來越多的數據存儲轉向雲環境，數據加密、審計和合規管理等功能成為必須提供的安全措施，以確保敏感數據在雲上安全存儲和訪問。
02 主流存儲方案利弊分析： NAS vs 對象存儲 vs JuiceFS
NAS
許多量化團隊在初期往往會選擇一種 “開箱即用” 的方式來搭建存儲系統，最常見的就是基於傳統協議的 NAS（Network Attached Storage），使用 NFS 或 Samba 協議進行訪問。在數據規模普遍處於幾十 TB 到幾百 TB 的情況下，很多私有機房採用 NAS 架構即可滿足需求，部署簡單、管理方便、成本在可控範圍內。然而，這種方案在實踐中也暴露出一些明顯的問題。
首先是成本問題。如果希望在 IDC 線下機房中獲得較高的存儲性能，通常必須使用全閃存 NAS 系統。全閃雖然性能更好，但價格昂貴，整體投資較大。而混閃架構（SSD 與 HDD 混合）在高併發訪問場景下往往性能不足，特別是在多個研究員同時讀取數據時，IO 吞吐容易成為瓶頸。
其次，雲上 NAS 的性能受限於容量綁定。在公有云環境中，許多廠商的 NAS 或並行文件系統（如部分 PFS 產品）會將吞吐量與購買的容量直接綁定。也就是説，如果一個量化團隊只需要 100 TB 的存儲容量，但其回測和策略計算需要達到較高的吞吐或 IOPS，例如聚合每秒 50GB 以上讀或者每秒上百萬次操作，就必須“超配”購買到 PB 級容量才能滿足性能需求。這種模式顯然會帶來資源浪費與成本上升。
第三個問題是協議層面導致的性能瓶頸。NAS 協議依賴內核客户端進行數據交互，當負載高時，由於數據與元數據通過同一通道傳輸（NFS4.2 前），容易在高併發讀寫下形成擁堵，從而引發性能下降甚至出現延遲抖動。這種情況雖然不是每次都會出現，但在量化研究高峯期或集中回測階段極易暴露。
綜上所述，雖然 NAS 系統具備“即插即用”、部署簡便、兼容性好的優點，但其在成本、性能擴展性以及高併發訪問效率方面仍存在明顯短板。
對象存儲
對象存儲也是量化行業會考慮的低成本的解決方案，儘管對象存儲的單次請求延遲較高，但它在處理大吞吐量的順序讀寫時表現較好。許多研究員對其業務代碼進行了改造，避免使用隨機讀寫，而是將數據聚合成適合順序讀取的格式，再通過內存進行隨機操作。這種做法雖然有效，但也存在一些問題。
首先，對象存儲只能通過 S3 協議進行訪問。對於已經使用 POSIX 掛載點的應用，遷移到對象存儲時需要對代碼進行改造，這對原有系統有一定的侵入性。此外，對象存儲原生缺乏元數據管理，由於其扁平結構，I/O 操作的響應速度較慢，尤其是文件重命名等操作。如果需要更改文件名，實際上需要刪除原文件並複製新的文件，這在性能上表現較差。
其次，對象存儲上的文件不可變（immutable），這意味着如果要修改數據（例如在 Parquet 文件中添加一列），只能通過創建一個新的文件來實現，而不能直接在原文件上修改。這種不可變特性在一些場景下，如數據庫文件可能導致很大的不便。
此外，頻繁讀取對象存儲會產生額外的流出費用，這對於量化行業高頻讀寫的需求來説，可能會造成較高的成本。同時，雖然對象存儲在大吞吐量下表現不錯，但它的性能完全依賴於存儲系統本身，在高併發訪問下可能仍然無法滿足量化研究對速度和實時性的要求。
JuiceFS
JuiceFS 是一款基於對象存儲的分佈式文件系統，兼容 POSIX ，能夠同時管理結構化與非結構化數據，為量化研究提供統一、高性能的數據存儲平台。系統支持 CSI 驅動，能與 Kubernetes 深度結合，同時具備雲原生特性，可靈活部署在公有云、私有云或混合雲環境中。
JuiceFS 採用數據與元數據分離的架構。數據被切分成小塊存儲在對象存儲中，元數據則由獨立引擎管理並緩存在內存中。這種設計顯著提升了訪問性能，使文件元數據操作（如重命名、查找，獲取文件屬性等）無需頻繁訪問底層存儲，從而實現高吞吐量、低延遲和高 IOPS 的性能表現。
在安全與權限方面，JuiceFS 提供基於 Token 和 POSIX ACL 的訪問控制機制，並支持數據傳輸與存儲加密。更重要的是，對象存儲與緩存中的數據均採用分塊存放方式，從架構層面進一步提升了數據的安全性與合規性。
實際操作時，用户通過下載並安裝 JuiceFS 的二進制文件，並使用 juicefs mount 命令將其掛載到本地系統上。一旦掛載完成，用户的業務就能通過 POSIX 掛載點進行訪問，操作方式與本機文件系統類似，方便與現有的應用兼容。
這樣的架構在量化行業中的應用帶來了多個顯著的優勢：
- 高吞吐量與高 IOPS 支持：量化投研中的數據使用模式大多是“讀多寫少”，尤其是回測、因子研究等任務，需要頻繁地讀取大量數據。JuiceFS 的切塊存儲和高效的多級數據緩存能夠提供 高吞吐量和高 IOPS 支持，滿足量化研究對數據訪問的苛刻要求。
- 彈性擴展與降本：量化研究常常面臨動態的存儲需求，JuiceFS 天生具備 彈性擴展 能力，能夠根據需求動態調整存儲和緩存資源。通過將對象存儲作為底層存儲架構，結合 分佈式緩存，JuiceFS 可以顯著降低存儲成本，避免了全閃存儲的高昂開銷。
- 數據安全：在量化投研中，因子數據和交易策略等屬於核心資產，其安全性至關重要。JuiceFS 通過數據切塊與加密機制有效保障數據安全。尤其是對於對上雲仍存顧慮的機構，這一分塊加密策略能顯著降低數據泄露風險——即便部分數據被截獲，攻擊者也無法在缺乏元數據的情況下還原原始內容，從而確保敏感信息的安全與合規。
- 雲環境兼容性：隨着雲計算和公有云的普及，量化投研逐步向雲環境遷移。JuiceFS 支持跨雲同步，能夠在多雲或混合雲環境中高效運行，為量化研究提供了更大的靈活性和可擴展性。
對於線下部署的量化企業，JuiceFS 同樣是可行且高效的選擇。傳統線下存儲多采用混閃或機械硬盤，性能往往難以滿足量化研究的高併發需求。JuiceFS 通過充分利用業務機器的本地緩存盤和高效的緩存機制，在低成本下即可實現接近全閃的性能，顯著降低硬件投入。同時，其運維管理簡單、穩定性高，客户反饋表明系統運行可靠、維護負擔較輕。
03 案例
案例 1 - 提升對象存儲性能，整體降本增效
為了進一步降低存儲成本，該企業選擇將數據遷移至對象存儲。在回測業務中，他們原先使用的是一個自研的接口，通過 S3 API 直接訪問 Amazon S3 對象存儲。由於他們的業務主要是寫入大塊數據並進行順序讀取，這種存儲模式即使沒有緩存也能夠勉強運行。儘管如此，這種做法仍然存在一些明顯的弊端。
首先，使用 S3 API 對業務代碼產生了侵入性，意味着如果 API 出現問題，業務代碼的調試和維護將變得非常困難。此外，該 API 沒有實現緩存，僅做了協議轉換，一定程度上性能也有上限。由於這些原因，業務團隊並不希望長期依賴這種模式。
為了改善這一狀況，該企業決定遷移到 JuiceFS 企業版。遷移之後，業務代碼不再依賴於 S3 API，JuiceFS 作為富客户端直接掛載在業務機器上。通過這種方式，業務代碼幾乎沒有受到侵入，開發人員可以繼續按原有方式編譯和運行代碼。同時，業務機器上的 NVMe 硬盤被用作分佈式緩存，這有效優化了數據訪問效率。
使用 JuiceFS 帶來了顯著的性能改進，客户得以在低成本的對象存儲上實現高性能讀寫：首先，本地緩存避免了重複訪問遠程存儲，顯著降低讀取延遲；其次，JuiceFS 的切塊與預讀機制充分利用了對象存儲帶寬，使單文件讀取也能達到系統性能上限。整體上，遷移後的系統在性能和維護便利性上均有明顯提升。
客户的神經網絡訓練任務同樣從 JuiceFS 的優化中獲益。在訓練過程中，系統需要讀取約 10 萬個文件（每個約 24MB），並在隨機打散後反覆讀取。未使用緩存時，每輪訓練都需重新加載所有文件，產生巨大的網絡流量。而引入 JuiceFS 後，首次讀取的數據會自動緩存到本地，後續訓練可直接從緩存池中獲取，大幅減少帶寬佔用並顯著提升整體訓練效率，完全滿足客户訓練使用對存儲的需求。
案例 2 - 業務對元數據要求極高
客户主要將 JuiceFS 用於回測業務。該客户從外部購買行情數據，通常是 CSV 格式，並將其存儲在目錄中。不同於其他客户將數據進行聚合，這個客户將原始數據直接存放在文件夾內，造成了更大的數據訪問負擔。每個股票的歷史行情數據被分開存儲，每個文件代表一支股票一年的數據，這些文件按月和年分佈在不同目錄下。每次需要讀取某一日期的行情數據時，必須隨機讀取並處理約 6000 個文件，然後將這些文件按順序排列。為了支持回測，這些數據被用來啓動數百台虛擬機，進行 4000 至 6000 個回測任務。
這一過程中，隨機讀取大量文件對存儲系統造成了巨大的負擔，尤其是在高併發讀寫的場景下，元數據的訪問效率嚴重影響了整體性能。這個客户原本使用 JuiceFS 社區版，並結合雲上 Redis 服務來緩存部分數據。雖然 Redis 提供了良好的性能，但它的 QPS 上限為 50 萬個，這對於該客户的高併發回測任務來説已經無法滿足需求。當回測任務達到 12,000 個時，Redis 的性能達到了瓶頸，導致整個系統變得非常緩慢，回測任務無法順利完成。
為了解決這個問題，客户嘗試使用 JuiceFS 企業版。企業版的元數據服務在性能上有了顯著的提升，特別是在處理大量元數據請求時，企業版可支持更高的併發量。企業版的元數據服務採用了基於目錄樹結構的管理方式，並且提供了一個更加高效的請求處理服務。客户不再需要通過 KV 存儲方式請求多個操作，而是通過簡單的請求告知元數據系統讀取文件。企業版元數據請求的單次處理效率約為社區版的 6 倍，因此在執行相同業務時，所需 QPS 僅為社區版的六分之一，整體執行效率更高。
除此之外JuiceFS 企業版還提供更強力的元數據客户端緩存機制：大量只讀請求（如 getattr、lookup）可直接命中緩存，顯著降低了對元數據服務的訪問壓力。如下圖所示，系統共處理約 50 萬 QPS 的只讀元數據請求，其中僅約 4 萬實際落到元數據服務端。再加上企業版元數據服務本身的高效處理能力，整體系統能夠在高併發場景下保持穩定運行，CPU 使用率僅約 40%，客户能夠穩定支持多達 12,000 個回測任務。
從這個案例我們可以看到，JuiceFS 企業版在量化行業中能夠有效應對高併發讀寫、高 IOPS 和大量 元數據請求 的挑戰。即使在沒有對業務場景進行優化的情況下，JuiceFS 依然能夠高效處理這些暴力操作的需求，滿足量化行業對數據訪問速度和響應能力的苛刻要求。
案例 3 - 雲 NAS 不滿足 IOPS 要求
在這個案例中，客户面臨的是將業務遷移到雲端時的雲存儲性能問題。他們最初選擇了使用雲 NAS 來支持存儲需求，但很快發現，隨着業務的擴展，雲 NAS 的性能無法滿足 IOPS 要求。在使用雲 NAS 的過程中，客户的 120 台機器就已經將普通型雲 NAS 的 IOPS 上限打滿，而即使使用極速型雲 NAS（提供約 20 萬 IOPS），性能仍然不能完全滿足需求。
為了應對這一瓶頸，客户決定切換到 JuiceFS。通過 JuiceFS 的分佈式緩存，客户能夠聚合更多的 IOPS 性能。理論上，5 台緩存機器可以提供每台 20 萬 IOPS，再加上本地硬盤的支持，最終可以提供 超過 100 萬的 IOPS。通過這種方式，客户可以靈活組合緩存資源，按需擴展存儲性能。
在極限場景下，客户能夠達到 7.5 GB 的吞吐量和近 300 萬 IOPS，這足以應對大規模的隨機讀寫場景。具體來説，客户能夠通過增加網絡帶寬來提升吞吐量，而通過增加緩存節點數量來提高 IOPS 性能。每個緩存節點大約可以提供 10 萬至 20 萬 IOPS，客户還可以根據需要通過掛載更多的硬盤或利用內存來擴展容量。這樣，客户可以根據業務的實際需求，自由組合和調整緩存池的能力，確保系統的性能。
04 小結
結合前文多個實際案例，可以總結出量化研究在存儲層面的幾個顯著特點：
首先，量化業務的數據容量相對較小，但對性能要求極高。JuiceFS 通過數據與元數據分離及緩存機制顯著提升訪問效率，即使在無緩存的情況下，也能依靠預讀和數據切塊上傳機制充分利用帶寬，確保高性能的數據處理能力。
其次，JuiceFS 的數據切塊與加密機制提升了雲上存儲的安全性。數據被切分並加密後存儲，即便部分數據被竊取，攻擊者也無法在缺乏元數據的情況下還原文件。這種設計特別適合保護量化因子、交易策略等敏感數據。
隨着量化業務逐步向雲端遷移，JuiceFS 提供了一種平衡性能與成本的技術路徑。它在對象存儲的基礎上實現了高性能訪問與統一管理，滿足公有云與混合雲環境下的多樣化計算需求，為量化機構構建可擴展、可靠的數據基礎設施。
我們希望本文中的一些實踐經驗，能為正在面臨類似問題的開發者提供參考，如果有其他疑問歡迎加入 JuiceFS 社區與大家共同交流。
