小 T 導(dǎo)讀：SIMICAS? OEM 設(shè)備遠程運維套件是由 SIEMENS DE&DS DSM 團隊開發(fā)的一套面向設(shè)備制造商的數(shù)字化解決方案。在確定選擇 TDengine 作為系統(tǒng)的時序數(shù)據(jù)庫后，他們在 SIMICAS? OEM 2.0 版本中移除了 Flink、Kafka 以及 Redis，大大簡化了系統(tǒng)架構(gòu)。

項目背景

IIoT（Industrial Internet of Things）是工業(yè)物聯(lián)網(wǎng)的簡稱，它將具有感知、監(jiān)控能力的各類采集、控制傳感器或控制器，以及移動通信、智能分析等技術(shù)不斷融入到工業(yè)生產(chǎn)過程的各個環(huán)節(jié)，從而大幅提高制造效率，改善產(chǎn)品質(zhì)量，降低產(chǎn)品成本和資源消耗，最終實現(xiàn)將傳統(tǒng)工業(yè)提升到智能化的新階段。

通過新的互聯(lián)網(wǎng)連接設(shè)備獲取的數(shù)據(jù)可用于提高效率、實時決策、解決關(guān)鍵問題，并最終創(chuàng)造新的創(chuàng)新體驗。然而隨著相互連接的設(shè)備越來越多，公司所面臨的碎片化和新挑戰(zhàn)也越來越多。為了獲取和利用數(shù)據(jù)的力量，他們需要解決方案來提供可互操作的端到端協(xié)作，從而在互聯(lián)網(wǎng)和設(shè)備之間架起橋梁，同時駕馭即將到來的創(chuàng)新浪潮。

SIMICAS? OEM 設(shè)備遠程運維套件是由 SIEMENS DE&DS DSM 團隊開發(fā)的一套面向設(shè)備制造商的數(shù)字化解決方案，該方案借助物聯(lián)網(wǎng)實現(xiàn)設(shè)備的高效遠程運維，對售后服務(wù)數(shù)據(jù)進行智能分析，從而真正實現(xiàn)整體售后環(huán)節(jié)的降本增效。

在 IIoT 大背景的發(fā)展浪潮下，SIMICAS 為企業(yè)提供了一個踏入數(shù)字化世界的靈活選擇，幫助企業(yè)根據(jù)自身發(fā)展需求定制數(shù)字化發(fā)展路徑。SIMICAS 解決方案由四個部分組成：SIMICAS 智能網(wǎng)關(guān)、SIMICAS 組態(tài)工具，以及兩個在西門子基于云的開放式物聯(lián)網(wǎng)操作系統(tǒng) MindSphere 基礎(chǔ)上開發(fā)的 APP——SIMICAS 生產(chǎn)透鏡和 SIMICAS 產(chǎn)效分析。 

一、系統(tǒng)架構(gòu)

在其 1.0 版中，我們使用了 Flink + Kafka + PostgreSQL + Redis 的架構(gòu)。該系統(tǒng)的數(shù)據(jù)流如下：

設(shè)備數(shù)據(jù)通過部署至現(xiàn)場的網(wǎng)關(guān)上傳至物聯(lián)網(wǎng)接入組件，組件根據(jù)配置對數(shù)據(jù)進行解析處理后，將其寫入 Kafka 隊列，F(xiàn)link 從 Kafka 中消費數(shù)據(jù)并進行計算，原始值及計算后的指標數(shù)據(jù)都會被寫入 PostgreSQL 中，最新值還會存一份到 Redis 中，以便更快地響應(yīng)前端實時的數(shù)據(jù)查詢，設(shè)備歷史數(shù)據(jù)則從 PostgreSQL 中查詢。

二、業(yè)務(wù)挑戰(zhàn)

1.0 系統(tǒng)落地之后，我們遇到了兩大挑戰(zhàn)，一個是部署繁瑣，一個是應(yīng)用復(fù)雜。

具體來說，因為引入了 Flink 和 Kafka，導(dǎo)致系統(tǒng)部署時非常繁瑣，服務(wù)器開銷巨大；同時為了滿足大量數(shù)據(jù)的存儲問題，PostgreSQL 中不得不做分庫分表操作，應(yīng)用程序較為復(fù)雜。

如何降低系統(tǒng)復(fù)雜度、減少硬件資源開銷，幫助客戶減少成本，成為研發(fā)團隊的核心任務(wù)。

三、技術(shù)選型

從產(chǎn)品的實際痛點出發(fā)，結(jié)合未來產(chǎn)品的發(fā)展規(guī)劃，我們團隊計劃對產(chǎn)品的數(shù)據(jù)處理部分進行重構(gòu)，在技術(shù)選型時主要考慮了如下幾個方面：

• 高性能，可以支持百萬級別的并發(fā)寫入、萬級的并發(fā)讀取，大量聚合查詢時依然有高性能表現(xiàn)
• 高可用，可支持集群部署，可橫向擴展，不存在單點故障
• 低成本，數(shù)據(jù)庫對硬件資源要求低，數(shù)據(jù)壓縮率高
• 高度一體化，在具備以上三個特點的基礎(chǔ)上，是否具備一定的消息隊列、流式計算和緩存的功能

本著以上幾個需求，在對各種開源數(shù)據(jù)平臺、時序數(shù)據(jù)庫（Time Series Database）進行選型對比后，我們發(fā)現(xiàn) TDengine 正好符合產(chǎn)品重構(gòu)所有的要求，尤其是低成本和高度一體化這兩個點，這是目前絕大部分數(shù)據(jù)平臺或時序數(shù)據(jù)庫都不具備的，所以團隊果斷選擇了 TDengine。

四、落地實踐

數(shù)據(jù)流程

在確定選擇 TDengine 作為系統(tǒng)的序數(shù)據(jù)庫后，我們在 SIMICAS? OEM 2.0 版本中移除了Flink、Kafka 以及 Redis，新系統(tǒng)的數(shù)據(jù)流如下：

數(shù)據(jù)建模

創(chuàng)建數(shù)據(jù)庫

數(shù)據(jù)默認保存 2 年，數(shù)據(jù)庫采用 3 節(jié)點集群，數(shù)據(jù)采用 3 副本存儲，保留 update 能力；

create database if not exists simicas_data keep 712 replica 3 update 2;

創(chuàng)建實時數(shù)據(jù)表格

為平臺中的每種設(shè)備類型創(chuàng)建一個獨立的超級表（super table），為每種設(shè)備類型下的每個具體設(shè)備創(chuàng)建獨立的設(shè)備子表。

create stable if not exists product_${productKey} (ts timestamp,linestate bool,${device_properties}) tags (device_code binary(64));
create table if not exists device_${device_code} using product_${productKey} tags (${device_code})

創(chuàng)建狀態(tài)表

為平臺中所有設(shè)備創(chuàng)建一個共同的超級表。

create stable if not exists device_state (ts timestamp,linestate bool,run_status int,error_code binary(64),run_total_time int,stop_total_time int,error_total_time int) tags (device_code binary(64),product_key binary(64));
create table if not exists device_state_${device_code} using device_state tags (${device_code},${productKey})

指標計算

我們基于 JEXL 表達式 + 實時查詢的方式實現(xiàn)了系統(tǒng)中的指標計算。我們使用 JEXL 表達式來定義指標的計算表達式，系統(tǒng)解析后將變量替換成 SQL 查詢?nèi)蝿?wù)，在查詢返回結(jié)果后再到系統(tǒng)中進行計算，返回至前端。

比如計算某項目下所有設(shè)備當前電壓的平均值，其表達式為 avg(voltage,run_status=1 && project=abc)，它會被分解為：1）查詢 run_status=1 && project=abc 的所有設(shè)備；2）查詢第一步結(jié)果中所有設(shè)備 voltage 字段的最新值；3）計算第二步所有設(shè)備最新結(jié)果的平均值。

得益于多線程和 TDengine 高效的查詢表現(xiàn)，單個 KPI 的查詢 P99 表現(xiàn)小于 100ms。

五、遇到的問題

在 TDengine 官方推薦的最佳實踐中，數(shù)據(jù)表建模建議使用多列模式，我們團隊在一開始選擇了這種方式，但是在實際使用中發(fā)現(xiàn)，部分客戶的設(shè)備測點非常多，甚至超過 2000 列，這樣可能會因為單行數(shù)據(jù)過大而導(dǎo)致插入數(shù)據(jù) SQL 過長的問題[1] ；另一個問題是現(xiàn)場設(shè)備是按照“OnChange（突發(fā)上送）”方式進行數(shù)據(jù)上傳，導(dǎo)致非常多的 NULL 值出現(xiàn)，在執(zhí)行 select last(*) from device_xxx 時效率較低[2]。

在與 TDengine 官方的技術(shù)人員溝通后，我們了解到，last 函數(shù)是對每列進行查找，直到最近一條非 NULL 值為止，在當時的版本下，cache 對 last 函數(shù)是無效的。

后來，團隊通過對項目中單個設(shè)備參數(shù)的最大數(shù)量進行限制，解決了問題[1]；又通過修改設(shè)備數(shù)據(jù)的上傳方式，解決了問題[2]。

但是在根本上，還是我們在最初建模時，沒有充分考慮到客戶的業(yè)務(wù)場景，從而導(dǎo)致了以上問題。因此，我們團隊后續(xù)在系統(tǒng)中實現(xiàn)了同時支持多列模式和單列模式，這樣客戶就可以根據(jù)現(xiàn)場的實際情況，自由切換建模方式。

六、寫在最后

與其他開源數(shù)據(jù)平臺或數(shù)據(jù)庫相比，目前 TDengine 的運維監(jiān)控能力還不算強大，不過前段時間發(fā)布的 TDinsight 已經(jīng)帶來了很多改進，我們團隊也規(guī)劃在下一階段試用一下。
特別感謝濤思數(shù)據(jù)的陳偉燦及其他同事在產(chǎn)品開發(fā)過程給予的支持，雖然在過程中遇到一些問題，但整體而言，TDengine 的各項優(yōu)異表現(xiàn)給了我們團隊很多驚喜。

最后期待 TDengine越來越好，幫助更多客戶、更多場景降本增效！