WonderTrader架構詳解之三——信號與執行

前言

  《WonderTrader架構詳解》系列文章，上週介紹了WonderTrader的數據處理機制。當平臺解決了策略的數據問題之後，就須要向策略提供穩定可靠的信號執行機制，保證策略的信號被正確的執行，是每個平臺最基本的功能。所以，本文做爲系列文章的第三篇，將主要介紹WonderTrader信號執行的處理機制。

往期文章列表：

• WonderTrader架構詳解之一——總體架構
• WonderTrader架構詳解之二——從數聽說起

1+N執行架構

  WonderTrader設計了一種執行架構，該執行架構能夠將一個策略組合的信號，分發到若干個執行通道執行，咱們稱之爲1+N執行架構。爲何會把信號執行設計成這樣呢？

• 基於策略最簡化的基本原則

對於策略來講，最核心的任務是抓住賺錢的因子。可是交易的過程當中，會涉及到行情的接入和訂單回報的處理。市面上有很多平臺，選擇直接將這樣的回報暴露給策略。在這類平臺上，策略除了核心邏輯之外，還須要寫不少重複的訂單管理邏輯。有些平臺甚至將底層接口的數據結構直接暴露給策略，這樣作的結果是給策略引入了更多的複雜度，除了管理回報，還須要對不一樣的接口作數據的兼容處理。
WonderTrader的一個設計目標就是是要給策略研發人員作減法，讓他們將更多的精力放到策略自己，而不是如何和接口打交道。 1+N執行架構，也正是基於這條基本原則。由於 信號和執行完全剝離，因此策略不須要關注任何回報，由於底層會將執行這塊處理得很好，策略只須要關注本身的目標頭寸和進出場的價格便可。這樣就 大大簡化了策略的編寫，只須要 將信號計算的核心邏輯實現好就能夠了。

• 大規模產品管理的實際需求

當咱們只有一個策略時，最簡單的方式，就是把策略寫成一個小型的平臺，本身處理行情回報和交易回報，再針對特定的需求作一些功能擴展便可。而這種作法，容易把平臺作成一個「玩具」，不具有管理大規模產品的基礎，有不少量化交易框架都相似這種。
對於大規模的產品管理，最基本的需求就是 多個策略造成一個組合共同交易，而一個策略組合又同時在多個產品進行交易。而不一樣資金規模的產品，在發出交易指令的時候，所須要的執行算法也是不同的。好比 買入100手和買入1手某期貨合約，顯然就不能用徹底同樣的方式下單。
1+N執行架構很重要的一方面就是 針對大規模產品管理的需求。相同的策略組合，在 不一樣的交易通道下，會根據產品的資金規模和風險偏好 配置不一樣的交易數量放大倍數。而交易數量的不一樣，有須要針對不一樣的交易通道 配置不一樣的執行算法，這樣才能讓各個產品都能 得到更好的執行價格。

• 策略邏輯和執行的反覆權衡

1+N執行架構下，須要把策略分爲兩類策略： 重邏輯輕操做的策略和 輕邏輯重操做的策略。 大多數趨勢類策略都屬於前者，而幾乎全部的高頻策略都屬於後者。
重邏輯輕操做的策略，最顯著的特色就是 信號出現時必需要執行到位。這類策略，還表現出頻率較低（相對高頻而言）， 對滑點敏感度低等特色。而這類策略就是 1+N執行架構主要服務的策略，這類策略也很容易經過 1+N執行架構擴展到更多的交易通道。
相對的， 輕邏輯重操做的策略，最顯著的特色就是 信號出現時，要看執行的狀況，才能決定下一步如何應對。這類策略最多見的就是 套利策略和 高頻策略，它們須要 不停地掛單試探盤口的狀況，才能作出更有利的決策。顯然 1+N執行架構沒法知足這類策略，因此 WonderTrader專門針對這類策略提供了 HFT引擎，該引擎將交易接口和交易 回報直接暴露給策略，這樣策略就能根據回報執行管理訂單。

• 投研人員的編碼水平的考量

在量化領域中，對從業人員的成分劃分，有一個頗有趣的分類方法： P-Quant和 Q-Quant。 P-Quant的共同屬性是這些從業人員基本都有軟件開發的 技術背景，擁有相對 較好的編碼能力。而 Q-Quant則相反，通常 沒有技術背景，編碼能力相對較弱，可是在 策略建模、金融工程方面相對較強。
由於兩類從業人員的背景和能力樹的不一樣，因此他們對於平臺的需求也不大同樣。 P-Quant編碼能力相對較強，傾向於 平臺提供核心的基礎功能便可，他們能夠 自行開發本身須要的各類功能，同時但願 平臺可以儘量低延時（P-Quant從事高頻策略開發的比例更高）； Q-quant編碼能力相對較弱，則傾向於 平臺提供更完善的基礎設施和策略開發API，相對的，他們 對延時不那麼敏感（固然若是平臺可以作到更低延時，對他們一樣有利），可是但願 平臺支持的應用場景更豐富一些（要知足不一樣類型的策略的回測、實盤等需求）。

  鑑於以上提到的幾個方面，WonderTrader最終決定針對CTA策略，基於信號和執行的剝離，採用1+N執行架構進行實盤交易。而針對HFT策略，則選擇將交易接口直接暴露給策略（不一樣交易接口的差別被封裝到交易模塊中，策略處理的交易接口是無差異的），讓策略自行管理訂單，轉而在數據需求上提供支持。這樣就能兼顧不一樣類型的策略的不一樣的應用場景，讓不一樣類型的策略都能在WonderTrader中能夠更高效的管理起來。

如何同步信號

  對於CTA引擎，既然採用1+N執行架構，就意味着平臺須要管理兩套頭寸，一套是策略的理論頭寸，一套是交易通道的實際頭寸。在實盤運行中，咱們須要對兩套頭寸分別進行管理。

• 理論頭寸的管理

理論頭寸的管理，也分爲兩個層面。第一個是 策略層面，即 每一個策略有本身的理論頭寸，包括進出場的時間、價格、方向、數量等。策略能夠管理的也只能是本身的理論部位， 每一個策略都是互相隔離的。持有的頭寸，再實時計算浮動盈虧，並覈算最大潛在浮盈和最大潛在浮虧等數據。 回測的時候，數據都在內存中， 不須要實時保存。而 實盤環境下，要考慮策略重啓等各類狀況，因此數據須要 實時保存到文件中。
第二個是 組合層面，即策略的目標頭寸整合到一塊兒之後，造成一個 淨頭寸。這個淨頭寸本質上和策略的理論頭寸是一致的，只不過是軋平過相反的頭寸之後， 歸屬於策略組合管理。策略組合也要實時計算浮動盈虧，同時根據預設的資金規模，計算資金風險指標，進行實時風控。 實盤環境下，數據也要實時保存到文件中（回測引擎針對單策略，因此不存在策略組合的概念）。

• 實際頭寸的處理

策略組合的頭寸是最終分發到各個交易通道的 基礎目標頭寸。每一個交易通道，會根據所對應產品的資金規模和風險需求分別配置本身的放大倍數，基礎爲1倍，支持小數倍數，會自動作四捨五入的處理。
每一個執行通道肯定了本身的 實際目標頭寸之後，跟本身當前 實際持有的頭寸進行比較，將有 差異的頭寸，根據預設的 執行算法（ WonderTrader內置的是以最新價、最優價和對手價三個價格做爲 基礎價格，再加上一個滑價跳數做爲限價，基本上知足了絕大部分資金規模有限的策略需求）發出下單指令。並根據 訂單回報和 成交回報實時更新 持倉狀態和 訂單狀態。

• 滑點如何處理

正如前面所說， 不一樣資金規模的策略，最終成交的價格是不一樣的，更況且不一樣的交易通道仍是依賴相同的信號進行交易的，併發執行的前提下，不一樣交易通道的訂單最終也會在交易所進行競爭。這就形成一個客觀的事實： 相同策略在不一樣產品中的實盤表現必定是有差別的，而差別的來源就是滑點。
回測的時候，咱們通常用小手數進行回測，因此通常狀況下都 不考慮滑點。可是 實盤環境下，滑點問題就不可避免。這也是咱們內置的執行算法，都是以限價單下單的根本緣由。通常狀況下，筆者建議 放大倍數大的交易通道，執行算法中 預設的滑價能夠相對放大倍數小的交易通道 設置得更大一些（最終要根據流動性判斷）。這樣即便產生滑點，也在能夠接受的範圍以內。若是使用市價單發出下單指令，極端行情下，最終產生的滑點可能會壓縮掉所有的利潤。

1+N執行架構的意義

  前面基本介紹了1+N執行架構基本原理。從WonderTrader的角度來講，所謂的1+N其實也有兩層意思：N個策略在1個組合中共同運行，而1個組合又同時在N個交易通道進行交易。因此一開始的時候筆者有意稱之爲N+1+N執行架構。顯然，無論從哪方面來講，1+N執行架構的意義是非凡的：

• 策略和執行剝離，對研發人員更友好，團隊管理更高效

投研人員的技術棧實際上是策略 coding的核心問題，咱們選擇一個平臺的時候，應該 儘可能的減小技術棧的引入。而通常交易接口都是異步回調的，若是強行要策略投研人員深刻了解這類純技術技能，從團隊管理的角度來講，是低效的。同時對於投研人員來講，花太多的精力到自身技能樹的分支上，也不是一個聰明的選擇，更況且技術自己也並不那麼容易。
因此 策略和執行的剝離，對大部分投研人員，尤爲是 Q-Quants來講，是一種很是友好的設計。這樣的設計固然也不是 WonderTrader獨創的，筆者也從同事的實際需求中和其餘的量化平臺吸取了一些經驗。

• 淨頭寸執行，不存在自成交風險

對於策略來講， 風控是必不可少的，一樣策略組合的風控也是平臺的重點之一。風控中，除了 資金風控之外，還有一個 合規風控。績效回撤了，能夠再賺，可是若是合規風控過線了，可能會引發很是大的麻煩。其中最重要的合規風控點就是自成交。 自成交次數過多，手數過大，很容易被認定爲對敲操控市場，相應的處罰也是很是嚴厲的。
WonderTrader須要解決多策略在多產品運營的問題， 首要考慮的就是合規性的問題。若是兩個策略同時發出相反的交易信號，而且分發到多個產品同時下單，自成交的風險就會被放大。因此 WonderTrader經過在策略組合中 軋平相反頭寸，最終以 淨頭寸的方式發出下單指令。除了自然避免自成交的問題，同時還能 節省佣金、 減小保證金的佔用。策略組合內部，策略有本身的理論頭寸，不受組合頭寸的影響。

• 同一個策略組合的多產品，能夠保證信號的一致性

筆者此前，常常會被投資人問：大家怎麼保證各個產品績效的一致性的？筆者沒有太多去研究別家是怎麼處理的，可是對於 WonderTrader的 1+N執行架構來講，這樣的問題就顯得太簡單了。
即便兩個規模同樣的產品，用同一套策略交易，績效也不可能徹底同樣。由於即便同時下單，也受到交易通道速度的影響。可是不能保證績效的徹底一致性，保證信號的徹底一致性倒是沒有問題的。

• 知足大規模管理產品的需求

專業投資機構對於交易平臺的需求，和我的投資者仍是有很大差異的。最核心的一點就是 大規模的產品如何管理的問題。例如某些頭部私募，發了數百隻產品，假設只有一百隻產品須要實際操做，而每隻產品都須要交易股票、期貨、期權等標的。
若是不從架構上解決這樣的需求，對於這些機構的 IT來講，這基本上是一個災難：在不一樣的服務器上部署策略運行環境，天天還要監控各臺服務器在開盤前是否正常運行。甚至有些櫃檯要到開盤前纔會啓動，這就使得運維人員的檢查時間窗口只能限定在半個小時甚至更短的時間範圍內。
WonderTrader的需求就從大規模產品管理中來，一開始的設計目標也是要知足大規模產品管理的需求。而 1+N執行架構正是針對這樣的需求的核心機制。

結束語

  本文對WonderTrader的信號執行機制的介紹就到此結束了，相信經過本文，各位讀者可以對WonderTrader的1+N執行架構有一個更深刻的瞭解，也但願本文可以在各位讀者在遇到相似問題的的時候，對你們有所啓發。筆者水平有限，不免有錯漏之處，還請各位朋友多多包涵指正。下一篇，筆者將圍繞平臺如何兼容不一樣的策略，來介紹WonderTrader不一樣的策略引擎的底層邏輯，望各位讀者屆時多多捧場。

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

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

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

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

---

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