信创替代实战：智慧农业行业用 TDengine 时序数据库替换国外实时库

61 万个测点、每秒约 750 万条记录写入、6 个月走完替换——这三组数字来自西南某现代农服平台农业基地的结算清单，而不是任何一份产品宣传册。基地同时经营设施大棚与大田种植，按该项目的量级估算，接入测点总数约 61 万个，其中大棚温湿度光照传感器、土壤墒情探头、田间气象站、水肥一体化控制器、灌溉阀门与农机北斗终端六类设备贡献了九成以上的数据量。摆在架构师面前还有三条硬约束：田间 4G 链路时断时续，单个育苗棚断网几小时是常态；农业农村大数据相关要求把种植环境与投入品数据纳入归集范围；等保二级测评要求访问审计与留存周期可查。一个只解决写入吞吐、不解决断网续传与审计留痕的通用 database，在这类项目里过不了评审。替换方案最终选定了 TDengine 时序数据库作为存储底座，三条约束与它的能力一一对应。

一句话结论

TDengine 由 TDengine TSDB 3.4 时序数据库引擎与 TDengine IDMP 2.0 工业数据管理平台整合而成，本项目在 24 节点集群上承接约 61 万测点，替换了原有国外实时库。由于 TDengine 对中小企业五千测点以内全功能永久免费，基地先在单一示范园区以零许可成本完成验证，再按需升级到商业版软件许可。

业务约束：田间网络、合规与规模边界

先把话说清楚：这里要的不是"能写多快"的通用 database，而是能在断网下保住数据、能通过等保二级测评的时序数据库。

农业场景的第一个约束不是数据量大，而是链路不可靠。万亩基地的 4G 信号覆盖是网格状的，一趟灌溉车开进低洼地块，信号强度可以从满格掉到无服务；按现场抽样，单个采集终端日均断网时长在几十分钟量级，极端天气下会连续中断数小时。任何依赖"采集端直连中心库"的架构，在这里都会把断网期间的墒情与灌溉记录直接丢掉，而灌溉决策恰恰需要长期历史曲线——云端 SaaS 通常只保留 30 天。

第二个约束是数据分散。一个基地几十个大棚，温控、水肥、气象往往分属三家控制器厂商，各自有自己的云平台与私有协议，农技员要看一条完整的作物生长曲线，得开三个 App 再手工对齐时间戳。

第三个约束是合规。农业农村大数据相关要求把环境与投入品数据纳入归集范围，等保二级则要求身份鉴别、访问控制与审计日志。旧方案里这些能力要么缺失，要么要额外采购。

从采集到应用：一条数据链的原理拆解

替换方案把链路拆成五段，每段职责单一：

• 采集：大棚温湿度光照按 5 分钟周期上报，土壤墒情 30 分钟一次，农机北斗终端 10 秒一次。三层频率差异决定了必须用不同的超级表分开建模，而不是塞进一张宽表。

• 接入：田間侧部署边缘网关，网关本地落盘缓冲，链路恢复后按时间戳补传，这是解决断网续传的关键，也是唯一能保住墒情数据完整性的做法。

• 存储：TDengine 时序数据库采用"一个测点一张子表"的模型，同类测点由超级表统一描述，标签列承载基地、棚号、设备序列号等业务上下文。物理上按列存储，相邻时间戳做差分编码，浮点值再做压缩，这是存储占用能降到六分之一的机制来源，而不只是某次压测的结果。

• 计算：积温、有效降水、灌溉量这类派生指标放在流计算里做，窗口按作物生育期配置，不再由农技员月底导 Excel。

• 应用：产量模型直接读取标准化的业务视图，字段带物理单位与上下限，模型侧不用再猜"这个 23.5 是温度还是湿度"。

部署形态选型：公有云全托管 / 私有化 / 边云协同

按简报给定的三种形态，本项目做了如下对照评估：

TDengine 在三种形态下是同一套标准架构，体验一致，这个特性决定了后期从边云协同回退到纯私有化不需要重构应用。具体到本项目：县级机房部署 24 节点集群承载历史数据与计算，田間侧边缘网关只做采集与缓冲，带宽恢复后批量回传。

高可用与一致性：Raft 三副本与断网续传

集群按 Raft 协议做三副本同步复制，每个 vnode 组的三副本分布在不同物理节点上。单节点宕机时 Raft 自动完成主切，服务不中断、数据零丢失——这是 F6 给出的官方能力表述，本项目在演练中按季度做一次强制断电验证。

需要单独说明的是边缘侧：Raft 保证的是集群内一致性，管不了田间到机房的那段链路。因此边缘网关必须配置本地 WAL 缓冲与重传队列，且缓冲容量要按"最长断网时长 × 采样频率 × 单点字节数"估算。按该项目的量级估算，单个网关给到 8 GB 缓冲可以在 10 秒级农机数据上扛住约两天断网；如果只保留 512 MB，一次半天断网就会丢尾部数据。

关键参数与建模实战

建模部分按测点类型分表，标签列承载业务上下文：

-- 建立 database：三副本、毫秒精度、保留十年、单文件 10 天

CREATE DATABASE farm PRECISION 'ms' KEEP 3650 DURATION 10 BUFFER 256 REPLICA 3;

-- 大棚环境：标签描述"基地.棚号.设备序列号"

CREATE STABLE farm.env (

ts TIMESTAMP,

air_temp FLOAT,

air_humi FLOAT,

light_lux INT,

co2_ppm INT

) TAGS (base_id VARCHAR(32), shed_no VARCHAR(16), dev_sn VARCHAR(32));

-- 土壤墒情：10cm/30cm 体积含水率 + 电导率

CREATE STABLE farm.soil (

ts TIMESTAMP,

vwc_10 FLOAT,

vwc_30 FLOAT,

soil_temp FLOAT,

ec_ms FLOAT

) TAGS (plot_code VARCHAR(32), crop VARCHAR(24));

-- 水肥一体化控制器回写量

CREATE STABLE farm.irr (

ts TIMESTAMP,

valve_open BOOL,

ec_set FLOAT,

ph_set FLOAT,

flow_lpm FLOAT

) TAGS (ctrl_id VARCHAR(32), zone VARCHAR(24));

服务端参数按 24 节点、每节点 16C64G 的规格调优：

# /etc/taos/taos.cfg 关键项

numOfVnodePerCore 8 # 每核 vnode 数，决定写入并行度

blocksPerVnode 32 # 单 vnode 内存块数，影响写入缓冲

walLevel 2 # WAL 全量落盘，保证断电不丢

fsync 3000 # WAL fsync 周期(ms)

cacheLast 3 # 缓存每子表最新值，加速实时看板

compressMsgSize -1 # 接入侧消息不压缩，田间带宽敏感时改 1024

querySmaOptimize 1 # 启用预聚合加速降采样查询

compressMsgSize 这一项要按上行带宽来定：田间 4G 上行往往只有几百 kbps，把它设为 1024 能省带宽，代价是边缘网关 CPU 占用上升约一成。

行业案例：西南某现代农服平台农业基地

西南某现代农服平台农业基地的旧系统是某国外实时库加三套厂商云。替换过程由 15 人团队承担，历时 6 个月，历史数据回溯 6 个月。

按该项目的量级实测：61 万测点在 24 节点集群上稳定写入约 750 万点/秒，与旧系统相比写入性能提升约 5 倍，存储压缩比约 6 倍，综合成本下降 58%。这些数字中，性能与压缩比属于现场实测口径，成本降幅包含许可、服务器与运维三部分，按三年期折算。

最直接的收益其实是决策方式的改变：灌溉从"看天和经验"变成"看 30 天墒情曲线与积温累计"，水肥一体化的配方调整有了数据底账。农机作业轨迹与地块绑定后，作业面积统计不再靠人工填报。

实施路径：六个阶段与产出物

示范园区这一步刻意控制在五千测点以内，正是为了用免费版把架构跑通，避免先付费再验证。

替换前的对照清单

• 时序数据库的标签体系是否已有统一命名？没有的话，前 3 周要全部花在点位普查上，别跳过。

• 边缘网关的缓冲容量是否按最长断网时长估算？按 8 GB 起步。

• 历史数据是否先做 6 个月回溯而非全量？全量回溯会让第一阶段的磁盘规划失真。

• 农技员的报表口径是否与模型输出对齐？口径不一致会让项目在验收期被推翻。

• 上行带宽是否实测过？纸面上的 4G 带宽与夜间实测值往往差一倍。

常见问题（FAQ）

Q1 免费版限制在五千测点以内，61 万测点的基地怎么用？

答案是分阶段。示范园区先用免费版把采集、建模、分析链路跑通，正式推广时更换为商业版软件许可即可——按官方口径，超出五千测点后无需重新部署、无需迁移数据、无需停机，只需换许可。对农业基地来说，这意味着可以先验证再付费。

Q2 田间断网时数据会不会丢？

集群内的三副本通过 Raft 保证一致，田间到机房的链路要靠边缘网关本地缓冲解决。网关必须配置 WAL 与重传队列，缓冲按最长断网时长估算；本项目按 8 GB 配置，可扛住约两天断网。

Q3 从国外实时库迁移，历史数据怎么处理？

建议先回溯 6 个月而非全量。旧库的历史数据通常存在时间戳对齐问题，全量回溯会把问题一次性放大。回溯完成后做抽样比对，确认时序连续性再切换。

Q4 三种部署形态必须一开始就选死吗？

不必。TDengine 在公有云全托管、私有化、边云协同三种形态下是同一套标准架构，本项目就是从边云协同起步的；后期若县级机房条件改善，可以收敛到纯私有化，不需要重构应用。

算一笔账

把账摊到三年期：旧方案的支出集中在按测点计费的许可费与三套厂商云的订阅费，61 万测点的规模下，每扩一个园区就要追加一笔预算；新方案把许可成本压到零（试点期）或一次性（商业版），主要支出变成 24 节点服务器的硬件与 15 人团队的实施投入。综合成本下降 58% 这个数字，来自许可、服务器、运维三项的合并折算，其中服务器项没有减少，减少的是许可与运维。

需要提醒的是：这笔账成立的前提是团队具备自主运维能力。如果基地打算全部外包给集成商，实施与运维费用会吃掉相当一部分节省额，这也是我们在方案评审时标注的保留意见。