小 T 導讀：華夏天信RED-MOS露天煤礦智慧礦山操作系統，基於微服務架構，結合HTAP混合大數據平臺，將產、運、銷各環節的生產與成本數據進行深度的挖掘和分析。TDengine是當前RED-MOS系統底層採用的測點數據存儲引擎，解決了我們最爲頭疼的歷史數據回溯性能問題。
應用場景
華夏天信RED-MOS露天煤礦智慧礦山操作系統，本身基於微服務架構，結合HTAP混合大數據平臺，平臺中包含TSDB及關係數據庫，數倉系統等組成運用工業數據協議轉換和數據採集網關係統將產、運、銷各環節的生產與成本數據進行深度的挖掘和分析，從生產運營ODS系統、成本管控BI系統和市場分析BI系統三個維度給煤炭企業決策層提供精準、實時的數據支撐，實現降低成本、提高決策效率的目標。主要包括礦山生產大數據、銷售大數據、物流大數據、設備運行大數據、安全大數據、環保大數據等的大數據分析應用。
地面生產集控系統採用的PLC設備採集的信號統一接入智能預警平臺，整合一、二期集控系統、機房狀態監測系統、電氣綜保裝置、破碎系統等數據接入RED-MOS露天煤礦智慧礦山操作系統。系統中接入的監控點數量將近1萬5千點。其中接近2300點需要綁定組態顯示，即時頁面更新，整體數據採集到顯示到前端要求秒級展示。
客戶同時要求大數據量展示（歷史數據回溯），可展示30天的全量數據，點數量超過50萬條。讀取時間要求在5~10s。這對底層的數據庫提出了一個相當大的挑戰。
數據庫方案選型
對於礦山監控的數據都是大量帶有時間戳的數值，本身結構簡單，也沒有太多關聯性的查詢需求；最主要的應用場景就是按設備、按時間段回溯和統計分析。這種場景中，最大難點是要處理的數據量太大，而不是關聯關係複雜，因此MySQL這類關係庫的關聯查詢優勢其實無法發揮。而HBase這種大數據存儲方案對於礦山系統而言太過龐大，且硬件資源要求很多，我們處於成本考慮也排除了。最終考量的是兩個數據庫MongoDB和TDengine。
MongoDB方案
MongoDB和MySQL考察時也都是集羣部署，至少需要6臺服務器。這個方案的缺陷如下。
1）比較耗費服務器資源，佔用空間過大。MongoDB每次空間不足時都會申請生成一大塊的硬盤空間，而且申請的量從64MB、128MB、256MB那樣的指數遞增，客戶使用2年後數據已超過500GB歷史數據備份及恢復非常痛苦。
2）寫入速度波動大，當點位超過10,000且採集頻率低於1s後，通過生產環境上線前模擬壓測發現，入庫數據存在10%以上比例在個別入庫時間超過2s的情況存在，無法達到項目要求。
3）MongoDB單機穩定性比較差，通過Prometheus監控MongoDB健康度發現，當docker容器內存使用量超過80%後，MongoDB單機大比例出現無法訪問的情況，導致時序數據集羣發生節點切換，嚴重時甚至發生實時數據集羣整體無法訪問。
TDengine方案
TDengine是一個專爲物聯網監測場景設計的高性能的時序數據庫。本身非常輕量，在解決我們對時序數據的高性能讀寫需求同時，大大降低了安裝、部署、維護的成本，是當前RED-MOS系統底層採用的測點數據存儲引擎。TDengine解決了我們最爲頭疼的歷史數據回溯性能問題。
1）安裝簡單。安裝包僅約5MB，與docker集成比較好，特別適合項目部署維護。
2）性能強勁。在實際生產場景中：15,000點計算及實時入庫時間均爲1s內（docker容器2C 8g）。大數據量展示，可展示30天的全量數據，點數量超過50萬條。讀取時間5~10s。整體使用期間 cpu在30%~40%之間，內存維持在6GB左右。
3）我們也對比數據壓縮的效果，TDengine的存儲空間可以節省約5~8倍，推測是因爲其採用列式存儲的設計，比較適合壓縮時序流。這是個非常不錯的提高。
綜合考慮，使用TDengine硬件成本和開發維護成本大大降低，寫入和查詢速度還比MongoDB等高一個級別。
實際應用展示
廠區監測
宏觀上的監控，例如對筒倉氣象站的監控，需要實時刷新顯示其溫度、風速、風向等數據。TDengine自帶最新數據的緩存，前端通過REST發送SQL直接訪問TDengine就可以獲取最新數據。因此相當於省掉了一部分Redis的開銷。當然整個組態畫面中，我們也動態展示了各個廠區間的生產作業流。
系統設備狀態統計
生產極其關鍵的一點也是要對設備進行監測，比如對送煤過程中各條線上皮帶、電機在線狀態的統計展示，對電力狀態、振動等進行狀態量統計。
設備明細數據查詢
二級頁面也會展示設備溫度、震動、電流等實時數據。由於TDengine的查詢都是即席查詢，本身不區分歷史庫和實時庫，因此應用系統查詢最近一小時的數據有可能是從內存中讀取的，也有可能是從硬盤上讀取的，這點是無法準確判斷的。因此對於測點數多的場景，如果緩存數據量要求大，就儘可能在TDengine中配置較大的cache參數，讓整體能夠緩存更多數據，實時顯示時足夠快。
設備趨勢數據回溯
對於每個電機，客戶要求系統能夠快速讀取相關設備屬性趨勢圖，這是我們發現TDengine最強大的地方：針對一天2萬條數據展示速度在200ms內。這塊我們也和官方團隊有過交流，之所以TDengine對這類查詢速度飛快，主要是設計時按照設備分表後，數據按塊存儲並按塊查出來，相對Key-Value型數據庫節省很多尋址時間。下圖是按照歷史數據查詢的可視化窗口，要開放給客戶去用，指定時間範圍拉取所有歷史數據。
最難的一個任務：大數據量展示，可展示30天的全量數據，點數量超過50萬條。讀取時間要求5秒級。目前看到只有TDengine可以做到這個性能。
小結
對於礦山生產系統而言，安全是第一位的。因此，各個生產環節和場地都要進行全面、有效的數字化監控。監控數據的特點就是時序、結構化、簡單但量大。TDengine應該說是量身定做來處理這類數據的數據庫。監控數據上報後的實時展示、歷史回溯都非常快，加上本身輕量的特點，對於縮減項目開發運維成本也非常有幫助。
作者簡介：
張俊水，華夏天信(北京)智能低碳研究院高級研發工程師，主要從事煤炭主運輸平臺開發及應用，近年關注通過大數據技術處理和解決露天煤礦設備預警報警問題。