NRQL 백분위수() 개선

원격 분석에서 백분위수는 많은 응용 프로그램에서 중요한 통계 측정입니다. 그러나 이는 또한 대규모 데이터 세트로 작업하는 사람들에게 어려운 과제이기도 합니다. 백분위수를 계산하는 표준 방법도 데이터를 정렬해야 하기 때문에 기술적으로 "비싸"기 때문입니다.

새로운 percentile() 함수는 최소한의 비용으로 임의의 큰 데이터 세트에서 작동합니다. 롱테일 분포에도 탁월합니다. 상대적 오류 일관성은 0%에서 100% 사이의 백분위수에 대해 전반적으로 보장됩니다.

사용자는 새 알고리즘을 얻기 위해 아무 것도 할 필요가 없습니다. 모든 percentile() 호출은 이를 사용하여 자동으로 실행됩니다. 그러나 새로운 percentile() 기능이 어떻게 개발되었고 이전 방법보다 우수한지 자세히 알아보려면 New Relic의 변경 사항 및 근거에 대해 자세히 읽어보십시오.

보고된 데이터에 대한 오류 유형 및 영향

최근까지 New Relic은 Quantiles over Data Streams: An Experimental Study에 설명된 방법에 의존했습니다. 이 방법은 순위 오차를 사용하며 New Relic의 매개 변수를 적용하면 0.3% 순위 오차가 발생합니다. 그러나 순위 오류는 상대 또는 절대 오류와 다르게 계산되기 때문에 실제 값과 보고된 값 사이에 원하는 것보다 훨씬 더 넓은 편차가 있을 수 있습니다.

다양한 오류 유형의 영향을 더 잘 이해하려면 백분위수 계산 percentile(p) = x 의 맥락에서 오류 유형을 자세히 살펴보는 것이 좋습니다. 표는 오류 유형이 보고된 값의 하한 및 상한에 미치는 영향을 보여줍니다.

표에서 볼 수 있듯이 절대 오차의 경우 보고된 값이 실제 값의 +/- 범위 내에 있고 상대 오차의 경우 보고된 값이 실제 값의 +/- 퍼센트 이내입니다.

순위 오류는 약간 다르게 작동하며 구체적인 예를 통해 가장 잘 설명됩니다. 데이터 세트의 99번째 백분위수를 요청하고 보고된 값이 0.3% 순위 오류와 함께 500이면 보고된 값이 98.7 및 데이터 세트에 대한 99.3 백분위수.

이것이 왜 중요한가? 순위 오류는 값 x 가 아니라 백분위수 p 를 기준으로 계산되기 때문에 보고된 값이 실제 값에 특히 가깝다는 보장이 없기 때문입니다. 롱테일 원격 분석 분포에서 실제 값과 보고된 값의 차이는 실제로 상당히 클 수 있습니다. 예를 들어, 98.7 백분위수에 해당하는 값이 1000이지만 99.3 백분위수에 해당하는 값이 2000인 경우 1000에서 2000 사이에 보고된 모든 값은 0.3% 순위 오류 사양을 충족하므로 꽤 큰 오차 한계가 생성됩니다.

예에서 볼 수 있듯이 이전 방법의 정확도는 백분위수 내에서 값이 얼마나 변하는지에 따라 다릅니다. 이 방법은 일반적으로 중앙값(50%) 및 최대 90%에 적합하지만 99% 이상의 롱테일 분포에는 종종 부족합니다.

백분위수 계산을 더 정확하게 만들기

2020년 7월, New Relic은 로그 스케일 등폭 히스토그램 제품군으로 알려진 독점 알고리즘을 사용하는 새로운 percentile() 계산 방법을 출시했습니다. 이 제품군의 다른 메서드와 마찬가지로 상대 오류 보장을 제공합니다.

대부분의 데이터 세트에 대한 새 방법의 일반적인 상대 오류는 약 3%입니다. 즉, 1%, 99% 또는 99.99%를 요청하는 백분위수에 관계없이 보고된 값은 3% 이내로 보장됩니다. 실제 값. 이것은 롱테일 추적에 특히 좋습니다. 어떤 백분위수를 요구하든 동일한 3%의 상대 오차가 유지됩니다.

명암비 및 상대 오차

명암비는 입력 데이터 세트의 가장 큰 숫자를 입력 데이터 세트의 0이 아닌 가장 작은 숫자로 나누어 계산됩니다. 입력에 음수가 있는 경우 명암비는 양수 집합과 음수 집합의 절대값에 대해 별도로 계산됩니다. 최종 명암비는 양수와 음수의 명암비 중 큰 값입니다. 데이터 세트의 대비가 높을수록 상대 오차도 높아집니다.

데이터 처리 측면에서 계산이 얼마나 "비용이 많이 드는"지를 제어하기 위해 새 알고리즘은 히스토그램 버킷 수를 제한하며 1,000-100만 명암비 버킷 내의 데이터 세트에 대해 약 3%의 상대 오류를 사용합니다. 여기에는 대부분의 고객의 사용 사례가 포함되어야 합니다. 아래 표는 1,000 미만 및 100만 이상의 대비 범위가 상대 오류에 미치는 영향과 규모의 경우 대비 비율이 나타낼 수 있는 기간을 보여줍니다.

음수와 0

새로운 방법은 양수, 0 및 음수가 혼합된 모든 것을 다룹니다. 음수에 대한 상대 오차는 절대값을 기준으로 정의됩니다. 0은 대비 계산에서 제외됩니다.

안정적인 측정

새로운 방법은 안정적인 측정값을 반환합니다. 측정된 데이터 세트의 변경 사항이 오차 한계 내에 있는 경우 메서드는 동일한 숫자를 반환합니다. 이것은 사용자에게 명확한 신호를 제공합니다. 숫자가 변경되지 않으면 측정 가능한 변화가 없는 것입니다. 숫자가 바뀌면 측정 가능한 변화가 있습니다.

이에 비해 이전 방법은 데이터 세트에 통계적으로 유의미한 변화가 없는 경우에도 다른 숫자를 반환할 수 있습니다. 반환된 숫자의 차이가 측정 가능한 변화를 나타내는지 여부를 결정하는 부담은 사용자에게 있습니다. 차이가 오차 한계보다 큰 경우에만 변경이 중요합니다.

상대 오차 보기

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

위의 공식을 사용하여 t 를 사용하여 r 의 범위를 표현한 다음 r 을 사용하여 t 의 범위를 다음과 같이 표현할 수 있습니다.

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은 90%에서 wallClockTime 의 보고된 백분위수입니다. 상대 오차는 .03125입니다. 반환된 쿼리 결과는 다음과 같습니다.

lower: 89.54, upper: 90.23

결과는 90%가 실제로 범위 내에 있음을 보여줍니다. 즉, 요청된 90% 백분위수는 오차 범위 내에 있습니다. 이것은 보고된 값의 정확성을 검증합니다.