小 T 導讀：在 TDengine 平穩(wěn)運行的數周時間里，中天鋼鐵的新系統(tǒng)平均每周收錄 3000 多輛車輛表與 100 多條船只表，每張表中數據或多或少，累計數量已達百萬，業(yè)務的實際效果也達到了預期。本文分享了他們對于新項目的數據庫選型、應用的思考，同時也進行了業(yè)務效果分析。

為了滿足業(yè)務發(fā)展需求，我們需要新開發(fā)一套功能，對廠內每輛運輸車輛的實時 GPS 位置進行追蹤，通過大數據平臺對 GPS 坐標進行處理、分析、可視化展示。同時也需要對公司貨運船只進行實時監(jiān)控，運用 GPS 平臺的分析處理能力對船只的航運軌跡進行預判，計算其是否偏離航線。這些 GPS 數據來自于中天云商 App，只要運輸車輛司機打開云商 App，系統(tǒng)每隔 10 秒會自動發(fā)送該車輛 GPS 信號到大數據平臺，再由大數據平臺分析處理。

數據處理路徑主要為，大數據平臺將 ERP 中關聯過合同的 MMSI 信息同步到 GPS 平臺，由 GPS 平臺挑選出 300 條船舶的 MMSI 同步至船達通平臺，同時將接收數據接口地址發(fā)送到船達通平臺，船達通平臺會根據 MMSI 編號以及推送地址，每隔 10 分鐘將該船只的最新位置以及動靜態(tài)信息推送至 GPS 平臺?；诖耍{研到一個合適的數據庫，對于實現項目的數據處理需求至關重要。

關于數據庫選型調研的思考

本質上來講，行車記錄、行船記錄都是時序數據，天然帶有時間戳，這些時序數據到達服務器時都是有序遞增的，且時序數據的特點是流量平穩(wěn)卻非常巨大，這點和電商數據不太一樣，比如雙十一時電商數據會出現陡增，平常卻沒有那么高流量。作為典型的時序數據，車聯網數據每隔 10 秒或 10 分鐘發(fā)送一條，相對固定，在調研時我們發(fā)現，TDengine “一輛車一張表”的模型很契合這一場景。

同時，時序數據在查詢時要匹配特定的時間線或數據標簽，且實時狀態(tài)查詢、數據降精度、整體趨勢分析較多，普通數據庫無法提供這種函數?；凇耙惠v車一張表”這樣的設計，TDengine 能夠實現任何一臺設備采集的數據，在存儲介質里都是一塊一塊連續(xù)存放的，且按照時間排序，保證了在查詢單個設備一個時間段的數據時，查詢性能能夠有數量級的提升。

另外一方面，雖然不同設備由于網絡的原因，到達服務器的時間無法控制，是完全亂序的，但對于同一個設備而言，數據點的時序卻是可以保證的?！耙粋€設備一張表”就保證了一張表插入的數據是有時序保證的，這樣一來數據插入操作就變成了一個簡單地追加操作，插入性能也有了大幅度提升。

在壓縮性能上，通過下表幾家 Database 的對比，也可看出 TDengine 的優(yōu)秀：

同時 TDengine 針對同類型設備間的聚合問題，創(chuàng)新性地提出超級表的概念，讓多設備間的聚合變得靈活方便，也讓實時數據大屏顯示、監(jiān)測設備分類管理變得極其簡單?？偨Y而言，TDengine 針對時序數據的寫入、存儲、索引、查詢等方面都進行了特定的優(yōu)化，從而實現了更優(yōu)的數據加載、壓縮、查詢、寫入性能，非常匹配工業(yè)傳感器數據的應用分析場景。

雖然接入設備繁多，但 TDengine 兼容性很強，寫入、讀取和統(tǒng)計效率也大大高于其他同類型數據庫。對比 InfluxDB 來看，其測試數據顯示如下：

為了評估不同長度的時間窗口對查詢性能的影響，我們選取了第四個查詢場景，設定并行執(zhí)行的 work 數量 16， 時間區(qū)間是隨機選取的 1h / 2h / 4h / 8h / 12h 等連續(xù)時間段，單個聚合時間窗口維持在 1min 不變。獲得的查詢響應時間如下所示：

平臺架構的實現

下圖是我們的數據處理路徑圖，數據通過中天云商、船達通平臺將數據抽到 GPS 平臺，通過 GPS 平臺分析處理后將數據存入數據倉庫（TDengine）。

基于 TDengine，GPS 平臺會對實時獲取的 GPS 數據以及 AIS 數據進行分析處理和存儲，再通過每輛車、每條船對應的表，實現車輛船只軌跡可視化。

根據業(yè)務不同，我們創(chuàng)建了兩張超級表，分別為車超級表與船超級表。超級表是具有溝通的 Schema 共同元數據表的集合，可以認為創(chuàng)建一個超級表，它下面能夠再次創(chuàng)建很多子表，對超級表的查詢相當于作用到它下面所有的子表。

比如當你要查一個超級表的平均值，假設它下面有 100 萬張表，我就相當于對這 100 萬張表做了查詢，這樣用一個超級表就解決了這個問題。每新增一條信息則依照對應載具信息新建子表或者在已有子表中插入最新數據。

測試與查詢

目前 TDengine 在我們的生產環(huán)境中運行平穩(wěn)，通過對生產環(huán)境的機器進行檢測，CPU 使用率平常不到 1%，內存使用率穩(wěn)定在 25%。下圖為集群中一臺機器的監(jiān)控圖表：

在 TDengine 平穩(wěn)運行的數周時間里，中天鋼鐵的新系統(tǒng)平均每周收錄 3000 多輛車輛表與 100 多條船只表，每張表中數據或多或少，累計數量已達百萬，業(yè)務的實際效果也達到了預期。

現在可以根據車輛車牌號、需要查詢的時間區(qū)間來可視化車輛軌跡。在數據庫中存儲上車輛信息時間、經緯度、車牌信息，在展示頁面中就會實時顯示當前廠內所有提貨車輛的最新位置（前提是必須保持中天云商處于打開狀態(tài)），當車輛提貨出廠后，則不再發(fā)送 GPS 信息，系統(tǒng)會將該車輛判斷為離線狀態(tài)，不再顯示?；蛘弋斔緳C異常關閉中天云商超過 8 個小時，系統(tǒng)也將視該車輛為離線，從屏幕顯示中去除，直到重新接收到 GPS 信號。

根據船舶名稱、需要查詢的時間區(qū)間，就可以查詢該艘船只的歷史 AIS 軌跡圖，如果有的船只中途異常關閉 AIS 信息發(fā)送裝置，則系統(tǒng)無法接收到該船只的 AIS，展示的歷史軌跡中則會出現間斷。船只 AIS 信息永久保存在 TDengine 庫中，在其中可以查詢任意時間段內的 AIS 軌跡。

未來規(guī)劃

本次在中天鋼鐵 GPS 平臺車輛調度中使用了 TDengine，我們發(fā)現它不僅性能高效，在設計上也很人性化，其支持的 SQL 查詢語句，讓人無需學習就能立刻上手。再就是關于 TDengine 在監(jiān)控領域的應用，監(jiān)控無非是做一個數據的存儲，數據庫的存儲性能相當重要，TDengine 表現很突出。

總而言之，TDengine 的應用真正讓車聯網、工業(yè)互聯網、運維監(jiān)測大數據平臺的搭建變得簡單，不僅降低硬件成本、運維成本，還能大幅降低對研發(fā)和運維人員的需求。后續(xù)我們也會繼續(xù)分享 TDengine 的更多應用場景和實踐經驗等，給到大家參考。

當然，對于 TDengine 我們也有一些建議，希望它能夠發(fā)展地越來越好：

1. 支持更加豐富的 SQL 語句：能夠針對特有的場景，提供更加靈活的 SQL 語句，便于做更加復雜的計算分析，這也是 AIOps 的進階部分。
2. 子表自動清理功能：由于域名會存在下線問題，目前的 TTL 策略只是針對數據而不是 Table 本身，淘汰子表還需要人工運維介入。
3. 現在 TDengine 對于數據的更新只有相同時間戳覆蓋這種辦法，希望能提供數據刪除功能（小T提示：TDengine 2.6 企業(yè)版已經提供刪除功能 ??點擊鏈接文章看詳情）。
4. 提供簡潔易操作的可視化界面，如 Navicat 之于 MySQL。