[Athena] Target Response Time의 윈저화 최댓값(Winsorization Maximum) 구하기
목적
극단적인 값에 민감한 평균과 표준 편차에 대하여 극한값의 영향을 줄임으로써 통계로써 유의미한 해석을 할 수 있도록 해주는 것을 목표로 한다. 일반적으로 원저화 평균 혹은 절사 평균을 통해 인사이트를 얻기도 하나, 본 글에서는 상위 n% 값을 제외한 다음으로 가장 큰값을 구하는 것을 목표로 두었다.
Goal: 특정 시간대에 대하여 ELB Target Response Time 값 상위 n% 집합에 대한 최댓값을 구하기.
개요
일반적으로 실험계획법 통계에서 상위 n% 값을 제외하고 통계를 내는 절사평균(Trimmed Mean) 방법이 존재한다. 데이터의 양 끝에서 일정 비율의 극단값을 제거하고 남은 데이터의 평균을 계산하는 방식이며, Cloudwatch에서는 이러한 분석에 대한 인사이트를 제공하도록 절삭평균에 대한 메트릭을 별도로 제공한다.
그러나, Cloudwatch에서 제공해주는 정보는 평균에 대한 정보이며 최댓값에 대한 정보는 확인할 수 없다. 그렇다면 상위 n%를 제외한 집합의 최댓값을 어떻게 산출할까?
Dataset이 작다면 정렬해서 값을 구하는 것은 어렵지 않으나, 대규모 데이터에 대하여 분석을 진행해야 하는 경우 일일이 모든 데이터를 정렬하여 정확한 값을 산출하는데 있어 더 많은 컴퓨팅 자원과 시간이 소요되어진다.
해결방안
AWS에서 제공하는 Athena 서비스는 Trino(Presto Engine) 기반으로 설계되었다. Trino 에서는 approx_percentile 함수를 제공하며 이를 통해 상위 n%에 대한 값에 대한 근삿값을 추론해낼 수 있다.
approx_percentile(x, percentages) → array<[same as x]>
Returns the approximate percentile for all input values of x at each of the specified percentages. Each element of the percentages array must be between zero and one, and the array must be constant for all input rows.
[+] https://trino.io/docs/current/functions/aggregate.html#approximate-aggregate-functions
Athena Engine3 경우, approx_percentile 함수는 T-Digest 근사화 알고리즘을 기반으로 설계되었다. 빅데이터 분석을 진행해야 하는 경우, 일일이 모든 데이터를 정렬하여 정확한 값을 산출하는 것보다, 근사화 알고리즘을 통해 정답에 가까운 숫자를 추론하는 것이 자원 및 비용적으로 효율적이다.
TDigest 알고리즘 주요 특징
(1) 아주 크거나 작은 (1st, 99th) 양 극단의 Percentile 값일 수록 정확도가 높다. 즉, 아웃라이어를 찾는데 유리한 특징을 지닌다.
(2) 데이터 값들의 집합이 작을 수록 정확도는 높아진다.
참고로 T-Digest 근사화 알고리즘에 대한 자세한 내용은 아래 사이트 링크에서 확인할 수 있다.
[+] https://arxiv.org/abs/1902.04023
그렇다면 이제 approx_percentile 함수를 이용하여 상위 n% 집합에 대한 최댓값에 대한 근삿값을 산출해보고 정확도는 얼마나 되는지 확인해보자. Athena 쿼리를 통해 ELB Access Log에서 확인할 수 있는 target_response_time들에 대하여 확인을 해볼 것이다.
실험계획
근삿값의 정확성을 확인해볼 수 있는 방법은 다음과 같은 방법으로 확인을 진행해 볼 것이다. 만약 근삿값 아래 분포되어 있는 데이터 개수가 전체 데이터 집합의 99%의 개수이라면 신뢰할 수 있는 알고리즘이다.
예를 들어 100만개의 데이터 집합에서 근삿값 아래 분포되어 있는 데이터 갯수가 99만개 근처일 경우 해당 근삿값은 신뢰할 수 있다고 할 수 있다.
Step 1. 전체 데이터셋 수량 확인
SELECT time, target_processing_time, request_url
FROM "table_name"
WHERE time >= '2024-02-08T15:00:00.000'
AND time <= '2024-02-12T15:00:00.000'
AND elb_status_code = 200
ORDER BY target_processing_time DESC;
Step 2. 윈저화 최댓값(Winsorized Maximum Value) 추출
SELECT
APPROX_PERCENTILE(target_processing_time, 0.99) AS p99_target_processing_time
FROM "table_name"
WHERE time >= 'start_time'
AND time <= 'end_time'
AND elb_status_code = 200
Step 3. 근삿값 아래 분포되어 있는 데이터 개수 확인
SELECT time, target_processing_time, request_url
FROM "table_name"
WHERE time >= 'start_time'
AND time <= 'end_time'
AND elb_status_code = 200
AND target_processing_time <= {p99_target_processing_time}
ORDER BY target_processing_time DESC;
실험결과
실험1. 8200만 개 데이터셋
Step 1. 전체 데이터셋 수량: 82,112,936 개 (82,112,936 * 0.99 = 81,291,806.64)
Step 2. 윈저화 최댓값(Winsorized Maximum Value) 추출결과: 0.5979797441556057 (쿼리시간 33초 소요)
Step 3. 최댓값 미만 데이터 분포수량 확인결과: 81,326,529 개 (쿼리 소요시간 4분 18초)
82,112,936 * 0.99 = 81,291,806.64 이다. Step 3에서 확인한 결과가 81,326,529이며 오차는 약 0.04%이다.
계산식: ( 81,291,806.64 - 81,326,529) / 81,291,806.64
실험 2. 2400만개 데이터셋
Step 1. 전체 데이터셋 수량: 24,848,052 개 (24,848,052 * 0.99 = 24,599,571.48)
Step 2. 윈저화 최댓값(Winsorized Maximum Value) 추출결과: 0.20319607619635877 (쿼리시간 14.9초 소요)
Step 3. 최댓값 미만 데이터 분포수량 확인결과: 24,612,050 개 (쿼리 소요시간 4분 18초)
24,848,052 * 0.99 = 24,599,571.48 이다. Step 3에서 확인한 결과가 24,612,050 이며 오차는 약 0.05%이다.
시사점
1. 실험 천만개 단위의 데이터 셋에 대한 분석 결과 매우 낮은 오차범위(e-2) 단위로 값에 근접한 것을 확인할 수 있으며 t-digest 기반 approx_percentile 함수는 신뢰할 수 있는 정보를 제공한다.
2. 쿼리시간 또한 오름차순으로 정렬을 진행하게되는경우 쿼리 시간은 (178초). approx_percentile 함수 계산 시간(33초)과 굉장히 많은 차이가 난다. (약 6배 차이)
Reference
[+] https://docs.aws.amazon.com/ko_kr/athena/latest/ug/functions.html#functions-env3
[+] https://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/Statistics-definitions.html
[+] https://elecs.tistory.com/351
'Observability > Athena' 카테고리의 다른 글
[Athena] ALB Access Log 를 이용한 국가별 트래픽 비중 확인하기 (0) | 2024.06.23 |
---|---|
[Athena] [쿼리튜닝] LIKE 절 vs RegEX 패턴 쿼리 속도비교 실험 (0) | 2024.04.07 |
댓글