::: hljs-center
:::
小 T 導讀：SIMICAS® OEM 裝置遠端運維套件是由 SIEMENS DE&DS DSM 團隊開發的一套面向裝置制造商的數字化解決方案。在确定選擇 TDengine 作為系統的時序資料庫後，他們在 SIMICAS® OEM 2.0 版本中移除了 Flink、Kafka 以及 Redis，大大簡化了系統架構。
項目背景
IIoT（Industrial Internet of Things）是工業物聯網的簡稱，它将具有感覺、監控能力的各類采集、控制傳感器或控制器，以及移動通信、智能分析等技術不斷融入到工業生産過程的各個環節，進而大幅提高制造效率，改善産品品質，降低産品成本和資源消耗，最終實作将傳統工業提升到智能化的新階段。
通過新的網際網路連接配接裝置擷取的資料可用于提高效率、實時決策、解決關鍵問題，并最終創造新的創新體驗。然而随着互相連接配接的裝置越來越多，公司所面臨的碎片化和新挑戰也越來越多。為了擷取和利用資料的力量，他們需要解決方案來提供可互操作的端到端協作，進而在網際網路和裝置之間架起橋梁，同時駕馭即将到來的創新浪潮。
SIMICAS® OEM 裝置遠端運維套件是由 SIEMENS DE&DS DSM 團隊開發的一套面向裝置制造商的數字化解決方案，該方案借助物聯網實作裝置的高效遠端運維，對售後服務資料進行智能分析，進而真正實作整體售後環節的降本增效。
在 IIoT 大背景的發展浪潮下，SIMICAS 為企業提供了一個踏入數字化世界的靈活選擇，幫助企業根據自身發展需求定制數字化發展路徑。SIMICAS 解決方案由四個部分組成：SIMICAS 智能網關、SIMICAS 組态工具，以及兩個在西門子基于雲的開放式物聯網作業系統 MindSphere 基礎上開發的 APP——SIMICAS 生産透鏡和 SIMICAS 産效分析。
一、系統架構
在其 1.0 版中，我們使用了 Flink + Kafka + PostgreSQL + Redis 的架構。該系統的資料流如下：
::: hljs-center
:::
裝置資料通過部署至現場的網關上傳至物聯網接入元件，元件根據配置對資料進行解析處理後，将其寫入 Kafka 隊列，Flink 從 Kafka 中消費資料并進行計算，原始值及計算後的名額資料都會被寫入 PostgreSQL 中，最新值還會存一份到 Redis 中，以便更快地響應前端實時的資料查詢，裝置曆史資料則從 PostgreSQL 中查詢。
二、業務挑戰
1.0 系統落地之後，我們遇到了兩大挑戰，一個是部署繁瑣，一個是應用複雜。
具體來說，因為引入了 Flink 和 Kafka，導緻系統部署時非常繁瑣，伺服器開銷巨大；同時為了滿足大量資料的存儲問題，PostgreSQL 中不得不做分庫分表操作，應用程式較為複雜。
如何降低系統複雜度、減少硬體資源開銷，幫助客戶減少成本，成為研發團隊的核心任務。
三、技術選型
從産品的實際痛點出發，結合未來産品的發展規劃，我們團隊計劃對産品的資料處理部分進行重構，在技術選型時主要考慮了如下幾個方面：
高性能，可以支援百萬級别的并發寫入、萬級的并發讀取，大量聚合查詢時依然有高性能表現
高可用，可支援叢集部署，可橫向擴充，不存在單點故障
低成本，資料庫對硬體資源要求低，資料壓縮率高
高度一體化，在具備以上三個特點的基礎上，是否具備一定的消息隊列、流式計算和緩存的功能
本着以上幾個需求，在對各種開源資料平台、時序資料庫（Time Series Database）進行選型對比後，我們發現 TDengine 正好符合産品重構所有的要求，尤其是低成本和高度一體化這兩個點，這是目前絕大部分資料平台或時序資料庫都不具備的，是以團隊果斷選擇了 TDengine。
四、落地實踐
資料流程
在确定選擇 TDengine 作為系統的序資料庫後，我們在 SIMICAS® OEM 2.0 版本中移除了Flink、Kafka 以及 Redis，新系統的資料流如下：
::: hljs-center
:::
資料模組化
建立資料庫
資料預設儲存 2 年，資料庫采用 3 節點叢集，資料采用 3 副本存儲，保留 update 能力；
create database if not exists simicas_data keep 712 replica 3 update 2;
建立實時資料表格
為平台中的每種裝置類型建立一個獨立的超級表（super table），為每種裝置類型下的每個具體裝置建立獨立的裝置子表。
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})
建立狀态表
為平台中所有裝置建立一個共同的超級表。
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 表達式 + 實時查詢的方式實作了系統中的名額計算。我們使用 JEXL 表達式來定義名額的計算表達式，系統解析後将變量替換成 SQL 查詢任務，在查詢傳回結果後再到系統中進行計算，傳回至前端。
比如計算某項目下所有裝置目前電壓的平均值，其表達式為 avg(voltage,run_status=1 && project=abc)，它會被分解為：1）查詢 run_status=1 && project=abc 的所有裝置；2）查詢第一步結果中所有裝置 voltage 字段的最新值；3）計算第二步所有裝置最新結果的平均值。
得益于多線程和 TDengine 高效的查詢表現，單個 KPI 的查詢 P99 表現小于 100ms。
::: hljs-center
:::
五、遇到的問題
在 TDengine 官方推薦的最佳實踐中，資料表模組化建議使用多列模式，我們團隊在一開始選擇了這種方式，但是在實際使用中發現，部分客戶的裝置測點非常多，甚至超過 2000 列，這樣可能會因為單行資料過大而導緻插入資料 SQL 過長的問題[1] ；另一個問題是現場裝置是按照“OnChange（突發上送）”方式進行資料上傳，導緻非常多的 NULL 值出現，在執行 select last(*) from device_xxx 時效率較低[2]。
::: hljs-center
:::
在與 TDengine 官方的技術人員溝通後，我們了解到，last 函數是對每列進行查找，直到最近一條非 NULL 值為止，在當時的版本下，cache 對 last 函數是無效的。
後來，團隊通過對項目中單個裝置參數的最大數量進行限制，解決了問題[1]；又通過修改裝置資料的上傳方式，解決了問題[2]。