前言

同花順每天需要接收海量交易所行情數(shù)據(jù)，確保行情數(shù)據(jù)的數(shù)據(jù)準(zhǔn)確。但由于該部分?jǐn)?shù)據(jù)過(guò)于龐大，而且使用場(chǎng)景頗多，每天會(huì)產(chǎn)生很多的加工數(shù)據(jù)，而組合管理(PMS)還會(huì)使用到歷史行情數(shù)據(jù)。之前雖然采用了Postgres+LevelDB作為數(shù)據(jù)的存儲(chǔ)方案，但仍然有不少痛點(diǎn)，所以必須對(duì)存儲(chǔ)方案進(jìn)行改造。

通過(guò)對(duì)ClickHouse、InfluxDB、TDengine等時(shí)序數(shù)據(jù)存儲(chǔ)方案的調(diào)研，最終我們選擇了TDengine Database。大數(shù)據(jù)監(jiān)控平臺(tái)采用TDengine Database后，在穩(wěn)定性、查詢(xún)性能等方面都有較大的提升。

項(xiàng)目背景與問(wèn)題

同花順?biāo)侥贾医M合管理是一個(gè)集多資產(chǎn)管理、實(shí)時(shí)監(jiān)控、績(jī)效分析、風(fēng)險(xiǎn)分析、輿情分控、報(bào)表輸出等功能于一體的智能投資組合管理平臺(tái)。為券商、基金、私募等機(jī)構(gòu)客戶(hù)提供實(shí)時(shí)準(zhǔn)確的投研服務(wù)。

數(shù)據(jù)層面主要依賴(lài)實(shí)時(shí)數(shù)據(jù)及歷史日級(jí)別數(shù)據(jù)，為所支持的股票、基金、債券、美股、港股、期權(quán)、期貨資產(chǎn)類(lèi)別的監(jiān)控和分析提供支持。

其中，實(shí)時(shí)數(shù)據(jù)主要用于資產(chǎn)監(jiān)控，由于使用場(chǎng)景會(huì)對(duì)數(shù)百個(gè)不同的標(biāo)的進(jìn)行資產(chǎn)監(jiān)控，數(shù)據(jù)刷新頻率在1秒左右。因此，整個(gè)系統(tǒng)對(duì)實(shí)時(shí)數(shù)據(jù)的讀寫(xiě)性能及延時(shí)有著比較高的要求。

此外，歷史日級(jí)別數(shù)據(jù)主要用于投資組合的各種分析。歷史分析所涉及的標(biāo)的數(shù)量，相較實(shí)時(shí)資產(chǎn)監(jiān)控更多，在時(shí)間上的跨度會(huì)長(zhǎng)至10數(shù)年。此外在輸出分析報(bào)告時(shí)，還會(huì)疊加多種分析指標(biāo)和分析模型。在整個(gè)分析過(guò)程中，涉及巨量的數(shù)據(jù)集。這對(duì)歷史數(shù)據(jù)庫(kù)的讀寫(xiě)性能又提出了更高的要求。

由上述架構(gòu)圖可以看到，該服務(wù)內(nèi)需要大量的基礎(chǔ)數(shù)據(jù)支撐，像實(shí)時(shí)行情、歷史行情。

針對(duì)歷史行情數(shù)據(jù)支撐，涉及多個(gè)證券品種的數(shù)據(jù)，包括股票、債券、基金、港股、美股、期貨、期權(quán)。數(shù)據(jù)跨度周期從數(shù)天到數(shù)年不等。頁(yè)面返回的數(shù)據(jù)是計(jì)算結(jié)果，而計(jì)算依賴(lài)的數(shù)據(jù)是業(yè)務(wù)層數(shù)據(jù)和大量歷史行情數(shù)據(jù)。這個(gè)計(jì)算過(guò)程包含了歷史行情數(shù)據(jù)請(qǐng)求。尤其是在展示結(jié)果包含多證券標(biāo)的和長(zhǎng)周期的情況下，產(chǎn)生一個(gè)分析報(bào)告可能達(dá)到 5s，而行情獲取耗時(shí)占比達(dá)到80%以上。而且，輸出報(bào)告服務(wù)面臨并發(fā)情況，這種情況帶來(lái)的擁堵會(huì)進(jìn)一步惡化用戶(hù)的使用體驗(yàn)。

通過(guò)對(duì)改造前的數(shù)據(jù)流進(jìn)行分析，當(dāng)前行情獲取模塊的分析， 當(dāng)前存在以下2個(gè)需要解決的問(wèn)題：

• 依賴(lài)多，穩(wěn)定性較差：PMS作為多品種的投后分析服務(wù), 需要使用到各種日線(xiàn)數(shù)據(jù)、當(dāng)天實(shí)時(shí)行情數(shù)據(jù)、當(dāng)天分鐘數(shù)據(jù)等，在數(shù)據(jù)獲取方面需要依賴(lài)Http以及Postgres、LevelDB等數(shù)據(jù)庫(kù)。過(guò)于多的數(shù)據(jù)獲取鏈路會(huì)導(dǎo)致平臺(tái)可靠性降低，同時(shí)依賴(lài)于其他各個(gè)服務(wù)，導(dǎo)致查詢(xún)問(wèn)題過(guò)于復(fù)雜。
• 性能不能滿(mǎn)足需求： PMS作為多品種投后分析，在算法分析層面需要大量的行情獲取，而且對(duì)行情獲取的性能也有較大的要求，當(dāng)前所有行情會(huì)占據(jù)大量分析的性能。

技術(shù)選型

為解決上述問(wèn)題，我們有必要對(duì)現(xiàn)有行情模塊進(jìn)行升級(jí)改造。在數(shù)據(jù)庫(kù)選型方面，我們對(duì)如下數(shù)據(jù)庫(kù)做了預(yù)研和分析：

• ClickHouse：運(yùn)維成本太高，擴(kuò)展過(guò)于復(fù)雜，使用的資源較多。
• InfluxDB： 可以高性能地查詢(xún)與存儲(chǔ)時(shí)序型數(shù)據(jù)，被廣泛應(yīng)用于存儲(chǔ)系統(tǒng)的監(jiān)控?cái)?shù)據(jù)、IoT行業(yè)的實(shí)時(shí)數(shù)據(jù)等場(chǎng)景；但是集群功能沒(méi)有開(kāi)源。
• TDengine：性能、成本、運(yùn)維難度都滿(mǎn)足，支持橫向擴(kuò)展，且支持高可用。

通過(guò)綜合對(duì)比，我們初步選定TDengine Database作為行情模塊的數(shù)據(jù)庫(kù)。

主要由于行情數(shù)據(jù)是綁定時(shí)間戳的形式，所以時(shí)序數(shù)據(jù)庫(kù)（Time-Series Database）更適用于這個(gè)業(yè)務(wù)場(chǎng)景。而且在同等數(shù)據(jù)集和硬件環(huán)境下，濤思官方的測(cè)試結(jié)果顯示，TDengine的寫(xiě)入速度遠(yuǎn)高于InfluxDB。同時(shí)TDengine支持多種數(shù)據(jù)接口，包含C/C++、Java、Python、Go和RESTful等。

數(shù)據(jù)接入過(guò)程需要進(jìn)行如下操作：

• 數(shù)據(jù)清洗，剔除格式不對(duì)的數(shù)據(jù)；
• 由于歷史數(shù)據(jù)過(guò)于雜亂，采取腳本生成csv形式并直接導(dǎo)入，后續(xù)增量數(shù)據(jù)由Python實(shí)現(xiàn)腳本導(dǎo)入數(shù)據(jù)。

數(shù)據(jù)庫(kù)建模以及應(yīng)用場(chǎng)景

TDengine Database在接入數(shù)據(jù)前需要根據(jù)數(shù)據(jù)的特性設(shè)計(jì)schema，以達(dá)到最好的性能表現(xiàn)。

同花順行情根據(jù)時(shí)間頻度的不同，數(shù)據(jù)特性分別如下。

通用特性:

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

tick快照數(shù)據(jù)特性如下:

• 每天數(shù)據(jù)量大，超過(guò)2000W；
• 需保留近幾年數(shù)據(jù)。

daily數(shù)據(jù)特性如下:

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

根據(jù)上述特點(diǎn)，我們構(gòu)建了如下的數(shù)據(jù)模型。

按照TDengine建議的數(shù)據(jù)模型，將每個(gè)特性的數(shù)據(jù)單獨(dú)創(chuàng)建數(shù)據(jù)庫(kù)，根據(jù)不同特性數(shù)據(jù)設(shè)置不同的參數(shù)，在各個(gè)數(shù)據(jù)庫(kù)內(nèi)根據(jù)品種去創(chuàng)建超級(jí)表，例如股票、指數(shù)、債券、基金等，結(jié)合我們的數(shù)據(jù)特點(diǎn)和使用場(chǎng)景，創(chuàng)建數(shù)據(jù)模型如下：

• 以品種類(lèi)型作為超級(jí)表，方便對(duì)同一類(lèi)型的數(shù)據(jù)進(jìn)行聚合分析計(jì)算；
• 標(biāo)的本身包括標(biāo)的信息，直接將標(biāo)簽信息作為超級(jí)表的標(biāo)簽列，每個(gè)品種作為子表。

庫(kù)結(jié)構(gòu)如下：

超級(jí)表結(jié)構(gòu):

落地實(shí)施

組合管理主要是需要可以穩(wěn)定高效地獲取到數(shù)據(jù)，所以在實(shí)施的過(guò)程中需要考慮查詢(xún)的性能、線(xiàn)上數(shù)據(jù)的更新以及運(yùn)維情況。

實(shí)施難點(diǎn)如下。

• 數(shù)據(jù)寫(xiě)入：由于歷史行情數(shù)據(jù)會(huì)存在大量的歷史數(shù)據(jù)，不是只接收當(dāng)前新增的數(shù)據(jù)，這對(duì)歷史數(shù)據(jù)的遷移有很大的挑戰(zhàn)。當(dāng)前TDengine數(shù)據(jù)庫(kù)對(duì)于現(xiàn)有數(shù)據(jù)的導(dǎo)入，通過(guò)insert語(yǔ)句達(dá)到批量更新，會(huì)導(dǎo)致歷史數(shù)據(jù)遷移耗時(shí)很大。為了解決該問(wèn)題，我們?cè)诒镜亟⒕彺妫瑢F(xiàn)有csv文件修改為可執(zhí)行導(dǎo)入的形式，直接通過(guò)csv導(dǎo)入，大大提升了寫(xiě)入速度。在這個(gè)過(guò)程中，我們還發(fā)現(xiàn)了一個(gè)問(wèn)題：通過(guò)csv導(dǎo)入的時(shí)候，如果采用自動(dòng)創(chuàng)建表的方式，會(huì)在幾個(gè)版本內(nèi)出現(xiàn)崩潰。通過(guò)詢(xún)問(wèn)官方，他們不建議在導(dǎo)入csv的時(shí)候創(chuàng)建表，后來(lái)我們就拆解為先創(chuàng)建表結(jié)構(gòu)再進(jìn)行csv導(dǎo)入，問(wèn)題得到了解決。

• 查詢(xún)問(wèn)題：查詢(xún)單點(diǎn)問(wèn)題。TDengine原生HTTP查詢(xún)是直接查詢(xún)特定服務(wù)端完成的。這個(gè)在生產(chǎn)環(huán)境是存在風(fēng)險(xiǎn)的。首先，所有的查詢(xún)都集中在一臺(tái)服務(wù)端，容易導(dǎo)致單臺(tái)機(jī)器過(guò)載；另外，無(wú)法保證查詢(xún)服務(wù)的高可用。基于以上兩點(diǎn)，我們?cè)赥Dengine集群使用過(guò)程中，在應(yīng)用使用創(chuàng)建鏈接的時(shí)候會(huì)配置多臺(tái)Http的接口來(lái)解決單點(diǎn)問(wèn)題。

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

改造效果

完成改造后，線(xiàn)上的行情獲取性能可以達(dá)到預(yù)期，目前運(yùn)行穩(wěn)定。

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

• 改造后穩(wěn)定性對(duì)比情況：改造前調(diào)用數(shù)據(jù)情況共40W次，共出現(xiàn)異常0.01%的異常，改造后出現(xiàn)異常降低至0.001%。

TDengine問(wèn)題解決

在使用TDengine的過(guò)程中，我們遇到了一些小問(wèn)題。比如在通過(guò)Restful接口使用TDengine的時(shí)候，獲取數(shù)據(jù)超過(guò)10240行會(huì)有限制。經(jīng)過(guò)溝通，我們了解到在啟動(dòng)服務(wù)端時(shí)，參數(shù)restfulRowLimit 可以控制返回結(jié)果集的最大條數(shù)。

其他一些在使用過(guò)程中不清楚的地方，在濤思數(shù)據(jù)的物聯(lián)網(wǎng)大數(shù)據(jù)微信交流群都能很快得到反饋和解答。一些小bug也可以通過(guò)版本升級(jí)解決。

總結(jié)

目前從大數(shù)據(jù)監(jiān)控這個(gè)場(chǎng)景看，TDengine Database在成本、性能和使用便利性方面都有非常大的優(yōu)勢(shì)，尤其是在節(jié)省成本方面給我們帶來(lái)了很大驚喜。

在預(yù)研和項(xiàng)目落地過(guò)程中，濤思數(shù)據(jù)的工程師提供了專(zhuān)業(yè)、及時(shí)的幫助，在此表示感謝。

希望TDengine能夠不斷提升性能和穩(wěn)定性，開(kāi)發(fā)新特性，我們也會(huì)根據(jù)自身需求進(jìn)行二次開(kāi)發(fā)，向社區(qū)貢獻(xiàn)代碼。祝TDengine越來(lái)越好。對(duì)于TDengine，我們也有一些期待改進(jìn)的功能點(diǎn)：

• 支持更加豐富的SQL語(yǔ)句；
• 灰度平滑升級(jí)；
• 可實(shí)現(xiàn)自定義聚合方法；
• 更快的數(shù)據(jù)遷移。

后續(xù)我們也將在同花順的更多場(chǎng)景中嘗試應(yīng)用TDengine，包括：

• tick、minute行情數(shù)據(jù)的遷移以及線(xiàn)上應(yīng)用；
• 采取自定義聚合方法實(shí)現(xiàn)分鐘行情、日線(xiàn)行情的聚合計(jì)算；
• 當(dāng)天實(shí)時(shí)行情的數(shù)據(jù)的管理。