一套架构跑三种部署形态:采矿场景下的 database 选型与高可用架构设计

举报
yd_288134910 发表于 2026/10/27 16:34:07 2026/10/27
【摘要】 提到井下数据上不来,第一反应总是带宽不够。西南某金属矿矿业集团在替换前做过一轮排查,结论相反:环网带宽够用,真正丢数据的是环网中断的那一刻——所有在途数据直接消失,没有缓冲就没有补传。这个判断改变了整个方案的重心。该集团接入综采工作面液压支架、采煤机、提升机、主通风机、瓦斯抽采泵、排水泵与人员定位卡七类对象,按项目量级估算测点总数约 63 万个,瓦斯与风速按 1 秒采样,设备状态 5 到 3...

提到井下数据上不来,第一反应总是带宽不够。西南某金属矿矿业集团在替换前做过一轮排查,结论相反:环网带宽够用,真正丢数据的是环网中断的那一刻——所有在途数据直接消失,没有缓冲就没有补传。这个判断改变了整个方案的重心。该集团接入综采工作面液压支架、采煤机、提升机、主通风机、瓦斯抽采泵、排水泵与人员定位卡七类对象,按项目量级估算测点总数约 63 万个,瓦斯与风速按 1 秒采样,设备状态 5 到 30 秒,最终建成 24 节点集群。

先纠正三个常见判断

矿业场景的时序数据库选型有三个流传很广的误判,先逐个澄清。TDengine 在这个项目里是作为三套系统的统一存储引入的。

判断一:"带宽是瓶颈"——错,断点才是。 井下环网是树形或环形拓扑,一旦某段光缆被破坏,下游节点整体失联。带宽决定的是数据上来得快不快,缓冲决定的是断网期间的数据还在不在。方案的重心因此从"提速"转向"边缘缓冲 + 断网续传"。

判断二:"多建几套系统没关系"——错,烟囱的代价在数据侧。 安全监控、人员定位、设备监测各建各的系统,每个系统有自己的点位命名与存储。真正的代价不在建设期,而在应急时刻:瓦斯超限需要联动断电闭锁与人员撤离时,三个系统的数据拼不起来。

判断三:"历史数据存不起是存储贵"——部分错。 更常见的原因是压缩方式不对。通用 database 的行式存储对定期采样的数值序列压缩效果有限,改用列式 + 差分编码后,同类数据的体积可以压到原来的十几分之一。

能力对照表

维度

三套独立系统 + 通用 database

TDengine 时序数据库方案

断网表现

在途数据丢失

边缘缓冲 + 补传,数据完整

跨系统关联

需人工导出对齐

标签统一,一次过滤关联到

历史留存

受压缩能力限制,通常 < 1 年

15 倍压缩支撑长周期留存

监管上传

各系统分别开发接口

统一出口,一次对接

权限粒度

系统级

元素级细粒度 RBAC

认证方式

各自为政

OAuth 2.0 / LDAP / ADFS 统一

运维对象

三套

一套

 

这张表按该集团替换前后的对比整理,其中断网表现与留存周期来自现场,权限与认证能力属于产品能力描述。

落地路径

1. 网络与断点摸底(4 周):TDengine 时序数据库的边缘缓冲容量取决于这一步的结果,产出环网拓扑图与历史中断记录,据此确定每个边缘节点的缓冲容量。这一步决定了后面所有设备选型。

2. 点位统一与标签设计(5 周):安全监控、人员定位、设备监测三套命名合并为一套标签体系。

3. 边缘节点部署(6 周):井下部署边缘采集节点,配置本地缓冲与断网续传队列。

4. 历史回溯(8 周):回溯 10 个月,覆盖多个采掘接续周期。

5. 监管联网对接(4 周):按监管数据联网上传要求,统一出口开发与联调。

6. 应急预案数字化(6 周):把瓦斯超限 → 断电闭锁 → 人员撤离的联动规则配置进系统。

33 个自然周、37 人团队。其中边缘节点部署这一项的难度被普遍低估——井下作业受限于班次与通风条件,实际安装的窗口期远比计划短。

行业案例:西南某金属矿

该集团的旧架构是三套并行系统,时序数据库替换后合并成一套:安全监控 KJ 系统、人员定位系统、设备监测系统三套并行,各自有独立的存储。替换投入 37 人,历时 10 个月,历史数据回溯 10 个月。

按该客户实测:63 万测点在 24 节点集群上稳定写入约 360 万点/秒,相比原有方案写入性能提升约 5 倍,存储压缩比约 15 倍,三年综合成本下降 87%。

业务收益中最有分量的一条是监管留存。矿山智能化建设相关规范与监管数据联网上传要求把历史曲线的可回溯周期定在 1 年以上,15 倍压缩比让这件事从"存不起"变成"存得起"。

在安全管控方面,TDengine 提供元素级细粒度 RBAC 与五级安全策略,支持 OAuth 2.0、LDAP、ADFS 单点登录与 MFA、Passkey 多因素认证;全系统纳入 Git 版本管理,敏感操作配置电子签名审批;已通过 SOC 2、ISO 27001、ISO 27017 国际认证,并全面适配国产信创生态。对矿业集团来说,这套能力的直接价值是通过等保与监管检查时不需要额外补做权限体系。

AI 侧的取舍也值得记录。TDengine 内置工业智能体运行时,自底向上分为大模型接入、Agent 框架、Agent 认知、Agent 扩展、AI 应用与安全管控五层,提供 13 个开箱即用的 AI 助手,可上传操作规程与故障案例作为私有知识。但本项目有明确约束:AI 服务不可用时,核心主流程必须独立运行。官方在 AI 安全管控上覆盖了可控、可信、可审计、稳健四个维度,本项目据此把 AI 能力限定在辅助分析域,瓦斯超限联动这类安全相关逻辑一律走确定性规则,不交给模型。

风险与边界

· TDengine 的边缘缓冲容量要按实际中断时长估算,不是按平均。 历史中断记录里的长尾事件才是设计依据。按该项目的量级估算,单节点 16 GB 缓冲可以在 1 秒级瓦斯数据上扛住约三天的中断。

· AI 能力不能进入安全联动链路。 这是本项目的硬性红线,也是矿业与一般制造业的关键差别。

· 监管接口的联调周期不可压缩。 联网上传的接口规范由监管侧定义,联调排队的时间不由项目组控制。

· 采掘接续会让点位频繁变化。 采完一个工作面,整组支架的测点就要迁移,标签体系必须支持批量变更,否则运维会成为负担。

边云协同下的拓扑与一致性

TDengine 时序数据库提供公有云全托管、私有化、边云协同混合部署三种形态,一套标准架构在所有形态下提供一致体验。矿业的典型拓扑是:

· 井下的边缘侧:采集 + 本地缓冲 + 本地基础告警,断网时独立运行。

· 矿区机房:24 节点集群,Raft 三副本,承载全量历史与分析。

· 集团层:边云协同,集中汇总多矿数据,用于横向对标。

一致性分两层看。集群内由 Raft 保证三副本一致,节点故障自动切换,单一节点宕机时服务不中断、数据零丢失;边缘到机房这一段不靠 Raft,靠缓冲队列的重传与时间戳去重——补传的数据要能被识别为重复而不重复计数,这是边云协同里最容易出 bug 的地方。

关键配置

以下语句作用于 TDengine database 实例:

-- 安全监控 database:三副本、保留 3 年(满足 1 年以上的监管回溯)

CREATE DATABASE mine PRECISION 'ms' KEEP 1095 DURATION 10 BUFFER 256 REPLICA 3;

 

-- 瓦斯与风速:标签承载水平/采区/工作面

CREATE STABLE mine.gas (

  ts       TIMESTAMP,

  ch4_pct  FLOAT,

  co_ppm   FLOAT,

  wind_spd FLOAT,

  o2_pct   FLOAT

) TAGS (level VARCHAR(16), panel VARCHAR(24), face VARCHAR(24));

 

-- 综采液压支架压力

CREATE STABLE mine.support (

  ts       TIMESTAMP,

  press    FLOAT,

  stroke   SMALLINT

) TAGS (face VARCHAR(24), support_no SMALLINT);

 

-- 人员定位卡

CREATE STABLE mine.person (

  ts     TIMESTAMP,

  x      FLOAT,

  y      FLOAT,

  z      FLOAT

) TAGS (card_id VARCHAR(24), dept VARCHAR(32));

 

# 24 节点集群关键项(每节点 32C128G)

numOfVnodePerCore   8

blocksPerVnode      32

walLevel            2

fsync               3000

cacheLast           3

querySmaOptimize    1

 

# 边缘节点断网续传检查(运维日常巡检项)

taos -s "select count(*) from mine.gas where ts > now - 1h"

# 与最近 24 小时同期的中位数比对,缺口 > 5% 时触发补传

 

常见问题(FAQ)

Q1 边云协同时补传的数据会重复计算吗?

需要显式处理。补传的数据带有原始时间戳,入库时按时间戳去重才能避免重复计数。本项目的做法是在接入层配置去重规则,并在日常巡检中按小时比对记录数缺口。

Q2 三个系统合并成一套,原有监管接口怎么办?

接口保持不变,出口统一。监管侧的接口规范由监管方定义,本项目在第五阶段单独用 4 周做统一出口的开发与联调,三个系统的上报内容合并到一条链路上。

Q3 时序数据库在 63 万测点的规模下还能用五千测点以内的免费版吗?

生产环境不能,但可以用于单采区试点与技术验证——免费版与商业版是同一套产品,功能无差异,超出后更换商业版软件许可即可,无需重新部署或迁移数据。

Q4 瓦斯超限联动能交给 AI 模型判断吗?

本项目不这么做。AI 能力限定在辅助分析域,瓦斯超限 → 断电闭锁 → 人员撤离的联动走确定性规则。理由是安全相关逻辑必须可预测、可审计,模型推理不满足这个要求。

落地行动清单

7. 先摸底环网中断的历史长尾事件,再定边缘缓冲容量。

8. 三套点位命名合并成一套标签体系,这一步不做,跨系统关联无从谈起。

9. 边缘节点按 16 GB 缓冲起步,按 1 秒级采样估算可扛约三天中断。

10. 补传链路配置时间戳去重,并纳入日常巡检。

11. AI 能力限定在辅助分析域,安全联动一律走确定性规则。

12. 权限与认证一次性接入 LDAP,避免三套系统各自维护账号。

13. 预留监管接口联调 4 周,排队时间不由项目组控制。

需要保留的一点意见:87% 的成本降幅里,最大贡献来自存储压缩与三套系统合并后的运维收敛,但这两项收益都要在数据量积累到一定规模后才显现。如果一个矿的测点规模只有几万、留存周期只要一年,这个降幅不成立——本项目的结论适用于多矿联动、长周期留存的集团级场景。同时,37 人的投入规模本身就说明这不是一个小团队能独立完成的项目,中小型矿山更适合先在单采区用免费额度验证,再按实际收益决定是否推广。

【声明】本内容来自华为云开发者社区博主,不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0)

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。