题目与使用场景
每个边缘节点持续产生延迟观测，节点先本地聚合，再把摘要合并到区域和全球层。查询需要 P50、P95、P99 以及时间窗口对比，不能保存全部原始值。系统要处理空窗口、热点租户、节点掉线、数据重放和版本升级，并向用户解释“近似分位数”的误差含义。
面试官考察什么
- 是否能区分分位数、排名误差、数值误差和尾部精度。
- 能否说明 KLL 的紧凑性与排名误差取舍，以及 t-digest 对尾部的经验性优势和限制。
- 是否理解摘要必须可合并、版本兼容、窗口边界和样本权重。
- 是否会用精确小样本、分层抽样和生产对照验证准确度，而不是只看单次输出。
作答前的澄清问题
先确认延迟分布是否重尾、P99 是否比中位数更重要、查询是否需要任意分位数、每个分组的最小样本量和允许误差。再确认窗口是固定还是滑动、摘要是否跨语言合并、是否需要回溯修正，以及存储预算和查询延迟目标。若业务要求强数学排名保证，不能只凭经验选择 t-digest。
30 秒回答框架
我会先定义可验收的误差：排名误差还是延迟值误差，以及 P99 的最小样本量。KLL 适合需要可解释的排名误差、固定内存和稳定合并的场景；t-digest 常用于尾部分位数，但误差依赖输入分布与实现约束，不能直接宣称有统一保证。两者都按窗口和分组生成可合并摘要，用精确保留样本做持续对照，再按结果选择参数和实现。
分步骤深入解答
- 先定义指标契约。 记录分位数、时间窗口、分组键、最小样本量、空值行为和误差预算。P99 在样本很少时不应被渲染成稳定结论。
- 明确两类误差。 排名误差描述估计值在排序中的位置偏差；数值误差描述返回延迟与真实分位点的距离。重尾分布中很小的排名误差可能对应很大的毫秒差。
- 评估 KLL。 KLL 是流式、可合并的分位数草图，参数影响保留空间与排名精度。它适合统一的排名误差预算，但要验证实现版本、序列化格式和合并顺序。
- 评估 t-digest。 t-digest 通过按分位位置控制簇大小，通常把更多精度放在尾部；其误差是经验性的，依赖输入分布、尺度函数、压缩和合并策略。不能把论文结果当成所有数据的保证。
- 设计分布式合并。 节点只上传摘要、样本数、最小值、最大值和版本。区域层合并摘要时检查参数一致；迟到数据进入所属窗口的新版本，不能静默覆盖已经发布的指标。
- 建立验证闭环。 对固定时间段保留精确采样或全量小窗口，比较 P50、P95、P99 的排名和数值误差，按区域、租户、流量规模和分布漂移分层。误差超标时报警、提高参数或回退到精确计算。
高质量示范回答
我不会先宣布某种草图“更准确”。先把 P50、P95、P99 的误差定义、最小样本量和窗口语义写入指标契约。KLL 适合需要可解释排名误差和稳定合并的通用分布；t-digest 可以把更多摘要空间放到尾部，适合 P99 这类查询，但 Apache DataSketches 明确指出其结果依赖输入数据，不能假设统一误差保证。
节点按窗口和分组生成摘要，携带参数、版本、样本数和边界值；区域层只合并兼容摘要，并把迟到数据写入新版本。系统保留精确采样作为对照，持续计算排名误差与毫秒误差，按分布和流量分层。只有在实际 P99 误差、空间和查询延迟都达标后才确定 KLL 或 t-digest，参数变化也必须通过回放和双写验证。依据包括 Apache DataSketches 的 KLL 与 quantiles 文档、t-digest 论文和 BigQuery 的近似分位数说明。
常见错误
- 只说“t-digest 对 P99 更准”，没有说明经验性误差、数据分布和合并方式。
- 把排名误差直接换算成固定毫秒误差，忽略重尾分布和业务量纲。
- 不携带参数与版本就跨节点合并，升级后把不同格式的摘要混在一起。
- 把迟到数据覆盖已发布窗口，导致仪表板同一时间点反复变化却无法追溯。
- 只用单个总体样本评估，漏掉小租户、低流量区域和分布漂移导致的尾部失真。
追问及应对
为什么 P99 的排名误差可能仍然不可接受？
如果延迟分布在尾部陡增，排名相差很小的两个点可能相差数百毫秒。必须同时报告排名误差和业务单位的数值误差，并设置最小样本量。
合并顺序会影响结果吗？
摘要应设计为可合并，但具体实现仍要验证合并顺序、压缩时机和序列化精度。用固定分片重排回放，比较不同树形合并与单机聚合的差异，超出预算就固定实现和版本。
什么时候直接保存原始值更合理？
当分组数量小、窗口短、合规允许且精确查询成本低时，原始值或精确排序更简单。草图的价值来自数据规模、分组数或保留期限让精确方案不可行，而不是为了追求复杂度。