26F12G

Young-Kyoo Kim·2026년 2월 11일

Iceberg/Spark 최적화 회의록

1. 회의 배경 및 현황

1.1 현재 데이터 상태

파일 크기 분포

벤더 확인:

"80% of their files are less than 32 megabytes."

현황:

80%: 32MB 미만
파일 수: 약 8억 개 (3 replicas 고려 전)
우려: 작은 파일 문제

실제 테이블 확인

벤더 평가:

"yesterday we saw their tables. Their files are very large. They were, 
like, 400 megabytes... Yeah, they were pretty good size."

발견:

일부 테이블: 400MB 파일 (양호)
혼재: 크고 작은 파일 혼합
결론: 전반적으로 개선 필요

1.2 사용 기술 스택

Query Engine

Trino: 주요 쿼리 엔진
Spark: 데이터 처리 및 ETL
Star Rocks: 실시간 분석 (일부)

Table Format

"Going to do iceberg and parquet going forward."

현재: Hive Metastore (HMS)
향후: Iceberg + Parquet
메타스토어: HMS → AIStore Tables 전환 계획

2. 황금률: Partitioning vs Bucketing

2.1 벤더의 핵심 원칙

문신으로 새기고 싶은 규칙

벤더 발언:

"I wish I had a tattoo, tattoo that says partition when you can 
bucket if you must avoid bucketing"

해석:
1. 우선순위 1: Partitioning (가능한 항상)
2. 우선순위 2: Bucketing (꼭 필요할 때만)
3. 원칙: Bucketing 회피

이유

"spark and Impala does not like all the buckets, lots of bucketing 
at the table level, it creates problems when you want to be able to 
do compaction later on with Spark."

문제:

Spark: Bucketing과 호환성 문제
Impala: Bucketing 처리 비효율
Compaction: Bucketing 시 복잡도 급증

2.2 Partitioning 권장사항

기본 원칙

"Partitioning is better, because almost everything has date as a 
date field"

권장:

Partition Key: 날짜 (가장 보편적)
빈도: 일별 (Daily) 권장
효과: 쿼리 pruning 효율성

파일 크기 제약

"You never want to partition with especially with Impala, if it's 
going to be using iceberg tables, you don't want to partition like, 
less than 10 Meg on the files."

최소 크기:

10MB 이상: 필수
32MB 이상: 권장
이유: Impala 성능 문제

벤더 확인:

"anything over 32 megabytes for the actual... partition file, the 
parquet file, you're fine. That's good."

2.3 Bucketing 사용 시나리오

언제 사용하는가?

벤더 설명:

"You further break out those partitions by bucketing based on zip code... 
but you have to know that ahead of time, it's database design."

적절한 사용:
1. Partition 내 추가 분할: 날짜로 파티션 → Zip Code로 버킷
2. 명확한 카디널리티: 사전 파악 가능
3. 빈번한 조인: 동일 키로 자주 조인

예시: 지역 데이터

"you partition based on city, and then you bucket based [on] zip code... 
California, you'll bucket on... the city, and then the zip code in 
North Dakota, which has, like, 1/100 the number of people."

Bucketing의 위험

벤더 경고:

"if you pocket, let's say you pocket by country, and then you have 
here, Korea, US, and then Mexico, you have one record, so you end up 
with a separate file."

문제 상황:

국가별 Bucketing
Mexico: 1개 레코드 → 1개 파일
결과: Small file problem 악화

역효과:

"every time the query engine needs to do something that involves 
everyone, it needs to read a lot of files. So it could actually backfire."

3. Compaction (파일 압축/병합)

3.1 Compaction이란?

정의

벤더 설명:

"The compaction goes and analyze all of these [small files] and puts 
together files into like larger chunks."

목적:

작은 파일 → 큰 파일 병합
분석 성능 향상
메타데이터 부하 감소

Query Engine 지원

"as far as compaction goes, that's normally handled by the query engine. 
So Impala does compaction, Spark does compaction, Hive Trino, they all 
handle compaction built in"

지원 엔진:

Spark: Built-in compaction
Trino: Auto-compaction (일부)
Impala: Iceberg 테이블 compaction
Hive: 사용 권장 안 함

3.2 Partitioning 없는 Compaction

시나리오

벤더 설명:

"Let's say you have an iceberg table, and this is the table, right? 
This is no partition, and let's say you write a ton of small files."

초기 상태:

Table (No Partition)
├── small_file_1.parquet
├── small_file_2.parquet
├── small_file_3.parquet
├── ... (수천 개)

Compaction 과정

1차 Compaction:

"When you do compaction, they compact... puts together files into 
larger chunks."

결과:

Table (No Partition)
├── compacted_chunk_1.parquet (Large)
├── compacted_chunk_2.parquet (Large)

재발 문제

벤더 경고:

"After you do compaction, if you keep adding small files and you do 
compaction, again, you have to again, recompact... all, every single 
one. It will be very slow."

문제:

신규 작은 파일 계속 추가
2차 Compaction 필요
전체 테이블 재처리 필요 → 매우 느림

결론:

"Compaction, without partitioning, is a very expensive process, and 
that's just doesn't matter whose storage is, just the way it works."

3.3 Partitioning 있는 Compaction

시나리오

벤더 설명:

"if you have partitioning in place... you have a bunch of smaller 
files, partitions, more files, partitions, more files, partition"

초기 상태:

Table (Partitioned by Date)
├── date=2026-02-01/
│   ├── small_file_1.parquet
│   ├── small_file_2.parquet
├── date=2026-02-02/
│   ├── small_file_3.parquet
│   ├── small_file_4.parquet
├── date=2026-02-03/
│   ├── small_file_5.parquet

Compaction 과정

1차 Compaction:

"Once you do compaction of partition, [compacted] files, when you 
compaction again, these are [already] compacted. There's no, not 
much that can be done. So they're left alone"

결과:

Table (Partitioned by Date)
├── date=2026-02-01/ (Compacted)
│   └── compacted.parquet (Large)
├── date=2026-02-02/ (Compacted)
│   └── compacted.parquet (Large)
├── date=2026-02-03/ (Compacted)
│   └── compacted.parquet (Large)

신규 데이터 추가

2026-02-04 데이터 유입:

Table (Partitioned by Date)
├── date=2026-02-01/ (이미 Compacted - 건드리지 않음)
├── date=2026-02-02/ (이미 Compacted - 건드리지 않음)
├── date=2026-02-03/ (이미 Compacted - 건드리지 않음)
├── date=2026-02-04/ (신규)
│   ├── small_file_6.parquet
│   ├── small_file_7.parquet

2차 Compaction:

"it's faster to just recompact the [new] data... So your goal is 
to have larger files."

처리:

2026-02-04만 Compaction
기존 파티션은 그대로
속도: 매우 빠름

효과

벤더 정리:

"If you have partitioning, it mitigates the problem, because the 
[query] will still just grab this [partition] after compaction. 
Compaction [is] really faster because it's very clearly defined 
[which partitions need work]."

장점:
1. 범위 제한: 신규 파티션만 처리
2. 기존 보존: 이미 Compacted된 파티션 재처리 불필요
3. 속도: 전체 대비 일부만 처리

3.4 현재 상태 평가

벤더 평가:

"They don't have the problem right now for the tables that are very 
large... [files were] 400 megabytes... you can always go one gigabyte, 
right? That will actually speed up [performance]."

현황:

일부 테이블: 400MB 파일 (양호)
개선 여지: 1GB까지 가능
권장: 추가 최적화

4. 파일 크기 최적화

4.1 최소 파일 크기

Impala/Iceberg 제약

벤더 강조:

"You never want to partition... less than 10 Meg on the files. 
It just does not work."

최소 기준:

10MB: 절대 최소
32MB: 안전 기준
이유: Query engine 성능

4.2 권장 파일 크기

Parquet 파일

벤더 권장:

"anything over 32 megabytes for the actual... partition file, 
the parquet file, you're fine. That's good."

권장 범위:

최소: 32MB
권장: 100~400MB
최대: 1GB

현재 상태

확인된 크기:

"Their files are very large. They were, like, 400 megabytes"

400MB: 양호
추가 최적화: 1GB까지 가능

4.3 Iceberg 자동 분할

기본 동작

벤더 설명:

"this is a feature of iceberg. It will naturally separate [partition] 
files... you can actually configure this if you want them larger"

Iceberg 특성:

쓰기 시 자동 파일 크기 조정
기본값: 적당한 크기로 분할
설정 가능: 더 큰 파일 허용

최적화 방향:

"you will, you won't hit like an immediate problem... [but] you can 
configure [for] larger [files]"

5. Spark 최적화

5.1 버전별 차이

Spark 3.1 (CDP)

벤더 설명:

"CDP has spark 3.1, I think, which required, like tuning for 
memory mapping."

문제:

Memory mapping 튜닝 필요
Local shuffle 설정 복잡

요구사항:

"There had to be extra shuffle set up for Spark in earlier versions, 
like three one"

Spark 3.5 (Kubernetes)

벤더 확인:

"you don't need that with three, five, with what you're going to be 
using in containers. None of that's a problem anymore."

장점:

Memory mapping 자동 처리
Shuffle 설정 불필요
Kubernetes: 추가 튜닝 불필요

5.2 MinIO 연결 설정

Path Style 설정

벤더 권장:

"you want to have [path-style] enabled, and then the path style 
should be set to true"

Spark 설정:

spark = SparkSession.builder \
    .config("spark.hadoop.fs.s3a.path.style.access", "true") \
    .getOrCreate()

Trino Path 설정

벤더 강조:

"they actually have a thing in there that talks about MinIO pathing. 
It's literally... s3 path full... the full path. That's it, simple 
as that"

Trino 설정:

iceberg.catalog.type=rest
s3.path-style-access=true

5.3 Shuffle 최적화

Spark on YARN (구식)

벤더 설명:

"spark on yarn. Required HDFS for the [shared] state"

문제:

HDFS 의존성
Shared state 관리 복잡

Spark on Kubernetes (권장)

벤더 확인:

"with unicorn, you're [not needing HDFS]... when you put spark in 
Docker and Kubernetes, your shuffle, where is that going [local]"

장점:

HDFS 불필요
Local shuffle (컨테이너 내)
관리 단순화

6. Small Files 문제 해결

6.1 현재 상황

파일 크기 분포

벤더 확인:

"80% of their files are less than 32 megabytes."

우려:

대다수가 작은 파일
Query 성능 저하
Metadata 부하

6.2 Compaction 전략

Auto-Compaction

벤더 제안:

"there's auto compaction with some of the query tools like Trino... 
Spark does compaction... they all handle compaction built in"

활성화 방법:

Trino: Auto-compaction 설정
Spark: 주기적 compaction 작업
Iceberg: Maintenance 작업

수동 Compaction

Spark 예시:

# Iceberg Compaction
spark.sql("""
  CALL system.rewrite_data_files(
    table => 'iceberg.db.table_name',
    strategy => 'binpack',
    options => map('target-file-size-bytes','134217728')
  )
""")

목표:

128MB 파일 생성
Partition별 처리
주기적 실행

6.3 Partition 전략

날짜 기반 Partitioning

현재:

"So normally we they use the daily partition."

권장 유지:

Daily partition 적절
파일 크기 10MB 이상 보장
Compaction 효율성

Over-partitioning 회피

벤더 경고:

"is there any recommendation on [depth] of partition... too many"

답변:

월별 파티션: 양호
시간별 파티션: 과도 (파일 너무 작음)
균형: 파일 크기와 쿼리 패턴

7. Iceberg vs Hive

7.1 Iceberg 장점

자동 파일 관리

벤더 설명:

"That's one of the features of iceberg, pretty much one thing that 
helps [with compaction]"

특징:

쓰기 시 파일 크기 자동 조정
Metadata 관리 효율적
Partition pruning 최적화

HMS 불필요

벤더 제안:

"if you wanted to simplify, we provide a rest catalog for iceberg... 
We're just replacing just the HMS in this scenario, directly on the 
storage itself."

AIStore Tables:

REST Catalog for Iceberg
Metadata on storage
HMS 제거 가능

7.2 Migration 경로

HMS → AIStore Tables

벤더 방법:

"in Trino, you set up the two catalogs, and then you just... migrate 
across it. You just copy it over... if the iceberg tables are already 
inside of AI store... We can do a discovery of the tables themselves."

방법:
1. Trino Dual Catalog: HMS + AIStore
2. Copy: HMS → AIStore
3. Discovery: 기존 Iceberg 테이블 자동 인식

Format 전환

벤더 제안:

"you're changing formats, going from RC or straight parquet into 
iceberg. This, it's ELT... it's better, because they can compact... 
you end up with larger files that are faster."

이점:

RC/Parquet → Iceberg
Compaction 기회
파일 크기 최적화

8. 성능 모니터링

8.1 파일 크기 분포

Grafana Dashboard

벤더 설명:

"if you just grab the [dashboard], you'll see like, last three hours 
this many files of this distribution came off, like large files, 
[many] small files"

모니터링:

시간대별 파일 크기 분포
Small files 급증 감지
Compaction 필요성 판단

8.2 Small Files Alert

설정 권장:

임계값: 32MB 미만 파일 비율
Alert: 80% 초과 시
조치: Compaction 작업 트리거

9. 권장사항 요약

9.1 Partitioning

✅ DO:
1. 날짜 기반 Partitioning: Daily 권장
2. 최소 파일 크기: 10MB 이상
3. 권장 파일 크기: 32MB~1GB
4. 쿼리 패턴 고려: 자주 필터링하는 컬럼

❌ DON'T:
1. 과도한 Partitioning: 파일 크기 < 10MB
2. Bucketing 남용: 꼭 필요할 때만
3. HMS 계속 사용: Iceberg REST Catalog로 전환

9.2 Compaction

✅ DO:
1. Auto-Compaction 활성화: Trino/Spark
2. 주기적 수동 Compaction: 주말/야간
3. Partition별 처리: 신규 파티션만
4. 목표 파일 크기: 128MB~1GB

❌ DON'T:
1. 전체 테이블 Compaction: Partition 없이
2. 빈번한 Compaction: 비용 대비 효과 낮음
3. Compaction 무시: Small files 누적

9.3 Spark 설정

✅ DO:
1. Spark 3.5 사용: Kubernetes 환경
2. Path-style Access: true로 설정
3. Local Shuffle: Container 내 처리
4. Iceberg Native: Spark-Iceberg 통합

❌ DON'T:
1. Spark 3.1 고집: 구형 버전
2. YARN 의존: Kubernetes로 전환
3. HDFS Shuffle: 불필요

10. 액션 아이템

10.1 즉시 실행 (1주일 내)

파일 크기 분석

현재 파일 크기 분포 확인
Small files (< 32MB) 비율 측정
Partition별 파일 수 확인

Partitioning 검토

현재 Partitioning 전략 분석
10MB 미만 파일 파티션 식별
Over-partitioning 여부 확인

Compaction 계획

Auto-compaction 설정 확인
수동 Compaction 스크립트 작성
실행 일정 수립 (주말/야간)

10.2 단기 (2주일 내)

Spark 업그레이드

Spark 3.5 마이그레이션 계획
Kubernetes 환경 준비
YARN → Kubernetes 전환 테스트

Iceberg 전환

HMS → AIStore Tables 계획
RC/Parquet → Iceberg 전환
Catalog 마이그레이션

모니터링 구축

Grafana 파일 크기 분포 Dashboard
Small files Alert 설정
Compaction 작업 모니터링

10.3 중기 (1개월 내)

최적화 적용

모든 테이블 Partitioning 검토
Bucketing 제거 (불필요 시)
파일 크기 32MB~1GB 달성

자동화

Auto-compaction 활성화 (Trino)
주기적 Compaction 작업 (Spark)
Alert 기반 자동 대응

11. 예상 효과

11.1 성능 개선

쿼리 성능:

Small files 감소 → 메타데이터 부하 감소
Compaction → I/O 효율 증가
Partitioning → Pruning 효과

예상:

쿼리 속도: 2~5배 향상
Metadata 부하: 80% 감소

11.2 비용 절감

스토리지:

Compaction → 압축률 향상
메타데이터 감소 → Inode 사용률 감소

컴퓨팅:

파일 수 감소 → Task 수 감소
Spark 실행 시간 단축

예상:

Spark Job 시간: 30~50% 단축
스토리지 메타데이터: 50% 감소

11.3 운영 효율

관리 단순화:

HMS 제거 → AIStore Tables
Auto-compaction → 수동 작업 감소

안정성:

Small files 관리 → 시스템 안정성
Spark 3.5 → 튜닝 불필요

12. 위험 요소 및 완화

12.1 Compaction 부하

위험

대규모 Compaction 시 클러스터 부하
사용자 워크로드 영향

완화

✅ 야간/주말 실행
✅ Partition별 점진적 처리
✅ 리소스 제한 설정

12.2 Migration 복잡도

위험

HMS → AIStore Tables 전환 시 다운타임
애플리케이션 호환성 문제

완화

✅ Dual catalog 운영 (과도기)
✅ 점진적 마이그레이션
✅ 롤백 계획 수립

12.3 Spark 버전 업그레이드

위험

기존 Job 호환성
성능 회귀 가능성

완화

✅ 테스트 환경 검증
✅ 주요 Job 재테스트
✅ 단계적 적용

13. 참고 자료

13.1 Iceberg 공식 문서

Compaction 가이드
Partition Evolution
Performance Tuning

13.2 Spark 최적화

Spark 3.5 Release Notes
S3A Path Style 설정
Kubernetes 통합

13.3 MinIO 블로그

Iceberg Best Practices
AIStore Tables 소개
Performance Benchmarking

14. 결론 및 다음 단계

14.1 핵심 합의사항

✅ "Partition when you can, bucket if you must"
✅ 최소 파일 크기: 32MB
✅ Auto-compaction 활성화
✅ Spark 3.5 + Kubernetes
✅ HMS → AIStore Tables 전환

14.2 즉시 실행 항목

파일 크기 분석
Partitioning 전략 검토
Compaction 계획 수립

14.3 성공 기준

✅ Small files (< 32MB) < 20%
✅ 평균 파일 크기 > 100MB
✅ 쿼리 성능 2배 이상 향상
✅ Compaction 자동화 완료

문서 버전: 1.0
최종 수정일: 2026년 2월 6일
다음 리뷰: Compaction 적용 후 (2026년 3월)

부록: 주요 인용문

Partitioning 황금률

"I wish I had a tattoo that says partition when you can bucket 
if you must avoid bucketing"

Compaction 없는 Partitioning

"Compaction, without partitioning, is a very expensive process, 
and that's just doesn't matter whose storage is, just the way 
it works."

파일 크기

"You never want to partition... less than 10 Meg... anything 
over 32 megabytes... you're fine."

Spark 3.5

"you don't need that with three, five... None of that's a 
problem anymore."

현재 상태

"80% of their files are less than 32 megabytes... Their files 
[in some tables] were, like, 400 megabytes"

Young-Kyoo Kim

engineer

이전 포스트

26F12F

다음 포스트