关于tdengine:TDengine-助力西门子轻量级数字化解决方案

小 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 的架构。该零碎的数据流如下：

设施数据通过部署至现场的网关上传至物联网接入组件，组件依据配置对数据进行解析解决后，将其写入 Kafka 队列，Flink 从 Kafka 中生产数据并进行计算，原始值及计算后的指标数据都会被写入 PostgreSQL 中，最新值还会存一份到 Redis 中，以便更快地响应前端实时的数据查问，设施历史数据则从 PostgreSQL 中查问。

二、业务挑战

1.0 零碎落地之后，咱们遇到了两大挑战，一个是部署繁琐，一个是利用简单。

具体来说，因为引入了 Flink 和 Kafka，导致系统部署时十分繁琐，服务器开销微小；同时为了满足大量数据的存储问题，PostgreSQL 中不得不做分库分表操作，应用程序较为简单。

如何升高零碎复杂度、缩小硬件资源开销，帮忙客户缩小老本，成为研发团队的外围工作。

三、技术选型

从产品的理论痛点登程，联合将来产品的倒退布局，咱们团队打算对产品的数据处理局部进行重构，在技术选型时次要思考了如下几个方面：

高性能，能够反对百万级别的并发写入、万级的并发读取，大量聚合查问时仍然有高性能体现
高可用，可反对集群部署，可横向扩大，不存在单点故障
低成本，数据库对硬件资源要求低，数据压缩率高
高度一体化，在具备以上三个特点的根底上，是否具备肯定的音讯队列、流式计算和缓存的性能
本着以上几个需要，在对各种开源数据平台、时序数据库（Time Series Database）进行选型比照后，咱们发现 TDengine 正好合乎产品重构所有的要求，尤其是低成本和高度一体化这两个点，这是目前绝大部分数据平台或时序数据库都不具备的，所以团队果决抉择了 TDengine。

四、落地实际

数据流程

在确定抉择 TDengine 作为零碎的序数据库后，咱们在 SIMICAS® OEM 2.0 版本中移除了 Flink、Kafka 以及 Redis，新零碎的数据流如下：

数据建模

创立数据库

数据默认保留 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。

五、遇到的问题

在 TDengine 官网举荐的最佳实际中，数据表建模倡议应用多列模式，咱们团队在一开始抉择了这种形式，然而在理论应用中发现，局部客户的设施测点十分多，甚至超过 2000 列，这样可能会因为单行数据过大而导致插入数据 SQL 过长的问题[1]；另一个问题是现场设施是依照“OnChange（突发上送）”形式进行数据上传，导致十分多的 NULL 值呈现，在执行 select last(*) from device_xxx 时效率较低[2]。

在与 TDengine 官网的技术人员沟通后，咱们理解到，last 函数是对每列进行查找，直到最近一条非 NULL 值为止，在过后的版本下，cache 对 last 函数是有效的。

起初，团队通过对我的项目中单个设施参数的最大数量进行限度，解决了问题[1]；又通过批改设施数据的上传形式，解决了问题[2]。

然而在基本上，还是咱们在最后建模时，没有充分考虑到客户的业务场景，从而导致了以上问题。因而，咱们团队后续在零碎中实现了同时反对多列模式和单列模式，这样客户就能够依据现场的理论状况，自在切换建模形式。

六、写在最初

与其余开源数据平台或数据库相比，目前 TDengine 的运维监控能力还不算弱小，不过前段时间公布的 TDinsight 曾经带来了很多改良，咱们团队也布局在下一阶段试用一下。
特别感谢涛思数据的陈伟灿及其他共事在产品开发过程给予的反对，尽管在过程中遇到一些问题，但整体而言，TDengine 的各项优异体现给了咱们团队很多惊喜。

最初期待 TDengine 越来越好，帮忙更多客户、更多场景降本增效！

想理解更多 TDengine Database 的具体细节，欢送大家在 GitHub 上查看相干源代码。