量化投資云原生存儲(chǔ)實(shí)踐：緩存加速、彈性對(duì)象存儲(chǔ)、POSIX兼容

Ariste AI 是一家專注于 AI 驅(qū)動(dòng)交易的公司，業(yè)務(wù)涵蓋自營(yíng)交易、資產(chǎn)管理、高頻做市等多個(gè)領(lǐng)域。在量化交易研究中，數(shù)據(jù)的讀取速度和存儲(chǔ)效率，往往直接決定了研究迭代的速度。

Ariste AI 團(tuán)隊(duì)在構(gòu)建量化研究基礎(chǔ)設(shè)施的過程中，面對(duì)總規(guī)模超過 500TB，行情與因子數(shù)據(jù)，經(jīng)歷了從本地盤到最終選擇在 MinIO 對(duì)象存儲(chǔ)之上疊加 JuiceFS 文件系統(tǒng)的四個(gè)階段。通過緩存機(jī)制與分層架構(gòu)，團(tuán)隊(duì)實(shí)現(xiàn)了高頻數(shù)據(jù)的快速訪問與集中管理。這一實(shí)踐驗(yàn)證了“緩存加速、彈性對(duì)象存儲(chǔ)與 POSIX 兼容”三位一體方案在量化場(chǎng)景下的可行性，希望這一經(jīng)驗(yàn)?zāi)転橥刑峁┮恍﹨⒖肌?/p>

量化投資存儲(chǔ)挑戰(zhàn)：

規(guī)模、速度與協(xié)作的平衡

量化投資流程依次包括數(shù)據(jù)層、因子與信號(hào)層、策略與倉(cāng)位層及執(zhí)行與交易層，構(gòu)成從數(shù)據(jù)獲取到交易執(zhí)行的完整閉環(huán)。

量化業(yè)務(wù)流程示意圖

在整個(gè)過程中，存儲(chǔ)系統(tǒng)面臨多重挑戰(zhàn)，主要體現(xiàn)在以下幾個(gè)方面：

• 數(shù)據(jù)規(guī)模與增速：量化研究所需處理的數(shù)據(jù)總量較大，涵蓋歷史行情數(shù)據(jù)、新聞數(shù)據(jù)以及自行計(jì)算的因子數(shù)據(jù)等。目前，這些數(shù)據(jù)的總量已接近 500T。并且，企業(yè)每日新增的行情數(shù)據(jù)也達(dá)數(shù)百 GB。若采用傳統(tǒng)磁盤進(jìn)行存儲(chǔ)，顯然無(wú)法滿足如此巨大的數(shù)據(jù)存儲(chǔ)需求。

• 高頻訪問與低延遲要求：高頻的數(shù)據(jù)訪問依賴于低延遲的數(shù)據(jù)讀取。數(shù)據(jù)讀取的速率直接決定了研究效率的高低。若數(shù)據(jù)讀取速度較快，研究進(jìn)程便能迅速推進(jìn)；反之，則會(huì)導(dǎo)致研究效率低下。

• 多團(tuán)隊(duì)并行與數(shù)據(jù)治理：在量化研究過程中，通常會(huì)有多個(gè)團(tuán)隊(duì)同時(shí)開展不同的實(shí)驗(yàn)。為確保各團(tuán)隊(duì)研究工作的獨(dú)立性與數(shù)據(jù)安全性，需要進(jìn)行安全的隔離，以避免數(shù)據(jù)混淆與泄露。

為應(yīng)對(duì)上述量化全流程對(duì)數(shù)據(jù)存儲(chǔ)的需求，打造面向未來(lái)的存儲(chǔ)系統(tǒng)，我們的目標(biāo)是實(shí)現(xiàn)：高性能、易擴(kuò)展與可治理，三者有機(jī)統(tǒng)一：

• 高性能：?jiǎn)喂?jié)點(diǎn)讀寫帶寬突破 500MB/s，訪問延遲低于本地磁盤感知閾值；

• 易擴(kuò)展：支持存儲(chǔ)與計(jì)算資源按需水平擴(kuò)容，業(yè)務(wù)無(wú)需改造即可實(shí)現(xiàn)平滑彈性伸縮；

• 可治理：提供細(xì)粒度權(quán)限控制、操作審計(jì)與數(shù)據(jù)生命周期策略的一站式管理能力。

存儲(chǔ)架構(gòu)的演進(jìn)

階段一：本地盤極速起步

在項(xiàng)目初期，我們采用了 Quantrabyte 研究框架，該框架內(nèi)置了 ETF 模塊，可直接將數(shù)據(jù)存儲(chǔ)在本地磁盤上，數(shù)據(jù)讀取速度較快。研究員可根據(jù)自身需求，直接運(yùn)行所需數(shù)據(jù)，迭代過程較為迅速。然而，這一階段也存在一些問題：

• 重復(fù)下載造成資源浪費(fèi)：多個(gè)研究員若使用相同數(shù)據(jù)，會(huì)進(jìn)行多次下載。

• 存儲(chǔ)容量不足：研究服務(wù)器的存儲(chǔ)容量有限，僅約 15T，難以滿足日益增長(zhǎng)的數(shù)據(jù)存儲(chǔ)需求。

• 協(xié)作困難：當(dāng)需要復(fù)用他人的研究結(jié)果時(shí)，操作過程不夠便捷。

階段二：MinIO 集中管理的雙刃劍

為解決第一階段存在的問題，我們引入了 MinIO 進(jìn)行集中管理。將所有存儲(chǔ)數(shù)據(jù)集中在 MinIO 上，通過拆分出的模塊將數(shù)據(jù)全部存入。同時(shí)，將具體因子數(shù)據(jù)也存入 MinIO，實(shí)現(xiàn)公共數(shù)據(jù)的統(tǒng)一下載。并通過權(quán)限隔離，實(shí)現(xiàn)多團(tuán)隊(duì)數(shù)據(jù)共享，提升存儲(chǔ)空間利用率。

然而，這一階段也出現(xiàn)了新的瓶頸：

• 高頻隨機(jī)讀延遲大：在進(jìn)行高頻數(shù)據(jù) I/O 操作時(shí)延遲較大，影響數(shù)據(jù)讀取速度。

• 無(wú)緩存導(dǎo)致讀寫慢：由于 MinIO 社區(qū)版無(wú)緩存功能，讀寫高頻公共數(shù)據(jù)時(shí)速度較慢。

階段三：JuiceFS 引入緩存加速

為解決上述瓶頸，經(jīng)充分調(diào)研，我們最終引入 JuiceFS 的緩存加速方案。該方案通過客戶端本地 RAID5 存儲(chǔ)進(jìn)行掛載，借助高效的緩存機(jī)制，成功將讀寫性能提升約三倍，顯著改善了高頻共享數(shù)據(jù)的訪問體驗(yàn)。

隨著業(yè)務(wù)數(shù)據(jù)量突破 300TB，本地存儲(chǔ)的擴(kuò)容瓶頸逐漸顯現(xiàn)。由于數(shù)據(jù)存儲(chǔ)在本地，擴(kuò)容需重新配置存儲(chǔ)設(shè)備，而 RAID5 架構(gòu)下擴(kuò)容速度緩慢且風(fēng)險(xiǎn)較高，難以滿足業(yè)務(wù)持續(xù)增長(zhǎng)的需求。

階段四：JuiceFS + MinIO 集群終局架構(gòu)

為解決擴(kuò)容難題，我們最終采用了 JuiceFS+MinIO 集群架構(gòu)。該方案具備以下優(yōu)勢(shì)：

• 持續(xù)高性能：JuiceFS 提供充足的緩存能力，充分滿足高頻數(shù)據(jù)訪問場(chǎng)景的性能需求；

• 便捷集群擴(kuò)展：基于集群化方案，可快速實(shí)現(xiàn)橫向擴(kuò)容，僅需添加同類型磁盤即可靈活提升存儲(chǔ)容量，大幅增強(qiáng)系統(tǒng)擴(kuò)展性。

圖片通過四階段演進(jìn)，我們驗(yàn)證了緩存加速、彈性對(duì)象存儲(chǔ)與 POSIX 兼容三位一體方案在量化場(chǎng)景的可行性。此方案可為同行業(yè)提供可復(fù)制、可落地的最佳實(shí)踐范本，在性能、成本與治理之間取得了卓越平衡。

性能與成本收益

通過采用 JuiceFS 與 MinIO 相 結(jié)合的存儲(chǔ)架構(gòu)，系統(tǒng)帶寬與資源利用效率得到質(zhì)的飛躍，目前已完全滿足研究業(yè)務(wù)對(duì)存儲(chǔ)性能的需求。引入 JuiceFS 緩存層后，回測(cè)任務(wù)執(zhí)行效率大幅提高，1 億條 Tick 數(shù)據(jù)回測(cè)耗時(shí)由之前的數(shù)小時(shí)降至數(shù)十分鐘。

讀寫帶寬變化

同時(shí)，基于我們完整的數(shù)據(jù)生命周期分層存儲(chǔ)體系策略，實(shí)現(xiàn)存儲(chǔ)單價(jià)由高到低的平滑過渡，整體存儲(chǔ)成本下降 40% 以上。

Ariste AI 數(shù)據(jù)生命周期分層存儲(chǔ)策略

運(yùn)維實(shí)踐與展望

多租戶治理

在數(shù)據(jù)隔離與權(quán)限管理方面，我們建立了完善的管理體系：

通過命名空間實(shí)現(xiàn)邏輯隔離，采用類似 /factor/A、/factor/B 的路徑規(guī)劃，確保各業(yè)務(wù)數(shù)據(jù)邊界清晰。在權(quán)限控制層面，支持用戶、團(tuán)隊(duì)、項(xiàng)目三個(gè)維度的精細(xì)化管理，并與 POSIX ACL 權(quán)限體系無(wú)縫對(duì)接。同時(shí)建立完整的審計(jì)日志系統(tǒng)，實(shí)現(xiàn)訪問行為的實(shí)時(shí)追蹤與變更歷史回溯，全面滿足合規(guī)性要求。

可觀測(cè)性與自動(dòng)化運(yùn)維

我們圍繞四大核心指標(biāo)構(gòu)建了完整的監(jiān)控體系：緩存命中率、I/O 吞吐量、I/O 延遲與寫入重試率，系統(tǒng)在指標(biāo)異常時(shí)可自動(dòng)觸發(fā)告警。

基于 Grafana 實(shí)現(xiàn)了運(yùn)維閉環(huán)管理，持續(xù)監(jiān)控節(jié)點(diǎn)健康狀態(tài)與存儲(chǔ)容量。在每次擴(kuò)容前，會(huì)通過模擬壓測(cè)驗(yàn)證系統(tǒng)承載能力，確保業(yè)務(wù)無(wú)感知。整體運(yùn)維體系實(shí)現(xiàn)了自動(dòng)化、可預(yù)測(cè)、可回滾的高標(biāo)準(zhǔn)運(yùn)維目標(biāo)。

回測(cè)系統(tǒng)中的數(shù)據(jù)更新設(shè)計(jì)

我們?cè)诨販y(cè)系統(tǒng)設(shè)計(jì)中采用基于 DAG（Directed Acyclic Graph，有向無(wú)環(huán)圖）的架構(gòu)，以提升系統(tǒng)的計(jì)算效率與可維護(hù)性。該框架以計(jì)算節(jié)點(diǎn)和依賴關(guān)系為核心，將數(shù)據(jù)處理、特征計(jì)算、信號(hào)生成等環(huán)節(jié)抽象為節(jié)點(diǎn)，并通過依賴圖統(tǒng)一管理。系統(tǒng)內(nèi)置版本控制機(jī)制，當(dāng)數(shù)據(jù)版本更新時(shí)，可依托依賴圖自動(dòng)識(shí)別受影響的節(jié)點(diǎn)，精確定位需重算部分，從而實(shí)現(xiàn)高效的增量更新與結(jié)果追溯。

回測(cè)數(shù)據(jù)版本更新示意圖

未來(lái)展望

在未來(lái)規(guī)劃中，我們將從以下三個(gè)方向持續(xù)優(yōu)化存儲(chǔ)架構(gòu)：

• 元數(shù)據(jù)高可用升級(jí)：計(jì)劃將元數(shù)據(jù)存儲(chǔ)從 Redis 遷移至 TiKV 或 PostgreSQL，以構(gòu)建跨機(jī)房高可用架構(gòu)，顯著提升系統(tǒng)容災(zāi)與快速恢復(fù)能力。

• 混合云分層存儲(chǔ)：通過對(duì)接公有云 S3 與 Glacier 存儲(chǔ)服務(wù)，構(gòu)建智能冷熱分層體系，在實(shí)現(xiàn)存儲(chǔ)容量無(wú)限彈性的同時(shí)，達(dá)成成本最優(yōu)化目標(biāo)。

• 研究數(shù)據(jù)湖統(tǒng)一治理：計(jì)劃構(gòu)建統(tǒng)一的研究數(shù)據(jù)湖平臺(tái)，集成 Schema 注冊(cè)、自動(dòng)數(shù)據(jù)清洗與統(tǒng)一目錄治理等核心服務(wù)，全面提升數(shù)據(jù)資產(chǎn)的發(fā)現(xiàn)與管理效率。

關(guān)于作者