题干与适用场景
这是数据工程与可观测性场景中的近似统计题。事件以流式方式到达，节点内存有限，结果要按窗口输出并支持跨节点合并。重点不是背诵某个库的 API，而是解释近似分位数的目标、误差边界与可验证性。
面试官考察什么
- 能否先区分精确分位数、固定桶直方图和可合并 sketch 的约束。
- 能否说明 t-digest 为什么把更多摘要容量放在分布两端。
- 能否处理重复值、极端值、窗口边界、合并顺序与空输入。
- 能否用离线真值和误差指标验证近似结果，而不是只报告一个看似精确的数字。
回答前需要澄清的问题
先确认查询分位点是否集中在尾部、数据是否有权重、窗口是否滚动、是否需要跨机器合并、允许的绝对或相对误差是多少，以及结果是否用于告警、计费或合规。若必须给出审计级精确值，近似 sketch 不能替代原始排序或可证明的精确结构。
30 秒回答框架
我会选择可合并的 t-digest，而不是保存全部样本。它把排序后的值压缩成带权重的簇，并让尾部簇更小，因此 P95/P99 的分辨率高于中部。每个节点独立更新，窗口结束时合并摘要，再查询分位数。压缩参数决定大小与误差；我会用保留的离线样本计算精确分位数，按分位点和窗口测量误差，并在极端值、重复值和不同合并顺序下做回归测试。
分步骤深入解答
1. 先定义精确目标与替代方案
精确分位数需要保留并排序所有样本，内存随事件数增长。固定桶直方图便于聚合，但桶边界决定误差，尾部可能很粗。t-digest 保存有序簇及其权重，适合流式更新与摘要合并；它仍是近似结果，不能把输出格式化成精确百分位。
2. 理解簇和尺度函数
一个簇包含中心值与权重，权重表示它覆盖的样本数。压缩时要求簇的权重上限随其分位位置变化：靠近零和一的尾部允许的簇更小，中间区域可用更大的簇。尺度函数和压缩参数共同决定摘要大小与尾部精度，不能只说“压缩越高越准”而不说明内存代价。
3. 设计分布式合并路径
每个分片先按时间窗口维护自己的 digest，窗口关闭或达到大小阈值后输出摘要。合并时把簇按中心排序并重新压缩，而不是简单平均各节点的 P99；百分位不是线性可平均的统计量。窗口标识、采样权重和版本要随摘要传递，防止跨窗口或重复消费。
4. 处理边界和数值问题
空窗口应返回明确的缺失状态；所有值相同或重复率很高时，权重会集中在少数簇，测试应确认查询仍稳定。极端大值、NaN、负延迟和单位混用必须在写入前拒绝或规范化。滚动窗口要定义迟到事件落在哪个窗口，以及摘要过期后如何释放。
5. 建立误差验证与报警规则
从生产流量抽取可控样本并保留原始值，离线排序得到真值，再比较 P50、P95、P99 的绝对误差、相对误差和超标比例。测试不同数据分布、样本量、分片数、合并树形和合并顺序；若摘要大小或误差超过预算，降低窗口粒度、调整压缩参数或改用更合适的 sketch。告警应同时展示样本量与误差估计，避免小样本尾部误报。
6. 何时不用 t-digest
需要精确审计、样本量小或查询分位点固定且桶边界稳定时，排序或直方图更简单。数据有严格可证明误差预算时，可比较 KLL 等 quantile sketch。若分布需要长时间回放，保留可重建的原始或分层采样数据，不能把一个压缩摘要当作永久事实源。
高质量示范回答
我会先确定 P95/P99 的误差预算、窗口和是否需要跨节点合并。t-digest 用带权重的有序簇表示分布，并在两端使用更小的簇，因此适合延迟这类关心尾部的指标。每个分片独立更新，窗口结束后合并簇并重新压缩，绝不平均各分片的 P99。写入时清洗 NaN、单位和异常值，记录窗口与权重。验证时保留抽样原始值，计算精确分位数，按分布、分片数和合并顺序比较误差；若超过预算，就调整压缩与窗口或换用直方图、KLL 或精确排序。
常见错误
- 平均各机器的 P99 → 分位数不可线性平均 → 合并摘要或原始样本后再查询。
- 把 t-digest 当精确结果 → 压缩会丢失排序细节 → 明确误差预算并输出样本量。
- 只调大压缩参数 → 摘要变大且尾部收益不一定线性 → 用离线真值测量大小与误差曲线。
- 忽略迟到事件 → 窗口统计不可复现 → 定义水位线、迟到策略和摘要版本。
- 用小样本 P99 直接报警 → 尾部估计方差很大 → 同时设最小样本量和误差护栏。
追问及应对
为什么不能直接合并各节点的 P99？
P99 是非线性统计量，各节点样本量和分布可能不同。只合并 P99 会丢失中间排序信息；应合并可携带权重的摘要或原始样本。
合并顺序会影响结果吗？
近似摘要的压缩过程可能让结果有小幅差异。把合并实现为排序后统一压缩，固定版本与参数，并将不同合并树形纳入误差回归测试。
P99 误差突然升高，先改哪个参数？
先检查样本量、异常值、窗口迟到和合并是否重复，再观察摘要大小。只有确认是表示能力不足时，才提高尾部精度或降低窗口粒度，并用真值验证收益。
什么时候 KLL 更合适？
当需要更明确的秩误差保证、查询分位点较均匀且不特别偏向尾部时，可评估 KLL。选择应依据误差定义、合并特性、内存预算和实现成熟度，而不是只看单一 benchmark。