zipline和rqalpha對比?

希望大牛能從數據量和回測速度等方面對這兩個框架進行詳細對比


利益相關: RQAlpha 作者

我沒有完整看過 zipline 的源碼,所以回答中對於 zipline 的評價未必準確,如有紕漏,請指出。

RQAlpha 和 Zipline 都是 Event-Driven Algorithmic Trading Library, 都源於在線演算法回測網站(Quantopian, Ricequant), 都發展為可以進行實盤交易的演算法引擎。有人說國內在線演算法交易網站沒有一個是原創,全部是改了zipline 的源碼,然後套了個網站的皮,在這點我並不認同的,雖然是兩個很相似的引擎,但底層實現、核心特點還是有很大區別的。

接下來我談一下幾個核心問題的看法:

API

Ricequant 最初基於以下原因在 API 設計上和 Quantopian 保持一致:

  • Quantopian API 設計優良(至少當時是這麼覺得的,實際並不是...)
  • Quantopian API 已經得到了很多用戶的反饋和優化
  • Ricequant 有做美股及吸引海外用戶的打算,保持 API 的一致性,可以降低用戶學習和轉化成本

基於以上原因,在通用性的部分比如 `init`, `handle_bar`, `context.portfolio` 等內容上採取了和 Quantopian 一致的 API。

但是,熟悉 Ricequant 的朋友應該知道,當初 Ricequant 是同時支持 Java 和 Python 兩種回測的,實際上第一代回測引擎是使用 java 編寫的,而 java 程序的 API 與 Quantopian 並不相同。而對應的 python 回測是在 java 引擎上面包裝了一層用來支持 Python 代碼運行的。雖然 Java 回測引擎速度非常快,但通過 Python 這一層轉換,回測速度並不理想,甚至還沒有直接通過 Python 回測速度要快,因此才有了後來的 RQAlpha 項目,而 RQAlpha 為了保證向前兼容,也沿用了原本 API 定義。

然而,在 RQAlpha 的發展過程中,API 也是不斷變化的,從而導致現在和 Zipline 的 API 形似神離,差異已經很大了。感興趣的話可以看一下之前寫的關於 API 和底層邏輯變更的 Issue:

  • RQAlpha 2.0.0 · Issue #65 · ricequant/rqalpha
  • 重構 RQAlpha 支持通過 Mod 擴展賬戶和持倉交易類型 · Issue #160 · ricequant/rqalpha

數據存儲格式

均使用 bcolz 作為底層回測數據存儲格式。這個沒什麼好說的,bcolz 壓縮率高,性能好,本身就是列式存儲容器,大家都愛用。

性能

事件驅動的演算法引擎,回測速度都不會太快,每一個 bar 要觸發一堆的事件,並且各種模塊要響應事件,並完成具體的業務邏輯,這個時間消耗相對於直接基於時間序列做計算或者做信號來說,肯定差異是巨大的,至少差一兩個數量級。所以在這點上,RQAlpha 和 Zipline 速度在回測框架中並不算是很快的。

相比之下,Zipline 對於數據讀取、處理做了不少 Cython 優化,RQAlpha 邏輯較之複雜些,功能更多一些,雖然我沒有測試,但是應該回測速度 Zipline 應該更快一些。但其實功能不同,直接進行速度的比較並沒有太大的意義。RQAlpha 速度上還是有挺大提升空間的,只不過目前可能有其它更重要的事情去做。

不過未來我可能會做一套基於 C 的 CEP 併兼容當前 RQAlpha 的 Mod,從而真正滿足對於速度、延遲更高標準的要求。

架構

RQAlpha 經歷過多次的重構,目前形成了以事件為觸發機制,通過 Mod 來實現具體業務邏輯的組織結構,比 Zipline 擴展性和靈活性要強得多,可以非常容易的支持各種擴展。

這裡有一個2.2.x 版本的結構圖(最新版本還沒來得及更新)

傳送門: RQAlpha_structure | 思維導圖(新) | ProcessOn

目前已經擁有了很多的擴展 Mod。

比如對接期貨實盤的擴展: ricequant/rqalpha-mod-ctp

比如對接富途港股的擴展: FutunnOpen/OpenQuant

內部對接財務數據、分鐘數據、tick數據回測的擴展

甚至客戶端應用的擴展: RQPro--專業級本地量化終端 - 知乎專欄


RQAlpha 的架構另一特點就是真正支持多品種交易,也就是說一個策略里可以同時交易股票、期貨,也可以交易你擴展的任意交易類型。

其實說來說去,可能也沒有解答提問者的疑惑,那麼直接說結論吧....

如果做國內交易,首選 RQAlpha (你去看看期貨的計算邏輯就明白了,全世界獨一家的複雜)

如果做國外交易,首選 Zipline

如果是編程、量化新手,兩個都不要選,先打好基礎,這些過於複雜。

如果是想要做擴展,首選 RQAlpha,你可以再不改 RQAlpha 代碼的情況下根據你自己的業務場景進行任意擴展,無論你是想交易比特幣,還是想做策略收益分析,還是想增加風控模塊等


利益相關:RQAlpha文檔參與者

偏個樓,架構方面已經有作者 @卜一 的回答,我就不班門弄斧了,不過做為文檔編寫的參與者,我可以講講在RQAlpha文檔編輯過程中,我們做了那些可能不為人知的小事。

RQAlpha一開始是由作者開始寫,但是作者在寫的過程中發現使用者的視覺與作者的視覺是有所不同的。在開發者看來的一些「基本常識」,往往可能對於使用者來說是具備門檻的。

舉個例子:

在安裝過程中,會遇到各種奇怪的問題,比如說我之前在一台新的mac上重新安裝一次RQAlpha,發現新的mac os在創建文件夾的時候出現「Operation not permitted」,而這個問題會影響到中文字體的安裝,最後翻了一圈是因為Mac OS 10.11 EI Capitan 後加入rootless機制,對系統的讀寫有了更嚴格的限制。

除此以外,還有很多一些小細節的問題如Mac OS默認關閉顯示隱藏文件,而這會影響到用戶去查看默認策略以及數據的存放位置。

這些問題肯定不會是一個人遇到,我們希望無論是開發者還是小白,都能在接觸RQAlpha的過程中擁有良好的體驗。


推薦閱讀:

面向對象編程為什麼沒有在科學計算領域獲得普及?
學 C 語言時,有沒有遇到過讓你「痛不欲生」、「揪心」或「不得要領」的術語?現在又是怎麼理解它的?
寫程序需要編譯器,編譯器是程序,輸入輸出也需要驅動,驅動也是程序,那麼第一個在電子計算機運行的程序是怎麼產生的?
Scheme語言的優勢?
Mathematica 能否成為取代 Python 乃至其他編程語言的程序設計語言?

TAG:編程 | 量化交易 |