从国外实时库迁移到云原生：智慧城市数据平台建设，TDengine 的部署形态怎么选

台风橙色预警发布的那个晚上，华东某新区城运中心的屏幕上同时亮起四套系统：水务的液位监测、交警的信号机状态、城管的井盖位移、应急的桥梁形变。值班人员要判断"某下穿隧道是否已断行"，需要在四个界面之间手动比对时间戳，其中两套系统的时间基准还差了 8 分钟。等结论出来，封路指令晚了近半小时。这不是人员素质问题，而是城市感知数据从未被放进同一个时空坐标系里。该新区随后启动了感知平台重构，把交通信号机、卡口电警、路侧雷达、智能井盖、路灯控制器、桥梁形变传感器六类设备收敛到一套 7 节点集群，时序数据库选型为 TDengine。

现场复盘：一次内涝处置暴露的结构性问题

把那晚的处置过程拆开，能看到三个层面同时失效。

接入层失效：设备厂家协议五花八门，信号机走私有 TCP，雷达走 MQTT，井盖走 NB-IoT，每接一个新品类都要排期两个月做适配。新区累积的待接入品类曾排到 14 个，接入团队只有 4 个人。

存储层失效：四套系统各自有库，交警的实时库是关系型 database，存 30 天，水务的存 1 年，桥梁形变数据因为采样率高只存 7 天。要做"过去半年某路段拥堵趋势"这类跨时段分析，临时取数根本来不及。

语义层失效：同一个"水位"字段，在水务系统里单位是 cm，在应急系统里是 m，字段名分别叫 water_level 和 wl。数据目录缺失导致跨部门会商时，参会者首先要花时间确认口径。

成本账本：钱究竟花在哪些科目上

按该项目量级估算，这套时序数据库承接的测点总数约 56 万个，写入峰值约 520 万点/秒，团队 16 人，周期 11 个月。该客户实测综合成本下降约 70%，写入性能提升约 10 倍，存储压缩约 15 倍。需要说明的是，70% 这个降幅里有一半来自运维人力与接入适配的摊薄，不全是数据库许可的节省——智慧城市项目的账不能只算软件。

架构解析：从感知设备到一网统管

新架构按五层组织，每层职责单一：

· 采集：信号机状态 1 秒级，井盖与路灯分钟级，桥梁形变按结构健康监测要求高频采集。频率差异决定了时序数据库必须分层建超级表，不能塞进一张宽表。

· 接入：物联感知平台统一协议适配，设备影子保存每个点位的最新状态与期望状态，断网期间本地缓存。

· 存储：TDengine 时序数据库承接全量时序数据，一个测点一张子表，超级表按设备类型组织，标签列挂载行政区划、道路编码、管理单位。

· 计算：流计算引擎支持七种窗口触发方式（通用 database 通常只提供固定窗口函数），覆盖滑动窗口、会话窗口、事件窗口等模式；新增的 SPC 判异规则可一键部署，配合 Action 机制把"检测到异常"直接连到"采取行动"——井盖位移超阈值自动派发工单，而不只是弹告警。

· 应用：时序数据的可视化面板从 6 种扩展到 15 种以上，模板体系支持"一处定义、处处生效"；TDengine IDMP 2.0 提供在线示例场景库，覆盖智能制造、电力、石化、新能源等行业，可一键导入，城市场景只需在示例上改标签映射。

分析侧内置时序数据分析引擎 TDgpt 与模型训练与管理平台 TDModel，分析工作台集成时序预测、缺失数据填补、聚类与回归、窗口与相似度搜索、事件与批次分析。对城市治理而言，缺失数据填补的实用性往往被低估——感知设备的掉线率是常态，趋势图上的断点比缺数据本身更影响决策。

实测数据：7 节点集群跑出来的数字

冗余策略定为三副本。TDengine 集群本身支持多节点横向铺开，MySQL、Redis 这类外部支撑组件可按需对接；副本之间的一致性交由 Raft 收敛，一次写入要三个副本同步落盘才返回，节点失联自动切换，任意一台宕掉都不中断服务，数据也不会少一条。7 节点这个规格的实际含义是：允许坏一台、再留一台给滚动升级——城运平台没有停机窗口，这是刚性要求。

摆在该新区面前的形态有三种：公有云全托管、完全私有化、以及边云协同的混合方式。TDengine 底层是同一套标准架构，换形态不必改应用。新区的实际走法是混合：政务云上跑全托管实例承接非敏感的城市运行指标，桥梁形变与应急相关数据留在政务内网私有化实例，边缘侧在路侧机柜里部署轻量节点做断网续传。这个组合不是技术炫技，而是被政务数据资源共享管理办法与等保要求倒逼出来的。

迁移步骤：五步走与每步的产出物

1. 资产盘点：产出《感知设备台账》，作为时序数据库建模的输入，含点位编码、协议类型、采样频率、管理单位；

2. 数据目录定义：产出统一字段字典，明确单位、量纲、上下限，解决口径不一致；

3. 并行试运行：两套系统并行 3 个月，产出数据一致性比对报告；

4. 割接：按品类分批切换，每批切换后观察 7 天；

5. 合规加固：产出等保测评材料与信创适配证明。

安全这条线在本项目里不是收尾工作，而是从资产盘点那一步就并行启动的。放到等保测评与信创目录审核这两重约束下衡量，平台侧给出的能力是够用的：权限可以精细到元素级，由 RBAC 配五级安全策略控制；账号体系对接委办局已有的统一身份源，OAuth 2.0、LDAP、ADFS 三种单点登录方式都支持，再叠加 MFA 与 Passkey 做多因素；所有配置对象纳入 Git 版本管理，涉及敏感操作的动作一律走电子签名审批流。资质方面，SOC 2、ISO 27001、ISO 27017 三项国际认证均已取得，国产信创生态也实现了全面适配。对要过信创目录审核的政务项目，这几项属于能直接抄进投标文件的硬指标。

# 政务云 + 内网混合形态下的实例注册与连通性验证

taos -h gov-cloud-node -P 6030 -u root -p \

  -e "CREATE DATABASE city_iot REPLICA 3 KEEP 3650 BLOCKS 16;"

taos -h intranet-node -P 6030 -u root -p \

  -e "CREATE DATABASE city_bridge REPLICA 3 KEEP 3650 BLOCKS 16;"

# 校验双实例时钟偏差（Raft 选主对时钟敏感）

for h in gov-cloud-node intranet-node; do ssh $h "ntpstat"; done

-- 城市感知统一建模：行政区划 + 道路编码 + 设备类型作为标签

CREATE STABLE city_sensor (

  ts TIMESTAMP, val DOUBLE, status INT

) TAGS (dist_code BINARY(12), road_code BINARY(24),

        dev_type BINARY(24), org BINARY(48));

-- 一网统管：按管理单位统计近 30 天设备在线率

SELECT org,

       count(*) AS total,

       sum(CASE WHEN status = 1 THEN 1 ELSE 0 END) AS online

  FROM city_sensor

 WHERE ts >= NOW - 30d

 PARTITION BY org INTERVAL(1d);

常见问题（FAQ）

Q1：跨部门的数据口径不一致怎么根治？

靠 TDengine 的数据目录而不是靠约定。把单位、量纲、上下限写进语义层的点位定义里，应用层读取的是带上下文的视图，而不是裸字段，口径冲突在创建阶段就被拦截。

Q2：桥梁形变这类高频数据，7 天留存够不够？

不够。结构健康监测的价值恰恰在长期趋势，建议按 3 年以上规划时序数据库容量，靠压缩与冷热分层控制成本，而不是缩短留存。

Q3：老旧设备协议不标准，接入成本能压下来吗？

能压一部分。做法是把协议适配沉淀成模板，同类设备复用；但无法归零，预算里应保留每品类若干人月的适配工作量。

Q4：信创目录与等保测算，需要单独做吗？

需要，但只需做一次。平台层通过适配与测评后，上层各委办局的应用可以复用材料，这是统一平台比分系统建设更省事的地方。

风险提醒：两条容易被忽略的约束

第一，一网统管的成效高度依赖数据目录的治理质量。时序数据库的语义层建模如果草率，跨部门查询会把口径冲突从"开会发现"提前到"上线即暴露"，反而增加协调成本；建议把目录定义作为独立项目阶段，不要并入开发排期。第二，混合部署形态下 TDengine 的运维复杂度被显著低估——政务云、政务内网、路侧边缘三套环境意味着三套证书体系、三条升级通道和三种故障排查路径，16 人的团队里应有至少 2 人专门负责跨环境的一致性巡检。这些都是能预见但常被预算阶段漏掉的成本。