小 T 導讀：SIMICAS? OEM 設備遠(yuan)程運維套(tao)件是(shi)由 SIEMENS DE&DS DSM 團(tuan)隊開發的一套(tao)面向設備制(zhi)造商的數字化解(jie)決方案(an)。在確定選擇(ze) TDengine 作(zuo)為(wei)系統的時序數據庫(ku)后(hou)，他們在 SIMICAS? OEM 2.0 版本中移除了 Flink、Kafka 以及(ji) Redis，大(da)(da)大(da)(da)簡化了系統架構。

項目背景

IIoT（Industrial Internet of Things）是工(gong)(gong)業物聯網(wang)的簡(jian)稱，它將具有感(gan)知、監控能(neng)力的各類采集、控制傳(chuan)感(gan)器(qi)或控制器(qi)，以及移(yi)動通信、智能(neng)分析等技術(shu)不斷融(rong)入到工(gong)(gong)業生產過程的各個環節，從(cong)而(er)大幅提高制造效率，改善產品(pin)質(zhi)量，降低(di)產品(pin)成本和資源消耗，最終實現將傳(chuan)統(tong)工(gong)(gong)業提升到智能(neng)化的新(xin)階(jie)段。

通過新的(de)(de)互聯網連接設備(bei)獲取的(de)(de)數據可用(yong)于提高(gao)效率、實時(shi)決策、解決關(guan)鍵問題(ti)，并最(zui)終創造新的(de)(de)創新體驗(yan)。然(ran)而(er)隨著相互連接的(de)(de)設備(bei)越來(lai)越多(duo)(duo)，公司(si)所面(mian)臨的(de)(de)碎(sui)片化(hua)和新挑戰也(ye)越來(lai)越多(duo)(duo)。為了獲取和利用(yong)數據的(de)(de)力量，他們(men)需(xu)要解決方案來(lai)提供(gong)可互操作(zuo)的(de)(de)端到端協(xie)作(zuo)，從而(er)在互聯網和設備(bei)之間架起橋梁，同時(shi)駕馭(yu)即將到來(lai)的(de)(de)創新浪(lang)潮。

SIMICAS? OEM 設(she)備遠程運(yun)維套件是由 SIEMENS DE&DS DSM 團隊開(kai)發(fa)的(de)一套面向設(she)備制造商的(de)數字化(hua)解(jie)決(jue)方(fang)案(an)，該(gai)方(fang)案(an)借助物聯網(wang)實現設(she)備的(de)高效遠程運(yun)維，對售后(hou)服務(wu)數據進行智能(neng)分析(xi)，從(cong)而真正實現整體售后(hou)環節的(de)降本增(zeng)效。

在 IIoT 大背(bei)景的(de)發展浪潮(chao)下，SIMICAS 為企業(ye)提供(gong)了一個(ge)踏入數(shu)字化世界的(de)靈活選擇，幫助(zhu)企業(ye)根據自身發展需求定(ding)制數(shu)字化發展路徑。SIMICAS 解決方案由四(si)個(ge)部(bu)分組(zu)成：SIMICAS 智能(neng)網(wang)關(guan)、SIMICAS 組(zu)態工具，以及兩個(ge)在西門(men)子(zi)基于云的(de)開放式物(wu)聯網(wang)操(cao)作系(xi)統 MindSphere 基礎上開發的(de) APP——SIMICAS 生產透鏡和 SIMICAS 產效分析(xi)。 

一、系統架構

在其(qi) 1.0 版中(zhong)，我(wo)們使用(yong)了(le) Flink + Kafka + PostgreSQL + Redis 的架構。該系(xi)統的數(shu)據流如下：

設(she)備數(shu)(shu)(shu)(shu)據(ju)通過部署(shu)至現場的網(wang)關上傳至物(wu)聯網(wang)接(jie)入組件，組件根據(ju)配(pei)置對數(shu)(shu)(shu)(shu)據(ju)進行解析處理后，將其寫(xie)(xie)入 Kafka 隊列(lie)，Flink 從(cong)(cong) Kafka 中(zhong)消費數(shu)(shu)(shu)(shu)據(ju)并進行計算，原始值(zhi)及計算后的指標數(shu)(shu)(shu)(shu)據(ju)都會被(bei)寫(xie)(xie)入 PostgreSQL 中(zhong)，最新值(zhi)還會存一份到 Redis 中(zhong)，以便(bian)更(geng)快(kuai)地響應(ying)前端(duan)實時(shi)的數(shu)(shu)(shu)(shu)據(ju)查詢，設(she)備歷史數(shu)(shu)(shu)(shu)據(ju)則從(cong)(cong) PostgreSQL 中(zhong)查詢。

二、業務挑戰

1.0 系統(tong)落地之后，我們遇到了兩大挑戰，一(yi)個(ge)是部署繁瑣，一(yi)個(ge)是應用復雜(za)。

具體來說，因為(wei)引入了(le) Flink 和(he) Kafka，導(dao)致系統部署時非(fei)常繁瑣，服務器開(kai)銷巨大；同時為(wei)了(le)滿足大量數據的存儲問題，PostgreSQL 中不(bu)(bu)得不(bu)(bu)做分庫分表操作，應用(yong)程序(xu)較為(wei)復雜。

如何降低(di)系統復雜度、減(jian)(jian)少(shao)硬件資源開銷，幫助(zhu)客戶減(jian)(jian)少(shao)成(cheng)本(ben)，成(cheng)為研發(fa)團隊的核心任務。

三、技術選型

從產(chan)品的(de)實際痛點出發(fa)，結合(he)未來(lai)產(chan)品的(de)發(fa)展規劃，我們(men)團隊計劃對(dui)產(chan)品的(de)數據處理部分(fen)進行(xing)重構，在技術選型(xing)時主要考慮了如下幾個(ge)方面：

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

本著以上幾個需求，在對各種開源數據平臺、時序數據庫（Time Series Database）進行選(xuan)型對比后，我們發現(xian) TDengine 正好符(fu)合(he)產品重(zhong)構所有(you)的要求，尤其是低成本(ben)和高度一體化(hua)這兩(liang)個點，這是目前絕大部分數據平臺或時序數據庫都(dou)不具備的，所以團隊果斷選(xuan)擇了(le) TDengine。

四、落地實踐

數據流程

在確定選擇 TDengine 作為系統(tong)的序(xu)數據庫后(hou)，我(wo)們在 SIMICAS? OEM 2.0 版本中(zhong)移除(chu)了Flink、Kafka 以及 Redis，新系統(tong)的數據流如下：

數據建模

創建數據庫

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

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

創建實時數據表格

為(wei)平臺中的每(mei)種(zhong)(zhong)設備(bei)(bei)類型創建一個(ge)獨立的超級表（super table），為(wei)每(mei)種(zhong)(zhong)設備(bei)(bei)類型下的每(mei)個(ge)具體(ti)設備(bei)(bei)創建獨立的設備(bei)(bei)子表。

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

創建狀態表

為(wei)平臺中所有(you)設(she)備創建一個共(gong)同的超級表。

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

指標計算

我(wo)們基于 JEXL 表(biao)達式 + 實時查(cha)詢(xun)的方(fang)式實現了(le)系(xi)(xi)統中的指標計算(suan)。我(wo)們使用 JEXL 表(biao)達式來(lai)定(ding)義(yi)指標的計算(suan)表(biao)達式，系(xi)(xi)統解析后(hou)將變量替換成 SQL 查(cha)詢(xun)任務，在查(cha)詢(xun)返(fan)回(hui)結果后(hou)再到系(xi)(xi)統中進行(xing)計算(suan)，返(fan)回(hui)至前(qian)端。

比如計(ji)算某(mou)項目下所有設(she)備(bei)當前電壓(ya)的(de)平均(jun)(jun)值，其表(biao)達(da)式為(wei) avg(voltage,run_status=1 && project=abc)，它會被(bei)分解為(wei)：1）查詢(xun) run_status=1 && project=abc 的(de)所有設(she)備(bei)；2）查詢(xun)第一步結果中所有設(she)備(bei) voltage 字(zi)段的(de)最(zui)新(xin)值；3）計(ji)算第二步所有設(she)備(bei)最(zui)新(xin)結果的(de)平均(jun)(jun)值。

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

五、遇到的問題

在(zai) TDengine 官方(fang)推(tui)薦的(de)最佳(jia)實(shi)踐中，數(shu)(shu)據表建模建議(yi)使用(yong)多列模式，我(wo)們團(tuan)隊在(zai)一開始選擇了這(zhe)種方(fang)式，但是在(zai)實(shi)際使用(yong)中發現，部分客戶的(de)設(she)備測點非(fei)常多，甚至超(chao)過 2000 列，這(zhe)樣可能會因為單行(xing)數(shu)(shu)據過大(da)而(er)導致插入數(shu)(shu)據 SQL 過長的(de)問題[1] ；另一個問題是現場設(she)備是按照“OnChange（突發上送）”方(fang)式進行(xing)數(shu)(shu)據上傳，導致非(fei)常多的(de) NULL 值出(chu)現，在(zai)執行(xing) select last(*) from device_xxx 時效率(lv)較(jiao)低[2]。

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

后來，團隊通過對項目中單(dan)個設(she)備參數(shu)的(de)最大(da)數(shu)量進行限制，解(jie)決(jue)(jue)了(le)問題[1]；又通過修改設(she)備數(shu)據(ju)的(de)上傳方式，解(jie)決(jue)(jue)了(le)問題[2]。

但是(shi)在根(gen)本(ben)上，還是(shi)我(wo)們(men)在最初(chu)建模時，沒(mei)有充分考慮(lv)到(dao)客(ke)戶的(de)業務場景，從(cong)而導致了以上問題。因此，我(wo)們(men)團隊后續在系統中(zhong)實現(xian)了同時支(zhi)持多列模式(shi)和單列模式(shi)，這樣客(ke)戶就(jiu)可(ke)以根(gen)據(ju)現(xian)場的(de)實際情況，自由切(qie)換建模方式(shi)。

六、寫在最后

與其他開源數據平臺或數據庫相比，目前 TDengine 的運維監控能力還不算強大，不過前段時間發布的 TDinsight 已經帶來了很多改進，我們團隊也規劃在下一階段試用一下。
特別感謝(xie)濤思數據(ju)的(de)陳偉燦及其他(ta)同事在產品開發(fa)過(guo)程給(gei)予(yu)的(de)支持，雖然在過(guo)程中遇到(dao)一些問題，但(dan)整體而言，TDengine 的(de)各項(xiang)優異(yi)表現給(gei)了我們團隊(dui)很多驚喜。

最后(hou)期待 TDengine越來(lai)越好(hao)，幫助更(geng)多客(ke)戶、更(geng)多場景(jing)降本增效！