Zstd Frame 및 Jump Table 도입을 통한 Cloud Egress 비용 99.9% 절감

Using Zstd Frames to Egress Partial Parquet Files

Joichiro Mitaka2026년 6월 24일13분advanced

AI 요약

Context

Parquet 파일의 Schema discovery 및 Column pruning 작업 시 전체 파일을 다운로드해야 하는 구조적 한계 존재. 이로 인해 실제 필요한 데이터는 수백 KB에 불과함에도 GB 단위의 불필요한 데이터 전송과 막대한 Cloud Egress 비용이 발생하는 병목 지점 발생.

Technical Solution

단일 압축 스트림 대신 독립적인 Zstd Frames 기반의 연결 구조 채택
uncompressed_offset과 compressed_offset을 매핑하는 Jump Table을 SQLite(husk_catalog.db)로 구현하여 정밀한 Byte-range Seek 가능
HTTP Range Request를 통해 필요한 특정 Frame만 선택적으로 Fetch하여 불필요한 I/O 제거
Parquet의 Row Group 구조를 아카이브 레벨의 Frame 모델로 투영하여 데이터 접근 효율 극대화
TLV(Type-Length-Value) 기반의 Footer 메타데이터를 활용한 볼륨 레벨의 Predicate Pushdown 수행
다중 백엔드(S3, R2 등) 간 최적 비용 경로를 선택하는 Gateway 라우팅 설계

Impact

Schema Sync 작업 시 Egress 비용 $9,216에서 $9.00로 99.9% 감소
Data Catalog Sync 시 데이터 전송량 4 PB에서 50 GB로 획기적 축소
Column Scan 시나리오에서 월간 리드 비용을 $9,216에서 $1,382로 약 85% 절감

실천 포인트

- 접근 패턴의 정밀도에 따라 Zstd Frame 크기(기본 16MB)를 1~4MB로 튜닝하여 Fetch 최소 단위 최적화 - 아카이빙 단계에서 CPU 자원을 투입해 TLV 통계 정보를 추출함으로써 런타임 시 Volume Read 회피 전략 수립 - 복제 저장소 운영 시 Egress 비용이 낮은 백엔드(예: Cloudflare R2)로 Range Request를 라우팅하는 비용 최적화 검토 - I/O 발생 전 Catalog 쿼리를 통해 예상 Egress 양을 먼저 산출하는 실행 계획(Explain Plan) 프로세스 도입

태그

#HTTP Range Request #Zstd #Jump Table #Cloud Egress #Parquet

원문 읽기