OpenTSDB 應用遷移到 TDengine 的最佳實踐

作(zuo)為一個(ge)分布式(shi)、可伸縮、基(ji)于(yu) HBase 的(de)分布式(shi)時序數據庫系統，得(de)益于(yu)其先發優勢，OpenTSDB 被(bei) DevOps 領域的(de)人員引入并廣泛地應(ying)用在了(le)運(yun)維(wei)監(jian)控領域。但最近(jin)幾年，隨著云計算(suan)、微服務(wu)、容(rong)器(qi)化(hua)等(deng)新技術(shu)快速落地發展(zhan)，企業級(ji)服務(wu)種類變(bian)得(de)越(yue)來(lai)(lai)越(yue)多，架構也越(yue)來(lai)(lai)越(yue)復雜(za)，應(ying)用運(yun)行(xing)基(ji)礎環境日益多樣化(hua)，給系統和運(yun)行(xing)監(jian)控帶來(lai)(lai)的(de)壓(ya)力也越(yue)來(lai)(lai)越(yue)大(da)。從這一現狀(zhuang)出發，使用 OpenTSDB 作(zuo)為 DevOps 的(de)監(jian)控后端存(cun)儲(chu)，越(yue)來(lai)(lai)越(yue)受困于(yu)其性能(neng)問(wen)題以(yi)及遲緩的(de)功能(neng)升級(ji)，以(yi)及由此而衍生出來(lai)(lai)的(de)應(ying)用部署成本上升和運(yun)行(xing)效率降低等(deng)問(wen)題，這些(xie)問(wen)題隨著系統規模的(de)擴大(da)日益嚴重(zhong)。

在(zai)這一(yi)背景下，為(wei)滿(man)足高速增長的(de)物(wu)聯網大數(shu)據(ju)(ju)市(shi)場和(he)技術需求，在(zai)吸(xi)取眾多(duo)傳統關(guan)系型數(shu)據(ju)(ju)庫、NoSQL 數(shu)據(ju)(ju)庫、流(liu)計算引擎(qing)、消息隊列等軟件(jian)的(de)優點之后，濤思數(shu)據(ju)(ju)自主開(kai)發出創新型大數(shu)據(ju)(ju)處理產品 TDengine。在(zai)時序大數(shu)據(ju)(ju)處理上(shang)，TDengine 有著自己(ji)獨特的(de)優勢。就 OpenTSDB 當前遇到(dao)的(de)問題來(lai)說，TDengine 能夠(gou)有效解決(jue)。

相對于 OpenTSDB，TDengine 具有如下顯(xian)著特點：

• 數據寫入和查詢的性能遠超 OpenTSDB；
• 針對時序數據的高效壓縮機制，壓縮后在磁盤上的存儲空間不到 1/5；
• 安裝部署非常簡單，單一安裝包完成安裝部署，不依賴其他的第三方軟件，整個安裝部署過程秒級搞定;
• 提供的內建函數覆蓋 OpenTSDB 支持的全部查詢函數，還支持更多的時序數據查詢函數、標量函數及聚合函數，支持多種時間窗口聚合、連接查詢、表達式運算、多種分組聚合、用戶定義排序、以及用戶定義函數等高級查詢功能。采用類 SQL 的語法規則，更加簡單易學，基本上沒有學習成本。
• 支持多達 128 個標簽，標簽總長度可達到 16 KB；
• 除 HTTP 之外，還提供 Java、Python、C、Rust、Go 等多種語言的接口，支持 JDBC 等多種企業級標準連接器協議。

如果我(wo)們將(jiang)原本運(yun)行在 OpenTSDB 上的應用遷移到 TDengine 上，不僅可以有(you)效地(di)降低計算(suan)和存(cun)儲資(zi)源的占用、減(jian)少部署服務(wu)器的規(gui)模，還能夠極(ji)大(da)減(jian)少運(yun)行維護的成(cheng)本的輸出，讓運(yun)維管(guan)理工作更簡(jian)單、更輕松，大(da)幅降低總擁(yong)有(you)成(cheng)本。與(yu) OpenTSDB 一樣(yang)，TDengine 也已經進行了(le)開(kai)源，不同的是，除了(le)單機版(ban)，后者還實現(xian)了(le)集群版(ban)開(kai)源，被廠商綁定的顧(gu)慮一掃而空。

在下(xia)文中我們將就“使用最典(dian)型(xing)并廣泛(fan)應用的運維監控(kong)（DevOps）場景(jing)”來說明，如何在不編碼(ma)的情況(kuang)下(xia)將 OpenTSDB 的應用快速、安全、可靠地(di)遷移到 TDengine 之(zhi)上(shang)。后續的章節會做更深度(du)的介紹，以便(bian)于進行非 DevOps 場景(jing)的遷移。

DevOps 應用快速遷移

1、典型應用場景

一(yi)個典(dian)型的(de) DevOps 應用場(chang)景的(de)系統整體的(de)架構如(ru)下圖(tu)（圖(tu)1） 所示。

在該應用(yong)場景中(zhong)，包含了(le)部署在應用(yong)環境中(zhong)負責收集機器(qi)度量（Metrics）、網絡度量（Metrics）以及(ji)應用(yong)度量（Metrics）的(de)(de) Agent 工具、匯聚 agent 收集信息的(de)(de)數(shu)(shu)據(ju)收集器(qi)，數(shu)(shu)據(ju)持久化存儲(chu)和管理的(de)(de)系統(tong)以及(ji)監控數(shu)(shu)據(ju)可視(shi)化工具（例如(ru)：Grafana 等）。

其中，部(bu)署在應用節點的 Agents 負(fu)責向 collectd/Statsd 提供不同來源的運行指標，collectd/StatsD則負(fu)責將匯聚(ju)的數(shu)據推送(song)到 OpenTSDB 集群系統，然后使用可(ke)視化(hua)看(kan)板 Grafana 將數(shu)據可(ke)視化(hua)呈現出(chu)來。

2、遷移服務

• TDengine 安裝部署

首先是 TDengine 的安裝，從官網上下載 TDengine 最新穩定版，解壓縮后運行 install.sh 進行安裝。各種安裝包的使用幫助請參見博客《TDengine 多種安裝包的安裝和卸載》。

注意，安裝完成以(yi)后，不要(yao)立(li)即啟動 taosd 服務(wu)，在正(zheng)確配置完成參(can)數以(yi)后再啟動。

• 調整數據收集器配置

在(zai) TDengine 2.3 版本(ben)中，我(wo)們發布了 taosAdapter ，taosAdapter 是一(yi)個(ge)無(wu)狀態、可快(kuai)速彈性伸縮的(de)組件，它可以兼容(rong) Influxdb 的(de) Line Protocol 和 OpenTSDB 的(de) telnet/JSON 寫入協(xie)議規范，提供了豐富的(de)數(shu)據接入能力，有效(xiao)的(de)節省用戶遷移(yi)成本(ben)，降低用戶應(ying)用遷移(yi)的(de)難度。

用戶可以根據需求(qiu)彈(dan)性(xing)部署(shu) taosAdapter 實例，結合場(chang)景的需要，快速提(ti)升數據寫(xie)入的吞吐量，為(wei)不同應用場(chang)景下的數據寫(xie)入提(ti)供保障。

通過 taosAdapter，用戶可以將 collectd 和 StatsD 收集的數據直接推送到 TDengine ，實現應用場景的無縫遷移，非常的輕松便捷。taosAdapter 還支持Telegraf、Icinga、TCollector 、node_exporter 的數據接入，使用詳情參考taosAdapter。

如果使用 collectd，修改其默認位置 /etc/collectd/collectd.conf 的(de)配置(zhi)文件(jian)為(wei)指向 taosAdapter 部署的(de)節點 IP 地址(zhi)和端口(kou)。假設 taosAdapter 的(de) IP 地址(zhi)為(wei)192.168.1.130，端口(kou)為(wei) 6046，配置(zhi)如下：

LoadPlugin write_tsdb
<Plugin write_tsdb>
    <Node>
        Host "192.168.1.130"
        Port "6046"
        HostTags "status=production"
        StoreRates false
        AlwaysAppendDS false
    </Node>
</Plugin>

即可讓 collectd 將(jiang)數據使(shi)用推送到(dao) OpenTSDB 的插(cha)件方式推送到(dao) taosAdapter， taosAdapter 將(jiang)調用 API 將(jiang)數據寫(xie)入(ru)到(dao) taosd 中，從而完成數據的寫(xie)入(ru)工作。如果(guo)你使(shi)用的是 StatsD 相應(ying)地(di)調整配置文件信息。

• 調整看板（Dashboard）系統

在數據能夠正常寫入 TDengine 后，可以調整適配 Grafana 將寫入 TDengine 的數據可視化呈現出來。獲取和使用 TDengine 提供的 Grafana 插件請參考與其他工具的連接。

TDengine 提供(gong)了默認的兩(liang)套 Dashboard 模板(ban)，用戶只(zhi)需要(yao)將 Grafana 目錄(lu)下的模板(ban)導入到 Grafana 中即(ji)可激活使用。

操作(zuo)(zuo)完(wan)以上(shang)步驟后，就完(wan)成了將 OpenTSDB 替(ti)換成為(wei) TDengine 的遷移(yi)工(gong)作(zuo)(zuo)。可以看到整個流程非常簡單，不(bu)需(xu)要寫代(dai)碼，只(zhi)需(xu)要對某些配置文件進行調(diao)整即可完(wan)成全部的遷移(yi)工(gong)作(zuo)(zuo)。

3、遷移后架構

完(wan)成遷(qian)移以(yi)后，此(ci)時的(de)(de)系統整體的(de)(de)架構如(ru)下圖(tu)（圖(tu) 3）所示，而整個過程中采集端(duan)、數據寫入(ru)端(duan)、以(yi)及監(jian)控呈現端(duan)均保(bao)持了穩(wen)定，除了極少的(de)(de)配置調(diao)整外(wai)，不涉及任何重要的(de)(de)更(geng)改和(he)變動。OpenTSDB 大量的(de)(de)應用場景均為 DevOps ，這種場景下，簡單的(de)(de)參(can)數設(she)置即可完(wan)成 OpenTSDB 到 TDengine 遷(qian)移動作，使用上(shang) TDengine 更(geng)加(jia)強(qiang)大的(de)(de)處(chu)理能(neng)力(li)和(he)查(cha)詢性能(neng)。

在絕大多(duo)數的(de) DevOps 場(chang)景中，如(ru)果你擁有一(yi)個小規模的(de) OpenTSDB 集群（3 臺及(ji)以(yi)下的(de)節(jie)(jie)點）作為(wei)(wei) DevOps 的(de)存(cun)儲端，依(yi)賴于 OpenTSDB 為(wei)(wei)系統(tong)持(chi)久化層(ceng)提供數據存(cun)儲和查詢(xun)功能，那么(me)你可以(yi)安全地將其替換為(wei)(wei) TDengine，并節(jie)(jie)約更多(duo)的(de)計算(suan)(suan)和存(cun)儲資源(yuan)。在同等計算(suan)(suan)資源(yuan)配置情況下，單臺 TDengine 即可滿(man)足 3 ~ 5 臺 OpenTSDB 節(jie)(jie)點提供的(de)服務能力。如(ru)果規模比(bi)較大，那便需要采用 TDengine 集群。

如(ru)果(guo)你的(de)應(ying)(ying)用特別(bie)復雜(za)，或(huo)者應(ying)(ying)用領域并(bing)不是 DevOps 場景，你可以繼續閱讀(du)后(hou)續的(de)章節，更加全面(mian)深入地(di)了解將 OpenTSDB 的(de)應(ying)(ying)用遷移到 TDengine 的(de)高級(ji)話題(ti)。

其他場景的遷移評估與策略

1、TDengine 與 OpenTSDB 的差異

本章將詳細(xi)介紹 OpenTSDB 與 TDengine 在系統功能層面上存在的差異。閱(yue)讀完本章的內(nei)容，你可(ke)以(yi)全面地評估是否能夠(gou)將某些基于 OpenTSDB 的復(fu)雜應用遷移(yi)到 TDengine 上，以(yi)及遷移(yi)之后應該注意的問(wen)題(ti)。

TDengine 當前只支持 Grafana 的(de)(de)可(ke)視化看板呈現，所以(yi)(yi)如果你的(de)(de)應用中(zhong)使(shi)用了 Grafana 以(yi)(yi)外(wai)的(de)(de)前端看板（例如、等(deng)），那么(me)前端看板將無法直接遷移到 TDengine，需要將前端看板重新適配(pei)到 Grafana 才可(ke)以(yi)(yi)正常運行(xing)。

截(jie)止到(dao)(dao) 2.3.0.x 版本，TDengine 只能(neng)夠(gou)支(zhi)持(chi) collectd 和(he) StatsD 作為數(shu)據(ju)(ju)(ju)收(shou)集匯(hui)聚軟(ruan)件，當然后面會陸續提供更多的(de)數(shu)據(ju)(ju)(ju)收(shou)集聚合軟(ruan)件的(de)接入(ru)(ru)支(zhi)持(chi)。如(ru)果您(nin)的(de)收(shou)集端使(shi)用(yong)了其他類(lei)型的(de)數(shu)據(ju)(ju)(ju)匯(hui)聚器(qi)，您(nin)的(de)應用(yong)需要(yao)適配到(dao)(dao)這兩個數(shu)據(ju)(ju)(ju)匯(hui)聚端系統，才能(neng)夠(gou)將(jiang)數(shu)據(ju)(ju)(ju)正常寫(xie)(xie)(xie)(xie)入(ru)(ru)。除了上(shang)述兩個數(shu)據(ju)(ju)(ju)匯(hui)聚端軟(ruan)件協(xie)(xie)議(yi)以外(wai)，TDengine 還支(zhi)持(chi)通過(guo) InfluxDB 的(de)行(xing)協(xie)(xie)議(yi)和(he) OpenTSDB 的(de)數(shu)據(ju)(ju)(ju)寫(xie)(xie)(xie)(xie)入(ru)(ru)協(xie)(xie)議(yi)、JSON 格式將(jiang)數(shu)據(ju)(ju)(ju)直接寫(xie)(xie)(xie)(xie)入(ru)(ru)，您(nin)可以重寫(xie)(xie)(xie)(xie)數(shu)據(ju)(ju)(ju)推(tui)送(song)端的(de)邏輯，使(shi)用(yong) TDengine 支(zhi)持(chi)的(de)行(xing)協(xie)(xie)議(yi)來(lai)寫(xie)(xie)(xie)(xie)入(ru)(ru)數(shu)據(ju)(ju)(ju)。

此外，如(ru)果你的應(ying)用中(zhong)使(shi)用了 OpenTSDB 以(yi)(yi)下(xia)特(te)性，在將應(ying)用遷移到 TDengine 之前你還需要了解以(yi)(yi)下(xia)注意事(shi)項：

1. /api/stats：如果你的應用中使用了該項特性來監控 OpenTSDB 的服務狀態，并在應用中建立了相關的邏輯來聯動處理，那么這部分狀態讀取和獲取的邏輯需要重新適配到 TDengine。TDengine 提供了全新的處理集群狀態監控機制，來滿足你的應用對其進行的監控和維護的需求。
2. /api/tree：如果你依賴于 OpenTSDB 的該項特性來進行時間線的層級化組織和維護，那么便無法將其直接遷移至 TDengine。TDengine 采用了數據庫->超級表->子表這樣的層級來組織和維護時間線，歸屬于同一個超級表的所有的時間線在系統中同一個層級，但是可以通過不同標簽值的特殊構造來模擬應用邏輯上的多級結構。
3. Rollup And PreAggregates：采用了 Rollup 和 PreAggregates 需要應用來決定在合適的地方訪問 Rollup 的結果，在某些場景下又要訪問原始的結果，這種結構的不透明性讓應用處理邏輯變得極為復雜而且完全不具有移植性。我們認為這種策略是時序數據庫無法提供高性能聚合情況下的妥協與折中。TDengine 暫不支持多個時間線的自動降采樣和（時間段范圍的）預聚合，由于 其擁有的高性能查詢處理邏輯，即使不依賴于Rollup 和 （時間段）預聚合計算結果，也能夠提供很高性能的查詢響應，而且讓你的應用查詢處理邏輯更加簡單。
4. Rate: TDengine 提供了兩個計算數值變化率的函數，分別是 Derivative（其計算結果與 InfluxDB 的 Derivative 行為一致）和 IRate（其計算結果與 Prometheus 中的 IRate 函數計算結果一致）。但是這兩個函數的計算結果與 Rate 有細微的差別，但整體上功能更強大。此外，OpenTSDB 提供的所有計算函數，TDengine 均有對應的查詢函數支持，并且 TDengine 的查詢函數功能遠超過 OpenTSDB 支持的查詢函數，可以極大地簡化你的應用處理邏輯。

通過上面的介紹，相信你(ni)應該能(neng)夠了解 OpenTSDB 遷移(yi)到 TDengine 帶來的變化(hua)，這些信息也有助于你(ni)正確地判斷是否可以接受將應用 遷移(yi)到 TDengine 之上，體驗 TDengine 提供的強大的時序(xu)數據處理能(neng)力(li)和便捷的使用體驗。

2、遷移策略

首先將基于(yu) OpenTSDB 的(de)系統進行遷移涉及(ji)到的(de)數據模(mo)式設計、系統規模(mo)估(gu)算、數據寫入端改造，進行數據分(fen)流、應(ying)用適配工(gong)作；之后將兩個(ge)系統并(bing)行運行一段時間(jian)，再將歷史數據遷移到 TDengine 中(zhong)。當(dang)然(ran)如果你的(de)應(ying)用中(zhong)有部(bu)分(fen)功能強依(yi)賴于(yu)上述 OpenTSDB 特性(xing)，同時又不希望停止(zhi)使用，可以考慮保持原有的(de) OpenTSDB 系統運行，同時啟動 TDengine 來提供主(zhu)要的(de)服(fu)務。

數據模型設計

一方(fang)面，TDengine 要(yao)求(qiu)其入(ru)庫(ku)的(de)數據具有嚴格的(de)模(mo)(mo)式定(ding)義。另一方(fang)面，TDengine 的(de)數據模(mo)(mo)型相對于 OpenTSDB 來(lai)說又更加豐富，多值模(mo)(mo)型能夠兼容全部的(de)單值模(mo)(mo)型的(de)建立需求(qiu)。

現在讓我們假設(she)(she)一個(ge) DevOps 的(de)場景(jing)，我們使用了 collectd 收集設(she)(she)備(bei)的(de)基礎度量（metrics），包含(han)了 memory 、swap、disk 等幾個(ge)度量，其在 OpenTSDB 中的(de)模式如下：

序號	測量（metric）	值名稱	類型	tag1	tag2	tag3	tag4	tag5
1	memory	value	double	host	memory_type	memory_type_instance	source	n/a
2	swap	value	double	host	swap_type	swap_type_instance	source	n/a
3	disk	value	double	host	disk_point	disk_instance	disk_type	source

TDengine 要求(qiu)存儲的數(shu)據(ju)(ju)具有(you)數(shu)據(ju)(ju)模(mo)式(shi)(shi)(shi)，即寫(xie)(xie)(xie)入(ru)數(shu)據(ju)(ju)之前需創建超級表(biao)并指(zhi)定超級表(biao)的模(mo)式(shi)(shi)(shi)。對于數(shu)據(ju)(ju)模(mo)式(shi)(shi)(shi)的建立(li)，你(ni)有(you)兩種(zhong)方式(shi)(shi)(shi)來完成此項(xiang)工(gong)作(zuo)：1）充分利用 TDengine 對 OpenTSDB 的數(shu)據(ju)(ju)原生寫(xie)(xie)(xie)入(ru)的支持，調用 TDengine 提供的 API 將（文本行或(huo) JSON 格式(shi)(shi)(shi)）數(shu)據(ju)(ju)寫(xie)(xie)(xie)入(ru)，并自(zi)動化地(di)建立(li)單值模(mo)型。采用這(zhe)種(zhong)方式(shi)(shi)(shi)不需要對數(shu)據(ju)(ju)寫(xie)(xie)(xie)入(ru)應用進(jin)行較(jiao)大的調整，也不需要對寫(xie)(xie)(xie)入(ru)的數(shu)據(ju)(ju)格式(shi)(shi)(shi)進(jin)行轉(zhuan)換。

在(zai) C 語(yu)言層面，TDengine 提(ti)供了 taos_insert_lines() 函(han)數來直接寫(xie)入 OpenTSDB 格式的數據（在(zai)2.3.x 版本中該函(han)數對應的是 taos_schemaless_insert()）。其代(dai)碼參考示(shi)例請參見安裝(zhuang)包目錄下示(shi)例代(dai)碼 schemaless.c。

2）在充分理解 TDengine 的(de)(de)(de)數據(ju)模(mo)型(xing)基礎上，結合生成數據(ju)的(de)(de)(de)特點，手動方式(shi)建(jian)立 OpenTSDB 到 TDengine 的(de)(de)(de)數據(ju)模(mo)型(xing)調(diao)整的(de)(de)(de)映射(she)關系(xi)。TDengine 能(neng)夠支持多(duo)值模(mo)型(xing)和單值模(mo)型(xing)，考慮到 OpenTSDB 均為(wei)單值映射(she)模(mo)型(xing)，這里推薦(jian)使用(yong)單值模(mo)型(xing)在 TDengine 中進(jin)行建(jian)模(mo)。

• 單值模型。

具體步驟如下：將度量（metrics）的名稱作為 TDengine 超級表的名稱，該超級表建成后具有兩個基礎的數據列—時間戳（timestamp）和值（value），超級表的標簽等效于 度量 的標簽信息，標簽數量等同于度量 的標簽的數量。子表的表名采用具有固定規則的方式進行命名：metric + '_' + tags1_value + '_' + tag2_value + '_' + tag3_value ...作為子表名稱。

在 TDengine 中(zhong)建立3個超級表：

create stable memory(ts timestamp, val float) tags(host binary(12)，memory_type binary(20), memory_type_instance binary(20), source binary(20));
create stable swap(ts timestamp, val double) tags(host binary(12), swap_type binary(20), swap_type_binary binary(20), source binary(20));
create stable disk(ts timestamp, val double) tags(host binary(12), disk_point binary(20), disk_instance binary(20), disk_type binary(20), source binary(20));

對于(yu)子(zi)表使用(yong)動態建(jian)表的方(fang)式創(chuang)建(jian)如下所示(shi)：

insert into memory_vm130_memory_bufferred_collectd  using memory tags(‘vm130’, ‘memory’, 'buffer', 'collectd') values(1632979445, 3.0656);

最終系統中(zhong)會建(jian)立 340 個左右的(de)子表(biao)，3個超級表(biao)。需(xu)要(yao)注意的(de)是，如果采用串聯標簽值的(de)方(fang)式導(dao)致(zhi)子表(biao)名稱超過系統限制（191字節），那么需(xu)要(yao)采用一定的(de)編碼方(fang)式（例如 MD5）將其轉化為可接受長度。

• 多值模型

如果你想要利用 TDengine 的多值模型能力，需要首先滿足以下要求：不同的采集量具有相同的采集頻率，且能夠通過消息隊列同時到達數據寫入(ru)端，從而確保使用 SQL 語句將多個指標一次性寫入(ru)。將度(du)量的(de)名(ming)(ming)(ming)稱作為超(chao)級(ji)表(biao)(biao)的(de)名(ming)(ming)(ming)稱，建立具(ju)(ju)有相同采集頻(pin)率且能(neng)夠同時到達(da)的(de)數據多列(lie)模型。子表(biao)(biao)的(de)表(biao)(biao)名(ming)(ming)(ming)采用具(ju)(ju)有固定(ding)規則的(de)方式進行命(ming)名(ming)(ming)(ming)。上述(shu)每個度(du)量均只包含一個測(ce)量值，因(yin)此無法將其轉(zhuan)化為多值模型。

數據分流與應用適配

從消息隊列中訂閱(yue)數據(ju)(ju)，并(bing)啟動調整后的寫(xie)入程(cheng)序寫(xie)入數據(ju)(ju)。

數據(ju)開始(shi)寫入持續一段時間后，可以采用SQL語句(ju)檢查(cha)寫入的(de)數據(ju)量是否符合預計的(de)寫入要(yao)求。統計數據(ju)量使用如下(xia)SQL語句(ju)：

select count(*) from memory

完成查詢后，如(ru)果寫(xie)入的(de)數(shu)據與(yu)預期的(de)相比沒有差(cha)別，同時(shi)寫(xie)入程序本身沒有異(yi)常(chang)的(de)報錯信息，那么可(ke)用確(que)認數(shu)據寫(xie)入是完整有效的(de)。

TDengine 不支(zhi)持采用(yong) OpenTSDB 的(de)(de)查詢(xun)(xun)語法進行(xing)查詢(xun)(xun)或數據獲(huo)取(qu)處理(li)，但是針對 OpenTSDB 的(de)(de)每(mei)種查詢(xun)(xun)都提供對應(ying)的(de)(de)支(zhi)持。可以(yi)用(yong)檢查附錄1獲(huo)取(qu)對應(ying)的(de)(de)查詢(xun)(xun)處理(li)的(de)(de)調整和應(ying)用(yong)使(shi)用(yong)的(de)(de)方式(shi)，如果(guo)需要全面了解 TDengine 支(zhi)持的(de)(de)查詢(xun)(xun)類型，請參(can)閱(yue) TDengine 的(de)(de)用(yong)戶手冊。

TDengine 支持標準的(de) JDBC 3.0 接口操(cao)縱數據(ju)庫，你(ni)(ni)也(ye)(ye)可以使用(yong)(yong)其(qi)他類型(xing)的(de)高級語言(yan)的(de)連接器來查詢讀取數據(ju)，以適配你(ni)(ni)的(de)應用(yong)(yong)。具體(ti)的(de)操(cao)作(zuo)和使用(yong)(yong)幫(bang)助也(ye)(ye)請(qing)參閱用(yong)(yong)戶手冊。

歷史數據遷移

1、使用工具自動遷移數據

為(wei)了方便歷史(shi)數(shu)(shu)(shu)據(ju)(ju)的(de)遷移工(gong)作，我們(men)為(wei)數(shu)(shu)(shu)據(ju)(ju)同步工(gong)具 DataX 提供了插件，能夠(gou)將數(shu)(shu)(shu)據(ju)(ju)自(zi)動寫入(ru)到 TDengine 中，需要(yao)注(zhu)意的(de)是 DataX 的(de)自(zi)動化數(shu)(shu)(shu)據(ju)(ju)遷移只能夠(gou)支(zhi)持單值模(mo)型的(de)數(shu)(shu)(shu)據(ju)(ju)遷移過(guo)程。

DataX 具體的使用方式及如何使用 DataX 將數據寫入 TDengine 請參見基于 DataX 的 TDengine 數據遷移工具。

在對 DataX 進行遷移(yi)(yi)實踐后，我們發現通過啟動多個(ge)進程(cheng)(cheng)，同時遷移(yi)(yi)多個(ge) metric 的方式，可以(yi)大(da)幅度的提高遷移(yi)(yi)歷史數據的效率，下面(mian)是遷移(yi)(yi)過程(cheng)(cheng)中的部分記錄(lu)，希望這些能為應用遷移(yi)(yi)工(gong)作(zuo)帶(dai)來參考。

datax 實例個數 (并發進程個數)	遷移記錄速度 （條/秒)
1	約13.9萬
2	約21.8萬
3	約24.9萬
5	約29.5萬
10	約33萬

（注：測試數(shu)據源自 單節點 Intel(R) Core(TM) i7-10700 CPU@2.90GHz 16核(he)64G硬件設備，channel 和 batchSize 分別為(wei) 8 和 1000，每條記錄包含 10 個 tag)

2、手動遷移數據

如(ru)果你需(xu)要使用多值模型進行(xing)數(shu)據寫入(ru)，就需(xu)要自行(xing)開(kai)發一個(ge)將數(shu)據從 OpenTSDB 導出(chu)的(de)(de)工具，然后確認哪(na)些時間線(xian)能夠合并導入(ru)到同一個(ge)時間線(xian)，再將可以(yi)同時導入(ru)的(de)(de)時間通過SQL語句的(de)(de)寫入(ru)到數(shu)據庫(ku)中。

手動遷移數據需要(yao)注意以下兩個問題：

1）在磁(ci)盤(pan)中存(cun)(cun)儲(chu)導(dao)出數據(ju)(ju)時，磁(ci)盤(pan)需要(yao)有(you)足夠的(de)(de)存(cun)(cun)儲(chu)空(kong)間以(yi)(yi)便能夠充分(fen)容(rong)納導(dao)出的(de)(de)數據(ju)(ju)文件。為了避免全(quan)量數據(ju)(ju)導(dao)出后導(dao)致磁(ci)盤(pan)文件存(cun)(cun)儲(chu)緊張，可以(yi)(yi)采(cai)用部分(fen)導(dao)入(ru)的(de)(de)模(mo)式，對于歸(gui)屬于同一個超級表的(de)(de)時間線優先導(dao)出，然后將導(dao)出部分(fen)的(de)(de)數據(ju)(ju)文件導(dao)入(ru)到 TDengine 系統中。

2）在系統全負載(zai)運(yun)行(xing)下，如果有足夠的剩(sheng)余(yu)計算和 IO 資(zi)源，可(ke)以(yi)建(jian)立多(duo)線程的導(dao)入(ru)機制(zhi)，最大(da)限度地提升數據(ju)(ju)遷移(yi)的效(xiao)率(lv)。考(kao)慮到(dao)數據(ju)(ju)解析對于 CPU 帶來的巨大(da)負載(zai)，需(xu)要控制(zhi)最大(da)的并行(xing)任務(wu)數量，以(yi)避免(mian)因導(dao)入(ru)歷(li)史數據(ju)(ju)而觸發的系統整(zheng)體(ti)過載(zai)。

由于 TDengine 本身操作(zuo)簡易性(xing)，所以不需要在整個過(guo)程中進行(xing)索引維(wei)護、數(shu)據格式的變(bian)化(hua)處(chu)理等工(gong)作(zuo)，整個過(guo)程只需要順序執行(xing)即可。

當歷史(shi)數(shu)據完(wan)全導入到 TDengine 以(yi)后(hou)，此時兩(liang)個系統處(chu)于同時運行的狀態，之(zhi)后(hou)便可以(yi)將查詢請求(qiu)切(qie)換(huan)到 TDengine 上，從(cong)而實現無縫的應用(yong)切(qie)換(huan)。

附錄1: OpenTSDB 查詢函數對應表

Avg

等效函數：avg

示例：

SELECT avg(val) FROM (SELECT first(val) FROM super_table WHERE ts >= startTime and ts <= endTime INTERVAL(20s) Fill(linear)) INTERVAL(20s)

備注：

1. Interval 內的數值與外層查詢的 interval 數值需要相同。
2. 在 TDengine 中插值處理需要使用子查詢來協助完成，如上所示，在內層查詢中指明插值類型即可，由于 OpenTSDB 中數值的插值使用了線性插值，因此在插值子句中使用 fill(linear) 來聲明插值類型。以下有相同插值計算需求的函數，均采用該方法處理。
3. Interval 中參數 20s 表示將內層查詢按照 20 秒一個時間窗口生成結果。在真實的查詢中，需要調整為不同的記錄之間的時間間隔。這樣可確保等效于原始數據生成了插值結果。
4. 由于 OpenTSDB 特殊的插值策略和機制，聚合查詢（Aggregate）中先插值再計算的方式導致其計算結果與 TDengine 不可能完全一致。但是在降采樣（Downsample）的情況下，TDengine 和 OpenTSDB 能夠獲得一致的結果（由于 OpenTSDB 在聚合查詢和降采樣查詢中采用了完全不同的插值策略）。

Count

等效函數：count

示例：

select count(*) from super_table_name;

Dev

等效函(han)數：stddev

示例：

Select stddev(val) from table_name

Estimated percentiles

等效(xiao)函數：apercentile

示例：

Select apercentile(col1, 50, “t-digest”) from table_name

備注：

1. 近似查詢處理過程中，OpenTSDB 默認采用 t-digest 算法，所以為了獲得相同的計算結果，需要在 apercentile 函數中指明使用的算法。TDengine 能夠支持兩種不同的近似處理算法，分別通過“default”和“t-digest”來聲明。

First

等(deng)效函數：first

示例：

Select first(col1) from table_name

Last

等效函數：last

示例：

Select last(col1) from table_name

Max

等效函數：max

示例：

Select max(value) from (select first(val) value from table_name interval(10s) fill(linear)) interval(10s)

備(bei)注(zhu)：Max 函數需要插值，原因見上。

Min

等效函數：min

示例：

Select min(value) from (select first(val) value from table_name interval(10s) fill(linear)) interval(10s);

MinMax

等效函數：max

Select max(val) from table_name

備(bei)注：該函數無插值(zhi)需求，因此可用直接計算。

MimMin

等效函數：min

Select min(val) from table_name

備(bei)注：該函數無插值需求，因此可用直接計(ji)算(suan)。

Percentile

等(deng)效函數：percentile

備注：

Sum

等效函數：sum

Select max(value) from (select first(val) value from table_name interval(10s) fill(linear)) interval(10s)

備注：該函數無插(cha)值(zhi)需求，因(yin)此(ci)可用直接計算。

Zimsum

等效函數：sum

Select sum(val) from table_name

備(bei)注：該(gai)函數無插值需求，因此可用直接計算。

完整示例：

// OpenTSDB 查詢 JSON
query = {
“start”:1510560000,
“end”: 1515000009,
“queries”:[{
“aggregator”: “count”,
“metric”:”cpu.usage_user”,
}]
}

//等效查詢 SQL:
SELECT count(*)
FROM `cpu.usage_user`
WHERE ts>=1510560000 AND ts<=1515000009

附錄2: 資源估算方法

數據生成環境

我們(men)仍然使用第 4 章中(zhong)的(de)假(jia)設環境(jing)，3個(ge)(ge)(ge)測量(liang)值。分別(bie)是：溫(wen)度和濕度的(de)數據寫入(ru)的(de)速率是每(mei) 5 秒(miao)一條記錄，時(shi)間線 10萬個(ge)(ge)(ge)。空氣質量(liang)的(de)寫入(ru)速率是 10 秒(miao)一條記錄，時(shi)間線 1 萬個(ge)(ge)(ge)，查詢的(de)請求(qiu)頻率 500 QPS。

存儲資源估算

假設產生數據并需要存儲的傳感器設備數量為 n，數據生成的頻率為t條/秒，每條記錄的長度為 L bytes，則每天產生的數據規模為 n×t×L bytes。假設壓縮比為 C，則每日產生數據規模為 (n×t×L)/C bytes。存(cun)儲(chu)資源預(yu)估(gu)為能夠容納 1.5 年的數據規模(mo)，生產環境下 TDengine 的壓縮比 C 一(yi)般在 5 ~ 7 之(zhi)間，同時為最后結果(guo)增(zeng)加 20% 的冗余，可計算得到(dao)需要存(cun)儲(chu)資源：

(n×t×L)×(365×1.5)×(1+20%)/C

結(jie)合以(yi)(yi)上(shang)的(de)(de)(de)計算公(gong)式，將參數(shu)帶(dai)入計算公(gong)式，在不(bu)考慮標簽信(xin)息(xi)的(de)(de)(de)情況下，每年產(chan)生(sheng)的(de)(de)(de)原始數(shu)據(ju)(ju)(ju)(ju)規(gui)模(mo)是 11.8TB。需要(yao)注意(yi)的(de)(de)(de)是，由于(yu)標簽信(xin)息(xi)在 TDengine 中關聯到每個時間線，并(bing)不(bu)是每條記錄。所以(yi)(yi)需要(yao)記錄的(de)(de)(de)數(shu)據(ju)(ju)(ju)(ju)量規(gui)模(mo)相對于(yu)產(chan)生(sheng)的(de)(de)(de)數(shu)據(ju)(ju)(ju)(ju)有一定的(de)(de)(de)降低，而這部分標簽數(shu)據(ju)(ju)(ju)(ju)整體(ti)上(shang)可以(yi)(yi)忽略不(bu)記。假設壓縮比為5，則保留(liu)的(de)(de)(de)數(shu)據(ju)(ju)(ju)(ju)規(gui)模(mo)最終(zhong)為 2.56 TB。

存儲設備選型考慮

硬(ying)盤(pan)(pan)應該選用(yong)具有(you)(you)較好隨(sui)(sui)機(ji)(ji)讀性(xing)能(neng)(neng)(neng)(neng)的(de)(de)(de)硬(ying)盤(pan)(pan)設備，如果能(neng)(neng)(neng)(neng)夠(gou)有(you)(you) SSD，盡可能(neng)(neng)(neng)(neng)考慮使(shi)(shi)用(yong) SSD。較好的(de)(de)(de)隨(sui)(sui)機(ji)(ji)讀性(xing)能(neng)(neng)(neng)(neng)的(de)(de)(de)磁盤(pan)(pan)對于提(ti)升系統查詢性(xing)能(neng)(neng)(neng)(neng)具有(you)(you)極(ji)大的(de)(de)(de)幫助，能(neng)(neng)(neng)(neng)夠(gou)整體上(shang)提(ti)升系統的(de)(de)(de)查詢響(xiang)應性(xing)能(neng)(neng)(neng)(neng)。為了(le)獲得(de)較好的(de)(de)(de)查詢性(xing)能(neng)(neng)(neng)(neng)，硬(ying)盤(pan)(pan)設備的(de)(de)(de)單線程隨(sui)(sui)機(ji)(ji)讀IOPS的(de)(de)(de)性(xing)能(neng)(neng)(neng)(neng)指標不應該低于 1000，能(neng)(neng)(neng)(neng)夠(gou)達到 5000 IOPS 以上(shang)為佳。為了(le)獲得(de)當前的(de)(de)(de)設備隨(sui)(sui)機(ji)(ji)讀取的(de)(de)(de)IO性(xing)能(neng)(neng)(neng)(neng)的(de)(de)(de)評估(gu)，建議使(shi)(shi)用(yong) fio 軟件對其進行運行性(xing)能(neng)(neng)(neng)(neng)評估(gu)（具體的(de)(de)(de)使(shi)(shi)用(yong)方式請(qing)參閱(yue)附錄1），確認其是否能(neng)(neng)(neng)(neng)夠(gou)滿足大文件隨(sui)(sui)機(ji)(ji)讀性(xing)能(neng)(neng)(neng)(neng)要求。

硬(ying)盤寫(xie)性(xing)能(neng)(neng)對(dui)于 TDengine 的影響不大(da)。TDengine 寫(xie)入過(guo)程采(cai)用了(le)追加寫(xie)的模(mo)式，所以只要(yao)有較好(hao)的順序寫(xie)性(xing)能(neng)(neng)即可，一般意義上(shang)的 SAS 硬(ying)盤和(he) SSD 均能(neng)(neng)夠很好(hao)地滿足 TDengine 對(dui)于磁(ci)盤寫(xie)入性(xing)能(neng)(neng)的要(yao)求(qiu)。

計算資源估算

由于物聯網數據的特殊性，數據產生的頻率固定以后，TDengine 寫入的過程對于（計算和存儲）資源消耗都保持一個相對固定的量。《TDengine 的運營與維護》上的描述，該(gai)系統中(zhong)每秒 22000個寫入，消耗(hao) CPU 不到 1 個核。

在針對查(cha)詢所需要消耗(hao)的(de)(de) CPU 資源的(de)(de)估算上(shang)(shang)，假(jia)設應用要求數據庫提供的(de)(de) QPS 為 10000，每(mei)次查(cha)詢消耗(hao)的(de)(de) CPU 時間約 1 ms，那么每(mei)個(ge)核每(mei)秒(miao)提供的(de)(de)查(cha)詢為 1000 QPS，滿(man)足 10000 QPS的(de)(de)查(cha)詢請求，至少需要 10 個(ge)核。為了讓系(xi)統整(zheng)體上(shang)(shang) CPU 負載小于 50%，整(zheng)個(ge)集群(qun)需要 10 個(ge)核的(de)(de)兩倍，即(ji) 20 個(ge)核。

內存資源估算

數據庫默認(ren)為每(mei)個(ge)(ge) Vnode 分(fen)配內存(cun)(cun)(cun) 16MB*3 緩沖區，集(ji)群系統包括 22 個(ge)(ge) CPU 核，則(ze)默認(ren)會建立 22 個(ge)(ge)虛擬節(jie)點 Vnode，每(mei)個(ge)(ge) Vnode 包含 1000 張表，則(ze)可以(yi)容納所有的(de)表。則(ze)約1個(ge)(ge)半小時寫滿一個(ge)(ge) block，從而觸發(fa)落(luo)盤，可以(yi)不(bu)做(zuo)調整。22 個(ge)(ge) Vnode 共計(ji)需要(yao)內存(cun)(cun)(cun)緩存(cun)(cun)(cun)約 1GB。考(kao)慮(lv)到查詢所需要(yao)的(de)內存(cun)(cun)(cun)，假設每(mei)次查詢的(de)內存(cun)(cun)(cun)開銷約 50MB，則(ze) 500 個(ge)(ge)查詢并發(fa)需要(yao)的(de)內存(cun)(cun)(cun)約 25GB。

綜上所述，可(ke)使用單臺 16 核 32GB 的機器，或(huo)者使用 2 臺 8 核 16GB 機器構成的集(ji)群。

附錄3: 集群部署及啟動

TDengine 提供了豐(feng)富的幫(bang)助文檔說明集群安裝(zhuang)、部(bu)署的諸多(duo)方面的內容，這(zhe)里提供響(xiang)應的文檔索引，供你參考。

集群部署

首先是安裝 TDengine，從官網上下載 TDengine 最新穩定版，解壓縮后運行 install.sh 進行安裝。各種安裝包的使用幫助請參見博客《TDengine 多種安裝包的安裝和卸載》。

注意安(an)裝完成以后，不(bu)要立即啟(qi)動 taosd 服務，在正確配置(zhi)完成參(can)數(shu)以后才(cai)啟(qi)動 taosd 服務。

設置運行參數并啟動服務

為(wei)確保系統能(neng)夠正常獲取(qu)運行的必要信息。請(qing)在服務端正確設置(zhi)以(yi)下關鍵參數(shu)：

FQDN、firstEp、secondEP、dataDir、logDir、tmpDir、serverPort。各參數的具體含義及設置的要求，可參見文檔《TDengine 集群安裝、管理》

按照相同的(de)步(bu)驟，在需要(yao)運行的(de)節點上(shang)設置參數，并(bing)啟(qi)動 taosd 服(fu)務，然后添(tian)加 Dnode 到集群中。

最后啟動taos，執行命令 show dnodes，如果能看到所有的加入集群的節點，那么集群順利搭建完成。具體的操作流程及注意事項，請參閱文檔《TDengine 集群安裝、管理》

附錄4: 超級表名稱

由于 OpenTSDB 的 metric 名稱中帶有點號（“.“），例如“cpu.usage_user”這種名稱的 metric。但是點號在 TDengine 中具有特殊含義，是用來分隔數據庫和表名稱的分隔符。TDengine 也提供轉義符，以允許用戶在（超級）表名稱中使用關鍵詞或特殊分隔符（如：點號）。為了使用特殊字符，需要采用轉義字符將表的名稱括起來，例如：cpu.usage_user這(zhe)樣(yang)就是合法的（超(chao)級）表名稱。

附錄5：參考文章

1. 使用 TDengine + collectd/StatsD + Grafana 快速搭建 IT 運維監控系統
2. 通過 collectd 將采集數據直接寫入 TDengine