历史数据基础：数据采集原理、数据存储方式、数据压缩技术
各位工程师，咱们今天聊聊历史数据。说白了，SCADA系统最值钱的东西，不是那些花花绿绿的实时画面，而是沉淀下来的历史数据。你想想看，没有历史数据，你怎么做趋势分析？怎么做故障回溯？怎么做优化决策？
我个人习惯把历史数据比作「黑匣子」。飞机出事要查黑匣子，产线出问题也得查历史数据。我见过太多项目，实时监控做得花里胡哨，历史数据存储却一塌糊涂。结果一出事，啥也查不到。嗯，今天咱们就把这块硬骨头啃下来。
数据采集原理：从现场到数据库的第一公里
数据采集，说白了就是「把现场信号变成电脑能认的数字」。这个过程看似简单，坑却不少。
我在一个水处理项目里遇到过：PLC采集的压力值，到了上位机就变成了乱码。查了两天，最后发现是数据采集的扫描周期和PLC的扫描周期没对齐。你想想看，PLC每100ms更新一次，上位机每200ms采一次，数据能不乱吗？
数据采集的核心参数，我整理了一张表：
| 参数 | 说明 | 我的建议 |
|---|---|---|
| 扫描周期 | 采集一次数据的时间间隔 | 一般设为PLC周期的1.5-2倍 |
| 死区设置 | 变化多少才记录 | 模拟量设0.5%-1%，开关量不设 |
| 采集方式 | 轮询还是中断 | 关键点位用中断，普通点位用轮询 |
| 数据校验 | CRC、奇偶校验等 | Modbus RTU必须开CRC校验 |
数据存储方式：选对路子，少走弯路
数据存到哪儿？怎么存？这问题我纠结了好几年。目前主流的有三种方式：
1. 关系型数据库（如SQL Server、MySQL）
适合结构化数据，查询灵活。但说实话，处理海量时序数据时性能堪忧。我做过测试：一张表存了1亿条记录，查一周的数据要等30秒。客户当场就炸了。
2. 时序数据库（如InfluxDB、TimescaleDB）
专门为时间序列数据设计的。压缩率高，查询快。我现在的新项目基本都用这个。举个例子：同样1亿条数据，InfluxDB查询只要2秒。
3. 文件存储（如CSV、二进制文件）
简单粗暴，适合小系统或离线分析。但并发读写是个大问题。我见过一个项目用CSV存数据，结果两个进程同时写，文件直接损坏了。
我个人习惯这样选型：
- 点数少于1000，用关系型数据库就行
- 点数在1000-10000，上时序数据库
- 点数超过10000，考虑分布式时序数据库
数据压缩技术：省空间就是省钱
数据压缩，说白了就是「用更少的空间存更多的数据」。但压缩不是瞎压，得保证精度。我见过有人为了省空间，把浮点数转成整数存，结果精度丢了，趋势图全是锯齿。
常用的压缩技术有三种：
1. 旋转门压缩（Swinging Door）
这是工业界最常用的算法。原理很简单：设定一个误差范围，只要数据在这个范围内波动，就不记录。只有超出范围才记录。
// 旋转门压缩伪代码
float last_value = 0;
float last_time = 0;
float epsilon = 0.5; // 误差范围
void compress(float value, float time) {
if (abs(value - last_value) > epsilon) {
save_to_db(last_time, last_value);
last_value = value;
last_time = time;
}
}我在一个化工项目里用过这个算法。原本每天要存500MB数据，用了旋转门压缩后，降到50MB。压缩比10:1，而且趋势图完全看不出区别。
2. 死区压缩
和旋转门类似，但更简单。设定一个死区值，变化量小于死区就不记录。适合变化缓慢的信号，比如液位、温度。
3. 趋势压缩
记录数据的变化趋势，而不是具体数值。比如「上升」、「下降」、「平稳」。适合做长期趋势分析，但精度较低。
知识体系总览
下面这张图，是我自己总结的历史数据知识体系。你把它存下来，做项目时对照着看，能少踩很多坑。
嗯，以上就是历史数据基础的核心内容。数据采集是源头，存储是载体，压缩是手段。三者缺一不可。我见过太多项目，只重视实时监控，忽略了历史数据。结果系统上线半年后，客户要查历史趋势，发现数据要么丢了，要么查不动。那时候再改，成本就高了去了。
记住一句话：好的历史数据系统，是「采得全、存得住、查得快」。你把这三点做好了，后面的趋势分析就是水到渠成的事。