前言

同花順(shun)每(mei)天(tian)需要接收(shou)海量(liang)交易所(suo)行(xing)情數(shu)據(ju)(ju)，確保行(xing)情數(shu)據(ju)(ju)的(de)(de)數(shu)據(ju)(ju)準確。但由于該部(bu)分數(shu)據(ju)(ju)過于龐大，而(er)且(qie)使(shi)用(yong)場景頗多，每(mei)天(tian)會產生(sheng)很多的(de)(de)加工數(shu)據(ju)(ju)，而(er)組合(he)管理(PMS)還會使(shi)用(yong)到(dao)歷史行(xing)情數(shu)據(ju)(ju)。之(zhi)前雖然采用(yong)了(le)Postgres+LevelDB作為(wei)數(shu)據(ju)(ju)的(de)(de)存(cun)儲方案，但仍然有不(bu)少痛點，所(suo)以必須對(dui)存(cun)儲方案進行(xing)改造。

通過對ClickHouse、InfluxDB、TDengine等時序數據存儲(chu)方(fang)案(an)的(de)調研，最終我們(men)選擇(ze)了TDengine Database。大數據(ju)監控平臺(tai)采(cai)用TDengine Database后，在穩定性、查詢性能等(deng)方(fang)面都有較(jiao)大的(de)提升。

項目背景與問題

同花順私募之(zhi)家組(zu)合管(guan)理是一(yi)(yi)個集(ji)多(duo)資(zi)產(chan)管(guan)理、實時監控(kong)、績(ji)效分(fen)析、風險分(fen)析、輿情分(fen)控(kong)、報表輸出等功能于一(yi)(yi)體的(de)智能投資(zi)組(zu)合管(guan)理平臺。為券商、基(ji)金、私募等機(ji)構(gou)客戶提供(gong)實時準確的(de)投研(yan)服(fu)務。

數據(ju)層面主要(yao)依賴實時(shi)數據(ju)及(ji)歷史日級別數據(ju)，為所支(zhi)持的股票、基金、債券(quan)、美股、港股、期權、期貨(huo)資產類別的監控和分析提(ti)供支(zhi)持。

其中(zhong)，實時數(shu)據主要(yao)用于資產(chan)監控，由(you)于使(shi)用場(chang)景(jing)會對(dui)數(shu)百個不同的(de)(de)標的(de)(de)進(jin)行資產(chan)監控，數(shu)據刷新頻率在1秒左右。因此(ci)，整個系統對(dui)實時數(shu)據的(de)(de)讀寫性能及(ji)延時有(you)著比較高的(de)(de)要(yao)求(qiu)。

此外，歷(li)史日級別(bie)數(shu)據主(zhu)要(yao)用于投資組合(he)的各種分析(xi)。歷(li)史分析(xi)所涉(she)及的標(biao)的數(shu)量，相較(jiao)實時資產(chan)監控更多，在(zai)時間上的跨度會(hui)長至10數(shu)年(nian)。此外在(zai)輸出分析(xi)報告時，還(huan)會(hui)疊加多種分析(xi)指標(biao)和分析(xi)模型。在(zai)整(zheng)個分析(xi)過程中，涉(she)及巨量的數(shu)據集。這對歷(li)史數(shu)據庫的讀寫性(xing)能又提出了更高的要(yao)求。

由(you)上述(shu)架構圖可(ke)以(yi)看到，該服務(wu)內需要大量的基礎(chu)數據支撐(cheng)，像實時行情、歷史(shi)行情。

針(zhen)對歷(li)史(shi)行(xing)情(qing)數(shu)據(ju)(ju)(ju)(ju)支撐，涉及多(duo)個(ge)證(zheng)券(quan)品種的(de)數(shu)據(ju)(ju)(ju)(ju)，包(bao)(bao)括(kuo)股票、債(zhai)券(quan)、基(ji)金、港股、美股、期貨、期權(quan)。數(shu)據(ju)(ju)(ju)(ju)跨度周期從(cong)數(shu)天到數(shu)年(nian)不(bu)等(deng)。頁(ye)面(mian)返回的(de)數(shu)據(ju)(ju)(ju)(ju)是計算結果(guo)，而(er)(er)計算依賴的(de)數(shu)據(ju)(ju)(ju)(ju)是業務(wu)層數(shu)據(ju)(ju)(ju)(ju)和大量歷(li)史(shi)行(xing)情(qing)數(shu)據(ju)(ju)(ju)(ju)。這個(ge)計算過(guo)程包(bao)(bao)含了歷(li)史(shi)行(xing)情(qing)數(shu)據(ju)(ju)(ju)(ju)請(qing)求。尤其是在(zai)展示(shi)結果(guo)包(bao)(bao)含多(duo)證(zheng)券(quan)標的(de)和長周期的(de)情(qing)況下，產生一(yi)個(ge)分析報(bao)告可(ke)能達到 5s，而(er)(er)行(xing)情(qing)獲取耗時占比達到80%以上。而(er)(er)且(qie)，輸(shu)出報(bao)告服務(wu)面(mian)臨(lin)并(bing)發情(qing)況，這種情(qing)況帶來的(de)擁堵(du)會進一(yi)步(bu)惡(e)化用戶的(de)使用體驗。

通(tong)過(guo)對改造前的(de)數據(ju)流(liu)進行分(fen)析(xi)，當前行情獲取(qu)模塊(kuai)的(de)分(fen)析(xi)， 當前存在以下2個(ge)需(xu)要解(jie)決的(de)問(wen)題：

• 依賴多，穩定性較差：PMS作為多品種的投后分析服務, 需要使用到各種日線數據、當天實時行情數據、當天分鐘數據等，在數據獲取方面需要依賴Http以及Postgres、LevelDB等數據庫。過于多的數據獲取鏈路會導致平臺可靠性降低，同時依賴于其他各個服務，導致查詢問題過于復雜。
• 性能不能滿足需求： PMS作為多品種投后分析，在算法分析層面需要大量的行情獲取，而且對行情獲取的性能也有較大的要求，當前所有行情會占據大量分析的性能。

技術選型

為(wei)解決上述問題，我們有(you)(you)必要對現有(you)(you)行(xing)(xing)情模塊進行(xing)(xing)升級改(gai)造(zao)。在數據庫選型方面，我們對如下數據庫做了預研和分(fen)析：

• ClickHouse：運維成本太高，擴展過于復雜，使用的資源較多。
• InfluxDB： 可以高性能地查詢與存儲時序型數據，被廣泛應用于存儲系統的監控數據、IoT行業的實時數據等場景；但是集群功能沒有開源。
• TDengine：性能、成本、運維難度都滿足，支持橫向擴展，且支持高可用。

通過綜(zong)合對比(bi)，我們初步選定TDengine Database作為(wei)行情模塊的數據庫。

主要由于行情數據是綁定時間戳的形式，所以時序數據庫（Time-Series Database）更適用于這個業務場景。而且在同等數據集和硬件環境下，濤思官方的測試結果顯示，TDengine的寫入速度遠高于InfluxDB。同時TDengine支持多種數據接口，包含C/C++、Java、Python、Go和RESTful等。

數(shu)據(ju)接入(ru)過程需要進行如下操作：

• 數據清洗，剔除格式不對的數據；
• 由于歷史數據過于雜亂，采取腳本生成csv形式并直接導入，后續增量數據由Python實現腳本導入數據。

數據庫建模以及應用場景

TDengine Database在(zai)接入(ru)數(shu)據前需要根據數(shu)據的特性設計(ji)schema，以達到最好(hao)的性能表現。

同(tong)花(hua)順(shun)行情根據時間頻(pin)度的不(bu)同(tong)，數據特性(xing)分別如下(xia)。

通用特性:

• 數據格式固定，自帶時間戳；
• 數據極少需要更新或刪除；
• 數據標簽列不多，而且比較固定；
• 單條數據數據量較小，字段較少。

tick快照(zhao)數據(ju)特性如下:

• 每天數據量大，超過2000W；
• 需保留近幾年數據。

daily數據(ju)特性如下:

• 子表很多，約20W張表；
• 每天數據20W；
• 需保留近30年數據。

根據上述特點，我們構建了如下(xia)的數據模型。

按照(zhao)TDengine建議的數據(ju)(ju)(ju)模型(xing)，將每個(ge)特性的數據(ju)(ju)(ju)單(dan)獨創建數據(ju)(ju)(ju)庫，根(gen)據(ju)(ju)(ju)不(bu)同特性數據(ju)(ju)(ju)設置不(bu)同的參數，在各個(ge)數據(ju)(ju)(ju)庫內根(gen)據(ju)(ju)(ju)品種去創建超級表，例(li)如(ru)股票、指數、債(zhai)券、基金等，結合我們的數據(ju)(ju)(ju)特點和(he)使用(yong)場景，創建數據(ju)(ju)(ju)模型(xing)如(ru)下：

• 以品種類型作為超級表，方便對同一類型的數據進行聚合分析計算；
• 標的本身包括標的信息，直接將標簽信息作為超級表的標簽列，每個品種作為子表。

庫結構如下：

超級表結構:

落地實施

組合管理主要(yao)是需要(yao)可以穩定(ding)高效地(di)獲(huo)取到數據，所以在實施的過程中(zhong)需要(yao)考慮查詢的性(xing)能(neng)、線(xian)上(shang)數據的更新以及運維(wei)情(qing)況。

實施難點如下。

• 數據寫入：由于歷史行情數據會存在大量的歷史數據，不是只接收當前新增的數據，這對歷史數據的遷移有很大的挑戰。當前TDengine數據庫對于現有數據的導入，通過insert語句達到批量更新，會導致歷史數據遷移耗時很大。為了解決該問題，我們在本地建立緩存，將現有csv文件修改為可執行導入的形式，直接通過csv導入，大大提升了寫入速度。在這個過程中，我們還發現了一個問題：通過csv導入的時候，如果采用自動創建表的方式，會在幾個版本內出現崩潰。通過詢問官方，他們不建議在導入csv的時候創建表，后來我們就拆解為先創建表結構再進行csv導入，問題得到了解決。

• 查詢問題：查詢單點問題。TDengine原生HTTP查詢是直接查詢特定服務端完成的。這個在生產環境是存在風險的。首先，所有的查詢都集中在一臺服務端，容易導致單臺機器過載；另外，無法保證查詢服務的高可用。基于以上兩點，我們在TDengine集群使用過程中，在應用使用創建鏈接的時候會配置多臺Http的接口來解決單點問題。

• 容量規劃：數據類型、數據規模對TDengine的性能影響比較大，每個場景最好根據自己的特性進行容量規劃，影響因素包括表數量、數據長度、副本數和表活躍度等。根據這些因素調整配置參數，確保最佳性能，例如blocks、caches和ratioOfQueryCores等。根據與濤思數據工程師的溝通，我們確定了TDengine的容量規劃計算模型。TDengine容量規劃的難點在于內存的規劃。

改造效果

完成(cheng)改造(zao)后，線上(shang)的(de)行情獲取性(xing)能可以(yi)達到預期，目前運(yun)行穩(wen)定。

• 改造后性能對比情況，可以看到性能提升明顯。

• 改造后穩定性對比情況：改造前調用數據情況共40W次，共出現異常0.01%的異常，改造后出現異常降低至0.001%。

TDengine問題解決

在使用TDengine的過程中，我們遇到了一些小問題。比如在通過Restful接口使用TDengine的時候，獲取數據超過10240行會有限制。經過溝通，我們了解到在啟動服務端時，參數restfulRowLimit 可以控制(zhi)返回結果集的(de)最大條數。

其他一(yi)些在使用過(guo)程中不(bu)清楚的地方，在濤思數(shu)據的物聯(lian)網大數(shu)據微信交流群都能很快(kuai)得(de)到反饋和(he)解答。一(yi)些小bug也可以通過(guo)版(ban)本(ben)升級解決。

總結

目(mu)前從大數據監控這個場景看(kan)，TDengine Database在(zai)(zai)成(cheng)(cheng)本、性(xing)能和使用便利性(xing)方面都(dou)有(you)非常大的優勢，尤其是在(zai)(zai)節省成(cheng)(cheng)本方面給我們帶來了很大驚喜(xi)。

在預研和項目落地(di)過程中，濤思數(shu)據的工(gong)程師提供了專業、及時的幫助，在此表示感(gan)謝(xie)。

希望TDengine能夠不(bu)斷(duan)提升性(xing)能和穩(wen)定性(xing)，開發新特性(xing)，我(wo)們也會(hui)根據自身需(xu)求進行二次開發，向(xiang)社區貢獻代碼。祝TDengine越(yue)來(lai)越(yue)好。對(dui)于(yu)TDengine，我(wo)們也有一些(xie)期待(dai)改進的功能點：

• 支持更加豐富的SQL語句；
• 灰度平滑升級；
• 可實現自定義聚合方法；
• 更快的數據遷移。

后續我們(men)也將在(zai)同花順的更(geng)多場景中嘗試應用(yong)TDengine，包(bao)括：

• tick、minute行情數據的遷移以及線上應用；
• 采取自定義聚合方法實現分鐘行情、日線行情的聚合計算；
• 當天實時行情的數據的管理。