时序数据链路：采集 → 清洗 → 存储 → 查询（附 TDengine vs ClickHouse 双库基准）文章目录时序数据链路：采集 → 清洗 → 存储 → 查询（附 TDengine vs ClickHouse 双库基准）引言：影子只存"现在"，调度要的是"历史"一、先算容量账：你的平台每天写多少数据1.1 四本容量账，不只算写入量二、链路四段：每段的职责与防线2.1 脏数据的确定性分类：为什么先别急着上 ML三、存储引擎无关：TsdbWriter 接口四、双库基准与复跑方法聚合查询数据：降级为"演示"，附复跑方法资源消耗记录五、存储分层：不是所有数据都值得放 SSD六、MQTT 集群：从优化技巧到容量决策6.1 两招被低估的优化6.2 更根本的问题：我的 Broker 到底能接多少台6.3 分批上下线与连接风暴：小平台也会中招七、踩坑实录：一个 8 小时的时区偏差八、数据路由与下沉：点位进哪个库谁说了算九、选型结论：不是二选一，是按场景分层结语：存储底座就位，设备还差最后一环引言：影子只存"现在"，调度要的是"历史"前几篇完成了报文三级跳：协议字节 → 语义点值 → 影子最新态。但影子只回答"现在"，而 VPP 的核心算法全是历史驱动：光伏预测要过去一年出力曲线，基线核算要 N 个相似日负荷，响应时间测算要在遥测流里检索"指令后首次超阈值的时刻"（第 02 篇埋的伏笔，本篇兑现）。47241 第 8.4 条对这条链路有十字要求：真实、实时、完整、准确、可靠。本篇交付的是这条链路的存储底座——写入契约定死、双库适配、独立基准跑通；清洗路由、降采样与"接入 → 时序"的端到端串通属目标设计（见结语边界）。在此基础上回答架构选型问题：TDengine 还是 ClickHouse？——不引用 benchmark 报告，自己跑一遍。本篇给自己立的规矩：凡称"实测"的数字必须能指到仓库里的可复跑脚本与原始日志；指不到的，降级标注"演示/估算/待复测"。第四节你会看到这条规矩被用在了本篇自己身上。本篇主线见图 1：影子按序号保留最近上报，时序链路按设备时标留历史，两条支路分别处理同一批补传报文。图 1：目标链路示意，虚线表示尚未接通的连接；当前工程已提供双库存储适配与独立基准，网关到解释器、时序写入的端到端串通仍属目标设计。批