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

一次調侃

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

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

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

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

項目經理經常調侃，”就是展示幾條曲線，幾個數據而已，為什么要那么復雜？”

一篇文章

在調侃之余，我們開發人員也在思考，其實工業互聯網以設備為主線，統計的都是一段時間內單個設備的數據，難道就沒有一個能夠很好地強調物聯網時序場景的大數據軟件嗎？

一次偶然機會，我在朋友圈看到了這篇文章——《》，再結合搜索引擎的這幾個關鍵字——”秒殺 Hadoop””分布式集群””開源”，馬上就吸引了我的注意，點進去一看，真的大有相見恨晚的感覺。

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

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

啟航揚帆

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

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

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

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

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

兩篇文章

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

比如，連接域名 ‘td-prod-service:6030’，通過負載均衡服務進行 udp 轉發（TDengine 的連接是走 udp 協議），隨機分發連接請求到實際的三節點之一（prod-td-1:6030, prod-td-2:6030, prod-td-3:6030），之后，應用程序根據接收到的節點信息，和實際的節點發生連接。為了解決這個問題，我們曾和 TDengine 社區的官方小伙伴們進行很多互動交流，后來他們把這個做成了經典案例文章——《》

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

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

后來，TDengine 的社區技術支持人員也基于此做成了經典案例文章——《》，當時我還沒留意，是我的同事和我說“你看這個文章里的示范表叫 daluo（我的微信 ID 名字）”我才發現。當時，我的心情是十分驚喜的。

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

幾點希望

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

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

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

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

總結一下，就是希望 TDengine 可以在物聯網大數據平臺方向提供全棧的技術方案，為企業的提效降本提供扎實便利的技術基礎，成為整個行業的事實標準。