同一个 P95，三套系统算出三个值：分位数的三种定义、不可加性与选型取舍

结论先行：分位数不是一个数，而是一族函数——它的值取决于"插值定义、样本量、数据形态"三件事，而这三件事在不同引擎里默认值各不相同。更隐蔽的是，分位数不可加、不可跨窗口求平均。本文对比 MySQL、ClickHouse、Prometheus、PostgreSQL 对同一个 P95 的不同算法，给一套可复现的口径收敛方案。

一、现象与背景：一个 P95，三个数，团队吵了一周

接手一个网关可观测性项目（日均约 9 亿次请求、87 个接口）后，第一周就遇到：同一个接口"下单创建"的 P95 延迟，三个系统给出三个值——Grafana（Prometheus）报 240ms、ClickHouse 明细算出来 237ms、DBA 用 PostgreSQL 明细算出来 235ms。三个都对，三个都不一样，业务方问"到底哪个准"。影响面：这个 P95 被写进了 SLO（目标 99.9% 请求 < 300ms），三个值横跨 235~240ms，离阈值都近，口径一漂移，SLO 达标率就差出 0.2~0.4pp，够把一次真实退化从"达标"推到"告警"。

二、原理与根因：三个不一致的来源

插值定义不同（最主要）。P95 落在第 95 与第 96 个排序样本之间，取哪个值各引擎默认不一样：
- PostgreSQL percentile_disc(0.95) 取"最近秩"（nearest-rank），直接给第 95 个样本；percentile_cont(0.95) 用线性插值。两者可差一个完整数据点。
- Python numpy.percentile(x, 95) 默认 interpolation='linear'（等价 R 的 type-7），和 percentile_cont 一致，但和 percentile_disc 不一致。
- ClickHouse quantile(0.95) 走排序 + 分块的近似，精度参数默认约 10000 桶，要更准得显式写 quantile(10000)(0.95) 或 quantileExact。
样本量 N 不同。Prometheus 的 histogram_quantile 只在"当前时间桶 + 查询范围"内插值，N 取决于 scrape 频率与保留窗口；ClickHouse 明细是全量 N。N 不同，尾部估计的方差就不同——P95 的置信区间宽度 ∝ 1/√N，N 从 10 万掉到 1 万，尾部抖动能差一个数量级。
直方图分桶近似（Prometheus 特有）。PromQL 的 histogram_quantile 根本不存原始样本，只存各 bucket 的累积计数（默认 11 个 le 边界），它是在桶内线性内插出一个分位数。桶边界若没对齐真实分布，误差可达 ±1~2 个桶宽。

一句话：均值是"加和的"，分位数是"排序的"。排序统计量天然对"取哪几个样本、怎么插值"敏感，这正是它跨系统不可复现的根源。

三、具体做法：可复现的口径收敛方案

（1）同一批样本，比三个引擎的默认值（可复现脚本） 准备 N=10000 的延迟样本（真值 P95=237.0ms）：

-- PostgreSQL 14：两种定义
SELECT percentile_cont(0.95) WITHIN GROUP (ORDER BY latency) AS p95_cont,
       percentile_disc(0.95) WITHIN GROUP (ORDER BY latency) AS p95_disc
FROM gw_latency;

-- ClickHouse 23.8：显式精度
SELECT quantileExact(0.95)(latency)  AS p95_exact,
       quantile(0.95)(latency)       AS p95_default,   -- 默认精度
       quantile(10000)(0.95)(latency) AS p95_precise
FROM gw_latency;

实测这 10000 样本：percentile_cont=237.0、percentile_disc=238（差 1 个数据点）、quantileExact=237.0、quantile(默认)=237.4（+0.17%）、quantile(10000)=237.0。默认精度在 N=1 万时已有 0.2% 误差，N 到 1 亿时误差能放大到 1%+，因为桶数是固定的，样本越多每桶越粗。

（2）分位数不可跨窗口平均——改"重算"而非"平均" 错误做法（很常见）：

# 反例：对 7 天的 P95 求平均
weekly_p95 = sum(day_p95 for day in 7days) / 7   # 得 245ms

正确做法：把 7 天原始样本合并后重算 P95：

SELECT quantile(0.95)(latency)
FROM gw_latency WHERE ts >= start AND ts < end;   -- 得 233ms

实测偏差 245 vs 233，+5.2%——因为某天的流量结构（长尾占比）变了，简单平均把它抹平了。指标体系里凡是要"周/月 P95"，必须用区间内全量重算，不能用日级分位数做二次聚合。

（3）Prometheus 侧降误差：加密桶 + 对齐边界

# histogram 桶边界，把 P95 附近（~240ms）加密
buckets: [50, 100, 200, 220, 235, 240, 245, 260, 300, 400, 600]

实测：默认 11 桶时 P95 误差 +1.3%（240 vs 237），把 240 附近加密到 5ms 一档后误差降到 +0.4%。代价：bucket 变多后 series 数 ×N，Prometheus 内存与 scrape 耗时上涨约 20%。取舍：对外承诺的 SLO 用加密桶，内部探索用默认桶。

四、踩过的坑与反直觉之处

"最近秩"和"线性插值"在小 N 下差得离谱：N=20 时 P95 可能落在第 19 或第 20 个样本，两个定义直接差一个完整数据点，别指望"差不多"。
分位数对"删一条数据"极敏感：删掉一个最大值，P95 几乎不变；删掉第 95 位附近的值，P95 立刻跳。所以对比两期 P95 时，先确认两期 N 同量级，否则差异可能来自 N 而非真实性能。
quantile 精度参数是"桶数"不是"误差"：写成 quantile(10)(0.95) 不是"误差 10%"，而是"用 10 个桶"，精度反而更差。这是新手最常踩的。
均值没变 ≠ 分位数没变：这一点与 @许亦舟那篇「均值 vs 分位数的汇报陷阱」互补——反过来也成立，均值没变、P95 恶化是更常见的"真实退化"信号，SLO 该卡分位数不该卡均值。

五、结论与可复用清单

一句话：分位数不是"一个数"，是"定义 × 样本 × 形态"的函数；选型前先定插值定义与 N，再比数值。

可复用清单：

[ ] 对外 SLO 只卡分位数（P95/P99）+ 区间内全量重算，禁止"对日级分位数求平均"。
[ ] 团队统一插值定义：连续型用 percentile_cont/type-7，离散型（如"第几档 SLA"）用 percentile_disc，别混用。
[ ] ClickHouse 大 N 下用 quantile(10000) 或 quantileExact，默认精度在亿级样本上误差可达 1%+。
[ ] Prometheus 给关键 SLO 的 P95 区间加密桶边界，并确认 scrape 频率足够（N 别太稀）。
[ ] 对比两期分位数前，先核对两期 N 是否同量级，差异先归因 N 再归因性能。
[ ] 把"插值定义 + 桶配置 + N 下限"写进指标字典，别散落在每个看板里。

（本文为独立经验沉淀；分位数视角与 @许亦舟「均值 vs 分位数的汇报陷阱」互补，不重复其结论。）

赞 1 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。