更多互联网精彩资讯、工作效率提升关注【飞鱼在浪屿】（日更新）

我们非常关心确保我们的网站和 API 调用在合理的时间内为用户返回结果；分析数据库中可能有数十亿行，但仍然希望确保该网站响应迅速且有用。

网站性能和业务结果之间存在直接相关性：如果用户不得不等待太久的结果，他们会感到无聊，从业务和客户忠诚度的角度来看，这显然是不达标的。为了了解网站的表现并找到改进方法，我们跟踪了 API 调用的时间，并将 API 调用响应时间用作关键指标。

监控API是一个常见的场景，一般都属于应用性能监控（APM）的范畴。

百分位数近似值对于处理大型时间序列数据集非常有用，因为它们提供了使用百分位数（而不是平均值或其他计数统计）的好处，同时仍然可以快速且节省空间地进行计算、可并行化。

从小学数学中忘记的事情：百分位数与平均值

可能在小学数学课上学到了平均值、中位数和众数，可能会定期迷失在“我学过一次并以为我知道，但实际上，我不知道”的云雾中。”

首先，让我们考虑如何定义百分位数和平均值。为了理解这一点，让我们从正态分布开始：

正态分布或高斯分布描述了许多真实世界的过程，这些过程落在给定值附近，并且找到离中心更远的值的概率会降低。正态分布的中位数、平均值和众数都相同，它们位于中心的虚线上。

正态分布是我们在思考统计时经常想到的；它是入门课程中最常用和最常用的一种。在正态分布中，中位数、平均值（也称为均值）和众数都是相同的，即使它们的定义不同。

该中值是中间值，其中一半的数据是在之上，另一半在之下。平均值被定义为SUM（值）/计数（值）。

当我们查看这样的曲线时，x 轴表示值，而 y 轴表示我们看到给定值的频率（即，y 轴上“更高”表示出现的次数更多更频繁）。

在正态分布中，我们看到一条以最频繁值为中心（虚线）的曲线，看到远离最频繁值（最频繁值是众数）的值的概率降低。正态分布是对称的，这意味着中心左侧和右侧的值出现的概率相同。

中位数或中间值也称为第 50 个百分位数（100 中的中间百分位数）。这是 50% 的数据小于该值，50% 大于该值（或等于该值）时的值。

在下图中，一半的数据在左边（蓝色阴影），一半在右边（紫色阴影），第 50 个百分位数直接位于中心。

这将引向百分位数：百分位数定义为数据的 x% 低于该值的值。

例如，如果我们称某事物为“第 10 个百分位数”，则表示 10% 的数据小于该值，而 90% 大于（或等于）该值。

第 90 个百分位数是其中 90% 的数据小于该值而 10% 大于该值：

要计算第 10 个百分位数，假设我们有 10,000 个值。我们取所有值，从大到小对它们进行排序，并确定第 1001 个值（其中 1000 或 10% 的值低于它），这将是我们的第 10 个百分位数。

我们之前注意到，中位数和平均值在正态分布中是相同的。这是因为正态分布是对称的。因此，值大于中位数的点的数量和小于的数量是完全平衡的。

换句话说，中位数的两边总是有相同数量的点，但平均值考虑了点的实际值。

为了使中位数和平均值相等，小于中位数和大于中位数的点必须具有相同的分布（即，必须有相同数量的点） .

为什么这很重要？ 正态分布中中位数和平均值相同的事实可能会引起一些混淆。

很容易忘记或没有意识到，只有中位数才能保证 50% 的值高于和的 50%，而平均值保证 50% 的加权值高于和低于 50%（即，平均值是质心，而中位数是中心）。

正态分布中的平均值和中位数是相同的，它们恰好将图形一分为二。但它们的计算方式不同，不代表相同的事物，并且在其他分布中也不一定相同。

但是，为了摆脱理论，让我们考虑现实世界中更常见的事情，例如广告分析公司工作中的 API 响应时间场景。

长尾、离群值和实际影响：为什么百分位数比平均值更能理解您的数据

我们研究了平均值和百分位数的不同之处——现在，我们将使用一个真实世界的场景来演示使用平均值而不是百分位数如何导致误报或错失机会。

为什么？平均值并不总是为您提供足够的信息来区分实际效果和异常值或噪声，而百分位数可以做得更好。

简而言之，使用平均值会对值的报告方式产生巨大（和负面）影响，而百分位数可以帮助您更接近“真相”。

如果您正在查看 API 响应时间之类的内容，您可能会看到如下所示的频率分布曲线：

API 响应时间的频率分布，峰值为 250 毫秒（所有图表均不按比例绘制，仅用于演示目的）。

在广告分析公司的目标是大部分 API 响应调用在半秒内完成，而且很多都比这短得多。当我们监控 API 响应时间时，我们试图了解的最重要的事情之一是用户如何受到代码更改的影响。

我们的大部分 API 调用都在不到半秒的时间内完成，但有些人使用该系统在很长一段时间内获取数据，或者有奇怪的配置，这导致着他们的仪表板响应速度较慢（尽管我们试图确保这些很少见！ ）。

得到的曲线类型的特征是长尾分布，其中我们在 250 ms 处有一个相对较大的尖峰，我们的很多值都在该尖峰之下，然后响应时间更长的数量呈指数减少。

我们之前讨论过对称曲线（如正态分布）如何，但长尾分布是不对称曲线。

这意味着最大值远大于中间值，而最小值与中间值相差不远。（在 API 监控案例中，您永远不会有一个 API 调用的响应时间少于 0 秒，但它们可以花费的多长时间没有限制）。

因此，长尾分布的平均值和中位数开始发散：

标有中值和平均值的 API 响应时间频率曲线。图表不按比例绘制，仅用于演示目的。

在这种情况下，平均值明显大于中位数，因为长尾中有足够多的“大”值使平均值更大。相反，在其他一些情况下，平均值可能小于中位数。

但是在这家广告分析公司，我们发现平均值并没有给我们足够的信息来区分我们的 API 如何响应软件更改的重要变化与仅影响少数人的噪音/异常值。

在一种情况下，我们对具有新查询的代码进行了更改。查询在暂存时运行良好，但生产系统中有更多数据。

一旦数据“热”（在内存中），它就会快速运行，但第一次运行速度非常慢。当查询投入生产时，大约 10% 的调用的响应时间超过一秒。

在我们的频率曲线中，大约 10% 的呼叫的响应时间超过一秒（但小于 10 秒）会导致频率曲线中出现一秒较小的驼峰，如下所示：

频率曲线显示了当 10% 的调用花费了 1 到 10 秒之间的中等时间时发生的偏移和额外的驼峰（图表仍未按比例）。

在这种情况下，平均值发生了很大变化，而中值略有变化，但受到的影响要小得多。

您可能认为平均值成为比中值更好的指标，因为它帮助我们识别问题（API 响应时间过长），并且我们可以设置警报以在平均值发生变化时发出通知。

让我们想象一下，我们已经这样做了，当平均值超过 1 秒时，人们会立即采取行动。

但是现在，我们有一些用户开始从我们的 UI 请求 15 年的数据……而这些 API 调用需要很长时间。这是因为 API 并不是真正构建来处理这种“标签外”使用的。

来自这些用户的几个电话轻松地将平均值在到 1s 阈值之上。

为什么？平均值可​能会受到像这样的异常值的显着影响，即使它们只影响我们的一小部分用户。平均值使用数据的总和，因此异常值的大小可能会产生巨大的影响，而中位数和其他百分位数则基于数据的排序。

我们的曲线有一些异常值，其中不到 1% 的 API 调用响应超过 100 秒（响应时间有一个中断，表示异常值会向右偏，否则，该图仍不按比例缩放） .

关键是平均值并没有给我们一个很好的方法来区分异常值和实际效果，并且当我们有长尾或不对称分布时可能会给出奇怪的结果。

为什么理解这一点很重要？

那么，在第一种情况下，我们有一个问题影响了我们 10% 的 API 调用，这可能是我们 10% 或更多的用户（它怎么会影响超过 10% 的用户？如果一个用户进行 10 个调用平均而言，10% 的 API 调用会受到影响，那么，平均而言，所有用户都会受到影响……或者至少是其中的很大一部分）。

我们希望对影响大量用户的此类紧急问题做出快速响应。我们建立了警报，甚至可能让我们的工程师在半夜醒来和/或恢复更改。

但第二种情况，即“标签外”用户行为或小错误对少数 API 调用有很大影响，则要温和得多。由于受这些异常值影响的用户相对较少，我们不想让我们的工程师在半夜醒来或恢复更改。（异常值对于识别和理解仍然很重要，无论是为了理解用户需求还是代码中的潜在错误，但它们通常不是紧急情况）。

我们可以使用多个百分位数来理解这种行为，而不是使用平均值。请记住，与平均值不同，百分位数依赖于数据的排序，而不是受数据量级的影响。如果我们使用第 90 个百分位数，我们知道10% 的用户的值（在我们的案例中为 API 响应时间）大于它。

让我们看看原始图中的第 90 个百分位数；它很好地捕捉了一些长尾行为：

我们的原始 API 响应时间图显示了第 90 个百分位数、中位数和平均值。图表不按比例。

当我们有一些由运行超长查询的少数用户或影响一小组查询的错误引起的异常值时，平均值会发生变化，但第 90 个百分位数几乎不受影响。

异常值会影响平均值，但不会影响第 90 个百分位数或中位数。

但是，当由于影响 10% 用户的问题而增加尾部时，我们看到 90% 向外移动非常显着——这使我们的团队能够得到通知并做出适当的响应：

但是，当影响超过 10% 的用户的响应产生“真实”效果时，第 90 个百分位数会发生显着变化（图未按比例绘制。）

这（让您更好地了解百分位数如何以及为什么可以帮助您识别大量用户受到影响的情况 - 但不会因为误报而给您带来负担，因为误报可能会叫醒工程师并使他们警报疲劳！