数据采集
概述
数据采集包含硬件和软件，硬件包含传感器，软件包含数据采集软件。
只从软件角度出发，数据采集软件包含数据采集工具和数据采集平台。
目前大部分的数采项目采用MQTT协议，MQTT协议是物联网领域最常用的协议之一，主要用于设备之间的通信。
如果只是简单的数采项目，只需要采集器将数据采集后，通过对应协议与加密打包发送给数据采集平台，数据采集平台将数据解密并存储到数据库中，然后再数据分析，最后通过Web页面展示出来。
简单数采项目运行流程
数采项目原理详解：
从硬件“抓数据”到软件“玩数据”的全流程
一、硬件部分：像“数据侦察兵”一样收集前线信息
核心作用：从物理世界“抓取”数据，转化为计算机能懂的数字信号。
通俗类比：相当于人的“五官”+“快递分拣站”。
传感器：数据采集的“五官”
功能：感知物理世界的变化，比如温度、压力、光线、声音等。
例子：
温度计（温度传感器）：把“热”转化为数字“25℃”；
摄像头（图像传感器）：把画面转化为像素数据；
电流传感器：监测电线里的电流大小，转化为数字信号。
数据采集器（DTU/RTU）：传感器的“大脑”
功能：收集多个传感器的数据，做初步处理（去噪、校准），打包成标准格式。
通俗理解：比如家里的智能电表，不仅测用电量，还会把数据存起来，定期打包发给电力公司。
通信模块：数据的“运输卡车”
功能：把打包好的数据从硬件传输到服务器（云端）。
常见方式：
- 无线：4G/5G（像手机发信息）、WiFi（短距离高速传输）、LoRa（山区远距离低功耗）；
- 有线：网线（像电脑插网线上网）、RS485（工业场景里的“数据线”，抗干扰）。
电源与保护设备：硬件的“后勤部队”
- 功能：给传感器和采集器供电，防止雷击、电压波动损坏设备（比如工业现场的防雷器）。
二、软件部分：
从“数据搬运工”到“数据分析师”的三层架构
核心逻辑：按“采集-传输-处理-应用”分层设计，每层解决不同问题。
第一层：设备接入层（数据“收费站”）
目标：让各种硬件都能“说同一种语言”，把数据顺利收上来。
关键组件：
驱动程序：相当于硬件的“翻译官”，比如摄像头需要驱动才能被电脑识别；
协议解析器：处理不同硬件的通信协议（比如MQTT、Modbus、HTTP），举例：
- 传感器用MQTT协议发消息，软件解析后知道“哦，这是温度数据”；
设备管理平台：记录每个硬件的“身份信息”（编号、位置、状态），比如在工厂里，哪个传感器坏了会报警。
第二层：数据处理层（数据“加工厂”）
目标：清洗、存储、分析数据，把“杂乱的原材料”变成“有用的信息”。
分阶段工作：
数据清洗与预处理：
去噪：剔除错误数据（比如传感器突然报出“温度1000℃”，明显异常）；
补全：网络断了没收到的数据，用算法“猜”一个合理值（类似手机没信号时，稍后自动同步消息）；
数据存储：
时序数据库（重点）：专门存按时间顺序来的数据，比如电表每10分钟传一次数据，存成“时间-数值”对，查询速度极快（类比心电图记录，按时间线看变化）；
常见工具：InfluxDB、TDengine、Prometheus；
实时分析与批量分析：
实时分析：用Flink/Spark Streaming，比如工厂设备温度突然升高，立刻报警；
批量分析：用Hadoop/Spark，每天晚上分析一整天的数据，找出设备故障规律。
第三层：应用展示层（数据“说明书”）
目标：把数据变成人能看懂的信息，辅助决策。
常见形式：
可视化大屏：用图表展示数据，比如工厂的能耗监控大屏，红色代表超标，绿色正常；
业务系统集成：把数据嵌入到业务流程中，比如电商平台用用户行为数据推荐商品；
预警与自动化：设定规则自动触发动作，比如仓库湿度超过80%，自动启动抽湿机；
移动端APP：手机查看数据，比如智能家居APP远程看家里温度。
三、软件核心技术：让数据采集又快又准的“秘诀”
实时性保障：
- 用消息队列（Kafka/RabbitMQ）缓冲数据，避免大量数据同时到达导致系统崩溃（类似高速公路的服务区，车太多先停下休息）；
可靠性设计：
断点续传：网络断了，数据先存在硬件里，联网后补发（像手机离线下载视频）；
数据校验：用CRC校验码检查数据有没有传错（类似快递单上的校验码，防止地址写错）；
可扩展性：
- 分布式架构：比如用Hadoop集群处理海量数据，加服务器就像给工厂增加生产线，产能翻倍；
四、数采项目的典型场景：软硬件如何协作？
案例：智能农业大棚数采系统
硬件部分：
温湿度传感器：实时测大棚内温度、湿度；
光照传感器：测阳光强度；
4G DTU：把数据打包，通过4G网络发给云端；
软件部分：
设备接入层：解析传感器发来的Modbus协议数据；
处理层：用InfluxDB存数据，用Flink实时分析，比如温度超过35℃；
应用层：大屏显示当前环境数据，自动触发通风机开关，同时给管理员手机发预警信息。
案例：智能监控告警系统
硬件部分：
摄像头：实时监控园区设备；
4G DTU：把数据打包，通过4G网络发给云端；
软件部分：
设备接入层：解析摄像头发来的视频流；
处理层：用InfluxDB存数据，用AI实时分析视频影像，比如识别出陌生人人脸；
应用层：大屏显示当前多监控画面，自动触发告警，同时给管理员手机发预警信息。
MQTT是什么？
一、MQTT的本质：像快递站一样的“消息中转站”
假设你和朋友住在不同小区，但想互相送零食：
直接送：你自己跑到朋友小区敲门（类似传统客户端直连服务器），但如果朋友不在家，你就得一直等，效率低。
快递站中转：你把零食放到小区快递站，朋友收到通知后自己去取（这就是MQTT的核心逻辑）。
MQTT（Message Queuing Telemetry Transport） 就是这样一种“消息快递站协议”，专门为低带宽、弱网络、多设备连接设计，比如智能家居、物联网设备（灯泡、传感器）、车载系统等。
二、MQTT的三大角色：快递员、快递站、取件人
发布者（Publisher）：寄快递的人
- 比如家里的温度传感器，发现温度超过30℃时，“发布”一条消息：“太热了！”
订阅者（Subscriber）：取快递的人
- 比如空调控制器，“订阅”了“温度过高”的消息，收到后自动开启制冷。
服务器（Broker）：快递站
- 负责接收发布者的消息，根据“地址”（主题）分发给对应的订阅者，不关心消息内容是什么。
三、MQTT的核心原理：靠“主题地址”送消息，不看“收件人是谁”
主题（Topic）：消息的“快递地址”
发布者发消息时，必须给消息贴一个“主题标签”，比如
home/temperature（家庭温度）、car/gps（车载定位）。订阅者提前“订阅”某个主题，比如空调订阅
home/temperature/high，只有主题匹配的消息才会被收到。类比：你在快递站留了地址“3栋501”，所有寄到“3栋”的快递都会被送到你家，不管寄件人是谁。
消息传输：轻量级、省流量
MQTT的消息格式非常简单，只有主题和内容，比如：
text主题：home/temperature 内容：32℃不像HTTP协议有大量头部信息，适合传感器、智能手表等带宽小的设备。
三种“快递服务”等级：按需选速度或可靠性
QoS 0（最多一次）：消息发出去就不管了，可能丢包（类似平邮，丢了不赔）。
QoS 1（至少一次）：没收到就重发，保证消息到达，但可能重复（类似挂号信，必须签收）。
QoS 2（恰好一次）：确保消息只送一次，不重复不丢失（类似EMS，全程追踪）。
四、为什么物联网场景偏爱MQTT？三大优势对比传统方案
| 场景 | 传统HTTP方案（客户端直连） | MQTT方案（快递站中转） |
|---|---|---|
| 智能家居设备联网 | 每个设备定期向服务器“问”有没有新命令，浪费流量 | 设备只订阅主题，服务器主动推消息，省电省流量 |
| 海量设备同时通信 | 服务器同时处理10万个设备请求，容易崩溃 | 设备只和“快递站”交互，服务器压力分散 |
| 弱网络环境（如电梯、山区） | 网络一断就失联，需重新连接 | 支持“遗言机制”：设备离线时，服务器会记录“它挂了”，网络恢复后补发消息 |
五、生活中的MQTT案例：原来这些都是它！
智能灯泡：手机APP点击“开灯”，APP作为发布者，向主题
home/light/control发消息，灯泡作为订阅者收到后执行命令。共享单车定位：每辆单车作为发布者，定期向主题
bike/location发送GPS坐标，服务器作为订阅者收集数据。医院监护仪：心电图设备向主题
hospital/patient/123发布数据，医生电脑订阅该主题实时查看。智能农业大棚：温湿度传感器向主题
greenhouse/temperature发布数据，云端订阅后分析处理。
六、总结：MQTT的核心逻辑一句话概括
“发布者把消息丢到快递站（Broker），订阅者按主题地址取快递，快递站负责分拣，不管消息是谁发的、发给谁，只看地址对不对。”
这种“去中心化”的设计，让大量设备能像“在同一个快递站取件”一样高效通信，尤其适合物联网时代“设备多、网络弱、流量贵”的场景。