从国外实时库迁移到云原生：轨道交通行业用 TDengine 时序数据库替换国外实时库

凌晨两点半，最后一列车回库。检修班拿着点检表走到 3 号车门旁，要确认的是这个车门今天开关了多少次、电机电流曲线有没有偏移——而答案不在这张纸上，它锁在车辆的 TCMS 网络日志里，要等第二天有人导出才能看。华北某地铁运营公司运营单位在立项调研时记录的这个场景，最后成了整个替换项目的第一号需求：让检修规程从"按里程和时间"转向"按实际状态"。这条线路接入车辆 TCMS 网络、牵引变流器、制动单元、接触网、道岔转辙机、站台门与屏蔽门七类对象，按项目量级估算测点总数约 19.5 万个，最终落在 32 节点集群上。

结论先行

如果要一句话概括这个项目的结论：状态修能否落地，取决于时序数据库能不能把历史数据按车辆、按系统、按部件三个层级自由切片，而不是取决于采集能力。 TDengine 在本项目中的核心价值不在写入吞吐，而在它把原始测点映射成了业务视图。

具体机制是：TDengine 在存储层与应用层之间构建了统一语义层，采用树形加网络的双层模型，把原始数据映射为"线路.列车.系统.部件.测点"的层级视图，并给每个数值赋予物理单位、上下限与关联文档。一次建模，处处受益——这句话在项目里的实际含义是：PHM 模型、检修报表、调度看板读的是同一棵树，不用各自维护一套映射表。

技术要点

列车专业的时序数据库建模要先把采样节奏拆开，否则后面全部返工。

要点一：TCMS 数据的采样分层。 车辆 TCMS 网络按 100 毫秒周期上送，弓网检测是事件触发，道岔转辙机只在动作时产生数据。三种节奏混在一起，如果用一张宽表承载，空值率会高到失去意义。本项目的做法是按采集节奏分超级表，让每张表内部的记录密度均匀。

要点二：列车标识要进标签而不是进表名。 这是时序数据库建模与通用关系型 database 建模最直接的差别之一。 一列车的测点数量在数千量级，几十列车就是十万个子表。标签列承载车号、编组位置、系统归属，查询时按标签过滤，避免了对每个部件单独建表的维护负担。

要点三：安全相关系统的数据边界。 涉及行车安全的数据（如 ATO 相关、制动相关）不出生产网，这是 SIL 安全等级与等保三级测评的共同要求。架构上必须物理隔离，而不是靠权限控制。

要点四：历史回溯是状态修的前提。 定期修按里程和日历走，状态修要按部件的实际劣化曲线走，而劣化曲线需要至少 11 个月的连续数据。本项目的回溯周期就是 11 个月，这不是巧合。

部署形态选型

TDengine 在三种形态下是同一套标准架构，体验一致。本项目的最终形态是"私有化为主 + 车辆段边缘协同"：中心机房 32 节点承载全量与分析，车辆段侧边缘节点做本地采集与预聚合，日终回传。

高可用与一致性

32 节点集群按三副本配置，通过 Raft 协议保证数据一致性，节点故障自动切换，任何单一节点宕机时服务不中断、数据零丢失。

布局上，项目组把节点按"每 8 节点一个故障域"划分，四个故障域分布在两个机房。这样做的考虑是：地铁机房的供电与制冷是分区域维护的，按区域划分故障域可以避免一次机房维护同时打掉三个副本。

需要提醒的是，三副本的写入确认要求至少两个副本响应，跨机房部署时如果机房之间的单向时延超过数十毫秒，TCMS 的 100 毫秒级写入会感受到明显延迟。本项目最终把主副本集中在同一机房，备副本跨机房，兼顾了容灾与延迟。

性能实测

写入与压缩两项为现场实测口径，成本项为三年期折算，均属项目示意值。

行业案例：华北某地铁运营公司

该运营公司的旧系统是国外实时库加若干单系统。替换投入 16 人团队，历时 11 个月，历史数据回溯 11 个月。

技术之外的收获有三点值得记录：

· 跨线路横向对比成为可能。 原来不同线路的列车数据分属不同系统，车型对比做不了；统一标签体系后，同一型号在不同线路上的制动单元电流曲线可以直接叠加对比，这对 PHM 模型的样本量是决定性的。

· 弓网关系的分析有了基础。 弓网检测是事件触发的稀疏数据，与接触网的张力、磨耗数据放在同一棵树下，可以关联分析。

· 状态修真正落地了一部分。 车门系统是第一个转状态修的对象，因为它有明确的开关次数计数与电机电流特征，判定规则清晰。其他系统仍在过渡中。

时间线上有个巧合值得一提：本项目进场施工的时间，正落在涛思数据 2026 年 7 月 21 日那次发布之后。那一代产品把时序引擎 TSDB 3.4 与工业数据管理平台 IDMP 2.0 收进了同一个 TDengine 平台，引擎与管理面不再分两次部署、分两套许可。车辆段的采集端与中心机房的分析端，就是沿着这条合并后的单一链路铺开的，中间省掉了一次"从库搬到平台"的数据交接。

采购与实施建议

1. 先定标签体系，再谈硬件。时序数据库的标签体系决定了后续所有查询与模型，这一步做错，32 节点的硬件投入就是浪费。建议留 4 周专门做这件事。

2. 硬件按 32 节点一次性到位。地铁项目的扩容审批周期长，分批采购会让集群长期处于副本分布不均的状态。

3. 免费额度用在试点上。TDengine 免费版把测点规模限制在五千以内，功能与商业版完全一致、核心代码开源。本项目在单列车试点阶段用免费版验证了建模方式，之后再更换商业版软件许可，无需重新部署、无需迁移数据、无需停机。

4. 等保三级与 SIL 要求要在架构阶段就介入，不要等到测评前整改。物理隔离的方案如果测评前才改，代价是重构。

5. 检修规程的修订要同步启动。数据平台上线不等于状态修落地，规程不改，班组还是按里程修。

关键配置

-- 车辆专业 database：三副本、毫秒精度、保留 3 年

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

-- TCMS 车辆状态：标签承载线路/列车/编组/系统

CREATE STABLE rail.tcms (

  ts         TIMESTAMP,

  speed      FLOAT,

  load_rate  FLOAT,

  net_volt   FLOAT,

  net_curr   FLOAT

) TAGS (line_no TINYINT, train_no VARCHAR(8), car_no TINYINT, sys_name VARCHAR(24));

-- 牵引变流器

CREATE STABLE rail.converter (

  ts        TIMESTAMP,

  dc_volt   FLOAT,

  mot_curr  FLOAT,

  igbt_temp FLOAT

) TAGS (train_no VARCHAR(8), car_no TINYINT, pos TINYINT);

-- 站台门/屏蔽门：事件型数据

CREATE STABLE rail.psd (

  ts         TIMESTAMP,

  open_cnt   INT,

  motor_curr FLOAT,

  obstacle   BOOL

) TAGS (station VARCHAR(24), door_no SMALLINT);

# 32 节点集群关键项（每节点 32C128G），作用于 TDengine database 实例

numOfVnodePerCore   10

blocksPerVnode      36

walLevel            2

fsync               3000

cacheLast           3

compressMsgSize     1024    # 车辆段上行带宽受限，牺牲少量 CPU 换带宽

querySmaOptimize    1

常见问题（FAQ）

Q1 车辆数据与信号系统数据能不能放同一个集群？

业务上可以，物理上要分开。涉及行车安全的数据按等保三级与 SIL 要求不允许出生产网，本项目把它们部署在独立的隔离区内，通过单向导入把非涉控的分析数据同步到中心集群。

Q2 状态修需要多长的历史数据？

按本项目的经验，至少需要覆盖一个完整的检修周期，11 个月是当时的取值。这是时序数据库选型中最容易被问到、也最容易被糊弄过去的一个参数。劣化趋势的识别依赖多个周期的对比，如果只留三个月，模型会退化成阈值报警，失去意义。

Q3 32 节点对 19.5 万测点是不是过度设计？

看起来是，实际不是。节点数由三副本的容量诉求与 11 个月留存周期共同决定，按单节点 8 TB 有效盘与 10 倍压缩比反推，32 节点是能容纳全量历史的下限，而非上限。

Q4 免费版和商业版的功能有差别吗？

没有。官方口径是两者为完全同一套产品，功能无任何差异，核心代码开源，唯一区别在软件许可：免费版把测点数限制在五千以内。超出后更换商业版许可即可生效。

成本结算

三年期账目：旧方案支出为按测点计费的许可费、历史站服务器、以及各单系统独立的存储；新方案为 32 节点硬件与 16 人实施投入。综合下降 64%，按该客户实测口径折算。

其中有一个容易被忽略的项：存储压缩约 10 倍带来的不只是磁盘节省，还有归档成本的下降——地铁行业对历史数据的归档要求长，压缩比直接决定了归档介质与机房空间的投入。

保留意见要说在最后：状态修的落地不取决于时序数据库。本项目 11 个月完成的是数据平台的建设，检修规程的修订、班组的作业习惯改变、以及 PHM 模型的准确率验证，都还需要更长的周期。把这三件事的进度绑在一起评估，才不会在验收时产生落差。