WonderTrader架構詳解之四——淺談平臺對策略的支持

前言

  《WonderTrader架構詳解》系列文章，上一篇介紹了WonderTrader的信號執行的處理機制。平臺的數據和信號執行機制已經完成之後，接下來就是要考慮如何生成信號了，也就是說策略如何編寫。在解決策略編寫的問題以前，首先要解決的就是平臺要支持哪些策略。本文做爲系列文章的第四篇，將針對WonderTrader對不一樣策略的支持展開討論。

往期文章列表：

• WonderTrader架構詳解之一——總體架構
• WonderTrader架構詳解之二——從數聽說起
• WonderTrader架構詳解之三——信號與執行

策略的分類

  如何對策略進行分類，這個問題自己就很複雜。不少介紹策略的書都會對策略進行一個分類，而後再展開介紹，可是每位做者都有本身的分類標準，因此每本書裏介紹的策略分類也不盡相同。筆者曾經拜讀過幾本，比較有表明性的就是丁鵬的《量化投資——策略與技術》。這本書裏大體分爲如下幾個大類策略：

• 量化選股策略

  • 多因子選股
  • 風格輪動選股
  • 行業輪動選股
  • 資金流選股
  • 動量反轉選股
  • ……

• 量化擇時策略

  • 趨勢追蹤擇時
  • 市場情緒擇時
  • 有效資金擇時
  • 牛熊線擇時
  • Hurst指數擇時
  • ...

• 股指期貨套利

  • 期現套
  • 跨期套

• 商品期貨套利

  • 期現套
  • 跨期套
  • 跨品種套利
  • 跨市場套利

• 統計套利

  • 配對交易
  • 股指套利
  • 融券套利
  • 外匯套利
• ……

  然而對於量化平臺來講，以上的分類都沒有實際的意義。爲何呢？由於平臺須要考慮的是從技術角度如何對策略進行分類，而上面展現的策略分類都是從策略實現的邏輯和目標交易品種來進行分類的。

  那麼從技術實現的角度角度對策略進行分類要考慮哪些問題呢？

• 行情數據的需求

  從技術實現的角度來講，策略對數據的需求會引發很大的架構變更。好比說有些策略須要K線數據進行信號的計算，有些策略須要 tick數據進行信號的計算，而有些策略同時須要 K線數據和 tick數據進行計算。 平臺在對策略開放接口的時候，就必需要考慮到不一樣策略的數據需求。
  以趨勢追蹤策略爲例，趨勢追蹤策略通常使用 K線數據進行信號計算，可是在實際運營的過程當中可能也須要利用實時的 tick數據進行一個止盈止損邏輯的觸發。
  平臺在考慮策略對數據的需求的同時，還須要考慮 在實盤過程當中對策略所須要的數據如何進行緩存、如何進行實時的更新、以及如何傳遞給策略。

• 信號執行的需求

  策略對信號執行的需求，主要是 執行響應速度和 執行方法兩個方面。對於不少 日頻調倉的策略來講，如多因子選股，通常狀況下須要執行較大數量的調倉，對於執行的要求相對較低，主要根據執行當天的平均成交價做爲一個參考基準，在一天內執行完成便可。而對於 高頻策略來講，單次執行的數量通常較少，須要當即響應信號，在微秒級的延遲下發出下單指令。而對於 日內調倉的策略來講，單次執行的數量介於多因子和高頻之間，對執行的要求也介於兩者之間：一方面不但願太大的延遲，形成太大的滑點；另外一方面須要也不可能以一天的成交均價做爲基準，反而如下一個週期的開盤價做爲成交價的參考基準。

• 重算調度的需求

  無論是何種策略，都須要一個機制驅動策略進行核心邏輯的計算。通常策略採用的驅動方式主要是 事件驅動和 時間驅動。 時間驅動，就是到了某個規則肯定的時間節點，驅動策略的核心邏輯進行重算。而 事件驅動，咱們這裏主要指的是 K線閉合、 K線開始、 tick進入等事件。對於基於 K線的日內趨勢策略，通常須要在 K線閉合的時候進行重算；而基於 日K線的跨日趨勢策略，則能夠在收盤後到次日開盤前進行重算；對於高頻策略，則須要在每一筆 tick到來的時候進行重算。

• 跟蹤標的的需求

  跟蹤標的的需求，主要考慮的是 跟蹤的標的數量。若是你是作國內商品期貨的，通常狀況下，即便活躍品種的主力合約所有跟蹤，也只有40多個。而若是要跟蹤滬深300的成分股、或者中證1000的成分股，那麼如何設計纔可以知足這樣的應用場景，就是一個很是重要的問題。

  綜合上面幾點，WonderTrader最終從技術實現的角度將策略分類成三個大類：

• 日內趨勢類策略

  日內趨勢類策略，不是說策略只作日內交易，而是指策略會 在日內觸發信號，即在交易時間內的某個時間點觸發信號。這類策略通常策略邏輯都是基於 分鐘K線數據進行核心邏輯的重算，利用 tick數據進行止盈止損邏輯的計算。這類策略信號強度通常較高， 不須要在執行的過程當中根據訂單的成交狀況動態調整執行策略， 可以容忍必定程度的滑點，屬於筆者在上一篇《 信號與執行》中提到的「 重邏輯輕執行」的策略。

• 高頻類策略

  高頻類策略，主要利用 tick數據觸發核心邏輯重算，對於信號響應的 延遲特別敏感，並且出現信號之後，還 須要根據訂單的執行狀況實時調整信號。這類策略的 盈利空間很小因此 對滑點的容忍度很是低，所以須要平臺處理信號要儘量地快，屬於筆者在上一篇《 信號與執行》中提到的「 輕邏輯重執行」的策略。

• 選股類策略

  選股類策略，主要指的是 日頻以上週期調倉的策略，以 多因子選股策略爲表明，因此稱爲選股類策略。選股類策略， 計算量大、 計算時間長， 資金容量大，信號的特色是 數量大， 對滑點也不敏感。所以這類策略對於信號執行的效果容忍度也比較高。不過正是由於這些特色， 選股類策略若是搭配更合適的執行算法的話，對績效能夠提高好幾個點。對於大規模的資金容量來講，幾個點的提高也是一個很是可觀的數字了。所以選股類策略，對執行算法的需求，就體現須要在更長的時間跨度上，找到更合適的買賣點。

WonderTrader的策略引擎

  針對上面的策略技術分類，WonderTrader提供了三種策略引擎，以知足不一樣類型策略的需求。

CTA引擎

  CTA引擎（類名WtCtaEngine），是WonderTrader針對日內趨勢類策略設計的策略引擎，由於最先主要是針對CTA策略的，因此引擎名字就按照CTAEngine沿用下來了。
  CTA策略在初始化的時候，會向CTA引擎訂閱一個主K線，也能夠同時訂閱其餘週期或者其餘品種的K線。CTATicker收到行情之後，會根據時間戳判斷是否有K線閉合，若是有K線閉合，則觸發策略的on_bar回調；若是閉合的是主K線，則檢查是否全部的K線都已經閉合；若是全部K線都已經閉合，則觸發策略的on_schedule回調進行策略核心邏輯的重算。若是出現新的信號，則由CTAEngine彙總之後獲得一個目標組合，再丟給執行管理器。執行管理器則將目標組合分發到各個執行通道，並由執行通道轉成交易指令下達交易所。若是沒有K線閉合或者K線閉合事件已經處理完成，再觸發策略的on_tick回調進行風控運算。
  下圖展現了CTA引擎中策略信號產生和執行的基本流程：

HFT引擎

  HFT引擎（類名WtHftEngine），是WonderTrader針對高頻類策略設計的策略引擎。
  HFT策略在初始化的時候，會向HFT引擎訂閱一些合約的tick數據（若是通道支持的話，還能夠訂閱股票Level2數據），也能夠訂閱K線數據（不分主次）。HFTTicker收到行情之後，和CTA引擎不一樣的是，不會檢查是否有K線閉合，而是直接觸發策略的on_tick回調進行核心邏輯的重算。若是出現新的信號，則直接經過交易通道發出交易指令。交易通道收到訂單回報之後，會觸發策略的on_order回調，若是策略有調整，則再發出新的交易指令。交易通道收到成交回報之後，會觸發策略的on_trade回調，若是有相應的調整，又會發出新的交易指令。
  下圖展現了HFT引擎中策略信號產生和執行的基本流程：

SEL引擎

  SEL引擎（類名WtSelEngine），是WonderTrader針對選股類策略設計的策略引擎。因爲選股類策略具備計算時間長和計算量大的特色，而且一般是非交易時間重算，因此SEL引擎本質上是一個時間驅動的引擎。SEL引擎在設計的時候，要兼顧盤後計算和盤中計算兩種需求，因此整個策略的重算是異步的。
  SEL策略在初始化的時候，會向SEL引擎註冊一個時間驅動的策略。例如天天、每週、每個月、每一年指定的時間觸發重算，或者在交易時間內每N分鐘觸發重算。在非交易時間，由於沒有行情接入，因此SEL引擎會根據本地時間進行比較，若是知足時間條件，則觸發策略的on_schedule回調進行核心邏輯的重算。若是註冊的是交易時間內的分鐘線驅動，則經過SELTicker根據最新接收到的tick數據的時間戳進行行情時間同步，再觸發策略的on_schedule回調進行核心邏輯的重算。若是有新的信號產生，則將目標組合丟給執行管理器。執行管理器則將目標組合分發到各個執行通道，執行通道會根據預設的算法交易進行拆單，並根據算法交易的邏輯在合適的實時機由執行通道轉成交易指令下達交易所。

策略引擎現狀的思考

  前面介紹的WonderTrader不一樣的策略引擎的核心邏輯，已經基本上能夠覆蓋市面上絕大部分策略調度的需求了。不過對於WonderTrader的策略引擎，筆者目前也存在一些疑慮。

HFT引擎對作市策略的支持

  WonderTrader爲了簡化策略的邏輯，將策略的信號所有簡化爲買和賣。這樣的簡化，省掉了策略研發人員不少事情，好比：究竟是買開仍是買平？可平今倉剩餘多少、可平昨倉剩餘多少？如今買進的信號要拆成幾個單子下出去？單筆下單的最大數量是多少？WonderTrader會把這些問題所有自動處理掉。好比：自動根據持倉肯定是開倉仍是平倉；自動根據預設的開平方案控制是平倉仍是鎖倉；自動根據可平數量拆分信號爲多個訂單。筆者相信絕大部分策略研發都會喜歡這樣的簡化，可是有一種策略可能會例外：作市策略。
  作市策略通常的交易邏輯是在高位掛一個賣單，同時在低位掛一個買單，經過賺取兩個單子之間的價差獲取收益。問題在於，若是按照前面提到的一些自動處理方案，開始的時候是沒有持倉的，同時掛的兩個訂單成交之後，持倉呈一多一空的狀態，淨頭寸仍然爲0。若是這個時候出現第二輪信號，就可能會出現一些問題：買入訂單會平掉空頭的頭寸，賣出訂單會平掉多頭的頭寸。持倉的狀況會如此反覆，對於有些策略來講可能就不大適應了。

SEL引擎回測的難點

  SEL引擎回測的難點起源於實盤中的策略的核心邏輯是異步執行的。好比說，t0時刻觸發了策略的重算，重算時間較長，一直持續到t1時刻。若是在生產環境下，直接在t1時刻執行新的信號便可。可是對於回測環境下，若是採用同步回測的方式，回測時執行的價格爲t0時刻的p0；若是採用異步方式回測的話，回測行情回放的時間又比生產環境快不少，到了t1時刻行情早已回放超過t1了，這時的執行價格變成了t2時刻的p2了，而不是t1時刻的p1。綜合來講，SEL引擎回測結果的參考價值要比CTA引擎小不少。筆者也曾經考慮過，根據重算時間t，計算t0+t時刻，找到該時刻的pt做爲執行價格。這樣的處理方式看起來比較可行，可是也會引入更多的複雜度。

WonderTrader的規劃

  前面大體介紹了WonderTrader各個策略引擎的一些基本狀況。通過多方調研，筆者認爲從底層來講WonderTrader支持的應用場景已經足夠豐富了。可是在WonderTrader運用和推廣的過程當中，筆者也發現了一些預計以外的需求，這些也是後面WonderTrader完善的方向。

完善交易接口

  目前來講，WonderTrader只支持普通的交易接口，能夠籠統地歸納爲現金業務的交易接口。實際上還有其餘業務類型，例如ETF申贖、期權詢價報價、期權行權、兩融業務等等。筆者後面會根據實際的須要逐步的完善這些接口，讓WonderTrader支持更多的業務類型。

適配更多品種

  從WonderTrader目前的推廣的反饋來看，很多用戶但願利用WonderTrader進行數字貨幣的交易。而後因爲數字貨幣7×24小時交易的特色，目前WonderTrader還不能很好的支持。拋開技術細節不談，根源仍是在於WonderTrader原本設計的目標就是針對常規的交易市場的，即便是NYMEX這樣的交易所，天天也有1個小時的休市時間。固然，這不能成爲WonderTrader固步自封的理由，因此將來WonderTrader也會逐筆完善對不一樣市場和不一樣品種的適配。

爲應用層開放功能擴展接口

  WonderTrader在設計的時候，爲了保證底層的執行效率，全部的功能組件都是用C++開發的。功夫不負有心人，WonderTrader系統內部延遲，在通常臺式機上也能達到10微秒之內。可是在推廣的過程當中，筆者發現部分用戶其實是基於wtpy作開發的，並無C++的開發能力。可是這樣的用戶想要作一些二次開發的話，都須要C++底層作同步調整，因而這些用戶只能望而卻步了。鑑於這樣的狀況，筆者也反覆斟酌了一下，計劃在將來考慮將行情接入模塊、交易模塊嚮應用層子框架開發。這樣的好處就是，一些二次開發的門檻也同步下降了，能夠豐富WonderTrader的生態，給不一樣需求的人羣提供更豐富的選擇。

結束語

  本文對WonderTrader的策略引擎的介紹就到此結束了，但願本文能給一些想要使用WonderTrader進行策略開發的朋友一些指引。筆者水平有限，不免有錯漏之處，還請各位朋友多多包涵指正。下一篇，筆者將針對不一樣的策略引擎，來詳細介紹WonderTrader不一樣類型策略的回測的機制，望各位讀者屆時多多捧場。

  最後再安利一下WonderTrader
  WonderTrader旨在給各位量化從業人員提供更好的輪子，將技術相關的東西都封裝在平臺中，打造更高效的底層框架，力求給策略研發帶來更好的策略開發和交易體驗。

WonderTrader的github地址：https://github.com/wondertrad...

WonderTrader官網地址：https://wondertrader.github.io

wtpy的github地址：https://github.com/wondertrad...

---

市場有風險，投資需謹慎。以上陳述僅做爲對於歷史事件的回顧，不表明對將來的觀點，同時不做爲任何投資建議。