数据采集与预处理：多源数据采集、清洗与特征工程
设备画像这件事，说白了就是给设备做「体检报告」。但报告好不好，全看原始数据靠不靠谱。我见过太多项目，算法模型调得再漂亮，数据源头一塌糊涂，最后全是白费功夫。这一章，咱们就聊聊怎么把那些乱七八糟的原始数据，变成能用的「干净料」。
多源数据采集：日志、指标、事件
设备的数据源，我习惯分成三大类。你想想看，一台设备从开机到报废，无非就是这三样东西在记录它的「一生」。
| 数据源类型 | 典型内容 | 采集方式 | 数据量级 |
|---|---|---|---|
| 日志（Log） | 系统日志、应用日志、操作日志 | Filebeat / Fluentd 实时采集 | GB ~ TB/天 |
| 指标（Metric） | CPU 使用率、内存、磁盘 IO、网络流量 | Prometheus / Telegraf 轮询拉取 | MB ~ GB/天 |
| 事件（Event） | 设备重启、告警触发、配置变更 | SNMP Trap / Webhook 推送 | KB ~ MB/天 |
我个人习惯，先把日志和指标分开存。日志用 Elasticsearch，指标用时序数据库。事件呢？我一般把它当成「触发信号」——事件一来，立刻去查对应时间窗口的日志和指标。这样查问题，效率高得多。
数据清洗与标准化
数据采回来了，但问题也来了。不同厂商的设备，日志格式五花八门。有的用 JSON，有的用纯文本，还有的用自定义二进制。指标的单位也不统一——有的用毫秒，有的用微秒，有的干脆不写单位。
嗯，这里要注意。清洗这一步，我一般分三步走：
- 格式统一：所有日志转成 JSON 结构。字段名统一用下划线命名法，比如
device_id、timestamp、log_level。 - 缺失值处理：数值型指标缺了，用前一个时间点的值填充。文本型字段缺了，直接标记为
unknown。千万别用 0 去填充缺失的 CPU 使用率——那会误导模型。 - 异常值过滤：比如 CPU 使用率突然变成 999%，这明显是采集器抽风了。我一般设个合理范围，超出范围的直接丢弃。
标准化这块，我推荐用 Z-score 或 Min-Max 归一化。具体用哪个？看场景。如果数据分布比较正态，用 Z-score。如果数据范围固定（比如 CPU 使用率 0~100%），用 Min-Max 更直观。
# 一个简单的标准化示例（Python 伪代码）
import numpy as np
def z_score_normalize(series):
mean = np.mean(series)
std = np.std(series)
return (series - mean) / std
def min_max_normalize(series):
min_val = np.min(series)
max_val = np.max(series)
return (series - min_val) / (max_val - min_val)
特征工程初步
数据洗干净了，接下来就是特征工程。这一步，说白了就是「从原始数据里挖金子」。我一般从三个维度入手：
- 统计特征：均值、方差、最大值、最小值、分位数。这些能反映设备的「稳态」和「波动」。
- 时序特征：滑动窗口均值、差分值、自相关系数。这些能捕捉设备状态的变化趋势。
- 业务特征：设备型号、固件版本、部署位置。这些是「元信息」，但往往对异常定位有奇效。
举个例子。我做过一个硬盘故障预测的项目。原始指标只有 IOPS 和延迟。后来我加了一个特征：「延迟的 5 分钟滑动窗口标准差」。结果模型准确率直接提升了 15%。为什么？因为硬盘快坏的时候，延迟会变得忽高忽低，这个波动特征比原始值更敏感。
下面这张图，是我做设备画像时常用的数据采集与预处理流程。你可以看看数据是怎么一步步从原始状态变成可用特征的。
你看，整个流程其实不复杂。但每一步都有坑。我刚开始做的时候，总觉得采集工具越全越好，结果数据量太大，存储成本直接爆了。后来学乖了——先搞清楚你要分析什么问题，再决定采什么数据。数据不是越多越好，够用就行。
特征工程这块，我再多说一句。很多人喜欢用自动化特征生成工具，一键生成几百个特征。但说实话，我很少这么干。为什么？因为那些工具不懂业务。你想想看，一个不懂设备原理的工具，怎么可能造出「硬盘延迟波动标准差」这种特征？好的特征，一定来自对业务的理解。