小 T 導(dǎo)讀：華夏天信RED-MOS露天煤礦智慧礦山操作系統(tǒng)，基于微服務(wù)架構(gòu)，結(jié)合HTAP混合大數(shù)據(jù)平臺，將產(chǎn)、運、銷各環(huán)節(jié)的生產(chǎn)與成本數(shù)據(jù)進行深度的挖掘和分析。TDengine Database是當前RED-MOS系統(tǒng)底層采用的測點數(shù)據(jù)存儲引擎，解決了我們最為頭疼的歷史數(shù)據(jù)回溯性能問題。

應(yīng)用場景

華夏天信RED-MOS露天煤礦智慧礦山操作系統(tǒng)，本身基于微服務(wù)架構(gòu)，結(jié)合HTAP混合大數(shù)據(jù)平臺，平臺中包含時序數(shù)據(jù)庫（Time-Series Database）及關(guān)系數(shù)據(jù)庫，數(shù)倉系統(tǒng)等組成運用工業(yè)數(shù)據(jù)協(xié)議轉(zhuǎn)換和數(shù)據(jù)采集網(wǎng)關(guān)系統(tǒng)將產(chǎn)、運、銷各環(huán)節(jié)的生產(chǎn)與成本數(shù)據(jù)進行深度的挖掘和分析，從生產(chǎn)運營ODS系統(tǒng)、成本管控BI系統(tǒng)和市場分析BI系統(tǒng)三個維度給煤炭企業(yè)決策層提供精準、實時的數(shù)據(jù)支撐，實現(xiàn)降低成本、提高決策效率的目標。主要包括礦山生產(chǎn)大數(shù)據(jù)、銷售大數(shù)據(jù)、物流大數(shù)據(jù)、設(shè)備運行大數(shù)據(jù)、安全大數(shù)據(jù)、環(huán)保大數(shù)據(jù)等的大數(shù)據(jù)分析應(yīng)用。

地面生產(chǎn)集控系統(tǒng)采用的PLC設(shè)備采集的信號統(tǒng)一接入智能預(yù)警平臺，整合一、二期集控系統(tǒng)、機房狀態(tài)監(jiān)測系統(tǒng)、電氣綜保裝置、破碎系統(tǒng)等數(shù)據(jù)接入RED-MOS露天煤礦智慧礦山操作系統(tǒng)。系統(tǒng)中接入的監(jiān)控點數(shù)量將近1萬5千點。其中接近2300點需要綁定組態(tài)顯示，即時頁面更新，整體數(shù)據(jù)采集到顯示到前端要求秒級展示。

客戶同時要求大數(shù)據(jù)量展示（歷史數(shù)據(jù)回溯），可展示30天的全量數(shù)據(jù)，點數(shù)量超過50萬條。讀取時間要求在5~10s。這對底層的數(shù)據(jù)庫提出了一個相當大的挑戰(zhàn)。

數(shù)據(jù)庫方案選型

對于礦山監(jiān)控的數(shù)據(jù)都是大量帶有時間戳的數(shù)值，本身結(jié)構(gòu)簡單，也沒有太多關(guān)聯(lián)性的查詢需求；最主要的應(yīng)用場景就是按設(shè)備、按時間段回溯和統(tǒng)計分析。這種場景中，最大難點是要處理的數(shù)據(jù)量太大，而不是關(guān)聯(lián)關(guān)系復(fù)雜，因此MySQL這類關(guān)系庫的關(guān)聯(lián)查詢優(yōu)勢其實無法發(fā)揮。而HBase這種大數(shù)據(jù)存儲方案對于礦山系統(tǒng)而言太過龐大，且硬件資源要求很多，我們處于成本考慮也排除了。最終考量的是兩個數(shù)據(jù)庫MongoDB和TDengine。

MongoDB方案

MongoDB和MySQL考察時也都是集群部署，至少需要6臺服務(wù)器。這個方案的缺陷如下。

1）比較耗費服務(wù)器資源，占用空間過大。MongoDB每次空間不足時都會申請生成一大塊的硬盤空間，而且申請的量從64MB、128MB、256MB那樣的指數(shù)遞增，客戶使用2年后數(shù)據(jù)已超過500GB歷史數(shù)據(jù)備份及恢復(fù)非常痛苦。

2）寫入速度波動大，當點位超過10,000且采集頻率低于1s后，通過生產(chǎn)環(huán)境上線前模擬壓測發(fā)現(xiàn)，入庫數(shù)據(jù)存在10%以上比例在個別入庫時間超過2s的情況存在，無法達到項目要求。

3）MongoDB單機穩(wěn)定性比較差，通過Prometheus監(jiān)控MongoDB健康度發(fā)現(xiàn)，當docker容器內(nèi)存使用量超過80%后，MongoDB單機大比例出現(xiàn)無法訪問的情況，導(dǎo)致時序數(shù)據(jù)集群發(fā)生節(jié)點切換，嚴重時甚至發(fā)生實時數(shù)據(jù)集群整體無法訪問。

TDengine方案

TDengine是一個專為物聯(lián)網(wǎng)監(jiān)測場景設(shè)計的高性能的時序數(shù)據(jù)庫。本身非常輕量，在解決我們對時序數(shù)據(jù)的高性能讀寫需求同時，大大降低了安裝、部署、維護的成本，是當前RED-MOS系統(tǒng)底層采用的測點數(shù)據(jù)存儲引擎。TDengine解決了我們最為頭疼的歷史數(shù)據(jù)回溯性能問題。

1）安裝簡單。安裝包僅約5MB，與docker集成比較好，特別適合項目部署維護。

2）性能強勁。在實際生產(chǎn)場景中：15,000點計算及實時入庫時間均為1s內(nèi)（docker容器2C 8g）。大數(shù)據(jù)量展示，可展示30天的全量數(shù)據(jù)，點數(shù)量超過50萬條。讀取時間5~10s。整體使用期間 cpu在30%~40%之間，內(nèi)存維持在6GB左右。

3）我們也對比數(shù)據(jù)壓縮的效果，TDengine的存儲空間可以節(jié)省約5~8倍，推測是因為其采用列式存儲的設(shè)計，比較適合壓縮時序流。這是個非常不錯的提高。

綜合考慮，使用TDengine硬件成本和開發(fā)維護成本大大降低，寫入和查詢速度還比MongoDB等高一個級別。

實際應(yīng)用展示

· 廠區(qū)監(jiān)測

宏觀上的監(jiān)控，例如對筒倉氣象站的監(jiān)控，需要實時刷新顯示其溫度、風速、風向等數(shù)據(jù)。TDengine自帶最新數(shù)據(jù)的緩存，前端通過REST發(fā)送SQL直接訪問TDengine就可以獲取最新數(shù)據(jù)。因此相當于省掉了一部分Redis的開銷。當然整個組態(tài)畫面中，我們也動態(tài)展示了各個廠區(qū)間的生產(chǎn)作業(yè)流。

· 系統(tǒng)設(shè)備狀態(tài)統(tǒng)計

生產(chǎn)極其關(guān)鍵的一點也是要對設(shè)備進行監(jiān)測，比如對送煤過程中各條線上皮帶、電機在線狀態(tài)的統(tǒng)計展示，對電力狀態(tài)、振動等進行狀態(tài)量統(tǒng)計。

· 設(shè)備明細數(shù)據(jù)查詢

二級頁面也會展示設(shè)備溫度、震動、電流等實時數(shù)據(jù)。由于TDengine的查詢都是即席查詢，本身不區(qū)分歷史庫和實時庫，因此應(yīng)用系統(tǒng)查詢最近一小時的數(shù)據(jù)有可能是從內(nèi)存中讀取的，也有可能是從硬盤上讀取的，這點是無法準確判斷的。因此對于測點數(shù)多的場景，如果緩存數(shù)據(jù)量要求大，就盡可能在TDengine中配置較大的cache參數(shù)，讓整體能夠緩存更多數(shù)據(jù)，實時顯示時足夠快。

· 設(shè)備趨勢數(shù)據(jù)回溯

對于每個電機，客戶要求系統(tǒng)能夠快速讀取相關(guān)設(shè)備屬性趨勢圖，這是我們發(fā)現(xiàn)TDengine最強大的地方：針對一天2萬條數(shù)據(jù)展示速度在200ms內(nèi)。這塊我們也和官方團隊有過交流，之所以TDengine對這類查詢速度飛快，主要是設(shè)計時按照設(shè)備分表后，數(shù)據(jù)按塊存儲并按塊查出來，相對Key-Value型數(shù)據(jù)庫節(jié)省很多尋址時間。下圖是按照歷史數(shù)據(jù)查詢的可視化窗口，要開放給客戶去用，指定時間范圍拉取所有歷史數(shù)據(jù)。

最難的一個任務(wù)：大數(shù)據(jù)量展示，可展示30天的全量數(shù)據(jù)，點數(shù)量超過50萬條。讀取時間要求5秒級。目前看到只有TDengine Database可以做到這個性能。

小結(jié)

對于礦山生產(chǎn)系統(tǒng)而言，安全是第一位的。因此，各個生產(chǎn)環(huán)節(jié)和場地都要進行全面、有效的數(shù)字化監(jiān)控。監(jiān)控數(shù)據(jù)的特點就是時序、結(jié)構(gòu)化、簡單但量大。TDengine應(yīng)該說是量身定做來處理這類數(shù)據(jù)的數(shù)據(jù)庫。監(jiān)控數(shù)據(jù)上報后的實時展示、歷史回溯都非?？?，加上本身輕量的特點，對于縮減項目開發(fā)運維成本也非常有幫助。

作者簡介：張俊水，華夏天信(北京)智能低碳研究院高級研發(fā)工程師，主要從事煤炭主運輸平臺開發(fā)及應(yīng)用，近年關(guān)注通過大數(shù)據(jù)技術(shù)處理和解決露天煤礦設(shè)備預(yù)警報警問題。

原文首發(fā)于： http://blog.itpub.net/69976243/viewspace-2696291/