小T導(dǎo)讀：在金融市場飛速發(fā)展的當(dāng)下，行情數(shù)據(jù)的處理與分析已成為金融機構(gòu)高效決策的關(guān)鍵支撐。華銳技術(shù)推出了華銳新一代歷史行情中心——D5 平臺，全面支持信創(chuàng)環(huán)境下的時序型歷史行情數(shù)據(jù)庫，具備海量數(shù)據(jù)存儲能力，顯著提升數(shù)據(jù)提取效率。相比傳統(tǒng)方案，歷史行情數(shù)據(jù)查詢性能實現(xiàn)數(shù)倍提升。本文將深入解析 TDengine 在 D5 平臺中的應(yīng)用實踐，展示其在數(shù)據(jù)建模、性能優(yōu)化、成本控制、運維簡化等方面帶來的核心優(yōu)勢。

作為分布式低時延技術(shù)的引領(lǐng)者，華銳技術(shù)致力于為金融機構(gòu)提供高性能行情解決方案。在傳統(tǒng)的行情處理中，傳統(tǒng)數(shù)據(jù)庫面臨著數(shù)據(jù)量大、處理效率低、存儲成本高等諸多挑戰(zhàn)。面對日益增長的市場數(shù)據(jù)，金融機構(gòu)亟需一種具備高并發(fā)處理、高可擴展性和低運維成本的新一代行情數(shù)據(jù)庫，以應(yīng)對更嚴(yán)苛的數(shù)據(jù)挑戰(zhàn)。

TDengine 的落地實踐

在 D5 平臺中，時序數(shù)據(jù)庫 TDengine 作為歷史行情數(shù)據(jù)庫 HDB 的核心組件，與行情持久化適配器 DPS、歷史行情服務(wù) HQS 等模塊深度協(xié)同。憑借 TDengine 的產(chǎn)品優(yōu)勢，D5 平臺顯著提升了客戶在歷史行情數(shù)據(jù)獲取方面的體驗，有力支撐了歷史查詢、行情回放、證券信息檢索等關(guān)鍵服務(wù)。

平臺架構(gòu)如下圖所示：

歷史行情建模

D5 平臺的歷史行情數(shù)據(jù)覆蓋了滬深交易所、中金所、大商所、鄭商所、上期所、上海能源所、北交所、港交所、外匯交易中心本幣市場等主要交易場所，涵蓋現(xiàn)貨、固收債券、基金、衍生品等多種品類，實現(xiàn)對國內(nèi)主要交易市場和品種的全行情支持。這類數(shù)據(jù)組織結(jié)構(gòu)復(fù)雜，若采用傳統(tǒng)關(guān)系型建模方式，管理難度高、維護成本大。

基于 TDengine“一個設(shè)備一張表”的建模理念，D5 平臺在構(gòu)建歷史行情數(shù)據(jù)模型時，按證券市場和證券代碼進行分類，將每支證券簡化為一張子表，實現(xiàn)對全市場各類證券的統(tǒng)一管理和高效存儲，大幅降低了數(shù)據(jù)建模和運維復(fù)雜度，同時顯著提升查詢性能。

如圖所示，平臺將證券市場和證券代碼抽象為 TAG，在一張超級表下統(tǒng)一管理所有市場的 K 線數(shù)據(jù)。每支證券作為子表，記錄其在每個時點的開盤價、最高價、收盤價、成交量、成交額等關(guān)鍵指標(biāo)。

借助 TDengine 的時序數(shù)據(jù)特性，平臺可通過 TAG 標(biāo)簽組織管理不同市場和品種的數(shù)據(jù)，同時通過數(shù)據(jù)分區(qū)分片機制，實現(xiàn)按市場、品種、證券維度的高效檢索。

從這一機制出發(fā)，平臺按不同 K 線周期（1 分、3 分、5 分、10 分、15 分、30 分、60 分、120 分、日、周、月、年）分別建立超級表，覆蓋各類時間粒度的查詢需求，從而實現(xiàn)全市場的 K 線極速查詢。

納秒級大規(guī)模數(shù)據(jù)存儲與檢索

以 Level-2 行情數(shù)據(jù)為例，D5 平臺借助 TDengine 強大的存儲與計算能力，構(gòu)建了納秒級快照超級表，用于存儲全市場行情數(shù)據(jù)，單表數(shù)據(jù)量超百億條。

在傳統(tǒng)關(guān)系型數(shù)據(jù)庫中，查詢一天滬深全品種的歷史快照數(shù)據(jù)往往需要長達 50 分鐘；而基于 TDengine 解決方案，最快僅需 17 秒即可完成同等查詢，效率提升超過百倍。

憑借極高的壓縮比和卓越的查詢性能，TDengine 顯著提升了歷史行情服務(wù)的存儲和訪問效率，為投研人員提供了更快速、更便捷的數(shù)據(jù)支持，加速策略開發(fā)與決策過程。

超大數(shù)據(jù)量導(dǎo)入

在項目落地過程中，華銳技術(shù)團隊也曾面臨挑戰(zhàn)。例如，項目初期在進行歷史數(shù)據(jù)遷移時，由于數(shù)據(jù)量大且格式復(fù)雜，使用 taosdump 命令導(dǎo)入 CSV 格式的歷史數(shù)據(jù)時出現(xiàn)了部分?jǐn)?shù)據(jù)導(dǎo)入速度較慢的問題。通過與 TDengine 開發(fā)團隊緊密協(xié)作，我們對數(shù)據(jù)格式進行了優(yōu)化調(diào)整，并完善了數(shù)據(jù)質(zhì)檢與回補機制，在保證導(dǎo)入性能的基礎(chǔ)上，也確保了數(shù)據(jù)的完整性和準(zhǔn)確性。

成本優(yōu)勢

在資源成本方面，得益于 TDengine 的架構(gòu)優(yōu)勢、高壓縮比和高效的資源利用能力，我們存儲 10 年規(guī)模的歷史數(shù)據(jù)，服務(wù)器數(shù)量大幅減少，硬件采購與運維成本也大幅降低。同時，TDengine 的簡單易用性也降低了開發(fā)和運維的難度，進一步提升了團隊的工作效率。

下一步規(guī)劃

華銳技術(shù)計劃進一步拓展 TDengine 在更多業(yè)務(wù)場景中的應(yīng)用，尤其是在構(gòu)建全棧信創(chuàng)體系、全面支持國產(chǎn)化方面發(fā)力。近年來，隨著國家對網(wǎng)絡(luò)與信息安全的高度重視，信創(chuàng)產(chǎn)業(yè)已上升為國家戰(zhàn)略重點，信息化發(fā)展環(huán)境也在持續(xù)演進。利用 TDengine 的高性能優(yōu)勢與國產(chǎn)化能力，華銳技術(shù)將為客戶提供更加完備的信創(chuàng)解決方案。同時，公司也在積極探索 TDengine 在金融其他領(lǐng)域的應(yīng)用潛力，推進復(fù)雜衍生指標(biāo)計算、多維度數(shù)據(jù)挖掘等行情分析功能的開發(fā)，持續(xù)豐富產(chǎn)品能力，助力客戶實現(xiàn)更全面的數(shù)據(jù)價值挖掘。

關(guān)于華銳技術(shù)

華銳技術(shù)創(chuàng)立于 2016 年，擁有世界領(lǐng)先的分布式低時延技術(shù)，是中國領(lǐng)先的分布式基礎(chǔ)技術(shù)公司和資本市場核心業(yè)務(wù)平臺提供商。公司總部位于深圳，在北京、上海、長沙設(shè)有子公司，業(yè)務(wù)網(wǎng)絡(luò)覆蓋全國。

華銳 AMD 行情產(chǎn)品部是華銳眾多產(chǎn)線之一，致力于打造公司級新一代高速行情服務(wù)平臺，提供行情極速分發(fā)、多數(shù)據(jù)中心行情傳輸、實時行情加工、歷史行情服務(wù)等綜合解決方案。平臺具備高性價比，能夠滿足公司各類系統(tǒng)對行情數(shù)據(jù)的不同需求，現(xiàn)已在多家頭部券商、銀行理財子公司及私募基金穩(wěn)定運行多年，持續(xù)為各類行情消費系統(tǒng)提供超高可用、超低時延的優(yōu)質(zhì)行情服務(wù)。

該項目需要實時展示國內(nèi)基金的凈值和收益（貨幣基金），在保證滿足折線圖展示的功能基礎(chǔ)上，還需要加入統(tǒng)計排行、分頁展示等功能，為用戶提供最全面實時的查詢服務(wù)。此前搜狐基金團隊使用的 MySQL 數(shù)據(jù)庫在面對海量數(shù)據(jù)時存在能力瓶頸，在此背景下，其決定基于 TDengine 嘗試一下全新的方案。

選型背景

在使用 TDengine 之前，我們使用的是 MySQL 數(shù)據(jù)庫。

由于所購買的數(shù)據(jù)源的基金數(shù)據(jù)都是混在一起的，包含來自國內(nèi)的2萬只基金，跨越幾十年（從九幾年至今）的數(shù)千萬行較寬的數(shù)據(jù)，如果通過 MySQL 來存儲這些數(shù)據(jù)，我們首先要把每個基金的數(shù)據(jù)分表，有一定程度的工作量，所以我們決定先全量保存這些數(shù)據(jù)在一張表中。

但這種大表會導(dǎo)致查詢的性能非常低下，為了應(yīng)對這一問題，我們通過離線查詢生成每天的基金數(shù)據(jù)圖片返回給用戶，暫未對外提供自定義查詢服務(wù)。

與此同時，經(jīng)歷了以上種種，我們也在懷疑傳統(tǒng)關(guān)系型數(shù)據(jù)庫面對海量數(shù)據(jù)的能力瓶頸。這時候，我們了解到了 TDengine ，它的核心是一款時序數(shù)據(jù)庫（Time Series Database），它“一個設(shè)備一張表”的特殊設(shè)計，與我們正在做的“一個基金一張表”的分表工作不謀而合。因此我們決定基于 TDengine 嘗試一下全新的方案。

使用經(jīng)歷

通過充分調(diào)研和測試后，我們發(fā)現(xiàn)：

由于“超級表”的存在，數(shù)據(jù)建模變得非常清晰，幾乎所有查詢都可以以“超級表”為核心用簡單的 SQL 完成。

此外，由于“自動建表”這個特色功能，我們可以無需校驗就能夠直接建表，這讓我們得以非常輕松地完成各只基金數(shù)據(jù)的拆分建表以及寫入工作。

可以說，接入 TDengine 的前期準(zhǔn)備工作十分順利。

我們使用三臺 4C 16GB 的服務(wù)器組建了 TDengine 的集群。

數(shù)據(jù)庫創(chuàng)建語句如下：

值得一提的是，基金數(shù)據(jù)是一日一條，屬于低頻次數(shù)據(jù)。對于這種數(shù)據(jù)，默認(rèn)的配置是不夠的。一開始我們的查詢性能并不快，基本都是在秒級別甚至還有更高。

通過文檔和博客以及官方團隊的支持，我們放大了 duration 和 stt_trigger 參數(shù)，這樣確保了不會產(chǎn)生過多的文件碎片影響讀寫性能，后續(xù)的查詢?nèi)勘粌?yōu)化至毫秒級別。

因此我們總結(jié)出來一點經(jīng)驗就是：不同的寫入頻率屬于不同的業(yè)務(wù)場景，最好不要使用同一個庫，而是要分庫處理比較好。

超級表建模如下：

當(dāng)前在日常使用時，業(yè)務(wù)查詢在 100 qps 的情況下，均可以實現(xiàn)毫秒級實時返回數(shù)據(jù)。

從超級表的設(shè)計特點出發(fā)，我們在超級表維度上做統(tǒng)計分析就方便多了，比如：篩選類型和日期的全量基金查詢——

select time, code, name, manager_id, manager_name, unit_net_value, pre_unit_net_value, accumulate_net_value, pre_day_rate, pre_week_rate, pre_month_rate, pre_three_month_rate, pre_half_year_rate, pre_year_rate, pre_cur_year_rate, pre_start_rate, last_time, last_unit_net_value, last_accumulate_net_value, asset_size from fund_net_value where time = #{date} and (type = '003009' or type = '003010')

又比如，查詢目前基金凈值排行和收益排行，通過簡單的 SQL 即可實現(xiàn)——

select time, code, name, manager_id, manager_name, unit_net_value, pre_unit_net_value, accumulate_net_value, pre_day_rate, pre_week_rate, pre_month_rate, pre_three_month_rate, pre_half_year_rate, pre_year_rate, pre_cur_year_rate, pre_start_rate, last_time, last_unit_net_value, last_accumulate_net_value, asset_size from fund_net_value where time = #{date} and order by ${column} ${sort} limit #{offset}, #{size}

與此同時我們搭建了 Grafana 可視化監(jiān)控體系，利用各種監(jiān)控工具和軟件來收集、存儲和分析監(jiān)控數(shù)據(jù)，并通過可視化界面提供實時的監(jiān)控圖表和警報，幫助項目相關(guān)負(fù)責(zé)人即時識別修改問題，進一步提高了服務(wù)的可靠性和穩(wěn)定性。

寫在最后

總而言之，在保證穩(wěn)定高效運行的前提下，我們已經(jīng)通過 TDengine 逐步平滑替代原有功能。考慮到國內(nèi)基金項目只是一個開始，圍繞著股票等其他項目，我們?nèi)孕枰獙@款國產(chǎn)時序庫做更多的研究與學(xué)習(xí)。

企業(yè)簡介

搜狐公司是中國著名的的綜合性互聯(lián)網(wǎng)企業(yè)，主要業(yè)務(wù)領(lǐng)域包括新媒體、通信以及移動增值服務(wù)，集成了娛樂中心、體育中心、時尚文化中心等多重角色。

作者介紹

武朋，搜狐智能平臺高級開發(fā)工程師。

小 T 導(dǎo)讀：對于青島協(xié)同創(chuàng)新金融研究院來說，一直打交道的交易記錄、價格等數(shù)據(jù)均為時序數(shù)據(jù)，在選擇數(shù)據(jù)庫（Database）時，TDengine “一個設(shè)備一張表”的設(shè)計吸引了他們的目光。目前 TDengine 已經(jīng)在其生產(chǎn)系統(tǒng)中穩(wěn)定運行了 38 周。本文總結(jié)了他們在選型、搭建等方面的所思所想，以及應(yīng)用 TDengine 之后所取得的效果。

企業(yè)簡介：

為切實服務(wù)國家經(jīng)濟、金融發(fā)展，中國金融量化科學(xué)與技術(shù)協(xié)同創(chuàng)新中心在山東青島設(shè)立了一個高端智庫，即青島協(xié)同創(chuàng)新金融研究院。依托于創(chuàng)新中心的國際頂級專家資源、在量化金融與金融科技領(lǐng)域的國際領(lǐng)先理論研究與實務(wù)技術(shù)成果，研究院致力于促進我國金融領(lǐng)域創(chuàng)新型尖端理論人才、適用性高端技術(shù)人才的教育與培養(yǎng)，提升相關(guān)領(lǐng)域在風(fēng)險管理、資產(chǎn)定價、產(chǎn)品設(shè)計等各方面的定量分析與決策技術(shù)水平，積極維護金融穩(wěn)定、促進金融發(fā)展。

開門見山地說，我們選擇 TDengine Database 的理由很簡單——“一個設(shè)備一張表”的模型很適合我們的量化分析場景。本質(zhì)上來講，交易記錄、價格等都是時序數(shù)據(jù)，其實就是“一只股票一張表”，所以十分契合。

在我們的業(yè)務(wù)場景中，TDengine 主要負(fù)責(zé)三點：一是對回測的數(shù)據(jù)支持，因為它可以輕松抗住海量數(shù)據(jù)的寫入。目前我們的數(shù)據(jù)入庫方式是使用 Python 連接器直接寫入 TDengine（6030 端口）。具體方式為：會通過券商的直連接口將他們提供的數(shù)據(jù)做一個 SQL 拼接，利用拼接 SQL 的方式，單個 SQL 寫入幾千行數(shù)據(jù)，將大批數(shù)據(jù)一次性寫入到一個表中。目前，我們每天新增數(shù)據(jù)量大概在 2000 萬行左右。

（注：股票回測是指設(shè)定了某些股票指標(biāo)組合后，基于歷史已經(jīng)發(fā)生過的真實行情數(shù)據(jù)，在歷史上某一個時間點開始，嚴(yán)格按照設(shè)定的組合進行選股，并模擬真實金融市場交易的規(guī)則進行模型買入、模型賣出，得出一個時間段內(nèi)的盈利率、最大回撤率等數(shù)據(jù)。）

二是基于以上數(shù)據(jù)進行的回測數(shù)據(jù)分析。

三是部分盤中策略的數(shù)據(jù)預(yù)加載。

但因為這塊有每秒幾萬次的查詢用在高頻業(yè)務(wù)上，所以暫時還沒有嘗試應(yīng)用 TDengine，目前大部分盤中業(yè)務(wù)使用的還是 Redis。據(jù)社區(qū)工作人員表示，未來的 TDengine 3.0 版本將會支持自定義時間范圍的緩存，屆時或許可以幫到我們。

除了上述主要的使用場景之外，TDengine 還幫助我們實現(xiàn)了部分深度學(xué)習(xí)模型的數(shù)據(jù)訓(xùn)練和測試。

具體落地與實際效果

在目前的業(yè)務(wù)中，我們選用了三臺 8 核 16G 服務(wù)器，以此搭建了三副本的集群。

這里大家需要注意，三節(jié)點并不代表三副本，也并不代表你的數(shù)據(jù)庫已經(jīng)具備了高可用性。數(shù)據(jù)庫的高可用是在 "create database xxxx replica 1/2/3" 的過程中指定的，但是如果你忘記了也沒關(guān)系，后期可以通過 "alter database xxxx replica 1/2/3" 來動態(tài)地進行調(diào)整。TDengine 會自動復(fù)制出一批分片（Vnode），并均勻地分布在各個節(jié)點之上，效果如下”show 庫名.vgroups”所示。

（注：如果數(shù)據(jù)量很大，在數(shù)據(jù)同步的過程中由于網(wǎng)絡(luò)波動導(dǎo)致數(shù)據(jù)文件復(fù)制中斷，也可以手動復(fù)制 Vnode 目錄下的文件到指定節(jié)點再啟動。）

根據(jù)不同類型的業(yè)務(wù)，我們創(chuàng)建了 7 張不同的超級表，子表數(shù)量為 33076 張，目前我們導(dǎo)入的數(shù)據(jù)總量已經(jīng)達到了 46 億之多，其中最大的一張超級表達到了 26 億行，實際磁盤占用大概在 130GB 左右。表的列數(shù)如下圖”columns”所示，數(shù)據(jù)類型以 Float 為主。

下面我再列舉一些典型的查詢場景：

select first(open), max(high), min(low), last(close), sum(volume), sum(amount) from 'bar_1m_SH600519' where trade_time >= '2021-12-25 09:30:00' and trade_time <= '2021-12-31 15:00:00' interval(30m) fill(null)

下圖為用 1 分鐘的 bar 數(shù)據(jù)合成 30 分鐘的 bar 數(shù)據(jù)，查詢出的茅臺股票在一段時間內(nèi)的開盤價、最高價、最低價、收盤價。

select code,name,trade_time,trade_date,open,high,low,price,pre_price,volume,amount,ask_price1,ask_volume1,ask_price2,ask_volume2,ask_price3,ask_volume3,ask_price4,ask_volume4,ask_price5,ask_volume5,bid_price1,bid_volume1,bid_price2,bid_volume2,bid_price3,bid_volume3,bid_price4,bid_volume4,bid_price5,bid_volume5 from tick_stock where trade_time >='2022-03-18 09:30:00' and trade_time <='2022-03-18 09:30:02' and code in ('002429.SZ', '000006.SZ')

下圖為查詢某兩支股票在某個時間范圍內(nèi)的 tick 數(shù)據(jù)。

期待 TDengine 3.0 版本

除了數(shù)據(jù)庫本身的功能之外，我們也注意到 TDengine 的周邊生態(tài)也在不斷完善。在 2.4 版本發(fā)布之后，它實現(xiàn)了很多功能更新，其中包括一款使用了監(jiān)控數(shù)據(jù)庫（log 庫） + Grafana 對 TDengine 進行監(jiān)控的解決方案——TDinsight。在此之前，我們使用的一直是我自己編寫的一款監(jiān)控程序，但 TDinsight 使最終的展示效果更加清晰直觀，數(shù)據(jù)庫的運行狀態(tài)也更加一目了然。

于是，我們立刻著手更新了 TDengine 2.4 版本，并且部署了 TDinsight。

以下就是 Grafana 展示界面的一部分，可以看到，在當(dāng)前并發(fā)寫入的規(guī)模下（每秒 1 萬-1.5 萬行），CPU 資源占用率只有 1.88%，內(nèi)存占用只有 2G。盡管目前我們使用的是三臺 8 核 16G 的機器，但卻可以在相當(dāng)長的時間內(nèi)不用再擔(dān)心硬件資源問題了。

不知不覺中，TDengine 在生產(chǎn)系統(tǒng)中已經(jīng)跑了 38 周了，整體來說各方面性能都不錯。偶爾遇到的一些使用問題，也在 TDengine 社區(qū)得到了及時的幫助和解答，運行至今我們發(fā)現(xiàn)了兩個小 Bug，官方都很快響應(yīng)處理了。盡管還有一些場景在當(dāng)前的 2.0 版本還并不能完全適配，但 3.0 版本出爐后就可以解決了。

最后祝 TDengine Database 越來越好吧，期待 3.0 版本的發(fā)布讓它成為時序數(shù)據(jù)庫里的 Oracle。

作者：

William (QQ: 392667) 16 年股票投資經(jīng)驗，15年軟件開發(fā)經(jīng)驗，負(fù)責(zé)青島金融研究院量化系統(tǒng)整體架構(gòu)，以及相關(guān)高頻交易模型的開發(fā)。

小 T 導(dǎo)讀：同心源（三亞）基金管理有限公司是一家致力于采取科學(xué)方法，在二級市場進行投資的私募公司。公司的團隊成員均來自于國內(nèi)外優(yōu)秀大學(xué)，創(chuàng)始人具有計算機博士學(xué)位，有多年的算法研究、軟件系統(tǒng)開發(fā)的經(jīng)驗。

從我司的業(yè)務(wù)模式出發(fā)，業(yè)務(wù)人員主要通過數(shù)據(jù)挖掘和自動模式識別這兩種方式來發(fā)現(xiàn)市場的交易規(guī)律。因此，我們的工作場景是基于大量的金融數(shù)據(jù)之上的，主要包括如下幾類：

1. 國內(nèi)期貨市場的實時高頻數(shù)據(jù)，逐筆數(shù)據(jù)等
2. 國內(nèi)期貨市場的歷史高頻數(shù)據(jù)，逐筆數(shù)據(jù)
3. 國內(nèi)股票市場的高頻數(shù)據(jù)，逐筆數(shù)據(jù)等
4. 國內(nèi)股票市場的歷史高頻數(shù)據(jù)，逐筆數(shù)據(jù)
5. 依據(jù)以上數(shù)據(jù)產(chǎn)生的更大量級衍生數(shù)據(jù)

經(jīng)過多年發(fā)展，股票市場數(shù)據(jù)量十分龐大，隨著每日新數(shù)據(jù)的清洗寫入，總量變得更加水漲船高。對于十幾TB的數(shù)據(jù)量，單是進行存儲已經(jīng)不易，如果還要對數(shù)據(jù)進行查詢下載等操作，更是難上加難。這些問題橫亙眼前，也讓我們對市面上的主流數(shù)據(jù)庫逐漸喪失信心。

后來，經(jīng)過專業(yè)人士的引薦，我們嘗試了TDengine Database，沒想到它輕輕松松地就適配了我們的當(dāng)前業(yè)務(wù)。

具體實踐與落地效果

選好數(shù)據(jù)庫之后我們馬上開始了搭建，并選擇了當(dāng)時最新的2.1.3.2的版本部署落地，不同數(shù)據(jù)種類對應(yīng)的數(shù)據(jù)庫分別如下：

1）股票高頻數(shù)據(jù)庫，包括股票市場的歷史數(shù)據(jù)+每日新增數(shù)據(jù)：

這類數(shù)據(jù)每日通過Python連接器的方式，在收盤后批量導(dǎo)入再做分析。其中每個表代表一個股票，共85列，以Float數(shù)據(jù)為主，共32311張。

根據(jù)上述表結(jié)構(gòu)計算，當(dāng)前情況每行大概有408字節(jié)的長度，然后我們用腳本對所有表進行了行數(shù)查詢，大概是320億行。

以上述數(shù)據(jù)為基礎(chǔ)對入庫的總數(shù)據(jù)量進行下估算，粗略計算為408*320億行，大概12TB左右，后面經(jīng)過統(tǒng)計最終實際占用磁盤空間卻只有2T左右，這令我們十分震驚——壓縮率高達16.7%。

眾所周知，Float類型的數(shù)據(jù)壓縮一直是數(shù)據(jù)庫領(lǐng)域的一個難題，尤其是對于行式存儲的數(shù)據(jù)庫更是困難，高興之余也非常感謝TDengine的列式存儲，幫助我們完美解決了這個棘手的問題。

之后從官方人員處我們得知，在后續(xù)版本中，TDengine還對浮點類型數(shù)據(jù)做了更進一步的算法優(yōu)化，壓縮率還能獲得大幅提升。只不過目前需要手動編譯，具體操作方式可以聯(lián)系官方人員。

2）期貨庫：

期貨庫是部署在另一個服務(wù)器上的，有如下三個：期貨高頻數(shù)據(jù)庫、期貨X頻率數(shù)據(jù)庫、期貨Y頻率數(shù)據(jù)庫。他們分別代表著國內(nèi)全部期貨的高頻數(shù)據(jù)和不同時間頻率的聚合數(shù)據(jù)：

1. 期貨高頻數(shù)據(jù)庫：實時記錄交易所發(fā)送的tick數(shù)據(jù)
2. 期貨X頻率數(shù)據(jù)庫：根據(jù)時間周期X設(shè)定，記錄聚合后的數(shù)據(jù)
3. 期貨Y頻率數(shù)據(jù)庫：根據(jù)時間周期Y設(shè)定，記錄聚合后的數(shù)據(jù)

以上三個庫分別包含3351、5315、5208張子表，與股票庫一樣，它們同樣包括長期的歷史數(shù)據(jù)以及實時數(shù)據(jù)。

具體的表結(jié)構(gòu)如下所示：

在查詢方面，由于當(dāng)前我們的查詢只是針對單表進行，因此邏輯比較簡單，代碼如下：

此外，由于期貨不存在連續(xù)多年的行情，所以對于長期的數(shù)據(jù)展示，我們選擇用多段的每X個月數(shù)據(jù)進行拼接，查詢效率非?？臁＠纾涸赥Dengine客戶端服務(wù)器使用Python從服務(wù)端拉取連續(xù)兩個月的期貨行情數(shù)據(jù)，耗時僅需0.16秒。

下圖為因子1在期貨菜粕上的收益曲線，從這張圖中我們也可以看出，一些其他常用的函數(shù)比如max、last，基于TDengine的緩存等技術(shù)也都實現(xiàn)了毫秒級返回數(shù)據(jù)。

從“兩點問題”到深入合作

細心的讀者可能也留意到了文章中的兩個小問題：

• 為什么我們在估算原數(shù)據(jù)量時，是通過腳本來統(tǒng)計所有子表行數(shù)，再將其乘以單行字節(jié)，而不是直接通過TDengine的“超級表”？
• 又為什么在文章開頭的數(shù)據(jù)分類描述中，1-4條都在后文中都看到了實際對應(yīng)的數(shù)據(jù)庫，但是唯獨沒有出現(xiàn)第5條——依據(jù)以上數(shù)據(jù)產(chǎn)生的大量衍生數(shù)據(jù)？

其實是這樣，由于項目初期沒有多表聚合查詢的需求，外加為了降低數(shù)據(jù)遷移的復(fù)雜度，因此在環(huán)境搭建初期時我們并沒有選擇超級表。

但是隨著業(yè)務(wù)的不斷完善，我們將會需要更大量的數(shù)據(jù)來做更復(fù)雜的分析，這也就出現(xiàn)了第5條的數(shù)據(jù)種類——依據(jù)以上數(shù)據(jù)產(chǎn)生的更大量級衍生數(shù)據(jù)。所以說，這部分?jǐn)?shù)據(jù)將來源于我們后面的待上線業(yè)務(wù)中。

屆時，我們將會更深入地用到TDengine Database的其他核心特性，如超級表、眾多計算函數(shù)等等。但僅就當(dāng)下而言，TDengine強大的存儲能力和快速查詢已經(jīng)非常令我們驚喜，也讓我們對未來更加深入的合作充滿期待。

關(guān)于作者：

劉健，北京航空航天大學(xué)模式識別專業(yè)碩士學(xué)歷，曾經(jīng)供職于中國航天科技集團從事軟件研發(fā)工作。2014年與朋友一起創(chuàng)業(yè)從事外匯、期貨、股票ETF的自動交易至今。著重致力于通過數(shù)據(jù)挖掘、自動模式識別等方式在國內(nèi)二級市場中進行自動量化交易。

公司簡介

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

場景簡介+核心訴求

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

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

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

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

TDengine Database具體落地

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

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

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

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

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

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

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

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

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

寫入性能

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

資源消耗

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

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

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

查詢性能

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

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

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

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

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

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

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

寫在最后

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

關(guān)于作者：

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

浙商銀行很早就開始全面推進數(shù)字化轉(zhuǎn)型，2010 年浙商銀行上線電子銀行服務(wù)、手機銀行業(yè)務(wù)，2017 年上線首個區(qū)塊鏈服務(wù)平臺，同年發(fā)布了直銷銀行品牌。2018 年浙商銀行國標(biāo) A 級數(shù)據(jù)中心啟用，并在 2020 年成立易企銀金融科技子公司。

業(yè)務(wù)背景

浙商銀行微服務(wù)可視化治理平臺是基于Java體系自研的微服務(wù)治理監(jiān)控平臺，為行內(nèi)基于統(tǒng)一的微服務(wù)框架開發(fā)的應(yīng)用提供全面、實時的微服務(wù)治理監(jiān)控功能，能夠有效提升云環(huán)境下的微服務(wù)可視化程度和服務(wù)管理控制的便捷度，減少服務(wù)故障發(fā)現(xiàn)時間，提升故障定位效率，輔助應(yīng)用程序優(yōu)化。在這樣的業(yè)務(wù)場景中，數(shù)據(jù)量大、監(jiān)控指標(biāo)繁雜成了我們的主要挑戰(zhàn)。

通過分析監(jiān)控數(shù)據(jù)，我們發(fā)現(xiàn)它有以下特點：

• 數(shù)據(jù)高寫入、低查詢、不修改
  • 對于按時間順序插入的監(jiān)控數(shù)據(jù)，會涉及到少量的查詢，沒有修改數(shù)據(jù)的業(yè)務(wù)場景。
• 無需事務(wù)支持
  • 如果數(shù)據(jù)模型設(shè)計妥當(dāng)，無需使用事務(wù)處理。
• 各監(jiān)控指標(biāo)之間相互獨立，無需聯(lián)合查詢
• 數(shù)據(jù)時效性較強，超過一定時間的數(shù)據(jù)參考價值很小

核心訴求

針對這樣的場景，我們需要一款能高效處理時序數(shù)據(jù)的工具。在各種因素的影響下，我們有如下幾點需求：

• 開源可控，且最好是國產(chǎn)軟件，且能支持國產(chǎn)化芯片
• 功能穩(wěn)定
• 社區(qū)活躍：開發(fā)者社區(qū)人員多，問答、討論頻繁且有穩(wěn)定的開發(fā)團隊支持
• 部署成本低：盡可能少的服務(wù)節(jié)點，運維成本低，占用 CPU、內(nèi)存資源較少
• 性能強大：支持萬條數(shù)據(jù)秒級插入

時序數(shù)據(jù)庫選型

在明確了核心訴求之后，我們調(diào)研了幾款典型的時序數(shù)據(jù)庫（Time-Series Database）產(chǎn)品，包括 Apache Druid、InfluxDB 和 TDengine。 具體對比如下：

• Apache Druid：Druid 是 Apache 基金會旗下的一款高性能的實時分析數(shù)據(jù)庫，支持時間序列數(shù)據(jù)。功能強大、可自愈、自平衡、易操作、可進行有效的預(yù)聚合和預(yù)計算。不過對于時間跨度較大的查詢不夠靈活，而且架構(gòu)較為復(fù)雜，需要的計算資源多。
• InfluxDB：InfluxDB 是由 InfluxData 公司開發(fā)的一款開源的時序數(shù)據(jù)庫，在業(yè)界非常流行。功能強大，部署簡單，使用方便。不過集群功能沒有開源。
• TDengine：能滿足我們的核心訴求，相關(guān)測試表明其性能優(yōu)于 InfluxDB，而且開源了核心的集群功能。簡單快捷、性能強大；支持 JDBC 接口，可以使我們應(yīng)用快速接入使用。還有一點非常重要，因為 TDengine 的核心研發(fā)團隊在國內(nèi)，很方便直接交流。

整體對比之后，我們決定嘗試 TDengine Database。

技術(shù)架構(gòu)

可視化服務(wù)治理平臺的一個核心功能就是實時的監(jiān)控功能，監(jiān)控數(shù)據(jù)通過微服務(wù)框架自帶的埋點發(fā)送到數(shù)據(jù)接收模塊，經(jīng)過數(shù)據(jù)處理和格式轉(zhuǎn)換之后發(fā)送到 Apache Kafka。數(shù)據(jù)處理模塊會接收 Kafka 中的各類監(jiān)控數(shù)據(jù)，根據(jù)不同的數(shù)據(jù)類型進行加工計算，存儲到 Elasticsearch 和 TDengine 中。用戶通過前端與后端的服務(wù)層對監(jiān)控數(shù)據(jù)進行查詢分析。

目前為止，存儲于 TDengine 中的數(shù)據(jù)主要為時序類數(shù)據(jù)，如CPU、內(nèi)存使用率等系統(tǒng)運行數(shù)據(jù)，微服務(wù)調(diào)用、分布式鎖、數(shù)據(jù)庫操作處理時間，業(yè)務(wù)線程池、連接池等各類指標(biāo)數(shù)據(jù)。

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

目前收集的監(jiān)控數(shù)據(jù)類型如下：

• JVMGC 相關(guān)指標(biāo)
• JVMThread 相關(guān)指標(biāo)
• JVMMemory 相關(guān)指標(biāo)
• 系統(tǒng)負(fù)載相關(guān)指標(biāo)
• 數(shù)據(jù)庫連接池監(jiān)控數(shù)據(jù)
• Transaction 調(diào)用監(jiān)控數(shù)據(jù)
• Dubbo 線程池監(jiān)控數(shù)據(jù)

我們針對每一個監(jiān)控類型都采用了超級表建表，以 JVMGC 為例，建表語句為：

 create stable JVMGC (happentime timestamp, jvmUsedMemory bigint, jvmUsedMemoryyPercentage double, nonHeapMemoryUsed double, oldGenUsed bigint, oldGenUsedPercentage double , directBufferUsed bigint) tags (application NCHAR(300), host NCHAR(500), ip NCHAR(50)) 

與此同時，對每一個監(jiān)控節(jié)點都建立一張子表，這樣處理的好處在于：

• 相同指標(biāo)在進行多表查詢時，可以利用超級表在一個 SQL 語句中完成查詢
• 超級表可以實現(xiàn)表與表之間的數(shù)據(jù)聚合
• 對于單節(jié)點的監(jiān)控數(shù)據(jù)，查詢只需要訪問單一子表即可

使用體驗

目前微服務(wù)可視化服務(wù)治理平臺對并發(fā)要求較高，但是 TDengine 可以很好地滿足需求，插入/查詢平均耗時均在 10ms 以內(nèi)。

TDengine 的開源版本小而精致，開發(fā)測試人員可以自己搭建私有的 TDengine 集群進行測試，無須擔(dān)心影響他人，非常方便。

TDengine 的社區(qū)非?；钴S，遇到問題在 GitHub 上提 issue，或直接在官方的微信交流群里討論，都可以快速得到響應(yīng)。

總結(jié)

TDengine Database很好地滿足了我們的需求，性能和穩(wěn)定性都非常出色，同時極大降低了部署和運維成本。

TDengine 的支持團隊也非常積極熱心，能夠快速解決我們遇到的大部分問題，為我們免除了后顧之憂。

作為一款為物聯(lián)網(wǎng)場景設(shè)計的時序數(shù)據(jù)庫，TDengine 以存儲效率高、性能強大、功能穩(wěn)定等特點在傳統(tǒng)互聯(lián)網(wǎng)應(yīng)用架構(gòu)中同樣有著相當(dāng)出色的發(fā)揮，超級表的設(shè)計省去了不少聯(lián)表查詢邏輯，大大簡化了業(yè)務(wù)層的開發(fā)工作。接下來，我們也期待在行內(nèi)挖掘出更多 TDengine 的應(yīng)用場景。

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

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

項目背景與問題

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

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

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

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

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

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

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

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

技術(shù)選型

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

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

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

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

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

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

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

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

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

通用特性:

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

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

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

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

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

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

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

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

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

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

落地實施

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

實施難點如下。

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

• 查詢問題：查詢單點問題。TDengine原生HTTP查詢是直接查詢特定服務(wù)端完成的。這個在生產(chǎn)環(huán)境是存在風(fēng)險的。首先，所有的查詢都集中在一臺服務(wù)端，容易導(dǎo)致單臺機器過載；另外，無法保證查詢服務(wù)的高可用?；谝陨蟽牲c，我們在TDengine集群使用過程中，在應(yīng)用使用創(chuàng)建鏈接的時候會配置多臺Http的接口來解決單點問題。

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

改造效果

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

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

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

TDengine問題解決

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

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

總結(jié)

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

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

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

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

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

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