파티션 전략과 파일 포맷·압축 조합으로 스캔 데이터량을 90% 이상 줄이는 실무 가이드(예시 수치 포함).
데이터레이크에서 파티션 설계·파일 포맷·압축·컴팩션을 조합해 쿼리 비용을 실무에서 즉시 줄이는 방법을 정리한다. 목표는 ‘스캔 바이트 최소화’와 ‘작업 비용 예측성 확보’다.
주요 내용
데이터레이크 성능 문제를 진단할 때 우선 점검해야 할 핵심 지표는 다음 세 가지다.
- 쿼리당 스캔된 바이트(Bytes scanned): 비용 기반 핵심 지표.
- 파일 수와 평균 파일 크기: 작은 파일(작게 쪼개진 파일)이 많으면 오버헤드 증가.
- 파티션 선택성(쿼리에서 자주 필터링하는 컬럼의 카디널리티): 파티션 프루닝 효과를 좌우.
실무자 A씨 사례: 일일 리포트 쿼리가 항상 전체 테이블를 스캔해 비용이 급증했다. 원인은 날짜 기반 파티션 미사용과 파일 포맷이 CSV였기 때문이다.
Parquet+파티션 적용으로 평균 스캔 바이트가 1TB→18GB로 감소했다.
쿼리 로그에서 상위 10개 쿼리가 전체 비용의 70% 이상을 차지하는 경우가 흔하다. 상위 쿼리를 우선 최적화하면 비용 구조가 빠르게 개선된다.
데이터 비교 표: 최적화 전/후 비용·응답시간 예시
| 항목 | 기존(예: CSV, 무파티션) | 최적화(Parquet+ZSTD+파티션) | 비고 |
|---|---|---|---|
| 데이터 규모 | 1 TB | 1 TB (논리적 동일) | 물리적 저장량은 압축으로 감소 |
| 평균 쿼리 스캔 바이트 | 1,024 GB | 18 GB | 파티션 프루닝+컬럼 프루닝 효과 |
| 쿼리당 비용(클라우드 비용 모델 예시) | $10.24 | $0.18 | 약 98% 비용 절감(예시) |
| 평균 응답시간 | 120 s | 6 s | 스캔 바이트와 IO 병목 해소 |
사례 분석: 실무 적용 흐름과 체크리스트
기획자 B씨는 신규 분석 파이프라인 도입 전 비용 시뮬레이션이 필요했다. 인사이트 에디토리얼팀의 권고 절차는 다음과 같다.
- 쿼리 로그 수집: 상위 비용 쿼리, 필터 패턴을 2주 단위로 집계.
- 주요 필터 컬럼 식별: 날짜, 지역, 고객ID 등. 파티션 후보로 우선 지정.
- 파일 포맷 전환 테스트: CSV→Parquet 또는 ORC. 컬럼형 포맷으로 전환해 컬럼 프루닝과 통계 활용.
- 압축 및 코덱 실험: Snappy, ZSTD, Brotli(읽기 성능 고려). 읽기 속도 대비 압축비 비교.
- 컴팩션/소형파일 처리: 배치 컴팩션 및 쓰기 파이프라인에서 파일 크기 목표(128MB~512MB)를 설정.
- 메타데이터 테이블/카탈로그(예: Hive Metastore, Glue, Iceberg, Delta): 파티션 메타데이터 관리로 목록 비용 최소화.
권장 파일 크기와 행그룹(row group) 설정 예시:
- 목표 파일 크기: 128MB ~ 512MB
- Parquet row group: 16MB ~ 256MB (일반적으로 64MB~128MB 권장)
- 파일 개수 최소화: 수백~수천 개 단위로 유지(플랫폼별 한계 고려)
압축 코덱 선택 가이드(실무 우선순위):
- ZSTD: 압축비와 디코딩 속도에서 균형이 우수. 실무 권장 1순위(특히 대용량 분석용).
- Snappy: 빠른 디코딩, 낮은 CPU 오버헤드. 실시간 분석이나 자주 읽기 작업에 유리.
- GZIP/Brotli: 높은 압축비지만 CPU 비용 증가. 장기 보관용 파일에 적합.
메타레이어 기술(Delta Lake, Apache Iceberg, Hudi)을 사용하면 파티션 롤업, 증분 컴팩션, 스냅샷 기반 쿼리 계획이 가능해 실무에서 운영 부담을 낮출 수 있다.
테스트 중 발견된 주의사항
실무 테스트에서 자주 발견되는 실수와 그 영향은 다음과 같다.
- 과도한 파티셔닝: 매우 높은 파티션 카운트는 메타데이터 조회 비용을 증가시킨다. 플랫폼별 메타데이터 한계를 확인하고 파티션 계층을 설계할 것.
- 작은 파일 다수 저장: 파일이 작을수록 IO 오버헤드와 연결 비용 증가. 쓰기측에서 적정 파일 크기 관리를 자동화할 것.
- 비효율적인 파티션 키 선택: 자주 필터되는 컬럼 대신 엔티티별 고카디널리티 컬럼을 파티션으로 쓰면 프루닝이 불발한다.
- 압축·인코딩 미세조정 부재: 컬럼형 포맷의 통계·인코딩 설정을 무시하면 컬럼 프루닝·Predicate pushdown 효율이 떨어진다.
테스트 환경에서 ‘읽기 시나리오’를 대표하는 20개 쿼리를 만들어 A/B 비교 측정하라. 비용 편차가 큰 쿼리를 우선해 최적화하면 ROI가 빠르게 가시화된다.
실행 우선순위(3단계 로드맵)
- 단기(1~2주): 쿼리 로그 분석 → 상위 10개 쿼리 집중 최적화 → Parquet로 변환 테스트.
- 중기(1~2개월): 파티션 전략 확정(날짜+지역 등), 파일 크기 목표 설정, 정기 컴팩션 파이프라인 도입.
- 장기(3~6개월): 메타레이어(Iceberg/Delta) 도입, 자동소형파일 모니터링, 비용 알림·쿼리 가드레일 적용.
기술 체크리스트(핵심 설정 값 예시)
- 파일 포맷: Parquet / ORC (호환성 우선이면 Parquet)
- 압축 코덱: ZSTD(레벨 1~3) 또는 Snappy(저지연)
- 목표 파일 크기: 128MB~512MB
- Row group: 64MB~128MB
- 파티션 전략: 날짜(일/월) + 보조 파티션(지역) – 카디널리티를 고려해 계층화
- 클러스터링(또는 Z-ordering): 자주 쿼리되는 조합 컬럼에 적용
- 모니터링 지표: bytes_scanned, files_opened, avg_file_size, partition_count
외부 공식 문서 참고(플랫폼별 권장 설정과 사례):
🔗 Google BigQuery 파티션·클러스터 가이드
마무리 체크: 비용 절감 시나리오 요약
간단한 수치 모델(예): 전체 테이블 스캔을 1TB→18GB로 줄이면 스캔 기반 과금 모델에서 쿼리 비용이 약 98% 감소한다. 실제 절감률은 쿼리 패턴과 플랫폼 요금 구조에 따라 달라진다.
항상 로그 기반으로 A/B 측정을 수행하고, 변경 전후의 bytes_scanned와 응답시간을 기록해 증빙하라.