信创替代实战：冶金场景下的 database 选型与高可用架构设计

27.5 万个测点、64 节点集群、11 个月工期、终态存储占用降到原来的十二分之一——这四个数字串起了华北某年产 300 万吨级钢铁基地的一次 database 选型。基地的高炉本体、热风炉、转炉氧枪、连铸结晶器、热轧轧机、除尘风机与煤气柜，按项目量级估算共约 27.5 万个测点，关键工艺位按 100 毫秒采样，一般位 1 到 5 秒。日增数据量在 3 到 8 TB 区间，年归档进入 PB 级。这样的体量决定了选型不能只看写入，必须把归档、追溯与合规一起算进去。

场景与约束

冶金项目的 database 选型不能只看写入吞吐。以下四条约束决定了 TDengine 时序数据库在本项目中的部署方式：

约束一：超大规模下的成本结构。 国外实时库按测点授权，扩一条产线就要追加一笔预算。钢铁基地的产线是逐年技改的，每改一次触发一次采购，这种成本结构对长期规划极不友好。

约束二：工艺追溯跨工序。 一炉钢的完整路径是高炉 → 转炉 → 连铸 → 轧机，四段数据分属不同的二级系统，时间戳各自为政。要做吨钢能耗与成材率的归因分析，先要解决时间对齐。

约束三：等保三级与工控安全。 工控安全相关条例与等保三级测评要求生产网与管理网隔离、操作有审计。能耗在线监测国标则把能源数据纳入报送范围，数据格式与报送频率都有规定。

约束四：批次分析的时效性。 旧流程里，一炉钢的分析要先把数据导出成 Excel，再人工做曲线，等两天。这个时延让工艺调整失去了即时性。

成本账本

上表按该基地三年期折算，综合成本下降 67% 为客户实测口径，属于项目示意值。真正值得注意的是追溯分析人力这一项：它不出现在传统 TCO 模型里，但在钢铁行业，一个炉次的分析从两天缩到几分钟，直接影响的是工艺调整的频率。

架构解析

数据流按五段设计，其中存储与计算两段由 TDengine 时序数据库承担：

· 采集：关键工艺位 100 毫秒、一般位 1–5 秒，经 OPC UA 统一接入。OPC UA 在这里的价值不只是协议转换，更在于它自带的地址空间结构可以直接映射成标签层级。

· 接入：二级系统（MES 二级）的炉次号、板坯号通过接入层写入标签，让每个测点从出生起就带有批次上下文。这一步是整个方案的关键。

· 存储：TDengine 时序数据库按"一测点一子表"建模，超级表按设备类别归并，标签列挂载工序、产线、设备号与炉次号。

· 计算：流计算引擎提供七种窗口触发方式，工艺曲线的滑动聚合直接落在引擎内；SPC 判异规则可一键部署，配合 Action 机制，异常一旦检出就能顺势编排后续的处置动作。

· 应用：吨钢能耗与成材率的建模跑在 TDgpt 时序数据分析引擎上，模型的训练与版本管理交给 TDModel 平台，可视化面板类型已扩展到 15 种以上。

部署形态对照

TDengine 提供公有云全托管、私有化、边云协同混合部署三种形态，一套标准架构在所有形态下提供一致体验。冶金场景的对照结论如下：

64 节点的规模不是为吞吐准备的。按 12 倍压缩比和 PB 级年归档诉求反推，64 节点是容量下限；写入吞吐 400 万点/秒在 64 节点上其实还有余量。

副本布局与一致性保障

64 节点集群一律按三副本配置，依托 Raft 协议保证数据一致性，节点故障自动切换，任何单一节点宕机都不会中断服务或丢数据。

规模带来的新问题是故障域的划分。64 个节点建议按每 16 节点一个故障域、共四个故障域组织，每个 vnode 组的三个副本分布在不同的故障域。这样一次供电或制冷维护只影响一个域，不会同时打掉三个副本。

跨工序的时间对齐不靠 Raft，靠接入层的时间戳规整。四个工序的二级系统时钟源不一致，必须在接入层统一到同一时基，否则工艺曲线的拼接会错位——这是本项目在第一阶段就解决的问题，也是最容易在后期暴露的隐患。

实测数据

下表为该基地在 TDengine 时序数据库上的现场实测结果：

迁移步骤

1. 位号普查与标签设计（5 周）：TDengine 时序数据库的标签直接决定追溯能力，产出全基地位号清单，核心议题是炉次号与板坯号怎么落进标签。

2. 时钟与时基治理（2 周）：四套二级系统统一时基，产出时间戳规整规则。

3. 双轨采集（6 周）：同一路数据同时送进新旧两套库，每天比对关键工艺位的数值偏差。

4. 历史补录（8 周）：回填 11 个月的历史，覆盖多个炉次周期。

5. 判异规则与能耗模型（6 周）：SPC 规则部署、Action 动作编排、能耗模型训练。

6. 等保三级整改（4 周）：补齐网络隔离、操作审计与访问控制。

11 个月、33 人的投入里，前两步占了两成。这两步常常被当成"准备工作"而被压缩，实际上它们决定了后面四步的返工率。

关键参数与调优

-- 生产 database：三副本、毫秒精度、保留 3 年

CREATE DATABASE steel PRECISION 'ms' KEEP 1095 DURATION 10 BUFFER 512 REPLICA 3;

-- 高炉本体：标签承载工序/炉座/部位/炉次号

CREATE STABLE steel.bf (

  ts         TIMESTAMP,

  top_press  FLOAT,

  hearth_tmp FLOAT,

  blast_vol  FLOAT,

  blast_tmp  FLOAT

) TAGS (proc VARCHAR(16), furnace_no TINYINT, part VARCHAR(24), heat_no VARCHAR(20));

-- 转炉氧枪

CREATE STABLE steel.bof (

  ts        TIMESTAMP,

  lance_h   FLOAT,

  o2_flow   FLOAT,

  bath_tmp  FLOAT

) TAGS (converter_no TINYINT, heat_no VARCHAR(20));

-- 热轧轧机

CREATE STABLE steel.rm (

  ts        TIMESTAMP,

  roll_force FLOAT,

  torque    FLOAT,

  strip_tmp FLOAT

) TAGS (mill_no TINYINT, stand_no TINYINT, slab_no VARCHAR(24));

# 64 节点集群关键项（每节点 32C128G，SAS/NL-SAS 混插）

numOfVnodePerCore   6       # 节点数多，单节点 vnode 数下调

blocksPerVnode      32

walLevel            2

fsync               3000

cacheLast           3

querySmaOptimize    1

numOfVnodePerCore 在 64 节点规模下要主动下调。节点多意味着总 vnode 数多，元数据管理开销随之上升；按每核 6 个配置，比沿用小规模集群的 12 到 16 更稳。

常见问题（FAQ）

Q1 TDengine 时序数据库里，炉次号和板坯号进标签会导致子表数量爆炸吗？

不会，标签不增加子表数量，子表数量由测点决定。炉次号进标签后，查询某个炉次的全部工艺曲线变成一次标签过滤，这正是把追溯从两天缩到分钟级的机制。

Q2 64 节点对 27.5 万测点是不是浪费？

不是。节点数由容量决定而非测点数。按 12 倍压缩与 PB 级年归档诉求反推，64 节点是满足留存的下限。写入吞吐上确实有余量，这部分余量用于应对技改扩产。

Q3 四个工序的时间戳对不齐怎么办？

在接入层统一时基，而不是在查询时修补。本项目在第二阶段专门用两周时间做时钟治理，产出时间戳规整规则；如果跳过这步，后期工艺曲线拼接会持续错位。

Q4 TDengine 免费额度和 64 节点集群怎么共存？

免费额度覆盖五千个测点，除此之外与商业版没有任何功能差别，核心代码开源。单工序验证通过后换成商业版许可即可生效，既不必重新部署，也不用迁移历史数据，业务侧无需停机。

行动清单

7. 先做位号普查与标签设计，给 5 周，不要压。

8. 时钟治理单独立项，四个工序统一时基后再谈回溯。

9. 节点数按容量反推，不按测点数；每核 vnode 数在大规模集群上下调到 6。

10. 免费额度用于单工序验证，五千测点以内即可跑通建模链路。

11. 追溯类需求优先做，因为它是业务方感知最强的收益项。

12. 等保三级整改排进主计划，不要留到验收期。

需要说清楚的保留意见有两条。第一，64 节点集群的电力与机房空间投入在改造类项目中常常被低估，本项目的成本测算里包含了这部分，但如果基地的机房条件紧张，扩容可能要先做土建。第二，行业背景数据显示，企业采集到的数据中真正被分析和利用的比例不足 30%；换 database 只解决存储与查询，不解决"有没有人用"——本项目 33 人团队中有 8 人专门负责把分析结果推进到工艺规程里，这部分投入不能被省掉，否则存储成本降下来的同时，数据利用率不会自动上升。