简介这份2023年出品的数字乡村与智慧农业数字化转型大数据平台建设方案PPT共40页面向农业数字化、乡村振兴领域的方案策划者、政企信息化人员及咨询设计人员可用于快速理解平台总体架构与落地路径。压缩包内为1个pptx文件约14.47MB内容集中、即开即用省去搜集零散素材的成本目前已有172人学习下载。PPT围绕“1341”工程展开梳理数字乡村建设三类问题与农业数字化转型七大需求拆解农业大数据中心、农业物联网平台、农村综合服务指挥决策平台三大基础平台并延伸到治理服务、民生服务、产业服务三大平台及农业生产、流通、管理、农村社会服务等应用场景配有总体框架图、架构图与信息采集、数据共享交换、可视化监管等模块示意适合作为方案汇报、项目申报或课题研究的参考底稿。1. 从一份 40 页 PPT 说起数字乡村与智慧农业大数据平台要交付什么县里农业农村局要上一套数字乡村平台评审会上专家翻到第 12 页架构图问了三个问题地里的数据谁采、采上来存哪儿、亩产这个数到底怎么算出来的。答不上来方案就悬了。不少团队把这类方案当成画图活五层架构、数据中台、一张图模板套一套交差。真下过田的人清楚难点从来不在架构图漂不漂亮而在地块编码怎么统一、传感器上报的墒情单位是体积含水率还是质量百分比、气象和农情数据按什么粒度对齐。这些口径在 PPT 里常被一两句话带过落地时却能让整个大数据平台返工重做。这一篇拆的是数字乡村叠加智慧农业场景下一套可落地的数字化转型大数据平台怎么设计以及把方案压成 40 页 PPT 时哪些技术细节必须写进去、哪些页留给谁看。适合做农业信息化集成、县域数据平台、以及需要给甲方讲清楚技术底牌的工程师。2. 智慧农业大数据平台的五层架构划分与关键选型2.1 五层架构的边界比分层本身更重要常见的分层是感知采集层、网络传输层、数据资源层、平台服务层、应用层。真正决定项目成败的不是分了五层还是六层而是每层不做什么。采集层只管三件事采到、传上来、不失真。设备侧不要做业务判断比如是否干旱这种结论必须放到平台侧算因为阈值会随作物生育期变改一次阈值不该去现场刷固件。数据层只负责数据的接入、清洗、建模、存储不做任何面向用户的展示逻辑。应用层不允许直连设备库一律走指标服务和 API 网关否则一张大屏的慢查询能把实时上报拖垮。平台服务层是最容易被忽略的一层它承上启下对外提供统一的指标接口、地块空间服务、标签服务对内管理元数据和血缘。没有这一层应用每加一个就要重复写一遍口径 SQL三个月后同一个亩产在四个页面里出现四个数。2.2 采集层协议选型LoRa、NB-IoT、4G 怎么取舍采集协议选错后面全是运维成本。下面这张表是县域项目里最常被拿出来比的一组。协议覆盖半径功耗单点带宽典型场景主要限制LoRa空旷 3~10km极低电池 3~5 年0.3~50kbps大田墒情、小型气象站需自建网关频段使用需合规NB-IoT依赖运营商覆盖低电池 2~5 年约 100kbps分散地块、灌溉水表时延大、下行能力弱4G/Cat.1运营商覆盖即可中高需常供电上 Mbps农机终端、虫情测报灯、视频功耗与流量成本RS485/有线几十到上百米取电稳定可靠大棚内密集点位布线成本随距离上升我一般这么定连片大田、点位固定、要求长待机选 LoRa 自建网关地块零散、跨乡镇、不想养网关运维选 NB-IoT要带视频或农机作业轨迹直接上 4G。混用是常态但网关和运营商的对接协议要统一收敛到 MQTT别让平台侧适配四套私有协议。2.3 存储选型Hive、ClickHouse、时序库各管一段数据资源层不要指望一个数据库打天下。分工大致是Kafka 做接入缓冲扛住上报尖峰Hive 或 Spark 做 T1 批处理和年度报表ClickHouse 或 Doris 扛即席查询和大屏TDengine、InfluxDB 这类时序库存设备原始测点负责降采样和长期归档PostgreSQL 存地块、作物、农户这类主数据配 PostGIS 处理空间关系对象存储放遥感影像和虫情图片。判断标准很朴素按时间范围扫描、写多读少的给时序库要 join 主数据、要 group by 出指标的给 ClickHouse要保证事务和唯一约束的给 PostgreSQL。把设备原始测点塞进关系库是新手最常见的坑三个月后单表过亿加索引也救不回来。2.4 用 docker-compose 拉起一套最小数据底座方案评审前建议先跑通单机版所有截图和数据都从这套环境出比纯画的架构图可信得多。version: 3.8 services: emqx: image: emqx/emqx:5.6 ports: - 1883:1883 # MQTT 接入端口设备侧连这个 - 18083:18083 # 控制台默认 admin/public上线前必须改 redpanda: image: redpandadata/redpanda:v23.3.5 command: - redpanda start --overprovisioned --smp 1 --memory 1G - --node-id 0 --checkfalse - --kafka-addr PLAINTEXT://0.0.0.0:9092 - --advertise-kafka-addr PLAINTEXT://redpanda:9092 ports: - 9092:9092 # 兼容 Kafka 协议生产环境换 Kafka 集群 tdengine: image: tdengine/tdengine:3.2.3.0 ports: - 6041:6041 # REST 接口方便快速验证测点写入 clickhouse: image: clickhouse/clickhouse-server:24.3 ports: - 8123:8123 # HTTP 接口 - 9000:9000 # Native 接口 ulimits: nofile: 262144 # ClickHouse 必需否则启动后易报 too many open files启动用docker compose up -d检查用docker compose ps看某个服务日志用docker compose logs -f clickhouse。这里用 Redpanda 替代 Kafka 只是为了单机省内存协议兼容方案里写的 topic 设计可以原样迁移。参数上要留意三处EMQX 的 18083 控制台默认口令必须改别把测试环境暴露在公网ClickHouse 的nofile不抬到 262144 以上跑批时容易中途挂TDengine 的 6041 是 REST 端口做演示脚本最省事但生产建议走原生连接。3. 数字乡村数据采集与接入从农田传感器到大数据的落地链路3.1 MQTT 主题规范与报文结构设计主题设计要一次性想清楚改主题等于全量设备重新配置。常见做法是按业务域、行政区划、设备类型、设备 ID、消息类型五段切分agri/{county_code}/{device_type}/{sn}/{msg_type} 例如agri/340124/soil/SN20230012/telemetry层级取值示例说明agri固定业务域多业务共用一个 Broker 时用来隔离county_code340124行政区划码便于按区做权限和限流device_typesoil / meteo / trap / vehicle决定 payload 用哪个解析器snSN20230012出厂唯一序列号不要用自增 IDmsg_typetelemetry / event / cmd上行数据、事件告警、下行指令报文本身用扁平 JSON字段名全小写下划线单位和量纲在设备侧固化不要留给平台猜{ sn: SN20230012, ts: 1720000000000, type: soil, metrics: { soil_moisture: 23.4, soil_temp: 18.2, ec: 1.35 }, battery: 87, rssi: -92 }ts用毫秒时间戳设备侧必须做一次 NTP 校时否则批量设备时间漂移会让时序库的降采样全乱。soil_moisture统一为体积含水率百分比soil_temp为摄氏度ec为 mS/cm这三个单位写进设备协议文档验收时逐台核对。3.2 用 Python 模拟设备上报并做格式校验接入联调阶段用脚本模拟几十台设备上报比等硬件到货快得多。import json import time import random import paho.mqtt.client as mqtt BROKER 127.0.0.1 PORT 1883 TOPIC_TPL agri/{county}/{dtype}/{sn}/telemetry def build_payload(sn: str, dtype: str) - str: 构造一条符合协议的上行报文单位在设备侧固化 return json.dumps({ sn: sn, ts: int(time.time() * 1000), # 毫秒时间戳依赖设备侧 NTP type: dtype, metrics: { soil_moisture: round(random.uniform(15, 35), 1), # 体积含水率 % soil_temp: round(random.uniform(10, 28), 1), # 摄氏度 ec: round(random.uniform(0.5, 2.5), 2), # mS/cm }, battery: random.randint(60, 100), # 电量百分比 rssi: random.randint(-110, -70), # 信号强度 dBm }, ensure_asciiFalse) def on_connect(client, userdata, flags, rc): print(connected, rc , rc) def on_publish(client, userdata, mid): print(published mid , mid) if __name__ __main__: client mqtt.Client(client_idsim-SN20230012) # client_id 用序列号避免会话抢占 client.username_pw_set(agri, change_me) # 生产环境按设备下发独立账号 client.on_connect on_connect client.on_publish on_publish client.connect(BROKER, PORT, keepalive60) client.loop_start() while True: topic TOPIC_TPL.format(county340124, dtypesoil, snSN20230012) client.publish(topic, build_payload(SN20230012, soil), qos1) time.sleep(30) # 30 秒一条模拟真实上报周期逻辑上qos1是至少一次投递网络抖动时会产生重复重复数据由平台侧用sn ts组合去重不要指望设备侧保证精确一次。client_id用设备序列号同一序列号的两个连接会互相踢下线正好可以当设备在线的判据。keepalive60与平台侧的心跳超时设置要匹配设备侧 60 秒、平台侧 180 秒是常见搭配。参数上最容易出问题的是上报周期。墒情类指标 30 分钟一条完全够用气象类 5 分钟电量类可以一小时。周期越短接入层压力和存储成本越高方案里写清楚每个设备类型的周期验收时按这个查。3.3 从消息队列落到 ODS建表与字段映射Kafka 侧建议一个原始 topic 走到底例如agri.telemetry.raw分区键用 sn保证同一设备乱序最小。落到 ODS 时ClickHouse 是性价比较高的选择。CREATE TABLE ods.telemetry_raw ( sn String, device_type LowCardinality(String), county_code LowCardinality(String), plot_code String, ts DateTime64(3), soil_moisture Nullable(Float32), soil_temp Nullable(Float32), ec Nullable(Float32), battery Nullable(UInt8), rssi Nullable(Int16), ingest_time DateTime DEFAULT now() ) ENGINE MergeTree PARTITION BY toYYYYMM(ts) ORDER BY (county_code, device_type, sn, ts) TTL ts INTERVAL 3 YEAR;ORDER BY就是主键排序键决定查询剪枝效果把最常用的过滤维度放前面。TTL ts INTERVAL 3 YEAR控制冷数据自动清理方案里要写明归档策略否则三年后磁盘会先扛不住。字段全用Nullable是为了容纳缺项指标代价是查询时要处理 NULL权衡后值得。原始 JSON 到 ODS 列的映射规则建议直接写进方案附录JSON 字段ODS 列类型处理规则snsnString必填缺失整条丢弃tstsDateTime64(3)毫秒转时间类型与平台时间偏差超 10 分钟打异常标typedevice_typeString枚举校验未知类型进死信 topicmetrics.soil_moisturesoil_moistureFloat32取值范围 0~100越界置 NULLmetrics.ececFloat32大于 0异常值告警batterybatteryUInt8低于 15 触发低电量工单4. 大数据平台侧建模地块、墒情、积温的指标口径怎么定4.1 四张主表的维度建模农业数据的分析维度高度稳定四张主表基本够用地块、设备、作物、经营主体。地块表是整个平台的空间锚点必须和确权或二轮承包的地块编码对齐否则补贴发放和一张图会各说各话。CREATE TABLE dim_crop ( crop_id SERIAL PRIMARY KEY, crop_name VARCHAR(32) NOT NULL, variety VARCHAR(64), stage_dict JSONB -- 生育期字典播种期/苗期/拔节期/成熟期 ); CREATE TABLE dim_plot ( plot_id BIGSERIAL PRIMARY KEY, plot_code VARCHAR(32) NOT NULL UNIQUE, -- 与确权地块编码对齐 county_code VARCHAR(12) NOT NULL, area_mu NUMERIC(10,2) NOT NULL, -- 面积单位亩 soil_type VARCHAR(16), crop_id INT REFERENCES dim_crop(crop_id), geom GEOMETRY(POLYGON, 4326), -- PostGIS 地块边界 updated_at TIMESTAMPTZ DEFAULT now() ); CREATE INDEX idx_plot_county ON dim_plot(county_code); CREATE INDEX idx_plot_geom ON dim_plot USING GIST(geom); CREATE TABLE dim_device ( sn VARCHAR(32) PRIMARY KEY, plot_id BIGINT REFERENCES dim_plot(plot_id), device_type VARCHAR(16) NOT NULL, install_time TIMESTAMPTZ, status SMALLINT DEFAULT 1 -- 1 在册 0 停用 );要点有三个plot_code唯一约束要建它是跨系统对齐的唯一凭据空间字段用 EPSG:4326与地图底图保持一致别混用投影坐标系设备与地块是多对一一个地块可能挂墒情、气象、虫情三类设备所以plot_id放在设备表而不是反过来。4.2 关键指标口径表把争议提前吵完指标口径不定平台上线后每天都在对数。下面这张表建议原样进方案正文。指标口径定义计算方式更新频率平均土壤含水率同一地块当日全部有效测点的算术平均avg(soil_moisture)仅取 0~100 区间小时/日有效积温日均温减去生物学下限温度后的累加值sum(max(daily_avg_temp - 10, 0))日地块亩产实收产量除以地块确权面积产量表关联 dim_plot按季汇总季设备在线率24 小时内有过上报的在册设备占比1 - 离线设备数 / 在册设备数10 分钟灌溉建议等级依据墒情与作物生育期阈值的分级规则引擎输出 1~4 级小时下限温度取 10℃ 是通用默认值小麦、玉米、水稻各不相同正式口径要按作物和品种在stage_dict里配。这类参数写入配置表不要硬编码在 SQL 里。4.3 墒情预警的实时计算与阈值设置预警不需要上重型实时引擎县域场景用 ClickHouse 定时查询就能满足 10 分钟级时效。-- 每 10 分钟跑一次输出地块级干旱预警 INSERT INTO ads.drought_alert SELECT p.plot_code, p.county_code, toStartOfInterval(t.ts, INTERVAL 10 MINUTE) AS win, avg(t.soil_moisture) AS avg_moisture, count() AS sample_cnt FROM ods.telemetry_raw t JOIN dim_plot p ON p.plot_code t.plot_code WHERE t.ts now() - INTERVAL 1 HOUR AND t.soil_moisture 0 GROUP BY p.plot_code, p.county_code, win HAVING avg_moisture 20 AND sample_cnt 3 ORDER BY win DESC;三个参数值得说明窗口取 10 分钟要与设备上报周期对齐上报 30 分钟一次却设 10 分钟窗口会出现大量空窗sample_cnt 3是防单点毛刺一个传感器被踩坏报出 2% 含水率就触发全县预警没人受得了阈值 20% 要按土壤质地调沙土可降到 15%黏土提到 25%这条写进方案的参数配置章节交付时按地块批量导入。5. 40 页方案的页数分配与评审表达技巧5.1 四十页怎么排按读者分段不按技术分层方案评审通常是领导看前八页、技术看中间十六页、决策看最后八页页数分配要顺着这个节奏走。页码板块内容要点主要读者P1~P3背景与依据区域农业现状数据、建设目标决策层P4~P8需求与痛点数据孤岛、口径不一、四类用户画像业务部门P9~P16总体架构五层架构图、数据流向、与既有系统关系技术评审P17~P24采集与治理协议选型表、主题规范、指标口径表技术评审P25~P32应用场景一张图、墒情预警、农机调度、产销对接业务部门P33~P37实施与投资分期计划、里程碑、硬件清单决策层P38~P40保障与风险数据安全、运维组织、验收指标决策层架构图一页放不下就拆成逻辑架构和部署架构两页比压缩成一张看不清的小图强。5.2 把技术参数翻译成评审听得懂的话同一件事两种说法效果差很远。别说Kafka 三副本、acksall说接入层任意单节点故障田间上报不丢数据。别说ClickHouse 单表承载 50 亿行说全县 5 万个测点、5 年历史数据大屏查询 2 秒内出结果。数字化转型方法论里反复强调的业务先行落到这个场景就是把指标口径表放在架构图前面讲——先让评审认同亩产怎么算再讲用什么存。第 4 章那张指标口径表和 ODS 字段映射表原样放进 PPT 附录。正文 P17~P24 只放结论例如统一为体积含水率百分比越界自动置空评审追问细节时再翻附录。这样正文干净、有据可查也避免了把单位换算这种枯燥内容占满屏幕。5.3 三个必被问的问题提前把答案塞进页面第一个是数据从哪来。要给出设备清单和覆盖率比如全县规划 3200 个墒情点、48 个气象站首期覆盖 60% 规模化种植地块而不是写通过物联网设备采集数据。第二个是钱花在哪硬件、软件、三年运维大致按 4:3:3 拆分评审对运维费用最敏感提前解释清楚为什么养人要花钱。第三个是上线后谁维护写明运维组织和响应时限比如设备离线 24 小时内响应、平台可用性 99.5%。最后一个小技巧把第 3 章里那条 MQTT 报文的真实 JSON 截图放进 P19。评审看到的是接口长什么样不是又一张彩色框图讨论会立刻从感觉不太行转到字段要不要加。本文还有配套的精品资源点击获取