第三篇　压缩与采样

日志收上来之后，账单就来了：日均千万条日志，原文一天近 100 GB，网络、磁盘、对象存储全都按字节收费。好在日志天生有两个特点——内容重复度极高，且绝大多数日志没人看。前者意味着压缩能大幅瘦身，后者意味着采样能理直气壮地少存。这两件事做得好，成本能降一个数量级；做不好，要么压缩吃光 CPU，要么采样把排查现场丢了。

本篇按「压缩 → 采样 → 分词索引 → 滚动归档」的顺序展开：先比较 LZ4 与 Zstd 的取舍，再看全量与哈希采样怎么选，接着让日志可检索，最后把归档按时间与大小切干净。云产品侧涉及对象存储 COS 的存储类型选择与日志服务 CLS 的检索能力，性价比方案可参考 腾讯云 AI 数据处理平台 ADP 特惠。

本篇路线

篇章关系

第二篇解决了「收得上来」，本篇解决「存得起、找得到」：压缩与采样决定存储与带宽成本，分词索引决定检索能力，滚动归档决定冷数据的去向。第四篇再谈落盘与崩溃恢复。分布式中类似的「压一压、少存点」思路，可对照 Go 即时通讯实战 的消息分发章节。

延伸阅读

• 压缩算法的取舍，见下一节 3.1。
• 采样与降级，见 3.2。
• 检索与分词，见 3.3。
• 冷数据归档，见 对象存储与 Go 实战。