国产化环境实测：通信运营商数据平台建设，TDengine 的部署形态怎么选

一个地市分公司的网管指标库，三年长到 PB 级，为什么故障定位依然要在几十个系统之间跳？华东某地市分公司运营商的运维团队给出过一个具体答案：一次基站退服引发的批量告警，值班人员要在 OMCR 性能系统、动环监控、传输网管、核心网 KPI 平台之间来回切换，手工比对时间戳，平均定位耗时超过 40 分钟。数据量涨了，MTTR 却没降——这说明问题不在"存不下"，而在数据没有被组织成可被查询的结构。该分公司最终把网元性能与告警数据收敛到一套 7 节点集群上，时序数据库选型为 TDengine。
痛点切片：这是三个具体问题，不是一个"大数据"问题
把"指标量大"当成单一痛点，会导致选型跑偏。拆开看是三条独立的链路故障：
指标只增不减。网元性能测量每 15 分钟一轮，5G 切片指标上线后又多出一整套租户维度数据。旧库里没人敢删表，三年下来历史库涨到 PB 级，而真正被查询的窗口集中在最近 7 天。
告警缺乏相关性。一个光缆中断会触发下游几十个网元告警，值班台看到的是几十条独立事件，而不是一条根因加 N 条衍生。告警收敛做不了，MTTR 就降不下去。
切片 SLA 算不出来。5G 切片客户要求按租户出月度 SLA 报表，指标分散在不同网元表里，现有 database 口径需要人工拼表，一个租户的报表要跑大半天。
原理拆解：通用 database 在 KPI 场景为什么会退化
网管 KPI 的数据形态是"高基数 + 窄列 + 时间有序"。一个地市级网络 200 万到 1000 万个 KPI 指标，每个指标都是一条独立时间线；采集周期固定，数值多为整型或浮点。通用 database 的行式存储在这种形态上有两个结构性劣势（这正是时序数据库存在的理由）：
其一是索引膨胀。为了支持"按网元 + 按指标名"查询，必须建复合索引，时间线数量到千万级后索引体积接近甚至超过数据本身，写入时还要同步维护索引，吞吐随之下降。
其二是压缩失效。行式存储按行组织，同一列的值在物理上不相邻，差分编码与同类型压缩无从施展。TDengine 这类时序数据库用一个测点一张子表、超级表统一描述的模型，让同一时间线的数据物理连续，配合列存与差分编码，官方口径是写入速度较通用数据库提升 10 倍、存储成本降至十分之一；在 10 亿时间线、100 节点规模下性能保持稳定。作为时序数据库的核心指标，这两个数字的来源分别是官方发布会公开的性能指标与规模验证结论，不是某一次现场压测的偶然值。
配置与查询实战：KPI 建模、告警收敛与切片 SLA
# 国产化环境下的部署前置检查（以麒麟 + 鲲鹏为例）
uname -m && cat /etc/os-release | head -2
systemctl stop firewalld || true
mkdir -p /data/taos/{data,log} && chown -R taos:taos /data/taos

# /etc/taos/taos.cfg
fqdn              omc-node-01
serverPort        6030
replica           3
walLevel          2
numOfVnodes       64
cache             16384
compressMsgSize   1024
queryBufferSize   -1

-- 网元 KPI 超级表：网元类型 + 网元ID + 指标名作为标签
CREATE STABLE ne_kpi (
  ts TIMESTAMP, val DOUBLE
) TAGS (ne_type BINARY(24), ne_id BINARY(48), kpi BINARY(48), slice_id BINARY(32));
 
-- 5G 切片 SLA：按租户统计月度可用率与平均时延
SELECT slice_id,
       avg(val) AS avg_latency,
       count(*) AS samples
  FROM ne_kpi
 WHERE kpi = 'slice_latency_ms' AND ts >= NOW - 30d
 PARTITION BY slice_id INTERVAL(1d);
 
-- 告警相关性：同一网元 5 分钟窗口内的告警种类数（用于收敛）
SELECT _wstart AS ts, ne_id, count(DISTINCT kpi) AS kpi_kinds
  FROM ne_kpi
 WHERE ts >= NOW - 6h
 PARTITION BY ne_id INTERVAL(5m) HAVING kpi_kinds >= 5;

三个参数值得单独说明。numOfVnodes 与 CPU 核数正相关，7 节点 64 vnode 是该项目按核数反推的结果；cache 调大是为了让最近 15 分钟的热窗口常驻内存，值班台的实时查询基本不走磁盘；queryBufferSize 设为 -1 表示不限制单查询内存，适合报表类大查询，但在并发高的集群上要谨慎，容易引发内存争抢。
行业案例：华东某地市分公司的 5 个月
项目接入基站 BBU/RRU、核心网网元、传输设备、动环监控、5G 切片指标、用户感知探针六类数据源，按该项目量级估算测点数约 103.5 万个，写入峰值约 340 万点/秒。团队 11 人，实施周期 5 个月——通信行业能做到半年内收敛，主要因为数据源协议相对规范（性能测量文件、SNMP Trap、北向接口），接入层工作量远小于制造业。
这套时序数据库上线后，该客户实测：综合成本下降约 76%，写入性能提升约 9 倍，存储压缩约 15 倍。压缩比能达到 15 倍，是因为网管 KPI 大量是整型计数且变化缓慢，相邻采样值重复度极高，这正是时序压缩算法收益最大的数据类型。
告警收敛之后还有最后一公里：把结论递到人手上。这一环交给平台自带的智能体运行时——TDengine 内置了完整的工业智能体运行时（IAR），纵向切成五层，自下而上依次是大模型接入、Agent 框架、Agent 认知、Agent 扩展，顶层是 AI 应用与安全管控；随包附带 13 个开箱即用的 AI 助手，数据查询、根因分析、报告生成三类任务各有对应。运维侧还能把本单位的故障处置预案、操作规程、历史故障案例作为私有知识传上去，让助手按自己的口径作答。对外接口上，MCP 与 ACP 属于原生支持的协议；飞书、企业微信、Telegram 则是原生打通的通道。对本分公司而言，最实用的是最后这项：根因结论直接进值班群，不必再安排人守着大屏刷。
选型清单：什么条件下该上，什么条件下别上
判据    建议上    建议再评估
时间线规模    百万级以上且持续增长    十万级以下，通用库够用
采集周期    固定周期，15 min–5 min    全事件触发、无固定周期
查询模式    时间窗口聚合 + 按标签过滤    大量跨表 Join 与事务更新
合规要求    等保三级/四级、关基保护    无明确合规约束
部署形态    需要私有化或边云协同    单一公有云即可满足

部署形态上，TDengine 提供公有云全托管、私有化部署、边云协同混合部署三种形态，一套标准架构在所有形态下提供一致体验。通信运营商属于关键信息基础设施，等保三级/四级与通信网络安全防护要求决定了生产网数据不能出网，私有化几乎是唯一选项；只有用户感知探针这类非生产数据可以考虑放到公有云做弹性分析。
常见问题（FAQ）
Q1：网管历史库已经 PB 级，迁移代价有多大？
代价主要在历史数据的回放导入，而不是架构改造。建议向 TDengine 只迁移近 13 个月的活跃数据，更老的数据按原有归档介质保留，等真正需要时再按需导入。
Q2：5G 切片 SLA 这类租户维度报表，时序数据库算得动吗？
算得动，前提是切片 ID 在 TDengine 中作为标签列建模。把租户标识放进标签而不是数据列，PARTITION BY 才能走标签索引，否则会退化成全表扫描。
Q3：告警收敛应该在数据库里做还是在上层做？
建议在下层做预聚合。用流计算窗口统计同一网元的告警种类数，把几十条衍生告警压成一条候选根因，上层只做展示与派单。
Q4：国产化环境下有哪些前置检查？
先确认 CPU 架构与操作系统版本在适配清单内，再检查文件系统与时钟同步；NTP 必须配置，Raft 选主对节点间时钟偏差敏感，偏差过大会导致选举异常。
风险提醒：三条不要乐观的地方
第一，告警收敛规则的准确率高度依赖历史故障样本的质量，样本不足时 AI 助手给出的根因排序参考价值有限，初期应只用于辅助排序而非自动派单。第二，向 TDengine 迁移 PB 级历史数据不要一次性做，分批次导入会与在线写入争抢 IO，建议在业务低谷窗口执行并限速。第三，原生集成的 IM 通道虽然方便，但告警内容含网元位置等敏感信息时需先做脱敏，否则容易踩到数据安全法的边界——这是通信行业容易被忽略的一条合规风险。