小T導(dǎo)讀：本文作者是一名來自廣州某企業(yè)的架構(gòu)師，主攻大數(shù)據(jù)和云原生方向。今天在這篇文章里，他想結(jié)合近些年的工作經(jīng)驗(yàn)，講講為何以及如何在物聯(lián)網(wǎng)、工業(yè)大數(shù)據(jù)項(xiàng)目中落地 TDengine Database，希望能給大家一些啟示和有意義的參考。

一次調(diào)侃

在認(rèn)識 TDengine 之前，我一直都在做工業(yè)互聯(lián)網(wǎng)項(xiàng)目，其中的一些工作，包含數(shù)據(jù)從應(yīng)用層到大數(shù)據(jù)庫的匯總、分析計(jì)算，以及反饋應(yīng)用層需要的業(yè)務(wù)報(bào)表數(shù)據(jù)。

例如計(jì)算平均每分鐘的功率曲線、統(tǒng)計(jì)每分鐘的用電量、對比不同設(shè)備乃至廠區(qū)的耗能情況，這里面既有實(shí)時(shí)流計(jì)算也有批處理。

如果把大數(shù)據(jù)系統(tǒng)作為一個(gè)中臺型服務(wù)，它對應(yīng)用層暴露的僅僅是 HTTP 形式的查詢接口，背后需要涵蓋很多技術(shù)組件，例如將 Hadoop 的 HDFS/Hive 做原始數(shù)據(jù)保留、使用 HBase 保存計(jì)算后的數(shù)據(jù)、利用消息中間件 Kafka 同步各類數(shù)據(jù)庫，計(jì)算框架是使用 Flink 還是 Spark、分布式協(xié)調(diào)上選擇 ZooKeeper。

因此，整個(gè)框架技術(shù)組件看起來非常的”重”，一方面體現(xiàn)在你需要對 Hadoop 的技術(shù)組件非常熟悉：例如數(shù)據(jù)均衡備份冗余策略、Hive 分區(qū)策略、HBase 的 key 設(shè)計(jì)規(guī)則；另一方面則體現(xiàn)在業(yè)務(wù)規(guī)則的不好把控和適應(yīng)：以每分鐘的功率計(jì)算為例，開始是取該分鐘間隔內(nèi)的最后一個(gè)數(shù)值，后來改成取該分鐘內(nèi)的平均數(shù)值，凡此種種需要大數(shù)據(jù)系統(tǒng)從 ods 層面重新進(jìn)行計(jì)算，會帶來非常大的開發(fā)工作量。

項(xiàng)目經(jīng)理經(jīng)常調(diào)侃，”就是展示幾條曲線，幾個(gè)數(shù)據(jù)而已，為什么要那么復(fù)雜？”

一篇文章

在調(diào)侃之余，我們開發(fā)人員也在思考，其實(shí)工業(yè)互聯(lián)網(wǎng)以設(shè)備為主線，統(tǒng)計(jì)的都是一段時(shí)間內(nèi)單個(gè)設(shè)備的數(shù)據(jù)，難道就沒有一個(gè)能夠很好地強(qiáng)調(diào)物聯(lián)網(wǎng)時(shí)序場景的大數(shù)據(jù)軟件嗎？

一次偶然機(jī)會，我在朋友圈看到了這篇文章——《比 Hadoop 快至少 10 倍的物聯(lián)網(wǎng)大數(shù)據(jù)平臺，我把它開源了》，再結(jié)合搜索引擎的這幾個(gè)關(guān)鍵字——”秒殺 Hadoop””分布式集群””開源”，馬上就吸引了我的注意，點(diǎn)進(jìn)去一看，真的大有相見恨晚的感覺。

因?yàn)?TDengine Database 的優(yōu)勢完全可以解決我們的痛點(diǎn)——以設(shè)備數(shù)據(jù)模型創(chuàng)建超級表，以設(shè)備為單個(gè)子表，按時(shí)間先后順序連續(xù)存儲數(shù)據(jù)。在查詢的時(shí)候，可以提供預(yù)計(jì)算的統(tǒng)計(jì)數(shù)據(jù)，可以基于設(shè)備單個(gè)子表的 tag 做聚合的功能，結(jié)合流計(jì)算中的滑動(dòng)窗口、滾動(dòng)窗口概念，還可以快速地基于原始數(shù)據(jù)得到聚合統(tǒng)計(jì)結(jié)果。

此外，TDengine 還支持分布式集群部署，避免單點(diǎn)故障，提升存儲計(jì)算能力。更重要的是，這個(gè)集群功能也是開源的！開源核心功能意味著不用擔(dān)心以后給人卡脖子，也意味著會有一個(gè)優(yōu)秀的開源社區(qū)伴你同行。

啟航揚(yáng)帆

心動(dòng)不如行動(dòng)，接下來我們團(tuán)隊(duì)立馬著手在新的物聯(lián)網(wǎng)項(xiàng)目上，按照”安裝->應(yīng)用集成(讀寫)->應(yīng)用部署”的三部曲，正式使用上了 TDengine Database。

它的安裝包十分小巧，只有 10M 左右，借助于官方文檔，Linux 系統(tǒng)下的集群部署也很簡單。接下來，配置好主機(jī)名、域名解析、暴露的端口、運(yùn)行程序，過程非常順滑，立馬就能使用了。對比之前的 Hadoop 技術(shù)棧，這對運(yùn)維團(tuán)隊(duì)來說簡直就是福音！

在和應(yīng)用集成方面，TDengine 支持 JDBC-JNI 和 HTTP RESTful 兩種方式讀寫數(shù)據(jù)，我們采取 JDBC-JNI 結(jié)合 Mybatis 的方式，本地開發(fā)的時(shí)候，需要安裝對應(yīng)版本的 TDengine-client。另外，設(shè)計(jì)好超級表后，子表在首次寫入的時(shí)候同時(shí)創(chuàng)建。

對應(yīng)于我們?nèi)?jié)點(diǎn)（24 核，62G）的集群，程序輕輕松松就達(dá)到 qps 每秒 1 萬記錄的寫入性能。至于查詢性能，以當(dāng)天的功率曲線為例，按照 1 分鐘 1 個(gè)記錄，總共 1440 個(gè)計(jì)算數(shù)據(jù)計(jì)算，可以輕松地在 1 秒鐘內(nèi)通過 1 句 SQL 聚合當(dāng)天 1 萬條記錄而得到；還有每月的日溫度曲線，總共 30 個(gè)計(jì)算數(shù)據(jù)，當(dāng)月的 30 萬條記錄，也可以通過 avg 函數(shù)結(jié)合 Interval 在秒級查詢的時(shí)間間隔內(nèi)返回！

最后是應(yīng)用部署，因?yàn)槲覀兊某绦虿捎萌萜骰姆绞竭\(yùn)行和管理，所以需要簡單基于 Linux 鏡像安裝對應(yīng)版本的 TDengine-client 生成基礎(chǔ)鏡像，再提供給應(yīng)用程序使用。期間，我們遇到問題都是在GitHub（https://github.com/taosdata/TDengine）上提交 issue，很快就有 TDengine 的官方伙伴回復(fù)，在社區(qū)群也有技術(shù)支持人員以及其他熱心開發(fā)者幫忙解答。

兩篇文章

項(xiàng)目運(yùn)行一段時(shí)間后，我們團(tuán)隊(duì)在客戶端連接高可用方面也嘗試著進(jìn)行了思考和改進(jìn)。實(shí)際場景下，我們會依據(jù)數(shù)據(jù)需求動(dòng)態(tài)增加節(jié)點(diǎn)，但是不希望應(yīng)用程序也跟著改動(dòng)連接地址，所以我們希望應(yīng)用程序的連接域名不變。那么，怎么實(shí)現(xiàn)呢？

比如，連接域名 ‘td-prod-service:6030’，通過負(fù)載均衡服務(wù)進(jìn)行 udp 轉(zhuǎn)發(fā)（TDengine 的連接是走 udp 協(xié)議），隨機(jī)分發(fā)連接請求到實(shí)際的三節(jié)點(diǎn)之一（prod-td-1:6030, prod-td-2:6030, prod-td-3:6030），之后，應(yīng)用程序根據(jù)接收到的節(jié)點(diǎn)信息，和實(shí)際的節(jié)點(diǎn)發(fā)生連接。為了解決這個(gè)問題，我們曾和 TDengine 社區(qū)的官方小伙伴們進(jìn)行很多互動(dòng)交流，后來他們把這個(gè)做成了經(jīng)典案例文章——《「GitHub問題精選」TDengine 如何做到客戶端高可用？》

再接著，我們又接到了應(yīng)用適應(yīng)客戶時(shí)區(qū)進(jìn)行統(tǒng)計(jì)的需求，這個(gè)需求的背景是因?yàn)槲覀兊脑O(shè)備遍布全球，每個(gè)客戶審閱自己設(shè)備的統(tǒng)計(jì)數(shù)據(jù)時(shí)，當(dāng)然期望是以客戶自己所在時(shí)區(qū)為維度進(jìn)行統(tǒng)計(jì)。很幸運(yùn)，TDegnine 不僅提供了時(shí)間窗口函數(shù) interval，還支持偏移 offset（偏移必須小于間隔）。

首先，我們配置taos的系統(tǒng)時(shí)區(qū)為 “timezone UTC-12″（即地球最早的時(shí)區(qū)）。然后，當(dāng)中國時(shí)區(qū)客戶(Asia/Shanghai (CST, +0800))查詢以天為間隔時(shí)，我們會偏移 4 個(gè)小時(shí)，例如， interval(1d, 4h)；當(dāng)美國時(shí)區(qū)客戶（America/Los_Angeles(PST, -0800)查詢以天為間隔時(shí)，我們會偏移 20 個(gè)小時(shí)，例如, interval(1d, 20h)；

后來，TDengine 的社區(qū)技術(shù)支持人員也基于此做成了經(jīng)典案例文章——《一文幫你掌握TDengine的降采樣查詢+跨時(shí)區(qū)統(tǒng)計(jì)》，當(dāng)時(shí)我還沒留意，是我的同事和我說“你看這個(gè)文章里的示范表叫 daluo（我的微信 ID 名字）”我才發(fā)現(xiàn)。當(dāng)時(shí)，我的心情是十分驚喜的。

這兩篇文章在解決我們問題的同時(shí)，進(jìn)一步完善了 TDengine 自身與用戶交互的技術(shù)資料，我們真正做到了在開源社區(qū)中合作共贏。

幾點(diǎn)希望

未來，我們希望 TDengine 可以繼續(xù)保持開源的態(tài)勢，及時(shí)友好地解答用戶的疑問，為社區(qū)繁榮以及中國的開源軟件建設(shè)充當(dāng)開路者。

同時(shí)，我們也希望 TDengine 的軟件部署可以向容器化的方式靠攏。畢竟在當(dāng)下云原生的時(shí)代，容器化已經(jīng)是團(tuán)隊(duì)提升效率必不可少的利器。想象一下未來的場景，基于云計(jì)算的強(qiáng)大共享存儲計(jì)算能力，以及可靠穩(wěn)定的容器化編排環(huán)境 Kubernetes，開發(fā)者只需要簡單的運(yùn)行 K8s operator 就能運(yùn)行 TDengine，然后實(shí)現(xiàn)版本的升級以及計(jì)算資源的隨意調(diào)度，將給運(yùn)維帶來極大的便利。

此外，結(jié)合傳統(tǒng)的數(shù)據(jù)倉庫星形模型，我們也希望 TDengine 可以實(shí)現(xiàn)多表的聯(lián)合查詢統(tǒng)計(jì)。因?yàn)樵谠O(shè)備的背后是業(yè)務(wù)，設(shè)備總是會關(guān)聯(lián)具體的車間、客戶、廠區(qū)，而我們可能無法把所有的業(yè)務(wù)屬性一次性預(yù)先作為 tag 寫入到子表中（雖然我們現(xiàn)在是這樣做的），當(dāng)有新的業(yè)務(wù)屬性需要關(guān)聯(lián)的時(shí)候，我們又需要去增加超級表的tag，然后更新到對應(yīng)的設(shè)備子表數(shù)據(jù)。而實(shí)際上，tag 和設(shè)備數(shù)據(jù)更像是索引關(guān)系。所以，如果子表作為事實(shí)表可以隨意和維度表進(jìn)行關(guān)聯(lián)統(tǒng)計(jì)查詢，這又是一個(gè)多么美妙的場景！

最后，我們希望結(jié)合機(jī)器學(xué)習(xí)等框架，TDengine 可以衍生出自己的 “MapReduce” 作業(yè)框架，支持開發(fā)者在上面進(jìn)行人工智能作業(yè)分析。

總結(jié)一下，就是希望 TDengine 可以在物聯(lián)網(wǎng)大數(shù)據(jù)平臺方向提供全棧的技術(shù)方案，為企業(yè)的提效降本提供扎實(shí)便利的技術(shù)基礎(chǔ)，成為整個(gè)行業(yè)的事實(shí)標(biāo)準(zhǔn)。