作者：丁博

公司簡介

深圳市弘源泰平資產(chǎn)管理有限公司組建于2016年，團(tuán)隊(duì)核心成員來自于知名高校，有豐富的資產(chǎn)配置與策略構(gòu)建的實(shí)踐經(jīng)驗(yàn)。弘源泰平以套戥交易絕對收益型配置工具為起點(diǎn)，致力于為用戶提供流動(dòng)性好、費(fèi)率公允的資產(chǎn)配置工具。產(chǎn)品線全面、豐富，涵蓋股、債、商品等各大類資產(chǎn)，通脹、趨勢等各類因子。

場景簡介+核心訴求

我們的量化交易系統(tǒng)每天要接收大量的行情數(shù)據(jù)，也要基于行情產(chǎn)生大量的決策信號(hào)。這些數(shù)據(jù)都需要及時(shí)存下來，供盤中和盤后使用。

傳統(tǒng)存放行情數(shù)據(jù)的方式有文件系統(tǒng)、關(guān)系型數(shù)據(jù)庫或者文檔數(shù)據(jù)庫。我們嘗試了MySQL和知名的時(shí)序數(shù)據(jù)庫InfluxDB，但是性能都沒有達(dá)到預(yù)期。分別遇到了如下問題：

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

最后，我們改用TDengine Database徹底解決了實(shí)時(shí)寫入大量數(shù)據(jù)點(diǎn)和快速查詢的問題。

TDengine Database具體落地

對于策略研究員而言，歷史行情和信號(hào)是交易策略研究的重要素材。下面以行情數(shù)據(jù)和策略信號(hào)數(shù)據(jù)為案例予以介紹。

數(shù)據(jù)建模

首先，將行情數(shù)據(jù)和信號(hào)數(shù)據(jù)分別存儲(chǔ)。在TDengine Database中分別創(chuàng)建了一個(gè)行情數(shù)據(jù)庫和信號(hào)數(shù)據(jù)庫。

雖然是時(shí)序數(shù)據(jù)庫，但是TDengine使用了關(guān)系型數(shù)據(jù)庫的模型，建庫，建表，使用SQL，十分便于傳統(tǒng)關(guān)系型數(shù)據(jù)庫的用戶入手。并且，他們還很有創(chuàng)意地設(shè)計(jì)了超級(jí)表的概念，與我們的場景十分契合。

因?yàn)樗行星閿?shù)據(jù)結(jié)構(gòu)相同，行情庫中只需要一個(gè)超級(jí)表，下面每個(gè)工具（衍生品基金等）對應(yīng)一個(gè)子表。比如CU2101表示2021年1月份到期的銅期貨交易合約。在合約到期之前，都會(huì)有行情數(shù)據(jù)寫入。下面重點(diǎn)介紹策略信號(hào)數(shù)據(jù)庫。

信號(hào)庫有兩張超級(jí)表，分別對應(yīng)合約級(jí)別信號(hào)和策略級(jí)別信號(hào)，每個(gè)交易信號(hào)對應(yīng)一張子表，當(dāng)前共有 40,000多張表，表結(jié)構(gòu)分別如下所示：

下面是信號(hào)庫執(zhí)行show tables的截圖：

數(shù)據(jù)庫配置以及寫入

我們選用的TDengine版本是2.2.0.0，由于單機(jī)版尚無壓力，目前還不需要集群。此外，機(jī)器有40核，而TDengine的每一個(gè)vnode又是擁有獨(dú)立運(yùn)行線程的工作單元。所以，根據(jù)文章《這幾個(gè)神秘參數(shù)，教你TDengine集群的正確使用方式》，我調(diào)整了minTablesPerVnode、tableIncStepPerVnode和maxVgroupsPerDb參數(shù)，讓vnode的數(shù)量恰好等于CPU核數(shù)，讓每個(gè)核獨(dú)立運(yùn)行一個(gè)線程，實(shí)現(xiàn)了數(shù)據(jù)的合理化分布，以爭取達(dá)到最佳性能。

寫入性能

當(dāng)前，我們大概每秒寫入3萬行數(shù)據(jù)。單節(jié)點(diǎn)TDengine可以十分輕松地實(shí)現(xiàn)這個(gè)級(jí)別數(shù)據(jù)量的寫入。同時(shí)，消耗服務(wù)器資源又比InfluxDB與MySQL小的多。因此，即便未來業(yè)務(wù)擴(kuò)大，我們也不需要擔(dān)心額外的硬件成本。

資源消耗

我們當(dāng)前的服務(wù)器配置如下：64G內(nèi)存+40核 1.8GHz CPU+機(jī)械硬盤。

在業(yè)務(wù)運(yùn)行期間，taosd的%CPU只有4%上下浮動(dòng)，進(jìn)程使用的物理內(nèi)存百分比為11.2%。雖然內(nèi)存占用稍多，但這是由于我們的vnode配置的比較多，每個(gè)vnode都有自己固定的內(nèi)存緩沖區(qū)。因此，后續(xù)即便是繼續(xù)大量增加新表或者加大寫入量，內(nèi)存占用也不會(huì)有明顯的浮動(dòng)了。

截至目前，通過TDengine錄入的兩個(gè)信號(hào)表已經(jīng)寫入了82億條數(shù)據(jù)，原數(shù)據(jù)大概為92GB，實(shí)際占用存儲(chǔ)空間為20G左右，壓縮率高達(dá)23%，如果是整型數(shù)據(jù)應(yīng)該還會(huì)更高。

查詢性能

除了寫入與存儲(chǔ)，使用TDengine做日常查詢的速度也十分優(yōu)秀，即便是對于幾十億級(jí)別的大表，也是毫秒級(jí)響應(yīng)。我們來看兩個(gè)場景。

場景1：查詢特定策略信號(hào)下一段時(shí)間的均值。

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查詢出的數(shù)據(jù)進(jìn)行可視化分析的示例。

場景2：查詢滿足模糊查詢條件的信號(hào)的最新值。

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

在修改cachelast緩存之前，查詢效率如上。 后面在濤思數(shù)據(jù)的技術(shù)支持之下，我們將cachelast參數(shù)設(shè)置成了3。

再執(zhí)行同樣的查詢，查詢效率得到了很大提升：

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

寫在最后

我們目前對TDengine的使用還處于初級(jí)階段，TDengine不僅僅是時(shí)序數(shù)據(jù)庫，還可以作為消息隊(duì)列，支持?jǐn)?shù)據(jù)訂閱。以后我們會(huì)探索將TDengine用于更多的業(yè)務(wù)場景，以更好地服務(wù)于我們的各類分析與交易執(zhí)行。

關(guān)于作者：

丁博，弘源泰平量化工程師。目前負(fù)責(zé)公司交易執(zhí)行系統(tǒng)、交易策略信號(hào)系統(tǒng)和交易組合管理系統(tǒng)的研發(fā)。