从一个红灯说起
你有没有在某个路口等过超过3分钟的红灯？
这不是极端情况。国内不少二三线城市的路口信号配时还在用"定时方案"——早高峰一套、平峰一套、晚高峰一套、夜间一套。四套方案，365天循环播放。路口的车流量是动态变化的——周一早高峰和周五早高峰的流量分布差异可能超过20%，下雨天和工作日的出行模式完全不同。但信号机不知道，它只认时间表。
不是不想做自适应控制。问题在于，要做自适应信号优化，你得先有数据——这个路口各个方向的车流量时间序列数据。车检器（地磁线圈、视频检测器、毫米波雷达）每秒都在产生数据，但这些数据去了哪？
多数去了信号控制器本地。信号机存不了多少历史数据——内置存储也就存几个星期的运行日志。更上层的交通管理平台可能有数据接入，但通常是分钟级的统计数据，秒级的原始流量数据存不住。想做精细化的信号优化？数据不够。
这就是城市交通数据的现状：数据采集设备不少，但数据管理能力跟不上采集能力。
交通数据到底有哪些
拆开来看。
路口信号灯系统。 信号灯相位状态（红/黄/绿/闪光）、倒计时、行人按钮触发。每个路口的信号机通常管理4-8个相位，数据变化频率1秒。
车检器数据。 地磁线圈检测器报告各车道流量、占有率、平均速度。视频车检器额外提供车型分类、排队长度。毫米波雷达检测器提供多车道流量和速度。数据频率1-10秒。一个中等城市主城区的信号控制路口1000+个，每个路口4-8个车检器，全城车检器数据点4000-8000个。
视频卡口。 车辆号牌识别、车型识别、通过时间。数据按事件触发——每辆车通过产生一条记录。一个卡口日均过车量几千到几万条。
高速公路监测。 可变情报板（VMS）显示内容和状态、气象站（能见度、风速、路面温度、雨雪冰状态）、隧道环境（CO浓度、能见度、风速、照度、火灾报警）、交通流参数（各车道流量/速度/占有率）。
数据类型 | 采集设备 | 参数 | 采样频率 | 单路口/路段日数据量 |
信号灯相位 | 信号控制器 | 相位状态/倒计时/方案号 | 1秒 | 约8.6万条 |
车辆检测 | 地磁/视频/雷达 | 流量/速度/占有率/排队长度 | 1-10秒 | 约8.6万-86万条 |
视频卡口 | 抓拍摄像头 | 车牌/车型/通过时间/图片 | 事件触发 | 约2000-20000条 |
气象监测 | 自动气象站 | 风速/风向/温度/湿度/能见度 | 1分钟 | 约1440条 |
隧道环境 | CO/VI/风速/照度仪 | CO浓度/能见度/风速/照度 | 10秒-1分钟 | 约1440-8640条 |
交通流 | 微波/视频检测 | 各车道流量/速度/占有率 | 30秒-1分钟 | 约1440-2880条 |
情报板 | VMS | 显示内容/设备状态 | 事件触发 | 约50-200条 |
一座中等城市（人口100-200万）主城区的交通监测测点总量在5000-20000之间。数据频率从1秒到1分钟不等，日数据量千万级。这些数据如果存3年以上，原始数据量在百GB到TB级。
传统交通管理系统的数据短板
交警部门的交通管理系统（通常称为ATMS——Advanced Transportation Management System）在实时监控和勤务管理方面功能已经比较完善——大屏上能看到所有路口实时状态、拥堵指数、事故报警。但数据层面有几个老问题。
数据存储短。 多数ATMS平台的实时数据只存7-30天，超过就覆盖。一个月以前的交通态势数据没了。想做年度交通特征分析？数据不够。想对比今年和去年同期的拥堵变化？更不行。
子系统数据不通。 信号控制系统（如海信ITS、大华交通管理平台）、交通流检测系统、视频监控系统、气象监测系统——通常由不同厂商承建，数据格式各异，存储各自为政。一个城市的交通数据中心可能有四五套系统各自存各自的数据。
跨区域分析难。 一个区的拥堵数据跟另一个区的不在一个库里。交通管理部门想看全市的拥堵热力图变化趋势，得把各区数据先汇总到一个库再做分析——而各区系统可能版本都不一样。
查询能力弱。 有些ATMS平台基于SQL Server或Oracle，查询"某个路口过去3个月每天高峰时段（7:00-9:00和17:00-19:00）的南北方向流量变化趋势"，可能要跑几十秒甚至几分钟。这种查询频率不高但每次都要等，用户体验差。
时序数据库在这个场景的切入点
跟其他行业类似，时序数据库解决的还是"存得住、查得快、打通了"这三件事。但交通场景有几个独特的需求点。
数据频率差异大。 信号灯相位1秒一个值，车检器1-10秒，气象站1分钟，情报板事件触发。同一座城市里，从1秒到事件触发的数据并存。TDengine的超级表按数据类型分表，各自有独立的写入频率和存储策略。信号灯数据可以设定较短的保留期（比如1年），气象数据存更长（5年），卡口数据按事件量级设保留期。各表各管各的，不影响。
路口标签建模。 城市交通的层级结构：区→路口→方向→车道→参数。TDengine超级表标签包括区编码、路口ID、方向（东/西/南/北）、车道编号、设备类型。查"XX区所有南北向路口早高峰车流量均值排名"——按标签过滤+时间窗口聚合，一条SQL。
多路口分布式写入。 1000个路口同时往数据库写数据，每秒1000-8000条记录。TDengine的写入引擎在集群模式下可以线性扩展写入吞吐。3-5节点的TDengine集群处理这个写入量绰绰有余。
信号优化的数据需求
自适应信号控制的核心算法——SCATS、SCOOM、或国产的自适应方案——都需要实时交通流数据作为输入。当前车检器的数据直接进信号控制器做控制决策，但信号优化的评估和方案调优需要历史数据。
举个例子。一个路口从定时方案切换到自适应方案后，到底效果好不好？衡量标准是路口延误时间——车辆从检测器到停车线的平均通过时间。这个指标需要对比方案切换前后的历史流量和延误数据。没有历史数据就无法评估优化效果。
TDengine的数据存储能力使得全城所有路口的历史流量数据可以长期保存。信号优化评估系统从TDengine中拉取方案切换前后各30天的流量数据做统计分析，量化评估优化效果。如果效果不好，分析是哪个时段、哪个方向的流量模式不匹配导致的，进一步调整方案。
拥堵溯源：数据驱动的分析
交通拥堵的成因分析是交通管理的刚需。路口拥堵可能是信号配时不当、上游路口溢出、临时事件（事故/施工/大型活动）、天气原因等多种因素叠加的结果。
拥堵溯源的数据需求是时间序列的多维关联分析——拥堵发生时间、位置、上游路口的流量变化、信号相位切换序列、气象条件、事件记录。这些数据分散在信号系统、车检系统、气象系统、接处警系统中。
TDengine可以把这些系统的时间序列数据统一存储（各系统各建超级表，共享时间轴），应用层做时间关联查询。"2024年8月15日17:30-18:30 XX路口拥堵期间各方向流量、信号相位序列和上游路口流量变化"——TDengine中按时间范围查多张超级表，拼接后做可视化分析。这种分析过去需要从四五个系统分别导数据到Excel拼接，耗时半天。有了统一数据底座后，几秒钟完成查询。
高速公路的特殊场景
高速公路的监测数据跟城市道路有差异。重点场景是隧道和长大下坡路段。
隧道环境监测的数据频率不高但必须连续——CO浓度（隧道内汽车尾气的主要有害成分）、能见度（VI值反映烟雾浓度）、风速（纵向通风效率）、照度（入口段加强照明效果）。这些参数的采样频率10秒到1分钟。一条3公里的隧道布设4-6组监测断面，每组断面CO/VI/风速各1-2个测点，全隧道环境监测点30-60个。
数据存储要求连续不中断。隧道通风控制依据CO和VI数据自动调节射流风机的启停和转速。如果数据系统停了几分钟，通风控制就失去了自动决策依据，操作人员只能手动控制——这在长大隧道里是有安全风险的。
TDengine的数据订阅功能在这个场景下有实际价值。CO和VI数据写入TDengine后，数据订阅推送给通风控制系统，控制系统根据最新值调整风机运行。比控制系统直接查询数据库获取最新值的方案延迟更低、更可靠（数据写入和订阅推送是异步的，不会互相阻塞）。
气象站数据对高速公路安全运营很重要——能见度低于200米需要限速，路面结冰需要封道或限速。气象站数据频率1分钟，存3年可以覆盖多个季节周期，分析路面温度和气温的关系为结冰预警模型提供历史数据。
多城市区域中心架构
交警支队层面的数据管理覆盖全市，但省交警总队层面需要跨城市的数据——全省干线公路网交通态势。这种需求在春运、国庆等节假日大流量期间尤为突出。
部署架构建议：各城市交警支队部署本地TDengine做本市交通数据存储，关键数据（干线公路流量、主要节点拥堵指数）同步到省总队TDengine集群。省总队做跨城市干线公路态势分析。
TDengine原生数据复制支持这种多层级架构，各城市到省总部的同步延迟在秒级。总队侧可以实时监控全省干线公路网的交通态势——某条高速公路某个路段流量突增，总队值班室第一时间能看到。
TDengine的技术适配性
分布式架构支撑多路口。 1000+路口的并发写入，TDengine集群通过分片（sharding）分散写入压力。每个vnode负责一部分路口的数据，多vnode并行写入，总写入吞吐线性扩展。
标签模型适配路口层级。 路口编号、方向、车道、设备类型——TDengine的标签体系直接映射交通管理的组织维度。新增路口自动建子表，零配置。路口改造（如新增车检器）只需在超级表中新增子表，不影响已有数据。
数据订阅支撑实时告警。 信号灯故障、车检器数据异常、隧道CO超限——这些事件通过数据订阅实时推送，比应用轮询数据库查最新值延迟低、对数据库压力小。
SQL查询简化分析。 交通管理部门的数据分析人员通常有SQL基础。TDengine支持标准SQL，做时间窗口聚合、标签过滤、降采样查询都不需要学新的查询语言。"查询XX区近30天工作日早高峰各路口南北向流量排名"——一条SQL聚合查询。
高压缩比。 交通数据中信号灯相位和车检器流量在正常时段变化平缓，TDengine的列式压缩效果显著。全城10000测点×1秒频率×3年数据，原始约9460亿条，TDengine压缩后约300-600GB。存3年的全城原始交通数据，普通服务器能装下。
一个被低估的收益
交通信号优化的收益被严重低估了。美国FHWA的研究表明，合理的自适应信号控制可以减少路口平均延误10%-25%。一座1000路口的城市，如果平均每个路口每天减少车辆延误2分钟，按日均通过量3000辆计算，一天节省100车小时。按社会车辆每车小时时间价值30元计算，一天的社会效益3000元，一年约110万元。
而一个能支撑全城交通数据长期存储和高效分析的数据平台，部署成本可能就二三十万。投入产出比显然有利。但关键不在于选什么数据库——而在于交通管理部门有没有把数据管理和信号优化当回事。很多时候不是技术不行，是管理意识没到。
结语
交通数据管理的价值不在于数据本身——数字就是那些数字，流量、速度、占有率、相位状态。价值在于数据被长期保存和高效查询后，能支撑信号优化、拥堵溯源和出行服务。时序数据库在交通场景做的事情说起来简单——把秒级采集的数据存上3年，让按路口和时间维度的查询能在1秒内返回。但就这么一件事，很多城市还没做到。做到了的城市，路口多等红灯的次数肉眼可见地少了。
