小 T 導(dǎo)讀：在對(duì)多款時(shí)序數(shù)據(jù)庫(kù)（Time-Series Database）進(jìn)行了選型測(cè)試后，同程旅行自研的“夜鷹監(jiān)控”搭載 TDengine 代替了現(xiàn)有存儲(chǔ)設(shè)備，減少運(yùn)維成本。本文分享了他們對(duì)建表模型的方案選擇思路，接入 TDengine 后所遇到問(wèn)題的解決經(jīng)驗(yàn)以及落地效果展示。

同程旅行有一套自研的基礎(chǔ)監(jiān)控系統(tǒng)“夜鷹監(jiān)控”。目前夜鷹監(jiān)控使用情況為百萬(wàn)級(jí)別 endpoint、億級(jí) metric、每秒 200 萬(wàn)并發(fā)寫(xiě)入以及 2 萬(wàn)并發(fā)查詢(xún)。其存儲(chǔ)組件基于 RRD 存儲(chǔ)，RRD 存儲(chǔ)雖然擁有很好的性能，卻也存在著一些問(wèn)題——基于內(nèi)存緩存定期寫(xiě)入 RRD，在機(jī)器重啟后會(huì)丟失部分?jǐn)?shù)據(jù)。

出現(xiàn)這一問(wèn)題的原因是 RRD 寫(xiě)入為單點(diǎn)寫(xiě)入，當(dāng)機(jī)器故障后無(wú)法實(shí)現(xiàn)自動(dòng)切換，這一存儲(chǔ)特性也導(dǎo)致無(wú)法展示更長(zhǎng)時(shí)間的原始數(shù)據(jù)。 針對(duì)此問(wèn)題，夜鷹監(jiān)控做了很多高可用設(shè)計(jì)，但還是很難滿(mǎn)足業(yè)務(wù)的需求，之后又進(jìn)行了如下改造：

• 引入了 ES 存儲(chǔ)，為夜鷹監(jiān)控提供 7 天內(nèi)原始數(shù)據(jù)的查詢(xún)，目前部署的 2 套存儲(chǔ)。
• RRD 提供給 API 調(diào)用，調(diào)用量在幾萬(wàn)級(jí) TPS。
• ES 提供給夜鷹面板使用，保存 7 天原始數(shù)據(jù)，調(diào)用量在幾百 QPS。

但隨著基礎(chǔ)監(jiān)控系統(tǒng)接入指標(biāo)的增長(zhǎng)，目前 2 套存儲(chǔ)系統(tǒng)在資源消耗方面一直在增長(zhǎng)，同時(shí)業(yè)務(wù)對(duì)監(jiān)控也提出了更多的聚合計(jì)算功能要求?；诖耍覀冃枰獙ふ乙粋€(gè)新的時(shí)序數(shù)據(jù)庫(kù)來(lái)代替現(xiàn)有的存儲(chǔ)系統(tǒng)，以減少運(yùn)維成本。

在進(jìn)行時(shí)序數(shù)據(jù)庫(kù)選型時(shí)，實(shí)際需求主要有以下三點(diǎn)：

• 性能強(qiáng)，可以支持千萬(wàn)級(jí)別并發(fā)寫(xiě)入、10 萬(wàn)級(jí)的并發(fā)讀取
• 高可用，可以橫向擴(kuò)展，不存在單點(diǎn)故障
• 功能強(qiáng)，提供四則運(yùn)算、最大、最小、平均、最新等聚合計(jì)算功能

在對(duì)比了 InfluxDB、TDengine、Prometheus、Druid、ClickHouse 等多款市面流行的 Database 產(chǎn)品后，最終 TDengine 從中脫穎而出，能滿(mǎn)足我們所有的選型要求。

一、基于 TDengine 的建表模型

夜鷹監(jiān)控系統(tǒng)不僅存在系統(tǒng)指標(biāo)數(shù)據(jù)，同時(shí)也會(huì)存在業(yè)務(wù)指標(biāo)數(shù)據(jù)。前者諸如 CPU、內(nèi)存、磁盤(pán)、網(wǎng)絡(luò)一類(lèi)，這類(lèi)信息是可以預(yù)測(cè)的指標(biāo)，其指標(biāo)名是固定的，總數(shù)約為 2000 萬(wàn)個(gè)。后者則會(huì)通過(guò)夜鷹監(jiān)控的 API 上傳業(yè)務(wù)自身定義的指標(biāo)，指標(biāo)名是無(wú)法預(yù)測(cè)的，其特點(diǎn)是并發(fā)量不大卻存在長(zhǎng)尾效應(yīng)，隨著時(shí)間累積，一年可以達(dá)到一億級(jí)。

而 TDengine 在創(chuàng)建表之前需要先規(guī)劃表的結(jié)構(gòu)，從上面的數(shù)據(jù)存儲(chǔ)背景來(lái)看，如果要將海量的指標(biāo)數(shù)量直接一次性扁平化全部創(chuàng)建，則會(huì)造成性能的下降。通過(guò)和 TDengine 技術(shù)支持人員溝通，他們給出了兩個(gè)建表方案：

其一，將系統(tǒng)類(lèi)基礎(chǔ)指標(biāo)聚合到一個(gè)超級(jí)表，一張表存放一個(gè)節(jié)點(diǎn)，多個(gè)指標(biāo)一次性寫(xiě)入。這個(gè)方式的好處是表的數(shù)量可以降低到千萬(wàn)級(jí)別，但因?yàn)橐国棻O(jiān)控的數(shù)據(jù)是單條上傳的，很難做到一個(gè)表里面全部指標(biāo)集齊再寫(xiě)入。并且不同的指標(biāo)上傳頻率不同，如果再根據(jù)頻率建不同的超級(jí)表，運(yùn)維管理成本會(huì)非常高。

其二，將不同的指標(biāo)建成一個(gè)一個(gè)的子表，5 千萬(wàn)個(gè)左右的指標(biāo)匯聚成一個(gè)集群，分多個(gè)集群接入。這種方式的好處是表結(jié)構(gòu)簡(jiǎn)單，但運(yùn)維管理多個(gè)集群會(huì)很麻煩。不過(guò)我們也了解到濤思數(shù)據(jù)明年會(huì)發(fā)布 TDengine 3.0 版本，能支持超過(guò)上億張表，那么這一方案就可以很好的進(jìn)行數(shù)據(jù)遷移了。

最終，我們選擇了第二個(gè)方案。同時(shí)為了減少搭建集群的數(shù)量，準(zhǔn)備寫(xiě)個(gè)程序定期清理掉過(guò)期的子表。目前夜鷹監(jiān)控的超級(jí)表結(jié)構(gòu)如下。

夜鷹監(jiān)控接入 TDengine 后，架構(gòu)圖如下。

二、接入 TDengine 之后的效果展示

在進(jìn)行數(shù)據(jù)遷移時(shí)，我們先是將夜鷹監(jiān)控?cái)?shù)據(jù)轉(zhuǎn)移到 Kafka 中，之后通過(guò)消費(fèi)轉(zhuǎn)換程序?qū)?Kafka 的數(shù)據(jù)格式轉(zhuǎn)為了 TDengine SQL 格式。 這個(gè)過(guò)程還遇到了如下三個(gè)小問(wèn)題，解決思路放在這里給大家參考：

• 連接方式問(wèn)題。剛開(kāi)始我們使用的是 go-connector sdk 的方式接入 TDengine，跑起來(lái)后發(fā)現(xiàn)，go-connector 依賴(lài)于 taos client 包以及 taos.cfg 配置文件里面的鏈接配置，同時(shí)因?yàn)?FQDN 的設(shè)置難以使用 VIP 負(fù)載均衡的配置方式。我們考慮到后面消費(fèi)程序會(huì)部署到容器中，不宜產(chǎn)生過(guò)多的依賴(lài)，因此還是放棄了 go-connector 的連接方式，改為了 HTTP RESTful 的連接方式。 

• Kafka 消費(fèi)數(shù)量問(wèn)題。由于夜鷹監(jiān)控上傳到 Kafka 里面的數(shù)據(jù)是一條一個(gè)指標(biāo)，再加上 200 萬(wàn)左右的并發(fā)，連接數(shù)很快就耗光了。通過(guò)和 TDengine 技術(shù)支持人員溝通，了解到可以改造成批量 SQL 的方式寫(xiě)入，最佳的實(shí)踐效果是 400-600K 單個(gè) SQL 的長(zhǎng)度。經(jīng)過(guò)計(jì)算，我們上傳的指標(biāo)條數(shù)大概為 5000 條左右，大小為 500K 。

• 讀取速度問(wèn)題。因?yàn)槊看我鹊较M(fèi) 5000 條數(shù)據(jù)，才會(huì)觸發(fā)一次寫(xiě)入，這種情況也導(dǎo)致讀取速度較慢。TDengine 技術(shù)支持人員再次給出了解決方案——使用 Taos 自己實(shí)現(xiàn)的 Queue，代碼地址為:github.com/taosdata/go-demo-kafka/pkg/queue ，有需要的同學(xué)可以自行獲取。

聚焦到實(shí)際效果上，TDengine 數(shù)據(jù)寫(xiě)入性能很強(qiáng)。原本我們的單套存儲(chǔ)系統(tǒng)需要 10 多臺(tái)高配機(jī)器，IO 平均 30% 最高 100% 的情況下才能寫(xiě)完數(shù)據(jù)；現(xiàn)在只需要 7 臺(tái)機(jī)器，并且 CPU 消耗在 10% 左右、磁盤(pán) IO 消耗在 1% 左右，這點(diǎn)非常的棒!

同時(shí)，其數(shù)據(jù)讀取接入過(guò)程也很順利。使用 RESTful 接口后，結(jié)合 TDengine 自帶的強(qiáng)大聚合函數(shù)功能，很容易就能計(jì)算出想要的結(jié)果。

三、寫(xiě)在最后

在我們的項(xiàng)目中，TDengine Database 展現(xiàn)出了超強(qiáng)的性能和多元化的功能，不僅具備高效的寫(xiě)入性能、壓縮率，其聚合函數(shù)功能也非常齊全，支持 Sum/Max/Min/Avg/Top/Last/First/Diff/Percentile 等多種函數(shù)，在架構(gòu)上也設(shè)計(jì)的很合理，可以實(shí)現(xiàn)很好地橫向擴(kuò)展。同時(shí)，其自身監(jiān)控也做的很不錯(cuò)，打造了基于 Grafana 的 TDengine 零依賴(lài)監(jiān)控解決方案 TDinsight，在監(jiān)控系統(tǒng)自身狀態(tài)上展現(xiàn)出了很好的效果。

未來(lái)，我們也希望與 TDengine 展開(kāi)更深層次的合作，在此也為其提出一些小小的建議，助力 TDengine 往更好的方向發(fā)展：

• 官方文檔還不夠完善，新版的功能在文檔中沒(méi)有體現(xiàn)，很多用法缺少代碼示例，個(gè)人理解起來(lái)比較晦澀難懂
• 社區(qū)用戶(hù)經(jīng)驗(yàn)傳遞不是很多， 遇到一些問(wèn)題時(shí)，Google 比較難以找到社區(qū)的解決案例

在接入的過(guò)程中，非常感謝 TDengine 的技術(shù)支持人員的全力支持。雖然目前 TDengine 還處于發(fā)展初期，也存在一些問(wèn)題需要優(yōu)化，不過(guò)其優(yōu)異的性能還是給了我們一個(gè)大大的驚喜！總而言之，TDengine 是個(gè)非常不錯(cuò)的存儲(chǔ)系統(tǒng)，相信在陶老師的帶領(lǐng)下會(huì)發(fā)展的越來(lái)越好！