在工(gong)業(ye)(ye)領域， 生產(chan)、測試、運行階(jie)段都(dou)可能會產(chan)生大量(liang)帶(dai)有時間(jian)戳的傳感器(qi)數據，這(zhe)(zhe)都(dou)屬于典型的時序(xu)數據。時序(xu)數據主要由各類型實時監測、檢查(cha)與分(fen)析設備所采集或產(chan)生，涉及制(zhi)造(zao)、電力、化工(gong)、工(gong)程作業(ye)(ye)等(deng)多(duo)個行業(ye)(ye)，具備寫多(duo)讀少、量(liang)非常大等(deng)典型特性。如 Apache HBase、MySQL 等(deng)互聯網(wang)公司常用的數據庫在寫入(ru)、存儲(chu)、查(cha)詢、運維等(deng)方面(mian)都(dou)暴露(lu)出了諸多(duo)問題(ti)。這(zhe)(zhe)種情況(kuang)下(xia)，從業(ye)(ye)務發(fa)展的角(jiao)度(du)出發(fa)，數據架構改(gai)造(zao)成為了當務之急。

本文(wen)匯總了(le)包括西(xi)門子、美的、拓斯達、和利時(shi)在內的四家比較(jiao)具有代表性的工(gong)業企業的架構改(gai)造案例(li)，一起(qi)來看看他們都是如何做(zuo)的，改(gai)造效(xiao)果是否達成了(le)預(yu)期。

西門子 x TDengine

“從高性能、高可用、低成本、高度一體化幾個目標出發，我們發現 TDengine 時序數據庫(Time Series DataBase)正好符合產品重構所有的要求，尤其是低成本和高度一體化這兩個點，這是目前絕大部分數據平臺或時序數據庫都不具備的。在確定選擇 TDengine 作為系統的實時數據庫后，我(wo)們在(zai) SIMICAS? OEM 2.0 版本中移除了Flink、Kafka 以及 Redis，系統(tong)架構大大簡化。”

SIMICAS? OEM 設(she)備(bei)(bei)遠程(cheng)運維套件(jian)是(shi)由 SIEMENS DE&DS DSM 團隊開發(fa)的(de)(de)一套面向設(she)備(bei)(bei)制造(zao)商的(de)(de)數(shu)字化解(jie)決(jue)方案(an)。在(zai)(zai)其 1.0 版中，團隊使用(yong)了 Flink + Kafka + PostgreSQL + Redis 的(de)(de)架構(gou)，因為(wei)(wei)引入(ru)了 Flink 和 Kafka，導致系統(tong)部署(shu)時非常繁瑣(suo)，服務器開銷巨大(da)；同時為(wei)(wei)了滿(man)足大(da)量數(shu)據(ju)的(de)(de)存儲問題，PostgreSQL 中不得不做分(fen)庫分(fen)表操作，應用(yong)程(cheng)序(xu)較(jiao)為(wei)(wei)復雜。這種情況下，如何降(jiang)低系統(tong)復雜度、減少硬件(jian)資源(yuan)開銷，幫助(zhu)客戶(hu)減少成(cheng)本，成(cheng)為(wei)(wei)研發(fa)團隊的(de)(de)核心(xin)任務。在(zai)(zai)調研過程(cheng)中，TDengine 脫穎而出。

架構圖

美的 x TDengine

“當前，TDengine 時序數據庫(TSDB) 主(zhu)要被應(ying)用于中(zhong)(zhong)央空調制(zhi)冷設備的監(jian)控業務(wu)中(zhong)(zhong)，作(zuo)(zuo)為先行試(shi)點，這(zhe)一場(chang)景(jing)已經取得(de)了不錯的效果。在(zai)樓宇智(zhi)能化方面，我們也有(you)很多(duo)工作(zuo)(zuo)要做，從(cong)邊緣側的監(jian)控、到指令控制(zhi)、再(zai)到邊云(yun)協同(tong)的一體化服務(wu)，我們會在(zai)這(zhe)些場(chang)景(jing)中(zhong)(zhong)繼續探(tan)索和(he)挖掘 TDengine 的潛力。”

業務背景

在 2021 樓(lou)宇(yu)科技 TRUE 大(da)會上，美的暖通與樓(lou)宇(yu)事業部首(shou)次發布了(le)數(shu)(shu)字化平臺(tai) iBuilding，以(yi)“軟驅硬核(he)”方式賦能建筑行(xing)業。作為(wei)一個全新的項目，iBuilding 在數(shu)(shu)據(ju)(ju)庫(ku)選型上比較謹慎，分別對比了(le)關系型數(shu)(shu)據(ju)(ju)庫(ku)（Relational Database）以(yi)及主流的時序(xu)數(shu)(shu)據(ju)(ju)庫(ku)（Time Series Database），包括 InfluxDB、TDengine、MySQL 等，因為(wei)在需求上更偏向于(yu)高效(xiao)的存(cun)儲(chu)和大(da)范(fan)圍(wei)時間(jian)的數(shu)(shu)據(ju)(ju)拉取，iBuilding 在綜(zong)合評估了(le)適配、查詢、寫入(ru)和存(cun)儲(chu)等綜(zong)合能力后，最終選擇了(le) TDengine。

架構圖

拓斯達 x TDengine

“運行一段時(shi)間(jian)(jian)后，TDengine 的(de)(de)查(cha)詢、寫(xie)入(ru)速度完全可以(yi)滿足我們目(mu)前(qian)的(de)(de)客戶需求，最慢的(de)(de)分(fen)鐘級，最快的(de)(de)能達到 1 秒(miao)一條(tiao)；一個(ge)設(she)備(bei)一天最多能寫(xie)入(ru)近(jin)十(shi)萬條(tiao)數(shu)(shu)據(ju)(ju)，近(jin)千(qian)個(ge)設(she)備(bei)同(tong)時(shi)寫(xie)入(ru)也(ye)完全沒(mei)有(you)問題，相(xiang)較(jiao)于(yu)之前(qian)，寫(xie)入(ru)速度提升了數(shu)(shu)十(shi)倍。查(cha)詢數(shu)(shu)據(ju)(ju)在(zai)以(yi)月為單位的(de)(de)時(shi)間(jian)(jian)范圍內也(ye)沒(mei)有(you)過于(yu)明(ming)顯的(de)(de)延(yan)遲(chi)，整體的(de)(de)數(shu)(shu)據(ju)(ju)壓(ya)縮比大概(gai)是 1/10，目(mu)前(qian)每天產生的(de)(de)數(shu)(shu)據(ju)(ju)量在(zai)數(shu)(shu) G 左(zuo)右。”

業務背景

在拓斯達的(de)(de)(de)業務中，傳統的(de)(de)(de)關(guan)系(xi)型數據(ju)(ju)(ju)庫已經無法(fa)高效處(chu)理時(shi)(shi)(shi)序(xu)數據(ju)(ju)(ju)，在加(jia)載、存(cun)儲(chu)和查詢等(deng)多(duo)個方面都遇到(dao)了挑戰，主要問題包括寫入吞(tun)吐低、存(cun)儲(chu)成本大(da)、維護成本高、查詢性(xing)能差。為(wei)了更好地滿足時(shi)(shi)(shi)序(xu)數據(ju)(ju)(ju)的(de)(de)(de)處(chu)理需求(qiu)，拓斯達開(kai)始進行數據(ju)(ju)(ju)庫選型調研，他們(men)發現，TDengine 專(zhuan)為(wei)時(shi)(shi)(shi)序(xu)數據(ju)(ju)(ju)庫所打造和優化的(de)(de)(de)寫入、存(cun)儲(chu)、查詢等(deng)功能，非常(chang)匹配工業傳感器數據(ju)(ju)(ju)的(de)(de)(de)應用分析場景，最終其(qi)使用 TDengine 搭建了新(xin)的(de)(de)(de)數據(ju)(ju)(ju)處(chu)理架構。

架構實現思路

通過網關采集設備數據(ju)(ju)推送(song)到(dao) MQTT，Java 后(hou)(hou)(hou)端(duan)(duan)監聽(ting)到(dao)后(hou)(hou)(hou)會(hui)寫入(ru) TDengine，在后(hou)(hou)(hou)端(duan)(duan)按需求查詢處理(li)(li)后(hou)(hou)(hou)再把數據(ju)(ju)返回(hui)給前(qian)(qian)端(duan)(duan)。具(ju)體來說，網關會(hui)先讀取后(hou)(hou)(hou)臺發布的上(shang)行規(gui)則，在采集到(dao)設備數據(ju)(ju)后(hou)(hou)(hou)，使用(yong)上(shang)行規(gui)則對數據(ju)(ju)進(jin)行處理(li)(li)計算后(hou)(hou)(hou)再將結果返回(hui)給下行規(gui)則模(mo)塊，后(hou)(hou)(hou)臺監聽(ting)到(dao)后(hou)(hou)(hou)，會(hui)連接 TDengine 進(jin)行數據(ju)(ju)庫表的創建修改和(he)數據(ju)(ju)寫入(ru)。之前(qian)(qian)在云平臺拓(tuo)斯達(da)使用(yong)過 Kafka 進(jin)行數據(ju)(ju)的發布訂閱，現在所(suo)有環(huan)境都(dou)改為(wei) MQTT 了。

點擊【】查看更(geng)多(duo)技術細(xi)節

和利時 x TDengine

“在(zai)測(ce)試(shi)階(jie)段，我們發現，同(tong)等條件下，TDengine 的(de)壓縮率最(zui)高(gao)，數(shu)據(ju)占用的(de)存儲空(kong)間(jian)最(zui)小；在(zai)原始數(shu)據(ju)查詢(xun)上，OpenTSDB 最(zui)慢，TDengine 與(yu) HolliTSDB 在(zai)伯仲之間(jian)；在(zai)聚合(he)查詢(xun)操作上，TDengine 最(zui)快，HolliTSDB 的(de)速度和(he) InfluxDB 相當(dang)，OpenTSDB 最(zui)慢。同(tong)時，InfluxDB 只能單機部署，集(ji)群版本并未開源，且查詢(xun)性能存在(zai)瓶頸，其 QPS 約為 30-50。”

業務背景

在(zai)(zai)物聯網場(chang)景下，面對龐大的(de)(de)時序(xu)數(shu)(shu)據處理需(xu)求，Oracle、PostgreSQL 等(deng)(deng)(deng)傳統關系型數(shu)(shu)據庫(ku)(ku)越來越吃力，因此和利時開始進行時序(xu)數(shu)(shu)據庫(ku)(ku)的(de)(de)選型，對包括 InfluxDB、OpenTSDB、HolliTSDB（和利時自研(yan)時序(xu)數(shu)(shu)據庫(ku)(ku)）和 TDengine 在(zai)(zai)內(nei)的(de)(de)四款(kuan)(kuan)時序(xu)數(shu)(shu)據庫(ku)(ku)進行了(le)選型調研(yan)及相關測(ce)試。測(ce)試結(jie)果顯示，在(zai)(zai)同等(deng)(deng)(deng)條件下，TDengine 在(zai)(zai)查詢、存儲(chu)等(deng)(deng)(deng)方面均優于其他幾款(kuan)(kuan)數(shu)(shu)據庫(ku)(ku)，最終和利時決定(ding)接入 TDengine，以享受更多元的(de)(de)本地(di)化支持和響應。

架構圖

結語

從以上案例中(zhong)不(bu)難看出，在(zai)工業(ye)互聯網場景下，面對龐(pang)大的時(shi)序(xu)數(shu)據(ju)處(chu)理需(xu)求，專(zhuan)業(ye)的時(shi)序(xu)數(shu)據(ju)庫(ku)顯然比傳統(tong)的關系型數(shu)據(ju)庫(ku)效果更加明顯，上述(shu)企業(ye)案例在(zai)架構改造之后，確實達到(dao)了更高程度的降本增效。如果你有同(tong)樣的困擾，歡(huan)迎(ying)點擊下方卡(ka)片，加入 TDengine 用戶交流群(qun)，和專(zhuan)業(ye)的解(jie)決方案架構師點對點溝通。