在工業(yè)領(lǐng)域， 生產(chǎn)、測試、運(yùn)行階段都可能會產(chǎn)生大量帶有時間戳的傳感器數(shù)據(jù)，這都屬于典型的時序數(shù)據(jù)。時序數(shù)據(jù)主要由各類型實時監(jiān)測、檢查與分析設(shè)備所采集或產(chǎn)生，涉及制造、電力、化工、工程作業(yè)等多個行業(yè)，具備寫多讀少、量非常大等典型特性。如 Apache HBase、MySQL 等互聯(lián)網(wǎng)公司常用的數(shù)據(jù)庫在寫入、存儲、查詢、運(yùn)維等方面都暴露出了諸多問題。這種情況下，從業(yè)務(wù)發(fā)展的角度出發(fā)，數(shù)據(jù)架構(gòu)改造成為了當(dāng)務(wù)之急。

本文匯總了包括西門子、美的、拓斯達(dá)、和利時在內(nèi)的四家比較具有代表性的工業(yè)企業(yè)的架構(gòu)改造案例，一起來看看他們都是如何做的，改造效果是否達(dá)成了預(yù)期。

西門子 x TDengine

“從高性能、高可用、低成本、高度一體化幾個目標(biāo)出發(fā)，我們發(fā)現(xiàn) TDengine 時序數(shù)據(jù)庫(Time Series DataBase)正好符合產(chǎn)品重構(gòu)所有的要求，尤其是低成本和高度一體化這兩個點(diǎn)，這是目前絕大部分?jǐn)?shù)據(jù)平臺或時序數(shù)據(jù)庫都不具備的。在確定選擇 TDengine 作為系統(tǒng)的實時數(shù)據(jù)庫后，我們在 SIMICAS? OEM 2.0 版本中移除了Flink、Kafka 以及 Redis，系統(tǒng)架構(gòu)大大簡化?！?/p>

SIMICAS? OEM 設(shè)備遠(yuǎn)程運(yùn)維套件是由 SIEMENS DE&DS DSM 團(tuán)隊開發(fā)的一套面向設(shè)備制造商的數(shù)字化解決方案。在其 1.0 版中，團(tuán)隊使用了 Flink + Kafka + PostgreSQL + Redis 的架構(gòu)，因為引入了 Flink 和 Kafka，導(dǎo)致系統(tǒng)部署時非常繁瑣，服務(wù)器開銷巨大；同時為了滿足大量數(shù)據(jù)的存儲問題，PostgreSQL 中不得不做分庫分表操作，應(yīng)用程序較為復(fù)雜。這種情況下，如何降低系統(tǒng)復(fù)雜度、減少硬件資源開銷，幫助客戶減少成本，成為研發(fā)團(tuán)隊的核心任務(wù)。在調(diào)研過程中，TDengine 脫穎而出。

架構(gòu)圖

美的 x TDengine

“當(dāng)前，TDengine 時序數(shù)據(jù)庫(TSDB) 主要被應(yīng)用于中央空調(diào)制冷設(shè)備的監(jiān)控業(yè)務(wù)中，作為先行試點(diǎn)，這一場景已經(jīng)取得了不錯的效果。在樓宇智能化方面，我們也有很多工作要做，從邊緣側(cè)的監(jiān)控、到指令控制、再到邊云協(xié)同的一體化服務(wù)，我們會在這些場景中繼續(xù)探索和挖掘 TDengine 的潛力。”

業(yè)務(wù)背景

在 2021 樓宇科技 TRUE 大會上，美的暖通與樓宇事業(yè)部首次發(fā)布了數(shù)字化平臺 iBuilding，以“軟驅(qū)硬核”方式賦能建筑行業(yè)。作為一個全新的項目，iBuilding 在數(shù)據(jù)庫選型上比較謹(jǐn)慎，分別對比了關(guān)系型數(shù)據(jù)庫（Relational Database）以及主流的時序數(shù)據(jù)庫（Time Series Database），包括 InfluxDB、TDengine、MySQL 等，因為在需求上更偏向于高效的存儲和大范圍時間的數(shù)據(jù)拉取，iBuilding 在綜合評估了適配、查詢、寫入和存儲等綜合能力后，最終選擇了 TDengine。

架構(gòu)圖

拓斯達(dá) x TDengine

“運(yùn)行一段時間后，TDengine 的查詢、寫入速度完全可以滿足我們目前的客戶需求，最慢的分鐘級，最快的能達(dá)到 1 秒一條；一個設(shè)備一天最多能寫入近十萬條數(shù)據(jù)，近千個設(shè)備同時寫入也完全沒有問題，相較于之前，寫入速度提升了數(shù)十倍。查詢數(shù)據(jù)在以月為單位的時間范圍內(nèi)也沒有過于明顯的延遲，整體的數(shù)據(jù)壓縮比大概是 1/10，目前每天產(chǎn)生的數(shù)據(jù)量在數(shù) G 左右。”

業(yè)務(wù)背景

在拓斯達(dá)的業(yè)務(wù)中，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫已經(jīng)無法高效處理時序數(shù)據(jù)，在加載、存儲和查詢等多個方面都遇到了挑戰(zhàn)，主要問題包括寫入吞吐低、存儲成本大、維護(hù)成本高、查詢性能差。為了更好地滿足時序數(shù)據(jù)的處理需求，拓斯達(dá)開始進(jìn)行數(shù)據(jù)庫選型調(diào)研，他們發(fā)現(xiàn)，TDengine 專為時序數(shù)據(jù)庫所打造和優(yōu)化的寫入、存儲、查詢等功能，非常匹配工業(yè)傳感器數(shù)據(jù)的應(yīng)用分析場景，最終其使用 TDengine 搭建了新的數(shù)據(jù)處理架構(gòu)。

架構(gòu)實現(xiàn)思路

通過網(wǎng)關(guān)采集設(shè)備數(shù)據(jù)推送到 MQTT，Java 后端監(jiān)聽到后會寫入 TDengine，在后端按需求查詢處理后再把數(shù)據(jù)返回給前端。具體來說，網(wǎng)關(guān)會先讀取后臺發(fā)布的上行規(guī)則，在采集到設(shè)備數(shù)據(jù)后，使用上行規(guī)則對數(shù)據(jù)進(jìn)行處理計算后再將結(jié)果返回給下行規(guī)則模塊，后臺監(jiān)聽到后，會連接 TDengine 進(jìn)行數(shù)據(jù)庫表的創(chuàng)建修改和數(shù)據(jù)寫入。之前在云平臺拓斯達(dá)使用過 Kafka 進(jìn)行數(shù)據(jù)的發(fā)布訂閱，現(xiàn)在所有環(huán)境都改為 MQTT 了。

點(diǎn)擊【案例】查看更多技術(shù)細(xì)節(jié)

和利時 x TDengine

“在測試階段，我們發(fā)現(xiàn)，同等條件下，TDengine 的壓縮率最高，數(shù)據(jù)占用的存儲空間最??；在原始數(shù)據(jù)查詢上，OpenTSDB 最慢，TDengine 與 HolliTSDB 在伯仲之間；在聚合查詢操作上，TDengine 最快，HolliTSDB 的速度和 InfluxDB 相當(dāng)，OpenTSDB 最慢。同時，InfluxDB 只能單機(jī)部署，集群版本并未開源，且查詢性能存在瓶頸，其 QPS 約為 30-50?！?/p>

業(yè)務(wù)背景

在物聯(lián)網(wǎng)場景下，面對龐大的時序數(shù)據(jù)處理需求，Oracle、PostgreSQL 等傳統(tǒng)關(guān)系型數(shù)據(jù)庫越來越吃力，因此和利時開始進(jìn)行時序數(shù)據(jù)庫的選型，對包括 InfluxDB、OpenTSDB、HolliTSDB（和利時自研時序數(shù)據(jù)庫）和 TDengine 在內(nèi)的四款時序數(shù)據(jù)庫進(jìn)行了選型調(diào)研及相關(guān)測試。測試結(jié)果顯示，在同等條件下，TDengine 在查詢、存儲等方面均優(yōu)于其他幾款數(shù)據(jù)庫，最終和利時決定接入 TDengine，以享受更多元的本地化支持和響應(yīng)。

架構(gòu)圖

結(jié)語

從以上案例中不難看出，在工業(yè)互聯(lián)網(wǎng)場景下，面對龐大的時序數(shù)據(jù)處理需求，專業(yè)的時序數(shù)據(jù)庫顯然比傳統(tǒng)的關(guān)系型數(shù)據(jù)庫效果更加明顯，上述企業(yè)案例在架構(gòu)改造之后，確實達(dá)到了更高程度的降本增效。如果你有同樣的困擾，歡迎點(diǎn)擊下方卡片，加入 TDengine 用戶交流群，和專業(yè)的解決方案架構(gòu)師點(diǎn)對點(diǎn)溝通。