📚 课程目录第4章数据采集与存储

数据采集与存储：常见日志系统、数据格式、ETL流程归纳总结

数据是模型训练的燃料，这话一点都不夸张。我早期做过一个安全分析项目，发现模型精度始终上不去，查到最后居然是日志采集阶段丢了30%的字段。从那以后，我就特别重视数据采集这一环——说白了，后面所有工作都建立在这个基础上。今天我们来聊聊日志系统、数据格式，还有ETL的那些事。

企业里的日志源五花八门：Web服务器、数据库、防火墙、操作系统、容器平台……要统一采集和存储，就得靠专门的日志系统。我用过几套，各有特点，先看个表对比一下核心差异。

日志系统	核心组件	适用场景	我遇到的坑
ELK Stack	Elasticsearch + Logstash + Kibana	中小规模、快速搭建、全文检索	Logstash 内存消耗大，建议用 Filebeat 替代采集端
EFK Stack	Elasticsearch + Fluentd + Kibana	Kubernetes 环境、流式处理	Fluentd 插件生态稍弱，但性能稳定
Splunk	Splunk Universal Forwarder + Indexer	安全运营（SOC）、合规审计、付费企业	许可证按数据量计费，随便乱采成本爆炸
Graylog	Graylog Server + Elasticsearch + MongoDB	中等规模、需要告警和流式搜索	MongoDB 版本升级容易导致兼容问题

我个人习惯在小团队项目里先用 EFK，因为 Fluentd 的配置更贴近容器化部署。如果要做大规模集中式日志管理，我建议直接上 Splunk——虽然贵，但它的字段提取和搜索语法是真的好用。

日志采集到手，首先得考虑用什么格式存。纯文本虽然人类可读，但解析效率低、压缩率差。在访问模式异常检测场景里，我们经常要处理百亿级别的日志行，格式选错，ETL 阶段就卡死了。

下面是我在项目中常用到的几种数据格式，以及它们的核心指标对比。

格式	Schema 支持	压缩比	读写性能	典型场景
JSON	无强制	差	写快读慢	小规模、开发调试
CSV	表头行	中	快	批量导入、传统工具对接
Parquet	强类型	高（列式存储）	极快（列裁剪）	Spark 分析、PyTorch 训练
Avro	强类型 + Schema Evolution	高	快（压缩 + 序列化）	Kafka 消息、流式处理
ORC	强类型	更高	极快	Hive、Presto

你会发现，JSON 虽然灵活，但在大规模场景下就是灾难。我记得有一次用 JSON 存储数亿条日志，单文件 200GB，后来换成 Parquet，同样数据压到 15GB，查询速度还快了 10 倍。

我的建议：如果你做实时特征管道，用 Avro（配合 Confluent Schema Registry）；如果做离线批量训练，用 Parquet。别在 JSON/CSV 上纠结太久。

ETL（Extract, Transform, Load）是数据工程的老三样，但在异常检测场景里，转换这一步尤其关键。你想想看，原始日志里可能混杂着敏感信息、冗余字段、格式错误……不处理干净，模型学出来的全是噪声。

下面是我总结的 ETL 标准步骤，每个步骤我都吃过亏。

我曾经因为跳过了清洗步骤，直接把原始日志喂给模型，结果训练出来的模型老是误报——后来发现是某台服务器时钟漂移，日志时间戳全错位了。嗯，教训深刻。

时间字段统一性：所有日志系统必须强制使用 UTC 时间，并记录时区偏移。我曾经对接过不同时区的日志源，一天内时间差导致模型窗口计算全乱套。

采样率 vs 误报：如果日志量太大（比如 10Gbps 流量），HDFS 存不下，很多人会随机采样。但异常往往是长尾事件，采样会把小概率事件丢掉。我的做法是先做轻量级过滤（扔掉正常 GET 请求），再对可疑记录做全量保留。

关于 Schema 演化：日志格式会变（比如新加了一个用户字段）。Avro 可以向后兼容，Parquet 不行。如果你做流式管道，优先用 Avro + Schema Registry。

你看，整个 ETL 流程可以拆成两条线：实时流处理 + 离线批处理。我个人习惯在做模型原型时先用离线批处理，跑通后再把实时分支加上。别一上来就搞流式，调试成本太高。

数据采集与存储不是最花哨的部分，但它是整个异常检测系统的地基。地基建不好，模型再强也白搭。我的经验就是：选择适合规模的日志系统、使用列式存储格式、把 ETL 分成清洗-转换-聚合三步走。对了，别忘了加监控——哪天采集管道断了，你不会希望模型用旧数据训三天才发现问题。