煤礦行業(yè)具備產(chǎn)業(yè)規(guī)模大、分布地域廣、安全性要求高等特點，而大部分煤礦系統(tǒng)都是獨(dú)立運(yùn)行的，為了實現(xiàn)各個系統(tǒng)數(shù)據(jù)的有效利用和深度融合，以此達(dá)成預(yù)警、數(shù)據(jù)分析等目的，煤礦行業(yè)亟需智能化賦能。在擁抱工業(yè)物聯(lián)網(wǎng)、人工智能、大數(shù)據(jù)等新技術(shù)的同時，其智能化發(fā)展道路也面臨著眾多挑戰(zhàn)：

• 一是設(shè)備管理層面的挑戰(zhàn)，隨著自動化程度越來越高，設(shè)備復(fù)雜度和管理難度也逐步增大，如何保障設(shè)備安全可靠的運(yùn)行，提升設(shè)備的利用率，促進(jìn)設(shè)備保值增值也成了挑戰(zhàn)之一；
• 二是安全生產(chǎn)的挑戰(zhàn)，安全是根本，如何通過數(shù)字化手段，將人和物的不安全因素統(tǒng)一管理好，提升整體煤礦企業(yè)安全生產(chǎn)水平至關(guān)重要。

從以上挑戰(zhàn)出發(fā)，一些煤礦企業(yè)已經(jīng)開始進(jìn)行數(shù)據(jù)架構(gòu)轉(zhuǎn)型實踐，也取得了一些進(jìn)展，值得一提的是，時序數(shù)據(jù)庫（Time Series Database）在其中發(fā)揮了重要作用。本文將這些案例進(jìn)行了相關(guān)匯總，供讀者參考。

TDengine x 智慧礦山系統(tǒng)

“我們以智慧礦山業(yè)務(wù)中的 5000 設(shè)備、每天 1000 萬采集點的數(shù)據(jù)量級下，在以車建模和以位置建模結(jié)合的數(shù)據(jù)模型下，TDengine 的性能遠(yuǎn)沒有達(dá)到極限，目前系統(tǒng)對于車和位置的查詢速度都在毫秒級?；谀壳皩?TDengine 的理解和使用經(jīng)驗，我們計劃在環(huán)保監(jiān)測和生產(chǎn)集控設(shè)備場景中進(jìn)一步使用它來完善系統(tǒng)?！?/p>

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

元智信息的智慧礦山項目需要一款實時數(shù)據(jù)庫來支撐起生產(chǎn)交互管控系統(tǒng)的采運(yùn)排環(huán)節(jié)所有過程設(shè)備的采集、存儲、計算和監(jiān)控功能。這些數(shù)據(jù)涵蓋范圍廣，包括挖機(jī)、卡車的采集數(shù)據(jù)、調(diào)度管理數(shù)據(jù)、設(shè)備 GPS 信息、以及每一個固定位置工序的采集數(shù)據(jù)等。在 MySQL、InfluxDB集群版、TDengine 的時序數(shù)據(jù)庫選型調(diào)研中，TDengine 脫穎而出（點擊下方案例查看具體原因）。

架構(gòu)圖

TDengine x 陜煤礦山項目

“最終落地時項目采用了 3 個節(jié)點的集群環(huán)境，定位設(shè)備采用超級表進(jìn)行管理，將數(shù)據(jù)標(biāo)簽及數(shù)據(jù)類型作為 tag 區(qū)分各類定位設(shè)備。每個定位設(shè)備采用子表存儲，實際項目已包含 2 萬多個定位設(shè)備。從寫入性能到查詢性能均大幅滿足現(xiàn)場實際需求：總計定位數(shù)據(jù)量超過 11 億條，數(shù)據(jù)壓縮后 TDengine 數(shù)據(jù)目錄占用磁盤大約 12GB，整體壓縮率可以達(dá)到 3/100?！?/p>

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

為打通煤礦生產(chǎn)環(huán)境中各類單一子系統(tǒng)之間的數(shù)據(jù)壁壘，實現(xiàn)各類子系統(tǒng)數(shù)據(jù)之間的互聯(lián)互通，陜煤開發(fā)團(tuán)隊打造了全礦井?dāng)?shù)字化平臺。以位置數(shù)據(jù)為例，由于初期系統(tǒng)容量較小且硬件設(shè)備上傳周期較大，所以采用了傳統(tǒng)的 SQL Server 數(shù)據(jù)庫來進(jìn)行軌跡數(shù)據(jù)存儲。隨著后續(xù)項目迭代，硬件設(shè)備定位精度提高且上報周期縮短，也導(dǎo)致數(shù)據(jù)庫存儲壓力增大?？紤]到數(shù)據(jù)類型及特點，其決定使用時序數(shù)據(jù)庫，在 OpenTSDB、TDengine、InfluxDB 三款數(shù)據(jù)庫中做選型調(diào)研。

架構(gòu)圖

TDengine x 華夏天信露天煤礦

“對于每個電機(jī)，客戶要求系統(tǒng)能夠快速讀取相關(guān)設(shè)備屬性趨勢圖，這是我們發(fā)現(xiàn) TDengine 最強(qiáng)大的地方：針對一天 2 萬條數(shù)據(jù)展示速度在 200ms 內(nèi)。之所以 TDengine 對這類查詢速度飛快，主要是設(shè)計時按照設(shè)備分表后，數(shù)據(jù)按塊存儲并按塊查出來，相對 Key-Value 型數(shù)據(jù)庫節(jié)省很多尋址時間?！?/p>

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

華夏天信 RED-MOS 露天煤礦智慧礦山操作系統(tǒng)，在對接某地面生產(chǎn)集控系統(tǒng)數(shù)據(jù)時，接入的監(jiān)控點數(shù)量將近 1 萬 5 千點，其中接近 2300 點需要綁定組態(tài)顯示，即時頁面更新，整體數(shù)據(jù)采集到顯示到前端要求秒級展示及大數(shù)據(jù)量展示（歷史數(shù)據(jù)回溯），可展示 30 天的全量數(shù)據(jù)，點數(shù)量超過 50 萬條，讀取時間要求在 5~10 s，這對底層的數(shù)據(jù)庫提出了一個相當(dāng)大的挑戰(zhàn)。

這種場景中，最大難點是要處理的數(shù)據(jù)量太大，而不是關(guān)聯(lián)關(guān)系復(fù)雜，因此 MySQL 這類關(guān)系庫的關(guān)聯(lián)查詢優(yōu)勢其實無法發(fā)揮，而 HBase 這種大數(shù)據(jù)存儲方案對于礦山系統(tǒng)而言又太過龐大，且硬件資源要求很多，出于成本考慮也排除了。最終其選擇了 TDengine，解決了最為頭疼的歷史數(shù)據(jù)回溯性能問題。

效果展示

TDengine 能夠滿足大數(shù)據(jù)量展示的需求——可展示 30 天的全量數(shù)據(jù)，點數(shù)量超過 50 萬條，讀取時間要求 5 秒級。

結(jié)語

對于礦山生產(chǎn)系統(tǒng)而言，安全是第一位的，基于此，各個生產(chǎn)環(huán)節(jié)和場地都要進(jìn)行全面、有效的數(shù)字化監(jiān)控，這些監(jiān)控數(shù)據(jù)的特點就是時序、結(jié)構(gòu)化、簡單但量大。作為時序數(shù)據(jù)庫賽道中的重量級選手，再從煤礦企業(yè)的實踐效果出發(fā)，TDengine時序數(shù)據(jù)庫(TSDB)就是為助力煤礦行業(yè)智能化發(fā)展而量身定做的數(shù)據(jù)庫。