핵심 인사이트 (3줄 요약)

  • 압축 알고리즘 선택은 압축률(Compression Ratio)과 속도(Throughput)의 트레이드오프이며, 빅데이터 환경에서 I/O 비용이 CPU 비용보다 클 때 높은 압축률이 전체 성능을 향상시킨다.
  • Snappy는 속도 우선(Hadoop 기본), Gzip은 압축률 우선(HTTP), LZ4는 초고속 실시간 스트리밍, Zstd는 속도와 압축률을 모두 잡는 현재 최선의 범용 선택이다.
  • 컬럼형 포맷(Parquet/ORC)에서 RLE (Run-Length Encoding)과 딕셔너리 인코딩이 데이터 특성 기반 고압축을 실현하며, 이는 일반 압축 코덱보다 훨씬 효율적이다.

Ⅰ. 개요 및 필요성

1-1. 압축이 빅데이터에서 중요한 이유

  • 스토리지 비용: S3/HDFS 저장 비용 직접 절감
  • I/O 처리량: 디스크 읽기·네트워크 전송 데이터 감소 → 쿼리 속도 향상
  • CPU vs I/O 균형: I/O 병목 환경에서 압축 CPU 비용 < I/O 절감 효과

1-2. 압축 알고리즘 선택 기준

기준우선 고려 알고리즘
최고 속도 (실시간 스트리밍)LZ4
최고 압축률 (아카이빙)Gzip level 9, Brotli, LZMA
속도 + 압축률 균형 (범용)Zstd
Hadoop 전통 환경Snappy
HTTP 웹 압축Gzip, Brotli

📢 섹션 요약 비유: 압축 알고리즘 선택은 짐을 꾸릴 때의 전략과 같다. 빠른 출발(실시간)이 중요하면 대충 넣고, 장기 보관(아카이빙)이라면 꼼꼼히 압축한다.


Ⅱ. 아키텍처 및 핵심 원리

2-1. 압축 알고리즘 성능 비교

압축률      ┤                                    Brotli
            │                                 ●
높음        │                           Gzip ●
            │                       Zstd ●
            │               Snappy ●
낮음        │       LZ4 ●
            └────────────────────────────────────────▶
                  빠름                           느림
                         압축/해제 속도

2-2. 주요 알고리즘 상세

알고리즘압축 속도해제 속도압축률특징
LZ4500 MB/s1700 MB/s낮음초고속, 실시간 스트리밍
Snappy250 MB/s500 MB/s중간Hadoop 기본, 속도 중시
Zstd400 MB/s1600 MB/s높음속도+압축률 균형, 레벨 조절
Gzip30 MB/s200 MB/s높음HTTP 표준, CPU 부하 큼
Brotli5 MB/s300 MB/s매우 높음정적 웹 콘텐츠 아카이빙

2-3. 컬럼형 인코딩 (Columnar Encoding)

Parquet/ORC에서 사용하는 데이터 특성 기반 인코딩:

인코딩원리최적 데이터 특성
Dictionary Encoding반복 값을 정수 인덱스로 치환저카디널리티 (국가, 카테고리)
RLE (Run-Length Encoding)연속 반복 값을 (값, 횟수) 쌍으로정렬된 컬럼, 연속 동일 값
Delta Encoding연속 값의 차이를 저장단조 증가 (타임스탬프, ID)
Bit Packing작은 정수를 최소 비트로 저장작은 숫자 범위

📢 섹션 요약 비유: Dictionary Encoding은 반복되는 단어를 번호로 대체하는 속기술처럼, "대한민국"이 1000번 나오면 숫자 1로 저장해 공간을 절약한다.


Ⅲ. 비교 및 연결

Parquet에서의 압축 효과

원본 (CSV)Parquet (Snappy)Parquet (Zstd)Parquet (Gzip)
100 GB~15 GB (85% 절감)~10 GB (90% 절감)~8 GB (92% 절감)
스캔 속도빠름빠름느림

컬럼형 포맷 자체의 압축 효과 + 추가 코덱 압축의 시너지

스트리밍 vs 배치 압축 선택

  • Kafka 메시지: LZ4 (Producer 압축, Broker 저장, Consumer 해제)
  • Spark 배치 처리: Snappy 또는 Zstd (중간 파일)
  • S3 아카이빙: Gzip 또는 Zstd (장기 보관)
  • 데이터 이관: Zstd (속도+압축률 균형)

📢 섹션 요약 비유: 스트리밍에 LZ4를 쓰는 건 빠르게 서류를 파일에 꽂는 것이고, 아카이빙에 Gzip을 쓰는 건 진공포장기로 꼼꼼히 압축해 보관하는 것이다.


Ⅳ. 실무 적용 및 기술사 판단

4-1. Zstd 채택 가이드

Zstd 레벨 1~22:
Level 1: LZ4와 유사한 속도, Snappy보다 나은 압축률 (일반 스트리밍)
Level 3: 기본값, 속도·압축률 균형 (범용 빅데이터)
Level 10-19: Gzip과 유사한 압축률, 더 빠른 해제 (아카이빙)
Level 20-22: 최고 압축률 (Cold Storage)

4-2. Splittability (분할 가능성)

Hadoop/Spark에서 대용량 압축 파일이 여러 태스크로 병렬 처리되려면 분할 가능해야 한다.

알고리즘Splittable
Snappy (raw)
Gzip
Snappy (within Parquet/ORC)✅ (파일 포맷 레벨에서 분할)
bzip2
LZO + Index

컬럼형 포맷(Parquet/ORC)을 사용하면 비분할 코덱(Snappy, Gzip)도 Row Group 단위로 병렬 처리 가능.

4-3. 기술사 시험 포인트

  • 압축 선택 근거: I/O 병목 환경 → 높은 압축률 우선, CPU 병목 → 빠른 코덱 우선
  • Parquet + Zstd: 현재 빅데이터 표준 권장 조합
  • Snappy가 여전히 사용되는 이유: Hadoop 레거시 환경, LZO 대안

📢 섹션 요약 비유: Splittability는 긴 서류를 여러 사람이 동시에 읽을 수 있도록 챕터별로 분리된 것처럼, 압축 파일을 여러 서버가 동시에 처리할 수 있는 분할 능력이다.


Ⅴ. 기대효과 및 결론

효과내용
스토리지 비용Parquet + Zstd로 CSV 대비 85~92% 절감
쿼리 성능스캔 데이터 감소로 Athena/BigQuery 쿼리 속도 2~5배 향상
네트워크 비용이그레스 데이터 압축으로 클라우드 전송 비용 절감

압축 전략은 비용·성능의 양면에서 큰 효과를 내는 고효율 최적화다. 기술사 관점에서 데이터 파이프라인 설계 시 파일 포맷과 압축 코덱을 함께 명시하고, 워크로드 유형별 최적 조합을 권장해야 한다.

📢 섹션 요약 비유: 올바른 압축 전략은 물건을 테트리스처럼 빈틈없이 쌓아 이사 트럭 횟수를 줄이는 것처럼, 같은 양의 데이터를 적은 비용으로 저장하고 전송한다.


📌 관련 개념 맵

개념관련 기술연결 포인트
RLEParquet, ORC컬럼형 인코딩
Dictionary Encoding저카디널리티 데이터반복값 압축
SplittabilityHadoop, Spark병렬 처리 가능성
I/O vs CPU 병목하드웨어 최적화코덱 선택 기준
Zstd Level압축 튜닝워크로드별 최적화

📈 관련 키워드 및 발전 흐름도

[무손실 압축 (Lossless Compression) — Huffman/LZ77]
    │
    ▼
[컬럼형 압축 (Columnar Compression) — Parquet/ORC]
    │
    ▼
[사전 인코딩 (Dictionary Encoding) — 반복값 치환]
    │
    ▼
[런 길이 인코딩 (RLE, Run-Length Encoding) — 연속값 압축]
    │
    ▼
[스노우플레이크 자동 압축 (Snowflake Auto-Compression) — 클라우드 최적화]

이 흐름은 손실 없이 데이터를 줄이는 기본 압축에서 시작해, 컬럼형·사전·RLE 기법을 거쳐 클라우드 자동 압축으로 발전하는 과정을 보여준다.

👶 어린이를 위한 3줄 비유 설명

  1. 데이터 압축은 여행 가방 짐을 압축 봉투에 넣어 작게 만드는 것처럼, 같은 데이터를 더 작게 저장해서 공간을 아껴요.
  2. 빨리 꺼내야 하면 LZ4처럼 느슨하게 넣고, 오래 보관할 거면 Gzip처럼 꼭꼭 눌러 넣어요.
  3. Parquet 파일은 같은 종류의 물건끼리 모아 넣어서 압축이 훨씬 잘 되는 특수한 가방이에요.