NRQL percentile()の改善

テレメトリでは、パーセンタイルは多くのアプリケーションで使用される重要な統計的測定です。しかし、大規模なデータセットを扱う人にとっては難題でもあります。" というのも、パーセンタイルを計算する標準的な方法は、データをソートする必要があるため、技術的にも"高価なものとなっています。

新しいpercentile()関数は、最小限のコストで、任意の大規模なデータ セットで動作します。ロングテールディストリビューションにも最適です。その相対エラーの一貫性は、0% から 100% までのパーセンタイルに対して全面的に保証されています。

ユーザーは、新しいアルゴリズムを取得するために何もする必要はありません。すべてのpercentile()呼び出しは、それを使用して自動的に実行されます。しかし、新しいpercentile()関数がどのように開発されたか、および以前に使用された方法よりも優れていることについて詳しく知りたい場合は、New Relic の変更点と理論的根拠を深く掘り下げて読んでください。

エラーの種類と報告データへの影響

最近まで、New Relic は Quantiles over Data Streams で説明されている方法に頼っていました。An Experimental Study で説明されている方法を採用していました。この方法は順位誤差を利用しており、New Relic のパラメータを適用した場合、順位誤差は 0.3% となります。しかし、順位誤差は相対誤差や絶対誤差とは異なる方法で計算されているため、実際の値と報告された値の間には、望ましいものよりもはるかに大きなばらつきがある可能性があります。

さまざまなエラーの種類の影響をよりよく理解するには、パーセンタイル計算のコンテキストでエラーの種類を詳しく調べると役立ちますpercentile(p) = x 。この表は、エラーの種類が報告された値の下限と上限にどのように影響するかを示しています。

表からわかるように、絶対誤差では、報告値が実際の値の±範囲内にあり、相対誤差では、報告値が実際の値の±パーセント内にあります。

ランクエラーの仕組みは少し異なりますので、具体的な例を挙げて説明します。あるデータセットの99パーセンタイルを要求し、報告された値が500で0.3%のランクエラーだった場合、報告された値がそのデータセットの98.7パーセンタイルと99.3パーセンタイルの範囲内にあることを意味します。

なぜこれが重要なのでしょうか。なぜなら、ランクエラーは、値 x ではなく、パーセンタイル p に対して計算されるため、報告された値が実際の値に特に近いという保証はないからです。ロングテールのテレメトリ分布では、実際の値と報告された値の差が実際には非常に大きくなることがあります。例えば、98.7パーセンタイルに対応する値が1000で、99.3パーセンタイルに対応する値が2000の場合、1000と2000の間で報告された値は、0.3%のランクエラーの仕様を満たしており、かなり大きな誤差が生じています。

この例からわかるように、旧来の方法の精度は、値がパーセンタイル内でどれだけ変化するかに依存します。この方法は、中央値(50%)と90%までは通常適切ですが、99%以上のロングテール分布ではしばしば不足します。

パーセンタイル計算をより正確に

2020 年 7 月、New Relic は、対数スケールの等幅ヒストグラム ファミリとして知られる独自のアルゴリズムを使用するpercentile()を計算する新しい方法を展開しました。このファミリの他のメソッドと同様に、相対エラー保証が提供されます。

つまり、パーセンタイルが1％、99％、99.99％のいずれであっても、報告される値は実際の値の3％以内であることが保証されているのです。これは特にロングテールのトラッキングに適しています。どのようなパーセンタイルを求めても、同じ3％の相対誤差が保たれます。

コントラスト比と相対誤差

コントラスト比は、入力データセット中の最大の数値を、入力データセット中のゼロではない最小の数値で割って算出します。入力に負の数がある場合、コントラスト比は正の数の集合と負の数の集合の絶対値に対して別々に計算されます。最終的なコントラスト比は、正の数と負の数のコントラスト比の大きい方となる。データセットのコントラストが高ければ、相対誤差も大きくなる。

データ処理の観点から"のコストがかかる" の計算を抑制するために、新しいアルゴリズムではヒストグラムのバケット数を制限しています。コントラスト比が1,000～100万のバケット内のデータセットでは、相対誤差が約3%となっています。これでほとんどのお客様のユースケースをカバーできるはずです。下の表は、コントラスト比が1,000以下と100万以上の範囲で、相対誤差にどのような影響があるかを示したもので、スケールとしては、コントラスト比が表現できる時間の長さを示しています。

負の数とゼロ

新しい手法は、正の数、ゼロ、負の数が混在していても対象となります。負の数の相対誤差は、絶対値に基づいて定義されます。コントラストの計算にゼロは含まれません。

安定した測定

新方式では、安定した測定結果が得られます。測定されたデータセットの変化が誤差の範囲内であれば、このメソッドは同じ数値を返します。これは、ユーザーに明確なシグナルを提供します。数値が変化しなければ、測定可能な変化はありません。数値が変化すれば、測定可能な変化があることになります。

一方、従来の方法では、データセットに統計的に有意な変化がない場合でも、異なる数値が返されることがありました。返された数字の違いが測定可能な変化であるかどうかを判断するのは、ユーザーの責任です。その差が誤差よりも大きい場合にのみ、変化は重大なものとなります。

相対誤差の表示

percentile()呼び出しの相対エラーは、 relativeErrorフィールドを介して NRQL クエリの JSON 結果で返されます。グラフィック UI を使用している場合、結果のメタデータを表示するには、JSON 形式に切り替える必要があります。

以下は、3.125%の相対誤差を示す結果メタデータの例です。

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

結果検証

新しい方法の精度を検証するには、 histogram() NRQL 関数を実行して分布の全体像を取得します。ヒストグラムを見ると、報告されたパーセンタイルが妥当かどうかがわかります。たとえば、報告された 99% パーセンタイルを超える母集団が予想される 1% に近いかどうかを視覚的に推定できます。null属性を持つデータ セットに対してパーセンタイル クエリを実行する場合は注意してください。これらのNULL行はパーセンタイル関数では無視されますが、パーセンテージ関数では総母集団としてカウントされます。パーセンタイル クエリのwhereフィルターも検証クエリにコピーする必要があります。

パーセンタイルの値とその相対的な誤差を正確に確認するには、以下の方法があります（正の数を想定）。

報告された値を r とし、真の値を t とします。すると、相対誤差 e は次のように定義できます。

e = absolute(r - t) / t

上の式を使って、 r の範囲を t で表し、次に t の範囲を r で表すと以下のようになります。

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

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

パーセンタイル クエリから報告されたrとeを使用して、以下のようなpercentage()クエリを使用してtの下限と上限を計算できます。これは、 percentage()関数が近似を使用しないために可能です。常に正確な結果を返します。

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

この例では、188 がwallClockTimeの 90% の報告されたパーセンタイルです。相対誤差は .03125 です。返されるクエリ結果は次のとおりです。

lower: 89.54, upper: 90.23

その結果、確かに90％が範囲内に収まっていることがわかりました。言い換えれば、要求された90%パーセンタイルは誤差の範囲内です。これにより、報告された値の正確性が確認されました。