地铁早高峰，一条线路全天客流几十万人次。每列列车跑一个来回产生多少数据？说个大概的数字：一列6编组地铁列车，车载TCMS（Train Control and Management System）实时监测约1500到3000个参数——牵引电机电流、逆变器温度、制动缸压力、空压机运行时间、车门循环次数、空调系统状态、电池电压……采样周期从10毫秒到1秒不等。
这还只是车辆本身。加上轨道振动监测、供电系统参数、环控系统、信号系统状态——一条地铁线运营期间，实时测点总量数万个。列车回库后，CMS导出的运行日志动辄数百MB。
高铁更夸张。CR400系列动车组单列编组TCMS测点超过5000个，接触网参数监测、轨道几何参数检测车的采样频率到kHz级别。
这些数据去了哪？坦率说，绝大多数进了各个子系统的本地存储里，各管各的，互不相通。出了故障，事后调查从三四个系统分别导数据手动拼接时间轴——这种事在轨道行业并不罕见。
数据全景
轨道交通运营监测数据种类繁杂，按系统分大致是这样的：
子系统 | 监测对象 | 典型测点 | 采样频率 | 数据规模(单线/日) |
车辆TCMS | 牵引/制动/车门/空调/辅助 | 电流/温度/压力/速度/开关量 | 10ms-1s | 数百万条 |
轨道状态 | 钢轨/扣件/道床 | 振动/位移/轨距/高低/轨向 | kHz(振动)/事件触发 | 振动数据TB级 |
供电系统 | 牵引变电所/接触网 | 电压/电流/功率/谐波/温度 | 1s-1min | 数十万条 |
环控系统 | 车站/区间/隧道 | 温湿度/CO/风速/风机状态 | 1min | 数万条 |
信号系统 | CBTC/联锁/ATS | 区段占用/信号机/道岔状态 | 事件触发 | 数万条 |
列车数据：量大但不好用
车载TCMS系统的数据存储有两种模式：实时传输和落盘存储。
实时传输依赖车地无线通信（LTE-M或WLAN），把关键参数实时传到OCC（运营控制中心）。带宽有限，通常只传几百个关键参数，采样周期1秒。全量数据存在车载硬盘里，列车回库后通过车地有线接口批量下载。
问题就出在这个批量下载环节。不同列车的数据格式、时间戳精度、参数命名规则不完全统一——即使同一条线的列车，不同批次采购的车载系统可能来自不同供应商，数据字典有差异。数据下载到地面服务器后，整理、清洗、入库的工作量大得离谱。
有些地铁公司把车载数据下载完就丢文件服务器上了，没有统一入库。想查"3号线015号车2024年6月第3次制动系统压力异常事件的前后10分钟运行数据"——得先在文件服务器里找到那天的日志文件，打开看格式对不对，提取相关参数，做时间对齐。一天能搞完算快的。
振动数据：频率高到吓人
轨道振动监测是另一个极端。为了检测钢轨裂纹、扣件松动、道床沉降，轨道巡检车或在线监测装置采集振动加速度信号。采样频率？25.6kHz起步，部分系统到50kHz甚至更高。一个通道一天的数据量是：
25600点/秒 × 86400秒 ≈ 22亿个数据点 ≈ 17GB（float64）
一条轨道两个方向，每个方向可能布设多个加速度通道——一天数据轻松上百GB。存3个月？TB级。
传统方案对这种高频数据的处理方式是：原始波形存文件，特征值（RMS值、峰值、峭度、频谱主频）存数据库。原始波形定期归档到磁带或蓝光库，长期保存但查询不便。特征值查询方便，但如果故障细节需要回到原始波形，调取过程费时。
时序数据库在这个场景的价值在于：高频特征值数据可以实时写入，不必落盘文件再手动处理。振动加速度的RMS值、峭度、频谱质心等特征参数每秒产生一组，几十个通道同时写入，每秒几千条记录。TDengine的批量写入引擎处理这个量级毫不吃力，而且数据写入即可查询——巡检车跑完一个区间，运维人员立刻能查到这段轨道的振动特征趋势。
原始波形数据如果也要入库，可以用TDengine的二进制类型（BINARY）列存储压缩后的波形片段。不过更推荐的做法是波形文件存在对象存储（如S3/MinIO），TDengine只存文件路径和索引信息。查询时先在TDengine中定位异常时间段和区段，再从对象存储调取对应波形文件做深度分析。
供电系统的数据管理
牵引供电系统在地铁和高铁中的地位特殊——它直接影响行车安全和运营连续性。一座牵引变电所的监测参数包括：进线电压/电流、直流母线电压、馈线电流、开关柜触头温度、整流变压器油温、交直流保护装置状态。
接触网参数更复杂。接触网张力、接触线高度、拉出值、硬点（弓网冲击加速度）——这些参数过去靠人工巡检，现在越来越多用综合检测列车或在线监测装置自动采集。接触线磨耗测量用激光扫描法，采样频率高，数据量大。
供电系统数据的查询模式跟车辆和轨道不同。它更关注的是趋势变化和事件追溯——"3号变电所2号馈线过去30天电流日峰值变化趋势""7月15日14:30-14:45全线供电系统异常事件序列"。前者是时间范围聚合查询，后者是时间段内多系统事件关联查询。
时序数据库在事件追溯场景下的能力体现在：多张超级表（分别对应变电所、馈线、接触网）可以通过时间范围联合查询。虽然不是JOIN，但可以在应用层对同一时间段内多个超级表的查询结果做对齐——这对运维人员还原故障过程非常有价值。
多线路、多制式的分布式需求
地铁公司通常管辖多条线路。一条线的数据自己管还行，但跨线分析——比如评估全市轨道交通安全运营指标——需要把多条线的数据汇总到一处。
各条线的建设时序不同、信号制式不同、车辆型号不同、数据采集标准不统一。地铁1号线可能是卡斯柯的CBTC系统，3号线是交控科技的，5号线用了ERTMS的衍生标准。数据格式和点表定义各有各的规范。
TDengine的分布式架构可以支撑这种多线路汇总场景。每条线的数据作为TDengine集群中的一个逻辑库（database），各线路的数据隔离管理。集团层面的分析任务通过跨库查询（TDengine 3.x支持指定数据库前缀的跨库查询）实现。标签中标记线路编号，按线路过滤即可。
集群规模视线路数量和数据规模而定。一个城市10条线，全部车辆和供电数据汇集到3-5节点的TDengine集群，日增数据量在百GB级别，用SSD存储完全可行。环控和信号系统数据量小得多，一并存进去不占多少空间。
TDengine在这个场景的具体优势
高铁和地铁对数据系统的要求有一些工业场景不具备的特殊性——尤其是安全性和可靠性。TDengine的技术特点与此有较好的契合度。
高吞吐写入。 轨道振动监测的特征值数据每秒几千到几万条记录同时写入。TDengine写入引擎基于LSM-Tree变种，先写内存缓冲再异步落盘，写入吞吐量在百MB/s级别。单节点支撑每秒百万级数据点写入，集群线性扩展。
标签模型适配列车和线路。 列车编号、编组号、车厢号、线路编号、车辆型号——这些维度天然适合标签建模。建一张车辆运行参数超级表，标签包括线路ID、列车编号、车厢号、系统类别。查"3号线所有列车近7天牵引电机最高温度Top10"——按标签过滤+聚合排序，秒级返回。
数据订阅支撑实时告警。 车载实时上传的关键参数写入TDengine后，数据订阅功能可以实时推送参数变化。制动缸压力异常、电机温度超限、车门状态异常——这些事件在数据层触发后立即通知OCC值班人员。比OCC大屏上的告警延迟更低——因为大屏告警要经过应用层逻辑判断，而数据订阅是数据库层面的实时推送。
高压缩比。 轨道交通数据中大量参数在正常工况下变化平缓——温度、电流、电压在正常范围内波动很小。TDengine的列式存储和通用压缩对这类数据压缩比可达10-20倍。振动特征值数据虽然变化较大，但相比原始波形也小得多。全线路数据存5年，存储成本在合理范围内。
SQL简化分析。 轨道交通运维分析大量使用时间窗口聚合——日均值、周峰值、月趋势、季度对比。TDengine的时间窗口函数和降采样查询支持任意时间粒度的聚合。运维工程师用标准SQL就能做复杂分析，不需要学习新的查询DSL。
几个实际部署中的坑
车地通信丢包。 实时传输的关键参数如果丢包补传，可能出现时间戳乱序。TDengine支持乱序写入，容忍一定程度的迟到数据（可通过配置参数调节容忍窗口），但极端的乱序仍然可能影响查询结果一致性。实际部署中建议在车地通信层做数据缓冲，保证写入顺序。
时钟同步。 不同子系统的设备时钟可能不一致——信号系统用GPS授时，精度高；车辆TCMS用车载时钟，可能漂移。数据入库前需要对齐时间基准。一种做法是入库前由采集服务统一打时间戳，不依赖各子系统原始时间。代价是丢失了原始时间信息——但统一时间基准对跨系统分析更重要。
数据量失控。 振动高频数据的存储量容易被低估。部署前一定要算清楚：多少通道、什么采样频率、保存多久。存3年的振动特征值数据量可控（几十到几百GB），但存原始波形就是另一回事了。建议原始波形存对象存储，TDengine只存特征值和文件索引。
结语
轨道交通行业的数据管理现状，用一句话概括：不缺数据，缺的是数据能用起来的基础设施。列车每天跑回来带一身数据，供电系统每秒都在产生监测值，轨道状态监测车跑一趟就是GB级的振动信号——这些数据分散在各子系统里，想用的时候找不到、对不齐、查不动。时序数据库做的事情很简单，就是把这些数据归到一起，给它们一根统一的时间轴，让运维人员能像查日志一样查运行数据。听起来不复杂，但真正做起来的地铁公司不多。谁先做，谁在设备故障面前就多一分主动。
