煤(mei)礦行業具備產業規模大、分(fen)布地域廣(guang)、安(an)全性要求(qiu)高(gao)等特(te)點，而大部分(fen)煤(mei)礦系(xi)(xi)統都是獨立運行的(de)，為了實現各個系(xi)(xi)統數(shu)據的(de)有效利用和深度融合，以(yi)此達成(cheng)預警、數(shu)據分(fen)析(xi)等目的(de)，煤(mei)礦行業亟(ji)需(xu)智能化賦能。在擁抱工業物聯網、人工智能、大數(shu)據等新技術的(de)同時，其智能化發展道路也面臨著眾(zhong)多挑戰(zhan)：

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

從以上挑戰出發，一些煤礦企業已經開始進行數據架構轉型實踐，也取得了一些進展，值得一提的是，時序數據庫（Time Series Database）在其(qi)中(zhong)發揮了(le)重要作用。本文將這些(xie)案例進(jin)行了(le)相關匯總，供讀者參考(kao)。

TDengine x 智慧礦山系統

“我們(men)以智(zhi)慧礦山(shan)業務中(zhong)的(de) 5000 設(she)備(bei)、每天(tian) 1000 萬(wan)采集點的(de)數據量級(ji)下(xia)，在(zai)以車(che)建(jian)模和以位(wei)置建(jian)模結合的(de)數據模型下(xia)，TDengine 的(de)性能遠沒有達到極限，目前系統(tong)對于(yu)車(che)和位(wei)置的(de)查詢速度(du)都在(zai)毫(hao)秒(miao)級(ji)。基于(yu)目前對 TDengine 的(de)理解和使(shi)用(yong)經驗，我們(men)計(ji)劃在(zai)環(huan)保監測和生產(chan)集控(kong)設(she)備(bei)場(chang)景中(zhong)進一步使(shi)用(yong)它來完善(shan)系統(tong)。”

業務背景

元智信息的智慧礦山項目需要一款實時數據庫來支撐起生產交互管控系統的(de)(de)采運(yun)排環(huan)節(jie)所(suo)有過程設備(bei)的(de)(de)采集(ji)、存儲、計算和監控功(gong)能。這些數(shu)據(ju)(ju)(ju)涵蓋范圍廣，包括挖(wa)機(ji)、卡車的(de)(de)采集(ji)數(shu)據(ju)(ju)(ju)、調度管理數(shu)據(ju)(ju)(ju)、設備(bei) GPS 信息、以及每一個固定位(wei)置工序的(de)(de)采集(ji)數(shu)據(ju)(ju)(ju)等(deng)。在 MySQL、InfluxDB集(ji)群版(ban)、TDengine 的(de)(de)時序數(shu)據(ju)(ju)(ju)庫選型調研中(zhong)，TDengine 脫穎而出（點擊(ji)下方案例查看具體(ti)原因）。

架構圖

TDengine x 陜煤礦山項目

“最(zui)終(zhong)落地時項目(mu)采(cai)用(yong)了(le) 3 個節點的集群(qun)環境，定(ding)位(wei)設備采(cai)用(yong)超級(ji)表進行(xing)管(guan)理，將數據標簽及數據類型(xing)作為(wei) tag 區分各類定(ding)位(wei)設備。每個定(ding)位(wei)設備采(cai)用(yong)子表存(cun)儲，實際(ji)(ji)項目(mu)已包含 2 萬多個定(ding)位(wei)設備。從寫(xie)入(ru)性(xing)能到(dao)查(cha)詢性(xing)能均大幅(fu)滿足現場實際(ji)(ji)需求：總(zong)計定(ding)位(wei)數據量超過 11 億(yi)條(tiao)，數據壓縮后 TDengine 數據目(mu)錄占用(yong)磁盤大約 12GB，整體壓縮率可以(yi)達(da)到(dao) 3/100。”

業務背景

為打通煤礦(kuang)生產環境中各類單一子(zi)(zi)系(xi)統(tong)之間的數(shu)據(ju)(ju)(ju)壁(bi)壘，實(shi)現各類子(zi)(zi)系(xi)統(tong)數(shu)據(ju)(ju)(ju)之間的互聯互通，陜煤開發團隊(dui)打造了全礦(kuang)井數(shu)字(zi)化平臺。以位(wei)置數(shu)據(ju)(ju)(ju)為例，由于初期(qi)系(xi)統(tong)容量較(jiao)小且硬(ying)件設備上傳(chuan)周(zhou)(zhou)期(qi)較(jiao)大，所以采用(yong)了傳(chuan)統(tong)的 SQL Server 數(shu)據(ju)(ju)(ju)庫(ku)(ku)來進行軌跡數(shu)據(ju)(ju)(ju)存(cun)儲(chu)。隨著后(hou)續項目迭代(dai)，硬(ying)件設備定位(wei)精(jing)度提高且上報周(zhou)(zhou)期(qi)縮短，也導致數(shu)據(ju)(ju)(ju)庫(ku)(ku)存(cun)儲(chu)壓力增大。考慮到數(shu)據(ju)(ju)(ju)類型及特點，其決定使用(yong)時(shi)序(xu)數(shu)據(ju)(ju)(ju)庫(ku)(ku)，在 OpenTSDB、TDengine、InfluxDB 三款數(shu)據(ju)(ju)(ju)庫(ku)(ku)中做選(xuan)型調研。

架構圖

TDengine x 華夏天信露天煤礦

“對于每個(ge)電機，客(ke)戶要求系統能(neng)夠(gou)快速讀取相關設(she)備屬性趨勢圖，這(zhe)是我(wo)們發現 TDengine 最強(qiang)大的地方：針對一天(tian) 2 萬條數(shu)據(ju)(ju)展(zhan)示(shi)速度(du)在 200ms 內(nei)。之所以 TDengine 對這(zhe)類查詢(xun)速度(du)飛(fei)快，主(zhu)要是設(she)計時按照設(she)備分(fen)表后，數(shu)據(ju)(ju)按塊存(cun)儲并(bing)按塊查出來，相對 Key-Value 型數(shu)據(ju)(ju)庫節省很多尋址時間。”

業務背景

華(hua)夏天信 RED-MOS 露天煤礦(kuang)(kuang)智慧礦(kuang)(kuang)山操作系統，在對接某(mou)地面生(sheng)產集(ji)(ji)控系統數(shu)(shu)據時，接入的監控點數(shu)(shu)量(liang)(liang)將近 1 萬 5 千點，其(qi)中接近 2300 點需要綁定(ding)組態顯示(shi)，即時頁面更新，整體數(shu)(shu)據采集(ji)(ji)到顯示(shi)到前端(duan)要求秒級(ji)展(zhan)示(shi)及(ji)大(da)數(shu)(shu)據量(liang)(liang)展(zhan)示(shi)（歷史數(shu)(shu)據回溯），可展(zhan)示(shi) 30 天的全量(liang)(liang)數(shu)(shu)據，點數(shu)(shu)量(liang)(liang)超過 50 萬條，讀取時間要求在 5~10 s，這(zhe)對底層(ceng)的數(shu)(shu)據庫(ku)提出(chu)了一個相當大(da)的挑戰。

這(zhe)種場景中，最(zui)大(da)(da)難點(dian)是要處理的(de)(de)數據(ju)量太大(da)(da)，而不是關聯(lian)關系復雜(za)，因此 MySQL 這(zhe)類關系庫(ku)的(de)(de)關聯(lian)查詢優勢其(qi)實(shi)無法(fa)發揮(hui)，而 HBase 這(zhe)種大(da)(da)數據(ju)存(cun)儲(chu)方案對于(yu)礦山系統而言又太過龐大(da)(da)，且硬(ying)件(jian)資源要求很多，出于(yu)成(cheng)本考慮也排除了(le)。最(zui)終其(qi)選擇了(le) TDengine，解決了(le)最(zui)為頭疼的(de)(de)歷史數據(ju)回溯性能問(wen)題。

效果展示

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

結語

對于礦山生產系統而言，安全是第一位的，基于此，各個生產環節和場地都要進行全面、有效的數字化監控，這些監控數據的特點就是時序、結構化、簡單但量大。作為時序數據庫賽道中的重量級選手，再從煤礦企業的實踐效果出發，TDengine時序數據庫(TSDB)就是為助力煤礦行業(ye)智能化發展(zhan)而量(liang)身(shen)定做的數(shu)據(ju)庫(ku)。