第3章固定间隔降采样

3、固定间隔降采样：固定时间窗口采样、固定行数采样、优缺点分析与适用场景

好，咱们接着聊降采样。前面讲了随机采样和分层采样，这两种方法各有各的用处。但说实话，在我日常处理日志的工作中，固定间隔降采样才是用得最多的。为什么？因为它简单、可控、好理解。

你想想看，很多时候我们并不需要「随机」的感觉，我们需要的是「每隔一段时间拿一条」或者「每 N 行拿一条」。这种确定性，在排查问题时特别有用。我记得有一次线上告警，我按时间窗口采样后，能清晰地看到每 5 分钟的系统状态变化——要是用随机采样，反而会漏掉关键的时间点。

这个方法说白了就是：每隔固定的时间长度，取一条日志。比如每 10 秒取一条，或者每 5 分钟取一条。

它的核心逻辑很简单：

# 伪代码示例
采样间隔 = 10 秒
上次采样时间 = 第一条日志的时间

遍历每条日志：
    如果当前时间 - 上次采样时间 >= 采样间隔：
        保留这条日志
        更新上次采样时间 = 当前时间
    否则：
        丢弃这条日志

我在项目中遇到过一种情况：某个微服务每秒产生 2000 条日志，磁盘一天就爆了。后来我用了固定时间窗口采样，每 5 秒保留一条，数据量直接降到原来的 1/10000。而且因为采样点是均匀分布的，做趋势分析时效果特别好。

重要提示：时间窗口采样最怕的是「时间戳抖动」。如果日志产生的时间戳本身就不准（比如服务器时钟不同步），那采样出来的数据可能会集中在某个时间段，失去代表性。

这个更直接——每 N 行日志取一行。比如每 100 行取第 1 行，或者每 1000 行取第 1 行。

代码实现几乎不用动脑子：

# 伪代码示例
采样步长 = 100
行号计数器 = 0

遍历每条日志：
    行号计数器 += 1
    如果 行号计数器 % 采样步长 == 1：
        保留这条日志
    否则：
        丢弃这条日志

嗯，这里要注意：固定行数采样有个隐藏的坑。如果日志的写入频率不稳定——比如白天流量大、晚上流量小——那白天采样的数据密度会远高于晚上。你想想看，白天每 100 行可能只间隔 0.1 秒，晚上每 100 行可能间隔 10 秒。这样采样出来的数据，时间分布是不均匀的。

避坑指南：我曾经在一个电商大促项目中用了固定行数采样，结果发现采样数据里全是高峰期的日志，低峰期的数据几乎没被采到。后来我改成时间窗口采样，才解决了这个问题。所以，如果你的日志流量波动很大，慎用固定行数采样。

我整理了一张对比表，方便你快速决策：

我个人习惯这样选：

做监控和告警时，我首选固定时间窗口采样。因为监控需要看到「时间维度上的变化」，比如 CPU 使用率每 1 分钟的变化趋势。固定行数采样在这种场景下会失真。
做日志归档时，我倾向于固定行数采样。因为归档需要严格控制数据量，你不能让归档文件忽大忽小。固定行数采样能保证「每 1000 行存 1 行」，存储量是确定的。
做故障排查时，我建议两种方法结合用。先用时间窗口采样缩小范围，再用行数采样做精细定位。我在一次数据库死锁排查中就是这么干的——先用 10 秒窗口采样找到问题时间段，再用每 10 行取 1 行的方式看详细日志。

小技巧：如果你用的是 ELK 或 Loki 这类日志系统，它们通常内置了降采样功能。比如 Elasticsearch 的 rollup 特性就支持固定时间窗口聚合。但要注意，这些工具默认用的是「聚合」而非「采样」，两者有本质区别——聚合会丢失原始数据，采样会保留原始数据。

下面这张图展示了固定间隔降采样的两种方式及其决策路径：

最后说点实在的。如果你刚开始做日志降采样，我建议先从固定时间窗口采样入手。原因很简单：时间维度是日志最重要的维度，丢了时间均匀性，很多分析就做不了。

等你的系统稳定了，再根据实际需求引入固定行数采样。比如有些合规要求必须保留一定比例的原始日志，这时候固定行数采样就派上用场了。

嗯，这两种方法不是互斥的。我在一个项目中同时用了两种：线上实时查询用时间窗口采样，离线归档用行数采样。各取所长，效果很好。

公众号:蓝海资料掘金营，微信deep3321