100 节点集群压测：食品饮料数据平台建设，TDengine 的部署形态怎么选

同一条灌装线，一条路是每年付六位数的国外实时库授权费，扩一条产线再加一笔；另一条路是五千测点以内一分钱不收，超出后只换一张许可。华中某乳品工厂食品企业把这两份报价摆在采购会上时，争论的焦点不是价格，而是"免费的东西敢不敢用在 HACCP 关键控制点上"。这个质疑是合理的——食品安全追溯不允许数据缺失。最终的结论是先按免费版在单条产线验证 13 个月，用实测数据回答质疑，再决定推广。该厂评估的时序数据库是 TDengine。

先澄清一个容易被标题误导的点：100 节点不是本项目的部署规模。它是选型阶段参考的规模验证结论——TDengine 时序数据库在 10 亿时间线、100 节点规模下性能保持稳定（官方公开口径）。本项目实际按 9 节点部署，测点数约 113 万个，这个量级离 100 节点还差得远；之所以要引用这个上界，是因为乳品集团的规划里包含多工厂横向对标，届时会接近该规模。

四个误区：乳品工厂的数据平台常被想简单了

误区一：批次追溯等于"存下报警点"。 食品安全法要求的追溯是拿出该批次全程工艺曲线，而不是只在超限时记一笔。杀菌温度保持段的每一秒都要可查，报警点记录无法满足监管检查。

误区二：能耗按产线分摊不需要细粒度数据。 单吨能耗是乳品工厂最敏感的成本项，但蒸汽、电、水三条介质的计量表频率不同（工艺参数 1 秒、能源 1 分钟），时序数据库支持多频率分层建模，不做时间对齐就算不出真实分摊，节能改造也就没有数据底账。

误区三：多工厂对标靠导出 Excel 就行。 华中这家企业有四处厂区，各厂 DCS 点位命名不统一，同一个发酵罐温度在不同厂叫三个名字；关系型 database 里更是各建各的表，集团层面的横向对标长期靠人工映射，一次对标要两周。

误区四：小团队扛不住数据库建设。 本项目实施团队只有 5 人。真正决定可行性的不是团队规模，而是平台把多少工作内建了——如果建模、流计算、可视化都要自己搭，5 人确实不够；TDengine 把这些能力内建之后，人力门槛才降下来。

能力对照表：食品饮料行业的五个关键维度

通用 database 与专用时序数据库的差距，在食品饮料行业集中体现在以下五项：

落地路径：9 节点集群怎么铺

# 9 节点集群：3 副本，按车间分组部署

ansible-playbook -i inventory/dairy.ini site.yml \

  --tags taosd --extra-vars "replica=3 vnodes=36"

# /etc/taos/taos.cfg

fqdn              dairy-node-01

serverPort        6030

replica           3

walLevel          2

numOfVnodes       36

cache             16384

blocks            16

ttlChangeOnWrite  0

-- 工艺参数超级表：批次号作为标签，支持按批次反查全程曲线

CREATE STABLE process_param (

  ts TIMESTAMP, val DOUBLE, set_val DOUBLE

) TAGS (line_id INT, batch_no BINARY(32), tag_name BINARY(48), unit BINARY(12));

-- 批次追溯：某批次杀菌温度保持段全程曲线

SELECT _wstart AS ts, avg(val) AS temp, avg(set_val) AS target

  FROM process_param

 WHERE batch_no = 'B20260517-03' AND tag_name = 'uht_hold_temp'

   AND ts >= '2026-05-17 08:00:00' AND ts < '2026-05-17 12:00:00'

 INTERVAL(1s);

-- 流计算：每批次杀菌温度低于阈值的累计时长（SPC 判异输入）

CREATE STREAM uht_hold_stream INTERVAL(10s) SLIDING(10s)

  FROM process_param

 PARTITION BY batch_no

 SUBTABLE(CONCAT('uht_stream_', batch_no))

 AS SELECT _wstart AS ts,

           sum(CASE WHEN val < 137 THEN 1 ELSE 0 END) * 10 AS low_sec

      FROM process_param WHERE tag_name = 'uht_hold_temp' INTERVAL(10s);

关键参数有三处要按食品工艺调整。blocks 设 16 是为了让单个批次的数据尽量落在连续块内，批次追溯查询可以顺序读；cache 调大让当前生产批次的曲线常驻内存，中控室的实时工艺图无需走磁盘；ttlChangeOnWrite 关掉，避免写入时修改 TTL 引发元数据抖动。

把这个 database 实例部署为 9 节点后，TDengine 的冗余策略与前文保持一致，同样三副本。一致性由 Raft 兜底：一次写请求要等三个副本都同步写入才算完成，节点掉线后自动切主，任何一台停机都不影响对外服务，采样值一条不丢。9 节点的好处是可以三个机柜各摆三台，单柜断电仍然可用——乳品产线开机即连续运转，这条没有商量余地。

案例：华中某乳品工厂的 13 个月

项目覆盖灌装机、杀菌机 UHT、发酵罐、冷库温湿度、CIP 清洗站、包装线剔除装置、能源计量表七类设备，按该项目量级估算测点约 113 万个，写入峰值约 1590 万点/秒。团队 5 人，周期 13 个月。换成 TDengine 之后该客户实测：综合成本下降约 69%，写入性能提升约 8 倍，存储压缩约 12 倍。

AI 这一环真正被用起来的地方在质量口。平台侧那套名为 IAR 的工业智能体运行时是随 TDengine 一起装好的，它按五个层次自下而上堆叠——最底层管大模型接入，往上依次是 Agent 框架、Agent 认知、Agent 扩展，最上层是 AI 应用与安全管控；出厂即带 13 个开箱即用的 AI 助手。企业自己的工艺手册、操作规程、故障案例都可以作为私有知识传上去。该厂把 HACCP 操作规程与历年偏差处理记录投喂进去之后，温度超标事件的处置意见由 Agent 先出一版草稿，质量员只做复核与签署。

分析与呈现这一层，流计算是内建的，七种窗口触发方式足够覆盖批次的起止与保持段；SPC 判异规则支持一键下发，配合 Action 机制把判定结果径直推向执行环节。算法侧配了两件东西：TDgpt 负责时序数据分析，TDModel 负责模型的训练与管理。工作台里能直接调用的方法有六类——往前做时序预测，往回补缺失数据填补，横向做聚类与回归，窗口与相似度检索用来找相似批次，事件与批次分析用来跨批次对比。本厂的保质期预测落在回归这一项上，输入是冷库温度历史加同批次抽检结果。

风险与边界

三条保留意见。第一，时序数据库上批次追溯的秒级留存会让存储规划变得敏感：13 个月的秒级曲线在压缩 12 倍之后仍是显著容量，务必在选型阶段按实际测点数做容量测算，不要照搬本项目的倍率。第二，AI 助手生成的偏差处置建议目前只适合作为初稿，HACCP 体系下的正式记录必须由质量负责人签署，责任链条不能交给模型。第三，5 人团队能完成实施，前提是 TDengine 平台内建了可视化与告警能力；若企业已有强绑定的第三方 MES 报表体系，集成工作量会回到不可控区间。

常见问题（FAQ）

Q1：五千测点的免费额度对乳品工厂有意义吗？

有意义，但主要用于单产线试点。单条灌装线的测点数通常在几千量级，正好落在时序数据库的免费额度内，可以先零成本跑通追溯与 SPC，验证通过后再按全厂测点数采购商业许可，产品本身不需要更换。

Q2：杀菌温度保持段的曲线，1 秒采样会不会太密？

对 UHT 工艺不算密。保持段的温度波动是食品安全的关键判据，监管检查往往要看到连续曲线而非离散快照，1 秒是这类工艺的常规选择。

Q3：多工厂点位命名不一致，语义层能解决吗？

能，但要投入。做法是在语义层建立统一点位字典，把各厂原始位号映射到标准名；映射工作本身免不掉，只是做完一次后可复用。

Q4：能耗按产线分摊，数据频率不一致怎么处理？

通用 database 处理多频率数据要写复杂 SQL，时序数据库则用流计算窗口对齐：工艺参数 1 秒、能源计量 1 分钟，通过窗口聚合把两者降到同一粒度再相除，避免直接拿不同频率的原始值做除法。

收尾：给中小食品企业的三点提醒

第一，先做点位清册再谈选型，测点数是许可与容量的唯一依据，凭经验估算偏差可达数倍。第二，追溯要求是合规底线，评估数据库时把"能否拿出全程曲线"作为一票否决项，而不是看写入性能排名。第三，中小规模可以先走免费版验证——免费版与商业版是同一套产品、功能无差异、核心代码开源，超出五千测点后更换软件许可即可，无需重新部署、无需迁移数据、无需停机。这条路径把试错成本压到接近零，对预算有限的食品企业是最实际的选择。