[Apache Iceberg] 아이스버그 테이블 최적화 - 스토리지 최적화 편

Apache 아이스버그 테이블 최적화 - 스토리지 최적화 편

 
 
 
 

---

 

스토리지 최적화

남아있는 만료된 파일들

테이블을 업데이트하거나 컴팩션 실행시 →  새 파일이 생성되지만, 과거에 생성된 문제의 스몰 파일들은 테이블의 과거 스냅샷으로부터 참조가 끊기지 않고 있어서, 삭제되지 않는다

 

이러한 불필요한 파일들을 정리하려면?

→ 스냅샷을 주기적으로 만료시켜야하며. (= 더 이상 Time travel이 필요하지 않은 스냅샷들) 

→ 스냅샷에서 참조가 끊긴 고아 파일들을 삭제해야 한다

 

그리고

→ 메타데이터를 다시 쓰기 하여, 메타데이터 읽기 성능을 개선한다

 

 

 

 

---

 

 

 

 

 

스냅샷 만료시키기

 

 

spark.sql("CALL system.expire_snapshots('temp.test_compaction', TIMESTAMP '2025-01-12 00:00:00.000', 10)").show(truncate=false);​

 

위에서 expire_snapshots에 패스한 파라미터들에 대해 알아보자

• 0: table: 테이블 명
• 1: older_than: 기준 시간 (이 시간 이전의 스냅샷 제거)
• 2: retain_last: 유지할 최소 스냅샷 수
• 3: snapshot_ids: 만료할 특정 스냅샷 ID
• 4: max_concurrent_deletes: 파일을 삭제하는 데 사용할 스레드 수
• 5: stream_results: 삭제된 파일을 RDD(Resilient Distributed Dataset) 파티션을 통해 Spark 드라이버로 보낼지 여부 선택
  • OOM 문제를 방지하기 위한 옵션

 

 

즉, 위 커맨드는 1월 11일 이전에 생성된 스냅샷을 제거하나, 최소 10개의 스냅샷은 남긴다.

실제로 수행한 후, 다음 커리로 남아있는 스냅샷 개수를 확인해 볼 수 있다.

 

 

spark.sql("SELECT COUNT(*) AS snapshot_count FROM temp.test_compaction.snapshots;").show(truncate=false);

 

 

 

 

 

expire_snapshots으로 스냅샷을 날린 후 새로 생성된 metadata.json의 파일 크기를 확인해보았더니,

1MB → 32KB로 확연히 작아졌다 !

1000여개의 스냅샷에서 10개로 줄였을 때의 결과다.

 

 

 

 

 

---

 

 

 

 

 

고아 파일 삭제하기

스토리지 최적화의 마지막 단계는 고아 파일(Orphan files)들을 정리하는 것이다.

이는 테이블의 데이터 디렉터리에 남아있지만, 메타데이터 트리에서 참조가 끊겨있는, 더 이상 필요없는 파일과 아티팩트들이다.

 

 

remove_orphan_files 에 패스할 수 있는 파라미터들에 대해 알아보자

• 0: table: 테이블 명
• 1: older_than: 기준 시간 (이 시간 이전에 생성된 파일 제거)
• 2: location: 고아 파일을 찾을 위치. 테이블의 기본 위치로 기본 설정
• 3:dry_run: True/False = 파일을 삭제하지 않으며, 삭제할 항목 리스트만 반환한다
• 4: max_concurrent_deletes: 파일을 삭제하는 데 사용할 스레드 수

 

 

 

 

remove_orphan_files를 sparkSQL으로 수행해 보았더니,

현재 스냅샷에 연결된 parquet 파일들만 남기고 미사용 파일들은 삭제되었다!

 

 

 

 

 

 

---

 

 

Rewriting Manifests

매니페스트 파일 병합

rewriteManifests 프로시저를 사용하여 매니페스트 파일만 다시 작성할 수 있다.

→ 매니페스트 파일의 총 개수를 줄이고 적은 수의 매니페스트 파일에 많은 수의 데이터 파일이 나열되도록 합니다.

 

spark.sql("CALL system.rewrite_manifests('temp.test_compaction')"

 

 

실행 권장 시점 시점

데이터 파일 크기가 최적으로 통합된 시점 → 흩어져있는 manifest 파일들을 rewrite 하여 하나로 합쳐준다

 

 

 

 

 

---

 

아이스버그 테이블 사용자들이 스토리지 최적화를 수행하는 방법에 대해 알아보았다.

과거 유력한 경쟁자였던 Hudi와 비교했을 때, 조금 번거롭다는 생각이 많이 들었다....

 

특히 스트리밍 수집용으로 아이스버그를 사용한다면, 필연적으로 스몰 파일이 많이 발생할 수 밖에 없을 것인데,

그러면 최적화를 위하여

컴팩션 → 스냅샷 만료 → 고아 파일 삭제 → 매니페스트 다시 쓰기 

이런 4단계 후처리를 수동으로 구현해야 한다는 것일까....? ㅠ

 

분명 방법이 있겠지...? 책을 통해 아이스버그+Flink와의 조합을 학습하여 보완점을 찾아볼것이다..!

 

---

 

Reference

이 포스팅은 Apache Iceberg The Definitive Guide 4장의 내용에 기반하여 작성하였습니다.
 

 
 

---

관련 포스팅 보기

2025.01.13 - [개발지식 아카이브/Data - Iceberg] - [Apache Iceberg] 아이스버그 테이블 최적화 - 컴팩션과 정렬

[Apache Iceberg] 아이스버그 테이블 최적화 - 컴팩션과 정렬

 

2025.01.13 - [개발지식 아카이브/Data - Iceberg] - [Apache Iceberg] 아이스버그 테이블 최적화 - 파티셔닝

[Apache Iceberg] 아이스버그 테이블 최적화 - 파티셔닝