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

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

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

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

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

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

• 性能強，可以支持千萬級別并發(fā)寫入、10 萬級的并發(fā)讀取
• 高可用，可以橫向擴展，不存在單點故障
• 功能強，提供四則運算、最大、最小、平均、最新等聚合計算功能

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

一、基于 TDengine 的建表模型

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

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

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

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

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

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

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

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

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

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

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

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

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

三、寫在最后

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

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

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

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