導(dǎo)讀：在拓斯達(dá)的智能工廠整體解決方案項目中，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫已經(jīng)無法高效處理時序數(shù)據(jù)，在加載、存儲和查詢等多個方面都遇到了挑戰(zhàn)，最終他們選擇了 TDengine 來匹配工業(yè)傳感器數(shù)據(jù)的應(yīng)用分析場景。本文將講述他們應(yīng)用 TDengine 的具體實踐。
企業(yè)簡介
廣東拓斯達(dá)科技股份有限公司(簡稱：拓斯達(dá)，股票代碼：300607)是廣東省首家登陸創(chuàng)業(yè)板的機(jī)器人骨干企業(yè)。拓斯達(dá)堅持“讓工業(yè)制造更美好”的企業(yè)使命，通過以工業(yè)機(jī)器人、注塑機(jī)、CNC為核心的智能裝備，以及控制、伺服、視覺三大核心技術(shù)，打造以核心技術(shù)驅(qū)動的智能硬件平臺，為制造企業(yè)提供智能工廠整體解決方案。
項目介紹
在工業(yè)領(lǐng)域， 生產(chǎn)、測試、運行階段都可能會產(chǎn)生大量帶有時間戳的傳感器數(shù)據(jù)，這都屬于典型的時序數(shù)據(jù)。時序數(shù)據(jù)主要由各類型實時監(jiān)測、檢查與分析設(shè)備所采集或產(chǎn)生，涉及制造、電力、化工、工程作業(yè)等多個行業(yè)，具備寫多讀少、量非常大等典型特性。
在我們的業(yè)務(wù)中，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(Relational Database)已經(jīng)無法高效處理時序數(shù)據(jù)，在加載、存儲和查詢等多個方面都遇到了挑戰(zhàn)。主要問題可以匯總?cè)缦拢?/FONT>
● 寫入吞吐低：單機(jī)寫入吞吐量低，很難滿足時序數(shù)據(jù)千萬級的寫入壓力;
● 存儲成本大：在對時序數(shù)據(jù)進(jìn)行壓縮時性能不佳，需占用大量機(jī)器資源;
● 維護(hù)成本高：單機(jī)系統(tǒng)，需要在上層人工進(jìn)行分庫分表，維護(hù)成本高;
● 查詢性能差：海量實時數(shù)據(jù)的聚合分析性能差。
為了更好地滿足時序數(shù)據(jù)的處理需求，我們決定進(jìn)行數(shù)據(jù)庫選型調(diào)研，最終選擇了時序數(shù)據(jù)庫(Time-Series Database)TDengine。事實證明，TDengine 針對時序數(shù)據(jù)的寫入、存儲、索引、查詢等方面都進(jìn)行了特定的優(yōu)化，從而實現(xiàn)了更優(yōu)的數(shù)據(jù)加載、數(shù)據(jù)壓縮、查詢寫入性能，非常匹配工業(yè)傳感器數(shù)據(jù)的應(yīng)用分析場景。
01、選擇 TDengine 的理由
與通用數(shù)據(jù)庫相比，TDengine 的壓縮率表現(xiàn)驚人，核心原因是其采用列式存儲，而且采用了二階段壓縮策略，還針對不同數(shù)據(jù)類型采取了不同的壓縮算法，這種壓縮機(jī)制使其壓縮率遠(yuǎn)超其他數(shù)據(jù)庫。
此外 TDengine 還擁有極高的讀寫性能，并且讀寫速度受數(shù)據(jù)存儲規(guī)模的影響微乎其微，要知道通用數(shù)據(jù)庫的數(shù)據(jù)量一旦過百萬級，讀寫速度就會有明顯下降，之前我們做過一次 MySQL 批量插入數(shù)據(jù)的測試，性能差距明顯，這也是在大量級數(shù)據(jù)存儲下我們會選擇 TDengine 的重要原因之一。具體來說，TDengine 優(yōu)勢如下：
● 數(shù)據(jù)的讀寫速度快且自帶時間戳，使用 SQL 進(jìn)行數(shù)據(jù)庫操作，簡單易學(xué)，支持復(fù)雜查詢
● 數(shù)據(jù)壓縮率高，大量級的數(shù)據(jù)也不會占據(jù)過多存儲空間，可導(dǎo)出數(shù)據(jù)進(jìn)行備份
● 擁有交流社區(qū)和交流群，遇見問題可以和 TDengine 的其他使用者一起探討，而且官方的同學(xué)也能提供及時的幫助
當(dāng)然，世上沒有完美的數(shù)據(jù)庫，我們在應(yīng)用之后總結(jié)出了兩點待改進(jìn)的地方：
● 無法使用可視化軟件如 Navicat 等進(jìn)行數(shù)據(jù)庫操作(TDengine GUI)
● 目前還沒有 Windows 版的服務(wù)端，像我們上一個客戶，只在本地 Windows 上使用程序，在沒有安裝虛擬機(jī)和部署到服務(wù)器的情況下，就無法部署 TDengine
但每一款產(chǎn)品都是在發(fā)現(xiàn)問題和改進(jìn)問題的步伐中逐漸進(jìn)步的，而且對于我們的業(yè)務(wù)實現(xiàn)來說，TDengine 不存在明顯的短板。沒有最優(yōu)的數(shù)據(jù)庫，在場景匹配的情況下，我們最終采用了 TDengine。
02、落地實踐
● 平臺架構(gòu)
我們是通過網(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ù)寫入。之前在云平臺我們使用過 Kafka 進(jìn)行數(shù)據(jù)的發(fā)布訂閱，現(xiàn)在所有環(huán)境都改為 MQTT 了。
● 超級表及建模思路
在應(yīng)用 TDengine 時，我們建立了流水?dāng)?shù)據(jù)庫 "iot_platform" 用來存儲網(wǎng)關(guān)傳來的數(shù)據(jù)，便于日后查詢使用。我們遵循“一個采集點一張表，一類數(shù)據(jù)一個超級表”的思路來建表，在具體實踐上設(shè)計了兩張超級表，一張是用于存儲 log 指令內(nèi)容的“l(fā)ogs”表，另一張是用于存儲其它指令內(nèi)容的“datas”表，數(shù)據(jù)類型基本為電流電壓、設(shè)備狀態(tài)等。在進(jìn)行數(shù)據(jù)存儲時首先會對數(shù)據(jù)加以判斷，再決定將數(shù)據(jù)存儲到哪張表里。
03、落地效果
運行一段時間后，TDengine 的查詢、寫入速度完全可以滿足我們目前的客戶需求，最慢的分鐘級，最快的能達(dá)到 1 秒一條;一個設(shè)備一天最多能寫入近十萬條數(shù)據(jù)，近千個設(shè)備同時寫入也完全沒有問題，相較于之前，寫入速度提升了數(shù)十倍。查詢數(shù)據(jù)在以月為單位的時間范圍內(nèi)沒有過于明顯的延遲，整體的數(shù)據(jù)壓縮比大概是 1/10，目前每天產(chǎn)生的數(shù)據(jù)量在數(shù) G 左右。
● 流水?dāng)?shù)據(jù)查詢
查詢某一時間段內(nèi)的流水?dāng)?shù)據(jù)，使用查詢語句：
● 聚合函數(shù)計算一天的數(shù)據(jù)
使用 TDengine 的函數(shù)計算每天的用電量，再通過每天的去計算月和年數(shù)據(jù)，查詢語句為：
● 計算某一時間段內(nèi)的數(shù)據(jù)
04、寫在最后
在工業(yè)互聯(lián)網(wǎng)快速發(fā)展的大背景下，工業(yè)生產(chǎn)現(xiàn)場投放了大量的設(shè)備傳感器和監(jiān)控系統(tǒng)，二者提供的實時數(shù)據(jù)能夠反映設(shè)備的狀態(tài)和生產(chǎn)的進(jìn)度，其中的大多數(shù)據(jù)都是按照時間順序形成的實時數(shù)據(jù)，這些海量實時數(shù)據(jù)有著多樣化的分析需求和重要的參考價值。
未來希望 TDengine 可以提供更復(fù)雜的流式計算、查詢分析以及監(jiān)測預(yù)警等能力，可以為產(chǎn)品的可視化運維、預(yù)測性維護(hù)、遠(yuǎn)程智能管理等方面提供數(shù)據(jù)依據(jù)，從而降低人員、時間等成本，加速工業(yè)化與信息化的深度融合，促進(jìn)復(fù)雜重型裝備制造業(yè)的轉(zhuǎn)型升級，產(chǎn)生社會經(jīng)濟(jì)效益。
（轉(zhuǎn)載）
