小 T 導讀：陜西煤業股份有限公司（股票代碼：601225），是陜西煤業化工集團有限責任公司煤炭資產唯一上市平臺。陜煤在煤礦智能化發展上成績斐然，開創了首個全國智能化無人開采工作面，首個全國智能化掘進機器人。不僅是國內采煤新方式的先河，更填補了煤礦開采技術的空白。
為實現煤礦企業數字化生產管理，提高煤礦企業生產安全性、擴展煤礦企業管理手段及管理思路，陜煤開發團隊考慮將煤礦企業人員、車輛、設備、環境參數等各類基礎數據，進行統一存儲和智能分析決策，在此背景下打造全礦井數字化平臺，實現了煤礦企業井下人員、膠輪車及電機·車位置監控、井下各類設備狀態監控、井下各類傳感器數據監控、井下位置地點的告警分析及事件聯動。
此平臺的搭建意義在于打通煤礦生產環境中各類單一子系統之間的數據壁壘，實現各類子系統數據之間的互聯互通。在實現路徑上，平臺底層基于標準 TCP/UDP 協議接入公司自研硬件設備，并通過定制化的協議轉換模組接入其他非標的設備通信協議，將上傳數據進行歸集入庫存儲并通過大數據分析平臺進行驅動分析，最后根據業務具體情況生成數據統計與驅動結果。
一、技術選型
以位置數據為例，井下人員、車輛佩戴安裝定位設備后將基于井下網絡進行位置數據的實時上傳，人員默認上報周期為 1 秒，車輛默認為 0.5 秒。在原有單系統項目中，由于初期系統容量較小且硬件設備上傳周期較大，所以采用了傳統的 SQL Server 數據庫來進行軌跡數據存儲。但隨著后續項目迭代，硬件設備定位精度提高且上報周期縮短，也導致數據庫存儲壓力增大。
為解決大數據量存儲問題，我們先是考慮在數據接收端增加大量數據過濾算法，對原始數據進行預篩來減少最終入庫數量，在數據庫側則采用增加分庫分表的策略，那在數據查詢端就需要對分庫分表進行大量的查詢語句優化。這樣一來，整體項目不僅復雜度較高，而且后續維護類工作量巨大。
在平臺設計階段，一是鑒于上述失敗經驗，其次我們也考慮到不管是位置數據還是傳感器數據，雖然數據載體不一樣，但它們都是包含時間戳的序列數據，且數據存儲固化后很少再有需要更新的業務場景，采用時序數據庫來存儲這類數據再合適不過了。基于此，我們開始進行選型調研，對幾類時序數據庫（Time-Series Database）進行了綜合比較：
基于 HBase 的時序數據庫實現，支持集群橫向擴展，但是部署及運維成本較高，且提供的查詢函數較少，不適合后續查詢業務的擴展。
- TDengine
早在 TDengine Database 開源之初，我們就有所關注。對于一個新興的基礎開源項目，穩定性一直是我們衡量的重要標準，TDengine 在后續開源的 2.X 版本中不僅增加了集群模塊且穩定性也大幅提高，同時其 SQL 語句與傳統關系型數據庫相似，部署及維護相對簡單，社區環境很好，也有企業合作模式。
- InfluxDB
InfluxDB 在開源時序庫領域長期占據 TOP1 的位置，社區比較活躍且生態建設也挺好。但由于集群模塊沒有開源，不適用公司產品的高可用要求。 綜合上述幾類時序數據庫的優缺點，最終我們決定采用 TDengine 作為本項目基礎數據的存儲方案。
二、建庫建表
- 基于 TDengine 的產品架構圖搭建如下：
- 建模思路
在定位業務時可以細分出人員、車輛等不同的定位對象，盡管數據類型不同，但定位相關數據字段均一致，因此定位數據使用一張超級表進行管理即可。在 TDengine 超級表內數據類型及各個數據對象編號將作為 tag 進行區分，在查詢業務時使用超級表并關聯 tag 字段進行查詢。 從我們的實際業務出發，具體建表思路如下：
三、落地效果
最終落地時項目采用了3個節點的集群環境，定位設備采用超級表進行管理，將數據標簽及數據類型作為tag區分各類定位設備。每個定位設備采用子表存儲，實際項目已包含2萬多個定位設備。從寫入性能到查詢性能均大幅滿足現場實際需求：總計定位數據量超過11億條，數據壓縮后TDengine數據目錄占用磁盤大約12G，整體壓縮率可以達到3/100。
下圖示例為項目中人員與車輛定位實際使用場景，基于 TDengine 時序數據庫，對井下的人員、車輛數量以及位置進行實時統計與展示。
四、未來規劃
隨著項目的不斷推進直到實施落地，我們也見證了 TDengine 的幾次大版本更新，目前集群整體運行情況相對穩定，性能和成本管控也達到了我們的預期。為了幫助 TDengine 能夠實現更好地發展，在此也為其提出幾點優化建議：
- 目前 TDengine 在陜煤使用的監控功能還較為簡單，希望后續版本升級過程中能夠優化集群環境監控相關的功能。
- 目前項目在使用 JDBC 驅動時，是通過客戶端連接 TDengine 的。隨著版本升級，運維工作量較高，需要同步升級服務器和客戶端，且 JDBC 驅動升級的話還需要同步升級對應服務，步驟相對繁瑣，希望在接下來的版本中能加以改善。
