Améliorations apportées au percentile NRQL()

En télémétrie, le percentile est une mesure statistique importante avec de nombreuses applications. Cependant, cela représente également un défi pour ceux qui travaillent avec de grands ensembles de données. Cela est dû au fait que la méthode standard de calcul percentile est également techniquement « coûteuse » en raison de la nécessité de trier les données.

La nouvelle fonction percentile() fonctionne sur un ensemble de données arbitrairement grand, avec un coût minimal. Il est également excellent pour les distributions à longue traîne. Sa cohérence d’erreur relative est garantie sur l’ensemble du tableau pour les percentiles de 0 % à 100 %.

En tant qu'utilisateur, vous n'avez rien à faire pour obtenir le nouvel algorithme. Tous vos appels percentile() sont automatiquement exécutés en l'utilisant. Mais si vous souhaitez en savoir plus sur la manière dont la nouvelle fonction percentile() a été développée et sur la manière dont elle est supérieure à la méthode précédente utilisée, lisez la suite pour une analyse approfondie des changements et des justifications de New Relic.

Types d'erreurs et impacts sur les données rapportées

Jusqu'à récemment, New Relic s'appuyait sur la méthode décrite dans Quantiles over Data Streams: An Experimental Study. Cette méthode utilise une erreur de rang et, avec les paramètres de New Relic appliqués, génère une erreur de rang de 0,3 %. Mais comme l’erreur de rang est calculée différemment de l’erreur relative ou absolue, cela signifie qu’il peut y avoir une variation beaucoup plus grande entre les valeurs réelles et les valeurs rapportées que ce qui est souhaitable.

Pour mieux comprendre l’impact des différents types d’erreurs, il est utile d’examiner de plus près les types d’erreurs dans le contexte du calcul percentile percentile(p) = x. Le tableau montre comment le type d’erreur affecte les limites inférieures et supérieures de la valeur signalée.

Comme vous pouvez le voir dans le tableau, pour l'erreur absolue, la valeur signalée est dans la plage +/- de la valeur réelle, et pour l'erreur relative, la valeur signalée est dans la plage +/- pour cent de la valeur réelle.

L'erreur de rang fonctionne un peu différemment et est mieux décrite avec un exemple concret : si vous demandez le 99e percentile d'un ensemble de données et que la valeur rapportée est de 500 avec une erreur de rang de 0,3 %, cela signifie que la valeur rapportée est comprise entre 98,7 et 99,3 percentile pour l'ensemble de données.

Pourquoi est-ce important ? Car, comme l’erreur de rang est calculée par rapport au percentile p et non à la valeur x, rien ne garantit que la valeur rapportée sera particulièrement proche de la valeur réelle. Dans les distributions de télémétrie à longue traîne, la différence entre les valeurs réelles et les valeurs rapportées peut en fait être assez importante. Par exemple, lorsque la valeur correspondant au 98,7e percentile est 1 000, mais que la valeur correspondant au 99,3e percentile est 2 000, toute valeur rapportée entre 1 000 et 2 000 répond à la spécification d'erreur de rang de 0,3 %, créant une marge d'erreur assez importante.

Comme vous pouvez le voir dans l’exemple, la précision de l’ancienne méthode dépend de la variation de la valeur dans le percentile. Bien que cette méthode soit généralement adéquate pour la médiane (50 %) et jusqu’à 90 %, elle est souvent insuffisante pour la distribution à longue traîne supérieure à 99 %.

Rendre les calculs percentile plus précis

En juillet 2020, New Relic a déployé une nouvelle façon de calculer percentile() qui utilise un algorithme propriétaire dans ce que l'on appelle la famille d'histogrammes à largeur égale à échelle logarithmique. Comme d’autres méthodes de cette famille, elle offre une garantie d’erreur relative.

L'erreur relative typique de la nouvelle méthode pour la plupart des ensembles de données est d'environ 3 %. Cela signifie que, quel que soit le percentile demandé (1 %, 99 % ou 99,99 %), la valeur rapportée est garantie d'être dans les 3 % de la valeur réelle. Ceci est particulièrement utile pour le suivi à longue traîne. Quel que soit percentile demandé, la même erreur relative de 3 % s’applique.

Rapport de contraste et erreur relative

Les rapports de contraste sont calculés en divisant le plus grand nombre de l'ensemble de données d'entrée par le plus petit nombre différent de zéro de l'ensemble de données d'entrée. Si l'entrée comporte des nombres négatifs, le rapport de contraste est calculé séparément sur l'ensemble des nombres positifs et sur les valeurs absolues de l'ensemble des nombres négatifs. Le rapport de contraste final est le plus grand des rapports de contraste des nombres positifs et négatifs. Lorsque le contraste de l’ensemble de données est plus élevé, l’erreur relative est également plus élevée.

Pour contrôler le « coût » des calculs en termes de traitement des données, le nouvel algorithme limite le nombre de groupes d'histogrammes, avec une erreur relative d'environ 3 % pour l'ensemble de données compris entre 1 000 et 1 million de rapports de contraste. Cela devrait couvrir les cas d’utilisation pour la plupart des clients. Le tableau ci-dessous montre comment les plages de contraste inférieures à 1 000 et supérieures à 1 million ont un impact sur l’erreur relative et, pour l’échelle, la durée qu’un rapport de contraste peut représenter.

Nombres négatifs et zéro

La nouvelle méthode couvre tout mélange de nombres positifs, nuls et négatifs. L’erreur relative pour les nombres négatifs est définie sur la base de valeurs absolues. Le zéro est exclu du calcul de contraste.

Mesure stable

La nouvelle méthode renvoie une mesure stable. Lorsque les modifications dans l’ensemble de données mesuré se situent dans la marge d’erreur, la méthode renvoie le même nombre. Cela fournit un signal clair à l’utilisateur : si le nombre ne change pas, alors il n’y a pas de changement mesurable. Si le nombre change, il y a un changement mesurable.

En comparaison, l’ancienne méthode peut renvoyer un nombre différent même lorsqu’il n’y a pas de changement statistiquement significatif dans l’ensemble de données. Il incombe à l’utilisateur de déterminer si la différence entre les nombres renvoyés représente un changement mesurable. Un changement n’est significatif que lorsque la différence est supérieure à la marge d’erreur.

Affichage de l'erreur relative

L'erreur relative d'un appel percentile() est renvoyée dans les résultats JSON de la requête NRQL via le champ relativeError. Si vous utilisez une interface utilisateur graphique, vous devrez passer au format JSON pour voir les métadonnées du résultat.

Voici un exemple de métadonnées de résultat affichant une erreur relative de 3,125 %.

"contents": [
{
  "function": "percentile",
  "attribute": "wallClockTime",
  "relativeError": 0.03125,
  "thresholds": [
    50,
    99
  ]
}

Vérification des résultats

Pour vérifier l’exactitude de la nouvelle méthode, vous pouvez exécuter la fonction NRQL histogram() pour obtenir une image globale de la distribution. En regardant l’histogramme, vous pouvez dire si un percentile rapporté est logique. Par exemple, vous pouvez estimer visuellement si la population au-dessus d’un percentile de 99 % rapporté est proche du 1 % attendu. Soyez prudent lorsque vous exécutez une requête percentile sur un ensemble de données avec un attribut nul . Ces lignes nulles sont ignorées par la fonction percentile , mais comptées dans la population totale dans la fonction de pourcentage. Tout filtre where dans la requête percentile doit également être copié dans la requête de validation.

Pour une vérification précise d’une valeur percentile et de son erreur relative, vous pouvez utiliser la méthode suivante (en supposant des nombres positifs).

Que la valeur rapportée soit r et la vraie valeur t. L'erreur relative e peut alors être définie comme :

e = absolute(r - t) / t

En utilisant la formule ci-dessus, nous pouvons exprimer la plage de r en utilisant t, puis exprimer la plage de t en utilisant r comme ci-dessous :

r > t * (1 - e) => t < r / (1 - e)

r < t * (1 + e) => t > r / (1 + e)

En utilisant r et e rapportés à partir d'une requête percentile , nous pouvons calculer la limite inférieure et supérieure de t, en utilisant une requête percentage() comme ci-dessous. Cela est possible car la fonction percentage() n'utilise pas d'approximation. Il renvoie toujours le résultat exact.

FROM myEventType SELECT percentage(count(*), where wallClockTime < 188 / (1 + 0.03125)) 
AS 'lower', percentage(count(*), WHERE wallClockTime < 188 / (1 - .03125)) AS 'upper' 
WHERE wallClockTime is not null

Dans cet exemple, 188 est le percentile rapporté de wallClockTime à 90 %. L'erreur relative est de 0,03125. Le résultat de la requête renvoyé est :

lower: 89.54, upper: 90.23

Le résultat montre que 90 % se situent effectivement dans la fourchette. En d’autres termes, le percentile de 90 % demandé se situe dans la marge d’erreur. Cela vérifie l’exactitude de la valeur rapportée.