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

一次調(diào)侃

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

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

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

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

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

一篇文章

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

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

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

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

啟航揚帆

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

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

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

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

最后是應用部署，因為我們的程序采用容器化的方式運行和管理，所以需要簡單基于 Linux 鏡像安裝對應版本的 TDengine-client 生成基礎(chǔ)鏡像，再提供給應用程序使用。期間，我們遇到問題都是在GitHub（https://github.com/taosdata/TDengine）上提交 issue，很快就有 TDengine 的官方伙伴回復，在社區(qū)群也有技術(shù)支持人員以及其他熱心開發(fā)者幫忙解答。

兩篇文章

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

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

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

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

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

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

幾點希望

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

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

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

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

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