乾象投資：基於JuiceFS 構建雲上量化投研平台
- 2022 年 10 月 28 日
- 筆記
背景
乾象投資 Metabit Trading 成立於2018年，是一家以人工智能為核心的科技型量化投資公司。核心成員畢業於 Stanford、CMU、清北等高校。目前，管理規模已突破 30 億元人民幣。
Metabit 非常重視基礎平台的建設，有一支強大的 Research Infrastructure 團隊。團隊試圖打破在單機上進行研發的壁壘，利用雲計算進行更高效、安全的工具鏈研發。
01 量化的研究都在做什麼
作為一家成立時間不久的量化投資機構，我們在對基礎存儲平台進行選型時，會受到這樣兩方面的因素的影響：公司成立的時間比較短，沒有太多技術上的歷史負擔，在做技術選擇時，更偏向於使用更現代的技術棧；同時，量化投資中使用到的機器學習場景中的特性也會影響到技術的選擇。
上圖是我們研究場景中和機器學習關聯最緊密的策略研究模式的簡化示意圖。首先，在模型訓練之前需要對原始數據做特徵提取。金融數據的信噪比特別低，如果直接使用原始的數據進行訓練，得到的模型噪音會非常大。原始數據除了行情數據，即大家經常會看到的市場上的股價、交易量之類的數據，也包括一些非量價的數據，比如研報、財報、新聞、社交媒體等之類的非結構化數據，研究人員會通過一系列的變換提取出特徵，再進行 AI 模型訓練。
模型訓練會產出模型以及信號，信號是對未來價格趨勢的判斷；信號的強度意味着策略導向性的強度。量化研究員會根據這些信息去優化投資組合，從而形成交易的實時倉位。這個過程中會考慮橫向維度（股票）的信息來進行風險控制，例如某一行業的股票不要過度持倉。當倉位策略形成之後，量化研究員會去模擬下單，而後得到實時倉位對應的盈虧信息，從而了解到這個策略的收益表現，以上就是一個量化研究的完整流程。
量化研究業務特點
研究需求產生大量突發任務：高彈性
在策略研究的過程中，量化研究員會產生策略想法，他們會通過實驗去驗證自己的想法。伴隨着研究人員新想法的出現，計算平台就會產生大量的突發任務，因此我們對計算的彈性伸縮能力的要求很高。
研究任務多樣化：靈活性
從上面的例子可以看到，整個流程涵蓋了非常多不同的計算任務，例如：
- 特徵提取，時序數據上的計算；
- 模型訓練，經典的機器學習的模型訓練場景；
- 投資組合優化，會涉及到最優化問題的任務；
- 策略回測，讀入行情的數據，再對策略的表現去做模擬撮合，得到倉位對應的表現。
整個過程任務的種類是非常多樣化的，對計算的要求也很不一樣。
研究內容需要保護：模塊化，隔離
研究員的投研內容是公司的重要 IP（知識產權）。為了保護這些知識產權，公司的研究平台會將每個策略研究環節抽象成包含標準輸入輸出和評價方式的模塊。例如對模型的研究，輸入標準的特徵值，輸出預測的信號和模型。通過對模塊之間進行隔離，研究平台可以有效保護 IP 的安全性。在進行存儲平台建設時，需要針對模塊化這個需求做相應的設計。
量化研究數據特點
大量任務的輸入來自於相同的數據，比如上文提到的回測，量化研究員需要對歷史策略去做大量的回測，同樣的倉位使用不同的參數去測試，觀察它們表現；或者特徵提取，經常有一些基礎特徵和新特徵的組合，其中大量的數據是來自於相同的數據源。
以 A 股的股票為例：A 股市場十年的分鐘 K 線歷史行情，5000/2 股票 240 分鐘 250 天 10 年 8 位元組*20 列=240GB，整體 10 年的數據量大約是 240G。
如果使用更細力度的數據，數據量就會更大，一般來說原始數據不會超過 100TB 的範圍。在大數據時代這算不上是特別大的數據量，但是當大量的計算任務去同時去訪問這些數據，這種場景就對數據存儲的有一些要求。
另外，量化投研過程中伴隨着大量的突發任務，研究團隊希望能將這些任務的結果存儲起來，因此會產生大量 archive 數據，但這些數據的訪問頻率很低。
量化研究計算任務特點
基於以上特點，如果以傳統的機房方式，是很難去滿足我們的計算需求，因此把計算搬到雲計算平台對我們來講是一個相對合適的技術選擇。
第一，突發任務多，彈性非常大。上圖是我們某個集群近期的運行實例數據。可以看到在多個時間段里，整個集群實例都是被打滿的狀態，但是同時整個計算集群的規模也會有 scale 到 0 的時候。量化機構的計算任務和研究員的研發的進度是有很大關聯的，波峰波谷的差距會非常大，這也是離線研究任務的特點。
第二，「技術爆炸」，很難準確預估何時會產生算力需求。「技術爆炸」是科幻小說《三體》的概念，對應到我們這就是我們的研究模式和算力的需求會發生飛躍式進步，我們很難準確預估算力需求的變化。我們在 2020 年年初的時候，研究的實際用量和預估用量都非常小，但是當研究團隊提出的一些新的研究方法思路之後，會在某個瞬間突然對算力產生非常大的需求。而容量規劃是在建設傳統機房的規劃時候非常重要的一件事情。
第三，現代 AI 生態，幾乎是搭載在雲原生平台上的。我們做了很多創新的技術嘗試，包括現在非常流行的 MLOps，將整套 pipeline 串聯起來，再去做機器學習訓練的流水線；現在很多的分佈式的訓練任務的支持，都是面向雲原生去做了很多的開發工作，這也使得我們把整個計算任務放到雲上成為一個很自然的選擇。
02 量化平台存儲需求
根據上面業務和計算的需求，可以比較容易的去推導出來我們對存儲平台的需求。
-
計算與存儲不均衡。上文提到計算任務會有很大的突增，計算量會很容易會達到非常高的水平。而熱數據的增長量並沒有那麼快，這就意味着我們需要去做存算分離。
-
為熱數據，比如行情的數據，提供高吞吐的訪問。上百個任務同時訪問數據，對它吞吐要求非常高。
-
為冷數據提供低成本存儲。量化研究需要大量 archive 數據，也要為這些數據提供相對低成本的存儲。
-
文件類型/需求多樣性即 POSIX 兼容性。我們有很多不同的計算任務，這些計算任務對文件的類型的需求是非常多樣的，例如CSV、Parquet 等，有一些研究場景還有更靈活的定製開發的需求，這就意味着在選型的時候不能夠對文件存儲方式做嚴格限制，因此 POSIX 的兼容性對於存儲平台選型是一個很關鍵的考量因素。
-
IP 保護：數據共享與數據隔離。我們 IP 保護的需求，不僅是計算任務上需要做這樣的隔離，在數據上也是需要支持這樣的隔離能力；同時對行情數據這類相對公開的數據，還需要支持研究員的獲取方式是便捷的。
-
AI 生態，在雲的平台上去做各種任務的調度。這也是較為基礎的一個使用需求，因此存儲上也是需要對 Kubernetes 做很好的支持。
-
模塊化即中間結果存儲/傳輸。計算任務模塊化的場景，導致我們會對中間結果的存儲跟傳輸也有需求。舉個簡單的例子，在特徵計算過程中會生成比較大量的特徵數據，這些數據會立刻用於被訓練的節點上，我們需要一個中間存儲介質去做緩存。
03 存儲方案選型
非 POSIX 兼容方案
最初，我們嘗試了很多對象存儲的方案，也就是非 POSIX 的方案。對象存儲有很強的擴容能力，而且成本非常的低，但是對象存儲的問題也很明顯。最大的問題就是沒有 POSIX 兼容性。對象存儲的使用方式跟文件系統有比較大的區別，如果把對象存儲直接作為接口面向研究員，對他們來講使用有很大的難度，便利性也有很大的限制。
除此之外，很多雲廠商的對象存儲有請求限制。例如，阿里雲會對整個帳號的 OSS 帶寬做限制。對於普通的業務場景這通常是可以接受的，但是突發性任務會在瞬時產生非常大的帶寬需求，僅僅使用對象存儲很難去支撐這類場景。
另一個方案是 HDFS ，我們在 HDFS 上面並沒有做太多測試。首先，我們所採用的技術棧對 Hadoop 沒有太強的依賴；同時， HDFS 對 AI 訓練的產品的支持並沒有特別突出，而且 HDFS 沒有完整的 POSIX 兼容性，這對我們的使用場景會有一些限制。
雲上 POSIX 兼容方案
上文中提到的業務特點決定了我們對 POSIX 兼容性有很強的需求，而且技術平台是基於公有雲來進行的，因而我們將存儲選型的範圍確定為：雲上兼容 POSIX。
雲廠商會提供一些方案，比如像阿里雲的 NAS，AWS EFS 之類；另外一類是像阿里雲的 CPFS 方案，AWS 的 FSx 方案。這兩類文件系統的吞吐是與容量強綁定的，當容量越大的時候，吞吐會越大，跟 NAS 的存儲性質是直接相關的。這樣的方案，在面對小量的熱數據的時候不太友好，需要額外的優化才能達到比較好的表現。另外 CPFS 或者阿里雲上的極速型 NAS，對低延時的讀取很友好，但缺點是成本比較高。
就各自官網展示的價格，我們做了個對比。各類高性能 NAS 產品的成本大概是 1500-2000元/TB/月，JuiceFS 整體的成本會低很多，因為 JuiceFS 的底層存儲是對象存儲 。JuiceFS 的成本分成這樣幾個部分：對象存儲的存儲費用；JuiceFS 雲服務的費用；以及SSD 緩存產生的成本。綜合來看，JuiceFS 的整體成本遠低於 NAS 和其他方案的成本。
在吞吐方面，早期做了一些測試，當節點數量比較少的時候，直接用 CPFS 跟做 JuiceF 對比，同時讀取性能不會有很大的差異。但是當節點數變大之後，因為 NAS 類文件系統有帶寬限制，讀取時間整體都拉長了，而 JuiceFS 只要做好緩存集群的部署，可以非常輕鬆的支撐下來，並且沒有太大的開銷，下圖場景是部署了總帶寬約為 300Gb 左右的集群。
除了成本和吞吐以外，在技術選型時， JuiceFS 對上文提到的功能 Full POSIX、權限控制、Qos、Kubernetes 都能夠比較好的支持；
值得一提的是JuiceFS 的緩存集群能力，它能夠實現靈活的緩存加速。最開始時，我們使用計算節點做本地緩存，這是一個挺常見的做法。存算分離之後，希望計算節點有一些數據可以本地化，JuiceFS 這方面功能的支持是比較完善的，對於空間的佔用、百分比的限制等都做得很完善。我們部署了獨立的緩存集群去服務一些熱數據，只要在使用之前去做緩存預熱就可以了。在使用過程中，我們發現不同的計算集群資源的利用率差別很大，集群中有一些大帶寬的機器，大部分時候都是用來做單節點的計算，這也就意味着機器的網絡的資源基本上是沒有怎麼用到，而且還有一些閑置的磁盤，因此就在這些機器上去部署了緩存節點，把閑置的網絡帶寬給利用了起來。最終使得我們在同一個集群中，實現了一個帶寬非常大的緩存集群。
目前 ，JuiceFS 被用在了以下生產場景：
- 計算任務數據文件系統，被應用於熱數據輸入；
- 日誌/ artifact 輸出；
- Pipeline 數據中轉：數據特徵生成之後，需要中轉到模型訓練中，訓練過程中也會有數據中轉的需求，Fluid 和 JuiceFS 作為中間的緩存集群來使用。
未來，我們將繼續探索雲原生、AI技術，用以進行更高效、安全的工具鏈研發和基礎技術平台建設。
如有幫助的話歡迎關注我們項目 Juicedata/JuiceFS 喲！ (0ᴗ0✿)
