物联网设备流水入库TDengine改造方案

1 .存储机制改造

      针对提出的流水查询需求，结合设备上报数据讨论后，初步定以下几种方案。

1.1.ES -> TDengine

1、ES入库有延时
2、ES没有提供数据监听API（不能主动监听，实时监听）
2、有替代方案监听ES数据入库 （被动方式，1、有延时，2、对ES服务有压力）

1.2. 暴露http接口给linkthings调用 -> TDengine 方案

1、服务宕机会丢数据
2、有http并发风险
3、高并发时，也会有一定延时

1.3. 设备流水 -> kafka -> TDengine 方案

1、linkthings需要改动
2、应用组没有消息队列
3、需要服务模块增加
4、需要运维提供

1.4.方案总结

      首先，个人赞成1.3方案，建议应用组增加消息队列服务。从稳定性、数据一致性考虑，方案1.3可以保证数据不丢失、且实时性高。

2.数据库建模方案

      结合目前设备流水数据在ES的存储格式，以及数据的查询、解析、展示。同时分析流水数据展示的场景，结合linkthings、Aep展示数据的界面，初步分析有以下几种建模思路。
      这块设计也主要是因为需求提出的流水查询要混合类型展示对建模有影响。大家有更好的设计想法欢迎明天讨论。

2.1.大宽表设计

2.1.1.简化字段

      就是建表只有设备相关的主要信息，外加上报原始数据、解析后的数据json串存一个字段。
Sql：

CREATE TABLE device_flow_table (
    data_ts TIMESTAMP,
    collect_time TIMESTAMP,
    create_time TIMESTAMP,
    data_str VARCHAR(10000),
    device_code VARCHAR(100),
    device_codes VARCHAR(10000),
    device_createor_id VARCHAR(100),
    device_manufacturer VARCHAR(100),
    device_name VARCHAR(100),
    device_type_name VARCHAR(100),
    device_unit_name VARCHAR(100),
    id VARCHAR(100),
    message VARCHAR(100),
    metadata VARCHAR(100),
    project_name NCHAR(200),
    push_state INT,
    show_message NCHAR(2000),
    storage_time TIMESTAMP,
    old_data_str NCHAR(2000),
    parse_data_str NCHAR(2000)
);

效果

优点：
1、 结构简单
2、 表字段少，读写效率高
3、 数据入库方便
缺点：
1、 字符串字段有长度限制，万一设备上报字符串过长，有入库失败风险
2、 后期无法通过sql对属性聚合计算
3、 单表数据量大

2.1.2.全字段建列

      这个就是真正意义的大宽表，所有物模型的字段都将建列。
优点：
1、 查询简单
2、 程序解析结果数据简化
3、 可以通过sql做聚合查询
4、 数据入库方便
缺点：
1、 表字段多
2、 查询返回字段多、多null字段，多不相关字段
3、 单表数据量大
PS：
TDengine有说明：表的每行长度不能超过 48KB

2.2.使用超级表

2.2.1单超级表

      超级表使用大宽表，子表按设备型号建，TAG里设置project_id,company_id,unit_code,device_code。
建超级表：

create STABLE device_flow (
    data_ts TIMESTAMP,
    collect_time TIMESTAMP,
    create_time TIMESTAMP,
    data_str VARCHAR(10000),
    device_code VARCHAR(100),
    device_codes VARCHAR(10000),
    device_createor_id VARCHAR(100),
    device_manufacturer VARCHAR(100),
    device_name VARCHAR(100),
    device_type_name VARCHAR(100),
    device_unit_name VARCHAR(100),
    id VARCHAR(100),
    message VARCHAR(100),
    metadata VARCHAR(100),
    project_name NCHAR(200),
    push_state INT,
    show_message NCHAR(2000),
    storage_time TIMESTAMP
) TAGS (device_unit_code varchar(100),
project_id BIGINT,
company_id INT);

建子表：

create table device_flow_ADK_CN_470 USING device_flow tags ("ADK-CN-470",1001,1001001);

      另一种就是超级表采用2.1.2的思路，TAGS一致。
优点：
1、 分别拥有2.1.1\2.1.2的优点
2、 数据量变小，分物模型存储了
3、 可以自动建表
缺点：
1、 分别拥有2.1.1\2.1.2的缺点
2、 插入数据需要判断型号 （TDengine可以通过超级表查所有子表数据，但是不能通过超级表插入数据到对应子表）

2.2.2多超级表

      拆解一个物模型建一个超级表，再使用2.2.1的思路，这样的超级表字段也少（字段与物模型1：1），但是因为业务需求，列表有不同物模型设备数据统一展示，所以这种设计不行。

      以上使用超级表思路优点类似分片，韵达快递有类似实现：
https://baijiahao.baidu.com/s?id=1731137979785063689&wfr=spider&for=pc （一个扫描枪一张表）

2.3.主副表设计

      主表只记录主要字段，副表是大宽表。查询采用join查询。这里依然是面临字符串超长的问题、字段聚合计算问题。

3.需求与技术冲突

业务需求的设备流水展示界面：

      从上面可以看出，这个需求与技术实现有冲突，能否按照linkthings一样，根据物模型查，或者设备流水列表按照物模型分组展示？
      但是确实混合展示更符合实际业务与认知习惯。

4.补充说明

1、设备推送数据字段不可预知，需要增加自动增加表字段机制。
2、tags可以有json类型，是否可以变态的设计，将设备上报数据json串放到 tags的字段里？
3、如果使用超级表，建表后超级表新增字段，子表不会对应新增，注意所有表都需要执行新增字段。
      涛思数据有专门的按行业分类的交流群，支持态度也超级好，有什么不懂可以直接在里面问。好了，就写到这里，希望能帮到大家。