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

項(xiàng)目背景

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

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

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

在 IIoT 大背景的發(fā)展浪潮下，SIMICAS 為企業(yè)提供了一個(gè)踏入數(shù)字化世界的靈活選擇，幫助企業(yè)根據(jù)自身發(fā)展需求定制數(shù)字化發(fā)展路徑。SIMICAS 解決方案由四個(gè)部分組成：SIMICAS 智能網(wǎng)關(guān)、SIMICAS 組態(tài)工具，以及兩個(gè)在西門子基于云的開(kāi)放式物聯(lián)網(wǎng)操作系統(tǒng) MindSphere 基礎(chǔ)上開(kāi)發(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ù)通過(guò)部署至現(xiàn)場(chǎng)的網(wǎng)關(guān)上傳至物聯(lián)網(wǎng)接入組件，組件根據(jù)配置對(duì)數(shù)據(jù)進(jìn)行解析處理后，將其寫入 Kafka 隊(duì)列，F(xiàn)link 從 Kafka 中消費(fèi)數(shù)據(jù)并進(jìn)行計(jì)算，原始值及計(jì)算后的指標(biāo)數(shù)據(jù)都會(huì)被寫入 PostgreSQL 中，最新值還會(huì)存一份到 Redis 中，以便更快地響應(yīng)前端實(shí)時(shí)的數(shù)據(jù)查詢，設(shè)備歷史數(shù)據(jù)則從 PostgreSQL 中查詢。

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

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

具體來(lái)說(shuō)，因?yàn)橐肓?nbsp;Flink 和 Kafka，導(dǎo)致系統(tǒng)部署時(shí)非常繁瑣，服務(wù)器開(kāi)銷巨大；同時(shí)為了滿足大量數(shù)據(jù)的存儲(chǔ)問(wèn)題，PostgreSQL 中不得不做分庫(kù)分表操作，應(yīng)用程序較為復(fù)雜。

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

三、技術(shù)選型

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

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

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

四、落地實(shí)踐

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

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

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

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

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

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

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

為平臺(tái)中的每種設(shè)備類型創(chuàng)建一個(gè)獨(dú)立的超級(jí)表（super table），為每種設(shè)備類型下的每個(gè)具體設(shè)備創(chuàng)建獨(dú)立的設(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)表

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

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})

指標(biāo)計(jì)算

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

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

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

五、遇到的問(wèn)題

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

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

后來(lái)，團(tuán)隊(duì)通過(guò)對(duì)項(xiàng)目中單個(gè)設(shè)備參數(shù)的最大數(shù)量進(jìn)行限制，解決了問(wèn)題[1]；又通過(guò)修改設(shè)備數(shù)據(jù)的上傳方式，解決了問(wèn)題[2]。

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

六、寫在最后

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

最后期待 TDengine越來(lái)越好，幫助更多客戶、更多場(chǎng)景降本增效！