2. 制造时序数据平台现状评估

迁移与扩容不是从“换一套新平台”开始，而是从“把现状说清楚”开始。制造时序数据平台的现状评估，核心是回答五个问题：数据从哪里来、以多快速度来、总量和增速有多大、现在存在哪里、被谁以什么方式查询。只有这五个维度都量化，后续的容量规划、分片设计、迁移窗口和回滚方案才有依据。本节按这五个维度展开，并给出可落地的瓶颈识别方法。

一、数据源类型：先分类，再定采集通道

制造现场的数据源通常可分为四类。第一类是设备侧控制器，如 PLC、CNC、机器人控制器，通过 OPC UA、Modbus TCP、S7 等协议暴露寄存器或节点；第二类是边缘采集网关，它把多个设备协议归一化后以 MQTT、Kafka 或 HTTP 上报；第三类是 SCADA/DCS/ historians 等既有系统，往往通过数据库接口或文件导出；第四类是 MES、QMS、WMS 等业务系统，产生的是工单、批次、检验结果等事件型数据，与设备测点通过时间戳和批次号关联。

分类的意义在于：不同数据源的采集频率、时间精度、断线补传能力和数据质量差异很大。例如 PLC 周期扫描数据时间戳常由网关打点，存在毫秒级抖动；而 MES 事件时间通常是业务时间，可能滞后数分钟。评估时要为每类源记录：协议、测点数量、单点字段结构、时间戳来源、是否支持批量订阅、断网缓存时长。这些字段直接决定后续接入层的并发模型和乱序处理策略。

二、采集频率与数据量级：用公式估算，而不是凭感觉

采集频率决定写入压力，数据量级决定存储与扩容规模。评估时应按“测点 × 频率 × 字段宽度”估算。示例：某车间有 1200 个测点，平均采集周期 1 秒，每条记录包含时间戳、测点 ID、值、质量码，序列化后约 60 字节，则单车间日增原始数据约为 1200 × 86400 × 60 B ≈ 6.2 GB/天。若全厂有 8 个类似车间，日增约 50 GB，年增约 18 TB（未计副本与索引）。

实际评估还要区分三类频率：高频波形类（如振动，可达 10 kHz 以上）、中频过程类（1 s～10 s）、低频状态类（分钟级或事件触发）。高频数据往往只保留短周期原始值，长期存聚合值；中低频数据则全量保留。评估表应至少包含：数据源、测点数量、采集周期、单条字节数、日增量、保留策略、副本数。这样得到的“逻辑总量”和“物理总量”才能用于磁盘与分片规划。

三、存储引擎与查询模式：现状决定迁移代价

现有存储引擎常见组合是：关系库（MySQL/PostgreSQL）存配置与事件、时序库（InfluxDB、TimescaleDB、TDengine）存测点、对象存储或文件库存历史归档。评估时要记录每个引擎的版本、部署形态（单机/集群）、分片或分区键、压缩方式、副本数、当前磁盘使用率和写入延迟。

查询模式则决定索引与预聚合设计。制造场景的典型查询包括：按设备+时间范围查原始曲线、按班次/工单聚合统计、按阈值查异常区间、按批次追溯关联多源数据。评估时应统计近 30 天慢查询的 SQL/查询语句、平均耗时、扫描行数、命中索引情况，并区分点查、范围查、聚合查、关联查的占比。若范围聚合查询占比高而现有引擎缺少降采样或连续查询能力，迁移后必须补上预聚合层。

四、瓶颈识别：用四类证据交叉验证

瓶颈识别不能只看“系统慢”，而要分侧取证。写入侧重点看写入延迟 P99、消息队列积压量、丢点率、磁盘 IOPS 饱和度；查询侧重点看慢查询 TOP N、扫描行数与返回行数之比、并发查询排队时长；存储侧重点看磁盘使用率与增速、压缩比、冷热数据是否分层、分片是否倾斜；资源侧重点看 CPU、内存、网络、GC 停顿、连接数和副本同步延迟。

一个可操作的判断路径是：先确认写入是否稳定，若写入延迟随测点增加线性上升且队列持续积压，说明写入通道或存储写入能力已达上限；若写入正常但查询变慢，则检查是否缺少时间+设备联合索引、是否每次查询都全表扫描、聚合是否在原始数据上直接计算。示例判断：某平台写入 P99 从 20 ms 升至 180 ms，同时 Kafka 消费滞后从 0 增至 40 万条，磁盘 util 长期高于 90%，可判定为存储写入瓶颈，而非查询瓶颈。

五、评估成果：形成可执行的基线表

评估结束后应输出一份现状基线表，至少包含：数据源清单（协议、测点数、频率）、日增/年增数据量、现有存储引擎与使用率、TOP 慢查询及耗时、已识别瓶颈及证据、迁移优先级。这份表是后续容量规划、分片设计和迁移窗口安排的输入。没有量化基线的迁移，往往会在切换后才发现写入或查询能力不足，导致回滚成本远高于前期评估成本。