1. 遥测数据基础:什么是遥测数据、数据格式与采集原理

各位同学好,我是老张。在遥测系统这个行当里摸爬滚打了十几年,今天咱们来聊聊最基础的东西——遥测数据到底是什么。

很多人一上来就扎进过滤规则、流式计算,结果连原始数据长什么样都没搞清楚。我见过不少团队,花了大半年搭了一套过滤平台,上线第一天发现数据格式解析就报错。嗯,基础不牢,地动山摇。

1.1 什么是遥测数据

说白了,遥测数据就是「远程测量」的结果。设备在远端运行,我们想知道它好不好、快不快、有没有出问题,就得靠遥测数据来传话。

举个例子。你手机上的 GPS 定位、CPU 温度、电池电量,每隔几秒就会上报一次。这些上报的内容,就是遥测数据。在工业场景里,可能是风力发电机的转速、石油管道的压力、自动驾驶汽车的激光雷达点云。

我个人习惯把遥测数据分成三类:

  • 指标数据(Metrics):数值型的,比如 CPU 使用率 78.5%、内存占用 4.2GB。这类数据最常用,也最好做过滤。
  • 事件数据(Events):离散的、有状态变化的,比如「设备离线」「温度超过阈值」。事件通常带一个时间戳和一个状态码。
  • 日志数据(Logs):文本型的,比如应用报错堆栈、用户操作记录。日志最灵活,但也最占带宽。

核心要点:遥测数据的本质是「带时间戳的观测值」。不管格式怎么变,时间、标识、数值这三个要素缺一不可。

1.2 遥测数据格式:JSON 与 Protobuf

数据要传,就得有个格式。目前主流的有两种:JSON 和 Protobuf。我当年刚入行时,JSON 一家独大,后来 Protobuf 慢慢追上来了。为什么?咱们对比着看。

1.2.1 JSON 格式

JSON 的好处是——人类可读。你打开一个 JSON 文件,一眼就能看出里面是什么。调试的时候特别方便。

{
  "device_id": "sensor-01",
  "timestamp": 1712563200,
  "metrics": {
    "temperature": 36.5,
    "humidity": 72.3,
    "pressure": 1013.25
  },
  "status": "normal"
}

但 JSON 有个硬伤:冗余。每个字段名都要重复传,比如 "device_id" 这个字符串,1000 条数据就传 1000 遍。带宽浪费很严重。我在项目中遇到过,一个物联网平台每天上报 10 亿条 JSON 数据,光字段名就占了 40% 的流量。

1.2.2 Protobuf 格式

Protobuf 是 Google 搞的,全称 Protocol Buffers。它用二进制编码,字段名不传,只传编号。同样的数据,体积能缩小 60%-80%。

// 定义文件 (sensor.proto)
message SensorReading {
  string device_id = 1;
  uint64 timestamp = 2;
  float temperature = 3;
  float humidity = 4;
  float pressure = 5;
  string status = 6;
}

编码之后,你看不懂了——全是二进制字节流。但机器解析极快,带宽占用极低。适合高吞吐、低延迟的场景。

对比维度 JSON Protobuf
可读性 ★★★★★ 人类友好 ★★☆☆☆ 需要工具反序列化
数据体积 较大(字段名重复) 很小(二进制编码)
解析速度 中等(文本解析) 极快(二进制直接映射)
Schema 约束 弱(可随意增减字段) 强(需预定义 .proto 文件)
适用场景 调试、小规模、异构系统 生产环境、高并发、嵌入式

我的建议:开发阶段用 JSON,方便调试。上线前转成 Protobuf,省带宽、提性能。我们团队就是这么干的,效果很好。

1.3 数据采集原理

数据怎么从设备端到服务器?这里涉及三个环节:采集、传输、接收。我画了一张图,把整个流程串起来。

遥测数据采集与传输流程 传感器 / 设备 采集原始信号 边缘采集器 模数转换 / 协议封装 传输通道 MQTT / HTTP / gRPC 模拟信号 JSON / Protobuf 接收网关 协议解析 / 鉴权 消息队列 Kafka / RabbitMQ 存储与处理 时序数据库 / 流计算 解码后数据 异步缓冲 网络传输 ⚠️ 注意 采集频率、数据精度、传输协议的选择,直接影响后续过滤效果。 高频采集 + 低精度数据,过滤规则容易误判;低频采集 + 高精度数据,可能漏掉瞬态异常。

整个流程其实不复杂。设备端采集原始信号,边缘采集器做模数转换和协议封装,然后通过网络传到服务器。服务器这边,接收网关先做鉴权和协议解析,再把数据扔进消息队列缓冲,最后落到存储系统里供后续处理。

这里有个坑,我曾经踩过。有一次我们做车载遥测,设备端采集频率设成了 100Hz,也就是每秒 100 条数据。结果网关扛不住,消息队列积压,最后丢了一大半数据。后来我们加了边缘过滤——在设备端先做一次降采样和异常判断,只上传有价值的数据。嗯,这就是咱们这门课的核心:过滤机制。

避坑指南:我曾经见过一个团队,把采集频率设得特别高,觉得「数据越多越好」。结果存储成本暴涨,查询慢得像蜗牛,过滤规则也因为数据量太大而跑不动。记住:采集不是越多越好,够用就行。

1.4 小结

这一章咱们把遥测数据的基础捋了一遍。你想想看,遥测数据就是设备在说话,JSON 和 Protobuf 是它的语言,采集传输是它的嘴巴和耳朵。搞清楚了这些,后面讲过滤规则、流式计算、降采样策略,你才能知道「过滤」到底在过滤什么。