智慧农业数据平台系列 · 第二篇 | 采集与汇聚
农业数据采集与汇聚：7种数据源、4种接入方式，一篇说透怎么把数据收进来
···
"项目进场第一周，甲方带我们看了六个系统：墒情监测的、虫情测报的、气象站的、遥感解译的、农情调度的、农机管理的。然后问了一句话——'你们什么时候能把数据都接到一张图上？'
我说先得搞清楚每个系统的数据怎么出来、什么格式、什么频率。甲方说'都是标准接口，很简单'。
结果第二天蹲机房抓包发现：墒情系统说是 MQTT 实际是 HTTP POST，虫情系统接口返回的是 HTML 不是 JSON，气象站连文档都没有，农机平台要 VPN 拨号才能进内网。
六个系统，四种协议，三个没文档。这就是农业数据采集的真实开局。"
上一篇说了数据工程就四件事——搬洗整供。这一篇专讲"搬"。采集汇聚是数据工程的第一道关，这一关过不好，后面洗整供全是空中楼阁。
一、农业数据源到底有几种
先把范围搞清楚。农业项目里常见的数据源，按来源分七大类：
| | | |
|---|
| 物联网传感 | | | 高频推送（10-30分钟），协议杂（MQTT/Modbus/HTTP/RS485），设备厂商多 |
| 遥感影像 | | | |
| 虫情/灾情 | | | |
| 农机作业 | | | |
| 业务台账 | | | |
| 空间数据 | | | |
| 第三方接口 | | | |
七类数据源，接法各不相同。但归纳下来就四种接入方式。
二、四种接入方式
方式一：消息订阅（实时推送）
适用：物联网传感数据——墒情、气象、水质。
设备主动把数据推上来，你订阅接收。最常见的协议是 MQTT。
原理不复杂：设备作为客户端连接 MQTT Broker，把数据发到指定主题（Topic），你写个消费者订阅这个 Topic，收到消息解析存库。
设备 → MQTT Publish → Broker → MQTT Subscribe → 你的消费者 → 解析存库
实操关键点：
- 主题设计：按"区域/设备类型/设备ID/数据类型"分层，比如
county_hefei/soil/ST001/moisture，别用一个 Topic 塞所有设备的数据 - QoS 选 1：至少收到一次。QoS 0 会丢包，QoS 2 太重，农业场景 QoS 1 够用
- 心跳监控：设备 30 分钟没发数据要告警，可能是断电、断网、传感器故障
- 报文格式：要求厂商给 JSON 文档，别接纯二进制——调试的时候 JSON 能直接看，二进制要对着协议手册逐字节拆
真实坑：某项目墒情设备厂商说"支持MQTT"，实际是 HTTP POST 一个 JSON 到指定 URL。不是真正的 MQTT Broker 订阅模式，只是借了个名字。开工前一定要现场抓包确认协议，别信文档别信口头。
方式二：接口调用（定时拉取）
适用：虫情测报、遥感解译、第三方API、农机平台。
对方有 HTTP 接口，你写定时任务去拉。跟实时推送的区别是你主动去取，不是等它推。
实操关键点：
- 拉取频率：按数据更新频率定。虫情每天拉一次，遥感每月拉一次，农机作业数据可以5分钟拉一次
- 增量拉取：别每次全量拉。带时间参数——
?startTime=2026-08-19 00:00:00&endTime=2026-08-20 00:00:00，只拉新增的 - 重试机制：接口超时、返回500、返回空数组——三种情况三种处理。超时重试3次，500告警，空数组记日志不告警（可能真没新数据）
- 分页处理：大数据量接口一般分页返回，要循环拉完，别只拉第一页
真实坑：某虫情测报平台的接口返回的不是 JSON，是 HTML 页面里嵌了一个 table。对方说"有接口"，你得先看接口返回的是什么格式——HTML 解析比 JSON 复杂十倍，而且对方改个页面样式你就挂了。碰到这种直接要求对方出 RESTful JSON 接口。
方式三：数据库直连（批量抽取）
适用：农情调度系统、植保平台等内部业务系统的数据库。
对方有数据库，你直接连过去抽数据。听起来最简单，实际最容易出问题。
实操关键点：
- 只读账号：让对方给你开一个只读权限的账号，千万别用管理员账号连——你抽数据时写错一条 SQL 就能把人家业务库搞崩
- 只抽副本：别直连生产库，让对方开个只读副本或者每天凌晨做个快照，你从副本里抽
- 只抽数据不改结构：你只在对方库里 SELECT，不在对方库里建表建视图。你自己的数据搬回你的临时区再处理
- 抽取时间：凌晨 2:00-5:00 抽，别在业务高峰期连人家数据库
- 字段映射文档：让对方给一份字段说明——哪个字段是什么意思、编码规则是什么、有没有枚举值、空值代表什么
真实坑：某县农情调度系统的作物编码字段，前缀"A"代表粮食作物、"B"代表经济作物，但文档里没写。抽过来的数据一看"A01"以为是编号，做统计时把粮食和经济作物混在一起，结果全县种植结构统计全错。字段映射文档一定要拿到，没文档就让对方口头解释一遍你记下来确认。
方式四：文件导入（手动+半自动）
适用：Excel 台账、Shapefile 图斑、CSV 报表、PDF 文件。
这是最原始但最常见的方式。农业口大量数据还停留在 Excel 阶段——种植台账、补贴名单、产量统计，都是乡镇报上来汇总成 Excel。
实操关键点：
- 模板固定：别指望每次收到的 Excel 格式都一样。先定一个标准模板，让填报方按模板填，不按模板的打回去重填
- 校验规则前置：导入前先校验——必填字段有没有空、数值范围合不合理、编码在不在映射表里、日期格式对不对
- 导入留痕：每次导入记录：谁导的、什么时间、哪份文件、导了多少条、成功几条失败几条、失败原因
- Shapefile 导入：注意坐标系——Shapefile 的 .prj 文件记录了坐标系，导入前先检查是不是 CGCS2000，不是的话先投影转换
真实坑：乡镇报上来的种植台账 Excel，表头每次都不一样——上次叫"作物名称"这次叫"种植品种"，上次"面积(亩)"这次"面积"。导入脚本每次都要改。解决方法：给乡镇发固定模板，第一行是字段名不允许改，数据从第二行开始填。模板不服从的打回去。
三、七种数据源的接入方案汇总
| | | | |
|---|
| | | MQTT 消费者订阅 Topic，解析JSON存时序表 | |
| | | | Modbus要写寄存器地址映射表，地址错了读出来全是0 |
| | | HTTP GET 拉图片+识别结果，存对象存储+结构化表 | 确认返回JSON不是HTML，图片走对象存储别存数据库 |
| | | 调遥感云平台API下载NDVI栅格+矢量，按地块裁剪 | 云覆盖导致数据缺失要有降级方案，别指望每月都能拿到 |
| | | | |
| | | | |
| | | | |
四、数据落在哪里——临时区设计
数据采进来第一件事不是清洗，是原样落盘到临时区。
临时区也叫贴源层（ODS），意思是源数据长什么样，落下来就什么样，一个字段不改。
为什么不能采进来直接清洗？
- 可追溯
- 可重跑：清洗规则改了，可以重新从临时区跑一遍，不用重新采集
- 可审计
临时区的设计原则：
| |
|---|
| 原样存 | 源数据什么格式就存什么格式，JSON存JSON，CSV存CSV，不改字段名不转格式 |
| 带元数据 | 每条数据附三个字段：数据来源(source)、采集时间(collect_time)、原始报文(raw_payload) |
| 分区存 | |
| 设保留期 | 原始数据保留90天，超期归档。别把临时区当历史库用，临时区是临时停靠不是长期仓库 |
五、实时 vs 批量：不是所有数据都要实时
很多甲方上来就要求"所有数据实时"。实际上农业场景里，大部分数据用批量就够了，只有少数场景需要实时。
| | |
|---|
| | |
| | |
| | |
| 实时（5分钟） | 农机调度要看实时位置和作业进度，延迟太大调度没意义 |
| | |
| 准实时（1小时） | 墒情数据到阈值要触发预警，30分钟采集+30分钟处理=1小时响应 |
| | |
判断标准很简单：数据变化速度有多快，业务响应需要多快。土壤湿度一天变不了几个百分点，没必要实时。农机位置5分钟就跑出一两百米，调度必须实时。
别被"实时"两个字绑架。实时意味着更高的技术复杂度、更多的服务器资源、更难的运维。能用批量解决的就用批量，实时的成本是批量的3-5倍。
六、采集监控：采进来的数据怎么知道有没有丢
采集任务上线后最怕什么？静默失败——任务没报错，但数据没进来，或者进来的数据量突然减半，你不知道。
这种情况在农业项目里非常常见：墒情设备太阳能板被杂草挡了，电量低自动休眠，不发数据了；虫情接口升级了，返回格式变了，解析全部失败但任务没挂；农机平台VPN断了，连不上但超时重试后标记成功。
必须建三层监控：
举个具体例子：墒情监测点42个，每30分钟应该收到42条数据。如果某个时段只收到20条，说明有22个点没报数——可能是设备故障、网络断了、或者太阳能板没电了。数据量级监控会在1小时内告警，你就能主动发现而不是等农技站打电话来说"数据怎么不刷新了"。
七、某县实操案例：7个数据源的采集方案
把上面的方法用到一个真实项目里。某县农业农村局，7个数据源，10周完成采集汇聚：
第1-2周：摸底+抓包
- 逐个系统对接，列数据源清单——7个系统、7种协议、12个接口
- 墒情系统现场抓包确认是HTTP POST不是MQTT
- 虫情平台要求对方出JSON接口（原来返回HTML，谈了一周才改）
第3-5周：开发采集程序
- 气象：写Modbus TCP客户端，10分钟轮询一次
第6-7周：监控+联调
第8-10周：上线+试运行
- 发现3个问题：墒情设备夜间低电量不报数、虫情接口偶发超时、农机GPS信号弱时轨迹飘
关键数据：7个数据源、12个接口、日均采集约12万条记录、采集稳定率98%、从进场到采集跑通10周。
八、采集阶段踩坑清单
| | |
|---|
| | 开工前现场抓包，文档只做参考，以实际报文为准。厂商口头承诺一律不信任 |
| | 第一天就调接口看返回什么，HTML/XML/纯文本都有可能。不是JSON的让对方改，改不了的要写适配解析器 |
| | 墒情设备低电量会休眠，夜间没数据是正常的。监控告警设"连续6小时无数据"而不是"30分钟无数据" |
| | 自己用Modbus调试工具读一遍，对照地址表确认。温度湿度风速雨量每个寄存器都要验证 |
| | 轨迹点精度低于15米的标记为低质量，做空间过滤+速度异常剔除 |
| | 一个月的Sentinel-2数据可能有50%被云挡住。要用多时相合成——取一个月内无云像素拼接，不是单张影像 |
| | 提前沟通，提供只读账号申请文档，承诺只查不改、凌晨执行、不影响业务。对方实在不让直连就用导出文件方式 |
| | 下发固定模板+数据校验规则，第一行字段名锁定不允许改。不符合模板的打回去重填 |
| | 导入前先读.prj文件检查坐标系，不是CGCS2000的先做投影转换再导入 |
| | 必须建三层监控：任务级（失败告警）、数据量级（环比下降50%告警）、字段级（空值率超20%告警） |
| | 采集程序做异常捕获——解析失败的数据存到死信队列，不阻断后续数据。接口变更要走变更通知流程 |
| | 按场景定：农机轨迹准实时，墒情气象批量够用。实时成本是批量的3-5倍，别被甲方一句话绑架 |
九、采集做完的标准是什么
很多项目采集做完了但不知道好不好，因为没标准。给一个验收清单：
| | |
|---|
| | |
| | |
| | |
| | 实时数据延迟≤采集频率的2倍，批量数据在约定时间窗口内完成 |
| | |
| | |
| | 每个数据源有接入说明：协议、格式、频率、接口地址、认证方式、异常处理 |
···
采集汇聚这关过了，数据就从"散在各系统"变成了"全部收进临时区"。但收进来的还是原始脏数据，不能直接用——墒情传感器有跳值，农机轨迹有飘点，台账有错填，遥感有云遮挡。
下一篇讲"洗"——数据清洗与处理，怎么把脏数据洗成可用数据。
智慧农业数据平台系列 · 第二篇
上一篇：数据工程到底干什么——不是写代码，是把数据从"有"变"好用"
下一篇：数据清洗与处理——传感器跳值、轨迹飘点、台账错填怎么洗
