1、物联网数据概述：物联网数据特点与生命周期管理
大家好，我是你们的讲师。今天咱们正式开始聊物联网数据。说实话，我做了这么多年物联网项目，最深的感触就是——数据才是整个平台的灵魂。没有数据，你搞再炫酷的界面、再复杂的规则引擎，都是空中楼阁。
这一节，我会从三个核心维度展开：数据特点、常见格式、生命周期管理。嗯，都是基本功，但也是你后面做时序数据库选型和对接的基石。
1.1 物联网数据的特点：高频、时序、海量
先问大家一个问题：物联网数据和传统互联网数据，最大的区别在哪？
我个人习惯用一个比喻来解释。传统互联网数据，像图书馆里的书——你查一次，它就在那，不怎么变。但物联网数据呢？它像一条奔流的河，每一秒都有新的水涌过来，而且你必须实时处理。
具体来说，有三个核心特点：
- 高频：设备上报频率从秒级到毫秒级不等。我在项目中遇到过最极端的情况，是一台工业振动监测设备，每秒上报2000个数据点。你想想看，一台设备一天就是1.7亿条数据。
- 时序：每条数据都带一个时间戳，而且时间戳就是它的主键。数据之间天然有先后顺序，你不能乱排。说白了，物联网数据就是一条时间线上的快照集合。
- 海量：一台设备可能还好，但一个物联网平台往往接入成千上万台设备。我记得有一次做智慧水务项目，全市装了50万个智能水表，每15分钟上报一次。一天的数据量是多少？480万条。一个月就是1.44亿条。传统的关系型数据库，根本扛不住。
核心结论：物联网数据是典型的“写多读少、追加写入、按时间查询”的数据。这也是为什么我们要用时序数据库，而不是MySQL或PostgreSQL。
1.2 常见设备数据格式：JSON与二进制
设备上报数据，格式五花八门。但归纳起来，主流就两种：JSON 和 二进制。
1.2.1 JSON格式
JSON 是物联网领域最通用的数据格式。为什么？因为它可读性强、解析方便、生态成熟。我早期做智能家居项目时，所有设备都用JSON上报，调试起来特别爽。
一个典型的JSON数据包长这样：
{
"deviceId": "sensor_temp_001",
"timestamp": 1712563200000,
"data": {
"temperature": 25.6,
"humidity": 68.2,
"battery": 85
}
}
但JSON也有缺点——冗余大。每个字段名都要重复传输，比如"temperature"这个字符串，每次上报都带一遍。对于带宽有限的NB-IoT或LoRa设备，这简直是灾难。
避坑指南：我曾经在一个NB-IoT项目中，设备上报JSON数据，结果一个月流量费比设备本身还贵。后来全部改成二进制协议，流量费直接降了70%。所以，选格式前一定要评估设备网络环境。
1.2.2 二进制格式
二进制格式，说白了就是按字节定义数据结构。它体积小、解析快，但可读性差，调试起来比较痛苦。
举个例子，上面那个JSON数据，用二进制可以这样定义：
字节0-3: 设备ID (uint32)
字节4-7: 时间戳 (uint32)
字节8-11: 温度值 (float32)
字节12-13: 湿度值 (uint16, 实际值除以10)
字节14: 电池电量 (uint8, 百分比)
你看，总共才15个字节。而同样的数据用JSON，至少150个字节。差距是10倍。
| 对比项 | JSON格式 | 二进制格式 |
|---|---|---|
| 可读性 | 高 | 低 |
| 解析速度 | 较慢 | 极快 |
| 数据体积 | 大（冗余多） | 小（紧凑） |
| 适用场景 | WiFi、以太网等带宽充足的场景 | NB-IoT、LoRa、2G等低带宽场景 |
| 调试难度 | 低 | 高（需要协议文档） |
注意：二进制格式虽然省流量，但协议一旦定下来，后期扩展很麻烦。我建议在协议设计时预留一些保留字节，方便后续加字段。别问我怎么知道的——都是血泪教训。
1.3 数据生命周期管理
数据不是存进去就完事了。你想想看，海量数据一直存着，存储成本会越来越高。而且，很多数据过了时效性，价值就大打折扣。
所以，我们需要对数据做生命周期管理。说白了，就是给数据定一个“生老病死”的规则。
我一般把数据分为三个层级：
- 热数据：最近7天的数据。查询频率高，需要毫秒级响应。一般存在内存或SSD上。
- 温数据：7天到3个月的数据。查询频率降低，但偶尔会用到。可以存在普通硬盘上。
- 冷数据：3个月以上的数据。几乎不查，但为了合规或审计需要保留。可以压缩后存到廉价存储上，比如对象存储或磁带库。
具体怎么做？我分享一个我在智慧园区项目中的实践：
-- 以TDengine为例，设置数据保留策略
-- 热数据保留7天，不压缩
-- 温数据保留90天，压缩存储
-- 冷数据自动迁移到对象存储
CREATE DATABASE iot_data
KEEP 3650 -- 总保留10年
DAYS 7 -- 每7天一个文件
BLOCKS 6 -- 每个文件6个数据块
COMP 2; -- 压缩级别
我的建议：不要等到存储满了才考虑生命周期管理。项目一开始就要设计好数据分级策略。我曾经接手过一个项目，上线两年后才发现存储成本失控，最后不得不停机做数据迁移——那叫一个痛苦。
另外，数据生命周期管理还要考虑合规性。比如金融或医疗行业的物联网数据，法律要求保留至少5年。你不能因为存储成本高就提前删掉，那是违法的。
嗯，这一节的内容就到这里。总结一下：物联网数据的特点是高频、时序、海量；常见格式有JSON和二进制，选哪个要看网络环境；数据生命周期管理要提前规划，分级存储。
下一节，我们会深入聊时序数据库的选型。到时候我会拿几个主流产品做对比，看看它们各自的优缺点。咱们下节见。