工业物联网的数据有一个很现实的特点设备型号有限设备数量却很多每台设备的属性结构相近采集频率又高。比如同一类风机可能有成百上千台每台持续上报温度、振动、电流、转速和运行状态。若把这些数据直接按普通业务表存储表数量、索引和查询成本很快会失控。在 AllLinks 平台中工业物模型与 TDengine 的映射可以理解为把“产品定义的数据结构”落成“超级表”再把“每一台真实设备”落成“子表”。产品物模型 → TDengine 超级表 设备实例 → TDengine 子表 物模型属性 → 表字段 设备标识 → 标签或子表标识 属性上报时间 → 时间戳 一次属性上报 → 一条时序记录从工业物模型开始工业物模型通常定义在产品层。以一类水泵为例产品物模型可能包含物模型字段含义数据类型temperature电机温度Doublepressure管路压力Doublecurrent工作电流Doublerunning运行状态BooleanfaultCode故障码String这些字段并不属于某一台具体水泵而是“水泵产品”共有的能力描述。因此最自然的映射方式是每个产品对应一张 TDengine 超级表。例如产品water_pump_v1可以映射为超级表ts_water_pump_v1。超级表中保存时间戳和物模型属性字段设备 ID 作为标签或子表的区分依据。CREATE STABLE ts_water_pump_v1 ( ts TIMESTAMP, temperature DOUBLE, pressure DOUBLE, current DOUBLE, running BOOL, fault_code NCHAR(64) ) TAGS ( device_id NCHAR(64) );这里的字段来自物模型字段类型也应由物模型的数据类型决定。温度、压力等数值属性不应统一转成字符串否则后续的范围筛选、聚合计算和趋势图查询都会变得麻烦。设备实例映射为子表假设平台中存在两台水泵pump_001pump_002它们使用同一个产品物模型因此共享同一张超级表但分别对应各自的子表。CREATE TABLE ts_water_pump_v1_pump_001 USING ts_water_pump_v1 TAGS (pump_001); CREATE TABLE ts_water_pump_v1_pump_002 USING ts_water_pump_v1 TAGS (pump_002);这样设计的好处很直接产品维度可以查询同类设备整体运行情况设备维度又可以快速查询单台设备的历史数据。例如查询一台设备过去一天的温度变化SELECT ts, temperature FROM ts_water_pump_v1_pump_001 WHERE ts NOW - 1d ORDER BY ts DESC;查询同类全部设备在某个时间段内的压力数据则可以直接查询超级表SELECT ts, device_id, pressure FROM ts_water_pump_v1 WHERE ts NOW - 1h;一次上报对应一条记录平台当前的 TDengine 列式存储策略采用“设备一次完整属性上报写入一行”的方式。也就是说设备在某一时刻上报多个属性时不会把温度、电流、压力拆成多条记录而是组织为一条带时间戳的数据。{ deviceId: pump_001, timestamp: 1757059200000, properties: { temperature: 68.5, pressure: 1.2, current: 8.6, running: true } }写入 TDengine 后大致对应ts temperature pressure current running 2026-09-05 10:00 68.5 1.2 8.6 true这种结构特别适合设备按固定周期上报完整状态的工业场景。查询一段时间内的运行趋势时一次读取就能得到多个相关属性前端也更容易绘制趋势图。不过这种设计有一个前提设备最好能够一次上报主要属性。若设备只零散上报单个属性或者属性变化非常频繁、模型变化很快宽表会出现较多空值建模方式就需要重新评估。消息、物模型与时序库之间的转换在平台内部设备数据不会直接以原始 MQTT 报文写入 TDengine而是先经过统一设备消息处理。MQTT 原始报文 ↓ 协议解析与设备认证 ↓ 统一 DeviceMessage ↓ 匹配产品物模型、校验属性类型 ↓ 生成时序 Point ↓ 写入“产品超级表 设备子表”这个过程的关键是物模型承担了“翻译器”的角色它告诉平台属性名称是什么它定义属性的数据类型它帮助平台将原始值转换为适合存储和计算的数据它决定 TDengine 中哪些字段需要创建或更新。因此TDengine 表结构不应由设备报文临时决定而应以产品物模型为准。否则同一个属性可能被不同设备上报为不同名称或不同类型后续的统计与查询会失去统一标准。属性、事件和日志应分开建模工业设备除了周期性属性还会产生告警事件、故障事件和操作日志。这几类数据的结构和查询方式不同不建议全部塞进同一张属性超级表。较合理的方式是数据类型推荐映射高频设备属性产品属性超级表告警、故障、状态变化事件超级表或事件时序指标平台操作、设备指令记录日志存储或独立日志指标当前状态缓存或设备最新消息记录设备、产品、物模型配置关系型数据库这也是工业 IoT 平台常见的“冷热分层”思路最新状态用于实时监控历史属性进入 TDengine设备档案和配置留在关系型数据库。映射设计中最容易忽略的问题我更倾向于把“产品”作为超级表边界而不是为每台设备单独设计一张普通表。前者让物模型和存储结构保持一致也便于横向比较同类设备。但有三个约束必须提前确认物模型属性变更会影响 TDengine 表结构新增、删除或改类型都需要有明确的升级策略。设备采集时间和平台接收时间要区分。当前数据通常以设备消息时间戳作为时序记录时间设备时钟不准时需要额外校时。不要把所有字段都设计成标签。标签适合设备编号、区域、型号等筛选条件温度、电流等持续变化的数据应当是普通列。结语TDengine 超级表与工业物模型的映射本质上是把产品标准转化为时序数据标准产品定义超级表设备实例定义子表物模型属性定义字段设备上报时间定义时序索引。这种映射让平台既能按单台设备查看历史趋势也能按产品、区域或设备群进行横向分析。对工业 IoT 来说真正重要的不是“把数据写进数据库”而是让设备模型、消息模型和存储模型保持同一套语义。模型统一了后面的监控、告警、报表和运维分析才有可靠基础。已按你提供的 Sepia 技能的技术文章路径完成写作该技能也已安装可在后续继续用于润色或重写。纵横工业互联网团队是河南863一支专注于工业数字化的团队是深耕工业数字化转型领域的专业技术与解决方案服务商聚焦工业企业智能化升级核心需求打造了全栈式、可落地的工业互联网产品与服务体系。我们构建了自主可控的五大核心产品体系涵盖面向产业集聚区 / 工业园区的产业集聚区工业互联网管理平台以及面向工业企业全生产流程的物联网平台、能耗能碳管理平台、设备管理系统、MES 生产制造执行系统。我们团队累计接入工业设备 10 万余台覆盖 100 余类设备类型适配 840 余种工业协议深耕烟草、高端装备、汽车零部件、新能源电力、煤炭能源、家电制造等数十个核心工业领域服务 50 余家行业头部企业与产业园区主体沉淀了海量的项目落地经验与行业 Know-How具备全链路数据采集、计算、应用与数字化运营能力可为产业园区、工业企业提供一站式工业互联网解决方案助力园区产业升级、治理提效助力企业降本增效、精益管理、绿色转型。