스파크에서 지원하는 압축 알고리즘 비교

압축 알고리즘 비교

Configuration - Spark 3.5.1 Documentation

Configuration - Spark 3.5.1 Documentation

• 현재 스파크 3.5 기준 압축 알고리즘으로 snappy, gzip, lzo, brotli, lz4, and zstd 지원

snappy

• 구글에서 2011년에 발표한 자체 개발한 무손실 압축 알고리즘
• spark default 설정
• 적당한 압축률 대비 빠른 압축/해제가 목표
• 다른 압축 방식 대비 CPU를 덜 사용하고 초당 250MB정도를 압축함

gzip

• GNU zip의 줄임말이며 초기 유닉스 시스템에 쓰이던 압축 프로그램을 대체하기 위해 만들어짐 현재 널리 사용되는 무손실 압축 알고리즘
• deflate 알고리즘을 사용하여 추가적인 헤더와 체크섬으로 오류 검출에 강점
• 압축률이 높고 호환성이 좋지만, 압축/해제 속도가 상대적으로 느림

lzo

• deflate 압축에 비해 더 높은 압축 속도, gzip보다 더 적은 cpu 리소스
• snappy와 유사하지만 압축률이 근소하게 더 높음
• 빠른 압축/해제 속도를 통해 실시간 데이터에 특화
• 압축률이 다른 알고리즘에 비해 낮은 편

brotli

• 구글에서 2013년 발표한 압축 알고리즘
• 텍스트 압축에 적합하기 때문에 웹 브라우저 등에서 콘텐츠 압축에 사용됨
• 2020년부터 AWS CloudFront에서도 지원
• gzip과 유사한 압축률을 제공하지만 압축 및 해제 속도가 더 빠름
• 메모리 사용량이 다른 알고리즘에 비해 많은 편

lz4

• 매우 빠른 속도에 특화된 무손실 압축 알고리즘
• 압축률은 Deflate 등에 비해 낮지만 속도가 최대 10배 이상으로 매우 빠름
• 값을 빠르게 전송하거나 저장해야하는 환경에서 자주 사용

zstd

• 페이스북에서 개발한 무손실 압축 알고리즘
• 자체 벤치마크상 gzip보다 압축률이 더 높으며 비슷한 해제 속도를 보임
• 원래는 1~22까지 압축 레벨을 정할 수 있는데 스파크에서는 지원하지 않는 것으로 보임

종합

• lz4가 가장 속도가 빠르지만 압축률이 낮고 크기와 속도 절충점으로 zstd가 가장 나아보임
• lz4는 실시간 데이터 처리, lzo는 자주 액세스해야하는 프로그램에, Brotli은 웹 성능에(http압축)에 특화되어있어서 좀더 범용적인 zstd, gzip을 대상으로만 평가진행
• 아래 config 설정을 통해서 spark에서 parquet를 쓸 때 압축코덱을 zstd로 변경 가능

spark.conf.set("spark.sql.parquet.compression.codec","zstd")

벤치마크 결과

다른 사이트들의 벤치마크 결과

1. heap

How We Saved Millions in SSD Costs by Upgrading Our Filesystem

How We Saved Millions in SSD Costs by Upgrading Our Filesystem

• lz4는 ~4.4x 정도의 압축률을 보임 하지만 zstd는 ~5.5x까지의 압축률을 보여줘서 22%개선
• 많은 벤치마크에서 zstd가 lz4보다 속도가 느리다고했지만 테스트 결과 쿼리 성능은 변하지 않고 쓰기 쿼리 시간도 절반으로 감소됨

2. AWS, 트위터

AWS는 S3의 압축을 gzip에서 zstd로 바꿔서 30% 정도 크기를 줄였음 | GeekNews

AWS는 S3의 압축을 gzip에서 zstd로 바꿔서 30% 정도 크기를 줄였음 | GeekNews

• 사실상 압축 알고리즘 비교 및 벤치마크를 진행하게 된 계기, aws와 트위터 등에서 zstd로 바꾸고 30%정도 비용 절감을 했다는 해커뉴스

3. 우버

https://www.uber.com/en-TW/blog/cost-efficiency-big-data/

• 분석을 위해 데이터레이크에 100 페타바이트의 GZIP과 SNAPPY 압축을 사용되었고 그중에 크기가 큰 상위 10개 Hive 테이블을 골라 ZSTD로 변환한 후 크기 감소를 확인함
• snappy에서 zstd로 변환에서는 약 39% 감소한 것으로 나타남

• 스토리지 절감뿐만이 아니라 일반적으로 gzip/snappy에 비해 zstd를 사용했을 때 하이브 쿼리에서 vCore사용 시간 또한 감소하였음

4. zstd

https://github.com/facebook/zstd

GitHub - facebook/zstd: Zstandard - Fast real-time compression algorithm

• Compression Speed vs Ratio

• Decompression Speed

• zlib은 Deflate 압축 알고리즘을 C언어로 구현한 구현체
• zstd쪽 자료인 것을 감안해서 봐야함

5. 리눅스 커널 벤치마크

https://linuxreviews.org/Comparison_of_Compression_Algorithms

Comparison of Compression Algorithms

• 압축
  • 속도: zstd(1core)>gzip(parallel)>lz4(빠르지만 압축률이 낮음)>gzip(normal config)
  • 용량:zstd>gzip>lz4
• 압축해제
  • lz4>gzip>zstd(no option)

실제 데이터 대상 벤치마크

• 직접 가지고있는 데이터로 테스트를 해봤을 때 평균적으로 gzip은 31~36%, zstd는 39~42%정도 snappy 대비 저장 용량이 감소한 것을 확인할 수 있었다.
• 3번 테이블은 MB라서 데이터를 확인하기 힘들어서 보기편하게 x10으로 보정함
• 우버의 벤치마크 결과와 매우 비슷한 결과
• trino, spark fetch 및 프로세싱 속도는 네트워크 상태, 인터프리터의 런타임 상황에 따라서 계속 뒤바뀌어서 비교가 무의미했음

결론

• 압축 알고리즘을 zstd로 변경시 성능적인 손실은 최소화하면서 최소 39%~최대 42%정도의 저장 비용을 절약 할 수 있음