设备属性与遥测基础
在 ThingsBoard 平台中，属性（Attributes）与遥测（Telemetry）是设备数据的两种核心表达形式。理解它们的定义、区别、存储机制及数据生命周期，是进行批量更新与遥测优化的前提。
1. 属性（Attributes）
属性用于描述设备的静态或半静态特征，通常不随时间频繁变化。例如设备型号、固件版本、安装位置、客户信息等。属性数据主要用于设备标识、配置管理和分组筛选。
- 数据类型：键值对（Key-Value），值支持字符串、数字、布尔、JSON 对象。
- 更新频率：低，通常在设备注册、配置变更或维护时更新。
- 作用域：分为服务端属性（由平台或应用写入）、客户端属性（由设备上报）、共享属性（可被客户端与服务端双向读写）。
2. 遥测（Telemetry）
遥测用于描述设备的动态测量数据，随时间连续变化。例如温度、湿度、电压、转速、GPS 坐标等。遥测是时序数据的主要载体，用于实时监控、告警触发和历史分析。
- 数据类型：带时间戳的键值对（Key-Value + ts），值支持数字、字符串、布尔、JSON。
- 更新频率：高，通常以秒或毫秒级间隔上报。
- 存储特性：按时间序列存储，支持数据保留策略（TTL）和聚合查询。
3. 核心区别对比
| 对比维度 | 属性（Attributes） | 遥测（Telemetry） |
|---|---|---|
| 本质 | 设备状态/配置 | 设备测量/事件 |
| 时间维度 | 无时间戳或仅记录最后更新时刻 | 每条数据自带精确时间戳 |
| 更新频率 | 低（分钟/小时/天级） | 高（秒/毫秒级） |
| 存储方式 | 键值存储（Cassandra / PostgreSQL） | 时序数据库（Cassandra / TimescaleDB） |
| 数据保留 | 永久保留，除非显式删除 | 按 TTL 策略自动清理 |
| 典型用途 | 设备分组、配置下发、固件管理 | 实时仪表板、告警规则、历史分析 |
4. 存储机制
ThingsBoard 根据数据类型选择不同的存储后端，以平衡查询性能与存储成本。
- 属性存储：默认使用 Cassandra 或 PostgreSQL 的键值表。每个设备的所有属性以 JSON 对象形式存储，支持按 key 快速检索。更新时直接覆盖旧值，不保留历史版本。
- 遥测存储：默认使用 Cassandra 的时序表或 TimescaleDB 的超表。每条遥测记录包含设备ID、时间戳、键名、数值。支持按时间范围、聚合函数（AVG、MAX、MIN）高效查询。
优化提示： 对于高频遥测，建议启用数据保留策略（TTL）并合理设置分区键，避免单表数据膨胀导致查询性能下降。属性更新应避免在循环中逐条调用，优先使用批量更新 API。
5. 数据生命周期
属性与遥测在 ThingsBoard 中遵循不同的生命周期管理策略。
6. 实际应用场景
- 设备注册与配置：使用服务端属性存储设备序列号、客户ID、固件版本。设备上线时读取属性完成初始化。
- 实时监控：遥测数据每5秒上报一次温度值，触发告警规则并在仪表板实时展示。
- 批量更新：通过 ThingsBoard REST API 或 MQTT 批量更新一组设备的共享属性，实现远程配置下发。
- 历史分析：查询过去24小时的遥测数据，计算平均值、最大值，用于能效分析报告。
注意事项： 不要将高频变化的动态数据存入属性中，否则会导致存储压力增大且无法利用时序查询优化。属性更新频繁时，建议评估是否应转为遥测数据。
7. 数据流示例
以下是一个设备上报遥测并同时更新属性的典型 MQTT 消息格式：
// 遥测上报（带时间戳）
{
"ts": 1712563200000,
"values": {
"temperature": 23.5,
"humidity": 68.2
}
}
// 客户端属性更新（无时间戳）
{
"firmwareVersion": "2.1.0",
"rssi": -45
}平台接收到数据后，遥测进入时序存储，属性直接覆盖旧值。开发者可通过规则链对两类数据分别执行不同的处理逻辑，例如遥测触发告警，属性更新触发配置同步。