第三章 日志传输与存储：从源头到仓库的每一步
日志从业务服务器生成，到最终被我们分析，中间要经历两段路：传输和存储。这两步要是没走好，后面做的所有模型都是空中楼阁。我见过太多团队花了几周调检测算法，结果发现数据在传输过程中就丢了一成——白忙一场。
这一章，咱们就聊聊日志怎么安全、高效地到达存储层，以及存储层该用什么来扛。
3.1 传输协议：选对工具，少踩一半坑
日志传输离不开网络协议。常用就三种：TCP、UDP、HTTP。它们各有各的脾气，说白了就是可靠性、速度、复杂度的权衡。
| 协议 | 可靠传输 | 吞吐量 | 适用场景 | 常见问题 |
|---|---|---|---|---|
| TCP | ✅ 有ACK，自动重传 | 中（受窗口大小影响） | 对丢失敏感的核心审计日志 | 连接断开时可能阻塞写入端 |
| UDP | ❌ 无确认，可能丢包 | 高（无握手开销） | 量极大但允许微量丢失的访问日志 | 网络拥塞时丢包率会飙升 |
| HTTP (REST / gRPC) | ✅ 可依赖HTTP状态码 | 低（每个请求都有头部开销） | 跨公网或需要认证的火墙 | 建立连接成本高，不适合高频小包 |
我个人习惯：内网传输用 TCP 做兜底，但在日志量超过 10万条/秒 时，我会把非关键日志切到 UDP 上，再在接收端做“以时间窗口补齐”的补偿逻辑。
我曾经踩过一个大坑：用 HTTP 批量推送审计日志到远程中心，结果业务高峰期请求失败率达到 8%。后来排查发现是默认的 HTTP 连接池没调大，每个 worker 都在等上一个响应。换了 gRPC 长连接才解决。
3.2 存储方案：没有银弹，只有取舍
日志到了存储层，问题才真正开始。你想想看，一周就能攒几个 TB，怎么存、怎么查、怎么赔钱？我建议先问自己三个问题：
- 查询延迟要求多高？（实时？离线？）
- 写入峰值多少？（突发流量扛得住吗？）
- 数据生命周期多长？（冷数据要不要挪走？）
下面三个方案，是我在多个项目里都折腾过的。
ELK（Elasticsearch + Logstash + Kibana）
ELK 在日志领域是当之无愧的“熟面孔”。它的倒排索引让全文搜索飞快，适合 IAM 异常、SQL 注入等需要模糊匹配的场景。但 ES 的写入瓶颈在索引合并，单节点每天也就写入 2-3 TB 顶天了。
ClickHouse
列式存储 + 超强聚合，这才是为审计分析量身定做的。我负责过一个用户行为异常检测项目，原本用 ES 跑一个时间范围 + 用户 ID 的聚合查询要 5 秒，换 ClickHouse 后降到了 200 毫秒。不过它的短板是不适合单条检索和频繁更新。
HDFS（Hadoop Distributed File System）
HDFS 说白了就是“便宜又大碗”。海量日志一股脑往里写，做批处理分析非常合适。但你要指望它实时 API 查询——醒醒，那是给 MapReduce 和 Spark 离线跑准备的。
| 特性 | ELK | ClickHouse | HDFS + Hive/Spark |
|---|---|---|---|
| 写入吞吐 | ≈ 100 MB/s（单机） | ≈ 200-500 MB/s（单机） | ≈ 1 GB/s（集群线性扩展） |
| 查询延迟 | 毫秒级（全文搜索） | 亚秒级（聚合） | 分钟级（需要启动任务） |
| 运维复杂度 | 中等（需要监控 JVM、分片） | 低（只有一个进程） | 高（组件多，配置繁琐） |
| 适用数据量 | TB 级（太多要冷热分离） | PB 级 | PB 级以上 |
| 典型使用场景 | 实时光告警、安全事件回溯 | 实时聚合指标、异常检测特征计算 | 长期审计归档、合规报表 |
我建议的分层方案：实时检测用 ClickHouse 做热存储（保留最近 7 天），全量历史数据放入 HDFS 做冷归档。至于 ES——我会把它作为入口的“快速搜索层”，仅索引最近 1 天的关键字段，避免过度写压。
3.3 数据压缩与归档：省空间就是省钱
日志存储的账单很大一部分来自磁盘。压缩率直接决定了你要买多少块硬盘。我接触过的项目里，大部分团队只用默认的 gzip，其实有更好的选择。
| 算法 | 压缩率（典型值） | 压缩速度 | 解压速度 | 适用场景 |
|---|---|---|---|---|
| gzip | 4:1 ~ 6:1（文本） | 慢（约 50 MB/s） | 中等 | 离线归档，对压缩率要求高 |
| Snappy | 2:1 ~ 3:1 | 极快（≈ 250 MB/s） | 快 | 实时传输和内存缓冲 |
| LZ4 | 2:1 ~ 3:1 | 极快（≈ 500 MB/s） | 极快 | 延迟敏感的管道 |
| Zstd (level 3) | 3:1 ~ 5:1 | 快（≈ 150 MB/s） | 快 | 兼顾速度和压缩率的通用选择 |
我现在的默认组合：写入 ClickHouse 时用 LZ4（牺牲一点压缩率换写入速度），归档到 HDFS 时改用 Zstd level 3。这样热数据写入快，冷数据节省约 40% 的磁盘空间。
归档策略
日志不能永远留在一个池子里。我建议按时间滚雪球：
- 热层（0-7天）：ClickHouse 或 ES，不压缩或 LZ4 快速写入。
- 温层（7-90天）：压缩后搬到低成本对象存储（如 S3、MinIO），查询时解压。
- 冷层（90天以上）：用 Parquet + Zstd 压缩后扔到 HDFS 或永久归档，查询频率极低。
我曾经犯过的一个错误：以为压缩率越高越好，把审计日志全部用 gzip 最高级别压了之后再写到 HDFS。结果每次合规检查要拉一个月的数据，解压花了 3 个小时——没人受得了。后来切到 Zstd level 3，压缩率只降了 10%，解压时间缩短了 70%。
3.4 本章核心知识体系
下面这张图梳理了日志从产生到归档的完整路径，你可以看作是一张“防迷路地图”。
记住一个原则：在线系统不要企图存所有东西。把热数据放在 ClickHouse 或 ES 里伺候查询，冷数据压缩归档后扔进 HDFS。你真正需要快速访问的，可能只占全量日志的 5%。
本章提到的传输和存储方案，你可以在具体的项目里按需组合。没有万能方案，但有了这张图和表格里的对比，至少你能避开那些我看过的坑。