S4 Scan
Athena scan 비용 절감기
S3 data-lake Parquet를 실제 query가 읽는 layout으로 재최적화해 AWS Athena 및 Redshift Spectrum scan 청구액을 30–70% 절감합니다 — partition 및 row-group pruning, dictionary encoding, zstd, small-file compaction을 query result를 변경하지 않는 안전한 shadow-then-swap 방식으로 적용합니다.
S4 Scan은 Athena query history에서 어떤 column이 읽히고 어떤 predicate가 table을 filter하는지 학습한 뒤, underlying S3 Parquet를 해당 query가 원하는 physical layout으로 다시 작성합니다: hot column을 먼저 배치하고, filter 대상 column으로 sort해 row-group statistics가 prune할 수 있게 하며, low-cardinality column은 dictionary-encoded 처리하고, file은 효율적인 size로 compact하며, zstd로 압축합니다. Athena와 Redshift Spectrum은 S3에서 scan한 terabyte 단위로 과금하므로 더 작고 더 잘 prune되는 layout은 직접적이고 반복적인 청구 절감으로 이어집니다. 안전성이 제품의 핵심입니다 — source는 절대 덮어쓰지 않습니다.
해결하고자 하는 과제
Athena 및 Redshift Spectrum은 S3에서 실제로 읽은 바이트 수에 따라 비용을 청구합니다 (기본 $5/TB, 리전별로 상이). Parquet의 물리적 레이아웃이 쿼리의 액세스 패턴과 일치하지 않으면 각 쿼리는 반환하는 것보다 훨씬 많은 S3 데이터를 스캔하게 되며 — 매달 그 격차에 대한 비용을 지불해야 합니다. 요금은 스캔된 바이트 수에 비례하므로 물리적 레이아웃에 따라 비용이 좌우됩니다.
작동 원리
- 1
쿼리 이력에서 학습
Glue 카탈로그와 Athena 쿼리 이력(워크그룹 메트릭, CloudTrail)을 읽어 각 테이블이 실제로 읽는 컬럼과 필터링에 적용되는 조건자(predicate)를 파악합니다.
- 2
섀도에 작성 후 검증
최적화된 Parquet를 별도의 shadow 위치에 작성하고 값, NULL, decimal scale 및 timestamp timezone까지 쿼리 결과가 완전히 일치하는지 검증합니다.
- 3
Glue를 통한 스왑(롤백 포함)
검증을 통과한 후에만 Glue 테이블 위치를 다시 지정하며 — 데이터 이동이 아닌 카탈로그 포인터 이동 — 단일 롤백 명령으로 되돌릴 수 있습니다.
주요 특징
설계상 안전: 최적화된 데이터는 shadow 위치에 기록하고, 쿼리 결과가 동일한지(값, null, decimal scale, timestamp tz) 검증한 뒤 Glue catalog를 통해 swap합니다 — rollback은 단일 command로 가능합니다. source data는 in-place로 수정하지 않습니다.
commit 전에 절감액 확인: dry-run이 실제 table 기준 월간 dollar 절감액을 예측하고, 이를 pruning, dictionary + zstd, small-file compaction에 정직하게 귀속합니다.
lock-in도, babysitting도 없음: 출력은 표준 Athena-readable Parquet이며, AMI가 EventBridge schedule에 따라 재최적화하므로 절감 효과가 자동으로 누적됩니다.
포함 사항
- 쿼리 이력 분석: 과거 쿼리에서 hot 열, 자주 사용되는 predicates 및 파티션/정렬 키 후보를 집계하여 최적화 계획을 도출합니다.
- 파티션 및 row-group 프루닝: predicate 키를 기준으로 파티션을 재지정하여 파일 전체를 건너뛰고, 필터 열을 기준으로 정렬하여 min/max 통계를 통해 일치하지 않는 row-group을 건너뜁니다.
- Dictionary/RLE 인코딩 + zstd: 카디널리티가 낮은 열을 dictionary 인코딩하고 Athena에서 읽을 수 있는 표준 zstd로 재압축하여 예상 읽기 바이트를 줄입니다.
- 소형 파일 컴팩션: 다수의 작은 객체를 I/O 효율성과 더 나은 통계를 위해 적정 크기의 파일로 병합합니다.
- Shadow → 검증 → 스왑 및 단일 명령 롤백: 원본 데이터는 직접 수정되지 않으며, 전환은 오직 Glue 포인터 이동으로만 이루어집니다.
- Dry-run 금액 예측: 데이터 쓰기 없이 현재와 최적화 후의 스캔 바이트 및 월별 차액을 보고하며, 절감 효과를 파티션 프루ニング / row-group 프루ニング / dictionary+zstd / 컴팩션에 정직하게 배분합니다.
- EventBridge 스케줄에 따른 재최적화 및 lock-in 없는 표준 Athena 호환 Parquet 출력.
주요 활용 사례
SQL을 전혀 수정하지 않고 높은 Athena/Redshift Spectrum 스캔 비용을 줄이고 싶은 경우.
쿼리가 극히 일부의 열만 읽고 소수의 predicates로 필터링함에도 불구하고 파일 전체를 스캔하는 wide 테이블의 경우.
수많은 작은 Parquet 객체로 파편화되어 I/O 효율성과 통계 품질이 저하된 데이터 레이크의 경우.
データが書き換わり続けるため、EventBridge 스케줄을 통해 주기적으로 재최적화를 수행하려는 경우.
자주 묻는 질문
데이터가 손상되거나 쿼리 결과가 달라질 수 있습니까?
원본 데이터는 직접 수정되지 않습니다. 최적화된 데이터는 별도의 shadow 위치에 작성되며, 값, NULL, decimal scale, timestamp timezone, 중첩 유형(nested types)까지 결과가 완전히 동일한지 확인한 후에 Glue 포인터만 이동합니다. 검증에 실패하면 스왑을 진행하지 않고 shadow 데이터를 폐기하여 원본 데이터를 그대로 유지합니다. 스왑 후에도 단 하나의 명령어로 원본 위치를 복구할 수 있습니다.
독자적인 포맷에 lock-in 되지 않습니까?
아닙니다. 출력은 독자적인 코덱을 사용하지 않고 오직 표준 Athena 호환 Parquet(표준 zstd, dictionary/RLE) 형식으로만 생성됩니다. 언제든지 롤백할 수 있으며 최적화된 데이터는 일반적인 Athena 도구로 바로 읽을 수 있습니다.
S4 Scan은 무엇을 최적화해야 할지 어떻게 판단하나요?
Athena의 쿼리 이력을 학습합니다. 어떤 열을 많이 읽고 어떤 predicates가 테이블을 필터링하는지 집계하여 권장되는 열 순서, 파티션 키 및 정렬 키를 도출합니다. 이는 추측이 아닌 실제 액세스 패턴을 기반으로 합니다.
실행하기 전에 비용을 얼마나 절감할 수 있는지 확인할 수 있나요?
네. dry-run을 통해 데이터 쓰기 없이 현재와 최적화 후의 스캔 바이트 및 월별 차액을 보고하며, 절감 효과를 파티션/row-group 프루닝, dictionary+zstd, 컴팩션별로 정직하게 배분합니다. 30–70%라는 수치는 레이아웃 불일치 정도에 따른 예상 범위일 뿐 보장되는 값은 아니므로, 먼저 보유하신 테이블을 대상으로 dry-run을 수행해 보십시오.
어디에서 실행되며, 데이터가 제 계정 밖으로 전송되나요?
귀하의 AWS 계정 및 VPC 내에서 AMI로 실행되며, 귀하의 S3, Glue, Athena에만 액세스하므로 데이터가 외부로 유출되지 않습니다. 최소 권한의 IAM 역할 하에 작동하며 EventBridge 스케줄에 따라 관리자의 개입 없이 자동으로 운영됩니다.
요금제 모델
시간당 software fee + EC2(t3 / m5 class), pay-per-GB-processed offer도 제공됩니다. annual option 제공.