作者：丁博

公司簡介

深圳市弘(hong)源(yuan)泰平資產(chan)(chan)管理(li)有限公司(si)組建于2016年，團隊核心成員來自(zi)于知(zhi)名高校，有豐(feng)富的資產(chan)(chan)配(pei)置(zhi)與策略構建的實踐經驗。弘(hong)源(yuan)泰平以套戥交(jiao)易絕對收益(yi)型配(pei)置(zhi)工具為起點，致(zhi)力于為用戶提供流動性好、費率公允的資產(chan)(chan)配(pei)置(zhi)工具。產(chan)(chan)品線全(quan)面、豐(feng)富，涵蓋股、債(zhai)、商(shang)品等各大類資產(chan)(chan)，通脹(zhang)、趨勢(shi)等各類因(yin)子。

場景簡介+核心訴求

我們的量化交易系統每天(tian)要(yao)接收大量的行情數(shu)據(ju)(ju)，也(ye)要(yao)基于行情產生(sheng)大量的決(jue)策信號。這(zhe)些數(shu)據(ju)(ju)都需要(yao)及時存下來，供(gong)盤中和盤后使(shi)用(yong)。

傳統(tong)存(cun)放(fang)行(xing)情數(shu)據(ju)的(de)方式有(you)文件系(xi)統(tong)、關系(xi)型數(shu)據(ju)庫或者文檔(dang)數(shu)據(ju)庫。我們(men)嘗(chang)試了MySQL和知名的(de)時序(xu)數(shu)據(ju)庫InfluxDB，但是性能都沒有(you)達到預期(qi)。分(fen)別(bie)遇到了如下(xia)問題：

• MySQL：在寫入大量實時的時序數據時，性能不理想；即便是優化之后，對于資源的浪費仍然十分驚人。而且隨著數據量的增加，對設備數據的實時查詢、時間范圍分析的需求增加，基于MySQL的查詢分析操作，響應時間會越來越長，甚至會無響應。缺乏自動建表功能，使用很不方便。
• InfluxDB：雖然是時序數據庫，但是經過測試后性能不能滿足預期，在完成同樣數據量的寫入時對于資源的使用程度也并不能令人滿意。

最后，我(wo)們改用TDengine Database徹底(di)解決了實時寫入(ru)大量數(shu)據(ju)點(dian)和快速查詢的(de)問題。

TDengine Database具體落地

對于(yu)策(ce)(ce)略(lve)研(yan)究員而言，歷(li)史行情和(he)(he)信號是交易(yi)策(ce)(ce)略(lve)研(yan)究的重要(yao)素材。下(xia)面以行情數據和(he)(he)策(ce)(ce)略(lve)信號數據為(wei)案例予以介紹(shao)。

數據建模

首先，將行(xing)情數據和(he)信號(hao)數據分別存儲。在TDengine Database中分別創(chuang)建了(le)一個行(xing)情數據庫和(he)信號(hao)數據庫。

雖然是(shi)時序(xu)數(shu)據庫，但是(shi)TDengine使(shi)用了關(guan)系型(xing)數(shu)據庫的模型(xing)，建(jian)庫，建(jian)表，使(shi)用SQL，十(shi)分(fen)便于(yu)傳統關(guan)系型(xing)數(shu)據庫的用戶入手。并且，他們還很有創意地設計了超級表的概念，與(yu)我(wo)們的場景十(shi)分(fen)契合。

因(yin)為所有行(xing)情數(shu)據結構(gou)相(xiang)同，行(xing)情庫(ku)中只(zhi)需(xu)要一個超(chao)級表，下(xia)面(mian)每個工具（衍生品基(ji)金等(deng)）對應一個子(zi)表。比如CU2101表示2021年(nian)1月份到(dao)期的銅期貨(huo)交易合約(yue)。在(zai)合約(yue)到(dao)期之前(qian)，都會有行(xing)情數(shu)據寫入。下(xia)面(mian)重點介紹(shao)策略信號數(shu)據庫(ku)。

信號(hao)庫有兩張(zhang)超級(ji)(ji)表，分別對應合約(yue)級(ji)(ji)別信號(hao)和策略級(ji)(ji)別信號(hao)，每個(ge)交易信號(hao)對應一張(zhang)子表，當(dang)前共有 40,000多(duo)張(zhang)表，表結構分別如(ru)下所(suo)示：

下面是信號庫執行show tables的截圖：

數據庫配置以及寫入

我們(men)選(xuan)用(yong)的TDengine版本(ben)是2.2.0.0，由于單(dan)機版尚無壓力，目前還不需要集群。此(ci)外，機器有(you)40核，而TDengine的每一個vnode又是擁有(you)獨(du)立(li)(li)運行(xing)(xing)線(xian)(xian)程的工作單(dan)元。所以，根據(ju)文章《》，我調整(zheng)了(le)(le)minTablesPerVnode、tableIncStepPerVnode和(he)maxVgroupsPerDb參數(shu)(shu)，讓vnode的數(shu)(shu)量恰(qia)好等于CPU核數(shu)(shu)，讓每個核獨(du)立(li)(li)運行(xing)(xing)一個線(xian)(xian)程，實現了(le)(le)數(shu)(shu)據(ju)的合理化分布，以爭(zheng)取達(da)到最(zui)佳性(xing)能。

寫入性能

當前，我(wo)們(men)大概每秒寫入3萬行數據(ju)。單節點(dian)TDengine可以十(shi)分輕松地實現這(zhe)個(ge)級(ji)別數據(ju)量的(de)(de)寫入。同時，消耗服務(wu)器資源又比InfluxDB與MySQL小的(de)(de)多(duo)。因此，即(ji)便未來業務(wu)擴大，我(wo)們(men)也不需要(yao)擔心額外的(de)(de)硬件成本。

資源消耗

我(wo)們當(dang)前的服務器配置如下(xia)：64G內存+40核 1.8GHz CPU+機(ji)械硬盤。

在業務(wu)運行期間，taosd的(de)(de)%CPU只有4%上下浮(fu)動，進程使用的(de)(de)物理內(nei)存(cun)百分比為11.2%。雖(sui)然內(nei)存(cun)占用稍多(duo)，但這是由于(yu)我們的(de)(de)vnode配置的(de)(de)比較多(duo)，每個(ge)vnode都(dou)有自己固定的(de)(de)內(nei)存(cun)緩沖區。因此，后續即(ji)便是繼續大量增加(jia)新表或(huo)者加(jia)大寫(xie)入量，內(nei)存(cun)占用也不會有明顯的(de)(de)浮(fu)動了。

截至目前，通過TDengine錄入(ru)的兩個信(xin)號表已經寫入(ru)了82億條數據，原數據大概為92GB，實際占用存儲空間為20G左右，壓縮率高達23%，如果是整型數據應(ying)該還會更高。

查詢性能

除(chu)了寫入與存儲，使用TDengine做(zuo)日常查詢的速度也十(shi)分優秀，即(ji)便是(shi)對于(yu)幾十(shi)億級(ji)別的大表，也是(shi)毫(hao)秒級(ji)響應。我(wo)們來看(kan)兩個場景。

場景1：查詢特定策略信號下一段時間的均值。

select avg(v) from stgbox.strategy_signal where stg_name = '{stg_id}' and signal_name ='{signal_name}' and ts >= '{from_date} 00:00:00' and ts <= '{to_date} 23:59:59.999' interval({interval})

以下是我們用場景1查詢出的數據進行(xing)可視化分(fen)析(xi)的示例。

場景2：查詢滿足模糊查詢條件的信號的最新值。

select name,last(v) from stgbox.global_signal where name like '%keyword%' group by name。

在(zai)(zai)修改(gai)cachelast緩存之前，查詢效(xiao)率如上。 后面在(zai)(zai)濤思數據的技(ji)術支持之下，我們將cachelast參(can)數設置(zhi)成(cheng)了3。

再執行(xing)同樣的查(cha)詢，查(cha)詢效率得到了(le)很(hen)大提升：

這兩個都是我們(men)比較典(dian)型(xing)的查詢場景，TDengine完(wan)美地(di)匹(pi)配了我們(men)對功能以及(ji)性能上的需求。

寫在最后

我(wo)們(men)目(mu)前對TDengine的使用還處于初(chu)級階段，TDengine不僅(jin)僅(jin)是(shi)時序(xu)數據(ju)(ju)庫，還可(ke)以作為消息隊列，支持數據(ju)(ju)訂閱。以后我(wo)們(men)會探索將TDengine用于更多的業務場景(jing)，以更好地服務于我(wo)們(men)的各類分析與交易執行(xing)。

關于作者：

丁博，弘(hong)源泰平量化工(gong)程師。目前負責公司交(jiao)易執行系(xi)統(tong)、交(jiao)易策略信號系(xi)統(tong)和交(jiao)易組(zu)合管理系(xi)統(tong)的研發。