数据面试：如何设计 OpenTelemetry 指数直方图管道并控制成本？

题目

为多区域服务设计延迟指标管道：SDK 产生 OpenTelemetry ExponentialHistogram，Collector 进行聚合，后端写入 Prometheus 原生直方图。请说明数据语义、降级和成本控制。

场景与约束

延迟范围从微秒到数分钟，服务有高基数标签。部分后端只支持经典桶，网络可能丢批，查询需要 p50、p95 和跨区域聚合。指标不能暴露租户隐私，也不能无限增加时间序列。

核心考点

考察指数边界、scale、正负桶、zero count、count/sum 与 temporality 的理解，以及跨进程合并的可交换性。OpenTelemetry 指数直方图用指数公式压缩桶边界，在相近大小下覆盖高动态范围；Prometheus 原生直方图可映射该模型，但转换和查询必须保留语义。

参考解法

SDK 只记录业务维度允许的标签和原始观测，Collector 按服务、区域和固定时间窗合并同 schema 数据。对不支持原生直方图的后端，显式转换为经典桶并记录精度损失。限制 scale、桶数、标签集合和每租户预算；超限时降采样或拒绝新标签，而不是静默截断。

关键细节

合并前检查 temporality、aggregation temporality、schema、正负桶和时间范围；不同 schema 不能直接拼接。查询层对 p95 使用直方图分位数近似，并在面板显示样本量、误差和降级标记。对丢批使用批序号和重试，避免把同一批重复计数。

常见误区

把指数桶当成精确分位数；把不同 temporality 相加；无界标签直接进入维度；将所有数据转换成最细 scale；忽略负值、零桶和重试重复；只看存储量不看查询放大。

评估标准

优秀答案能画出 SDK、Collector、远程写入、查询和预算控制边界，给出合并不变量、降级策略和 p95 误差说明。一般答案只说“用 histogram_quantile”，没有解释数据模型和成本。

追问

为什么不能直接合并不同 schema 的指数直方图？

桶索引与边界映射不同，直接相加会把观测放进错误区间；应先按规范重映射到兼容 schema，并记录精度变化。

如何处理累计 temporality 与 delta temporality 混用？

在 Collector 明确转换并保存每个流的起点与上次值；缺少连续性时丢弃不完整窗口或标记缺口，不能把累计值当 delta 重复相加。

什么时候应退回经典直方图？

当下游不支持原生格式、合规要求固定桶或查询生态无法解释指数桶时，选择有限经典桶并公开误差与成本，而不是让消费者猜测转换规则。