[트러블 슈팅] Iceberg Maintenance -- 현재 구현 & 개선 고민

1. 현재 구현 - 어떻게 동작하는가

1-1. 어떤 부분에 대해 고민을 했는가

• `iceberg_maintenance.py`가 Bronze 4테이블 + Silver 1 테이블을 정리한다.
• Gold 테이블은 대상에 없다. (당연히 maintenance 잡이 Gold 가 생기기 전에 만들어지기 때문에 미포함됨)

1-2. maintenance가 동작하는 방식 

3가지 연산이 있고,
순서는 compact → expire → orphan

연산	Iceberg	설정
compaction	`rewrite_data_files`	`min-input-file=5`(5개 미만 파티션은 스킵), `target-file-size=128MB`, `partial-progress.enabled`(OCC 충동 시 부분 커밋)
expire	`expire_snapshots`	보존 7일, 최근 `retain_last=5`개는 무조건 보존
orphan	`remove_orphan_files`	`older_than=72h` (in-flight 파일 보호), 24h 미만은 24h로 클램프

1-3. 자동화 방식(DAG)

• `iceberg_maintenance` DAG: `schedule="0 4 * * *"`(매일 04:00) - 
  Silver 배치(자정)와 시간대 분리 → compaction <-> MERGE OCC 충돌 회피 (이 부분은 뒤에 고민 부분에 또 나옴)
• 태스크 순서: `compact → expire → orphan`

1-4. 고민 포인트

• OCC를 "시간대 분리"로만 회피한거다 솔직히.
  별도 DAG라 Silver와 안 겹치게 04:00으로 둔거다. → 다만 테이블 빈도가 늘면 자연스럽게 깨뜻한 창을 찾기는 어려울거다.

---

2. 왜 이러한 고민들이 나왔는가

2-1. 통짜 maintenance DAG는 테이블이 늘수록 비대해진다

• 하나의 DAG가 모든 테이블을 순회 → 테이블 N개면 런타임 N배 → 자연스럽게 04:00을 침범하게 될거다 (겹침 무조건)
• 자정에 쓴 테이블이 04:00까지 압축 안 된 채 방치(staleness)
• 쓰기와 안 겹치는 OCC 창을 매번 찾아야함
• 테이블 추가 = maintenance DAG 수정(결함)

2-2. 아이디어1 - maintenance를 "레이어별 테이블 쓰기 직후"에 붙이기

• 별도 DAG가 아니라, 각 레이어별 테이블이 만들어진 뒤 마지막 절차처럼 compaction이 따라붙게 하는거다.
• 효과: 쓰기-압축 직렬화 → OCC 충돌 제거(시간대 분리 로직이 불필요), locality(fresh할때 압축), 테이블별 분산

2-3. 아이디어1 의 한계 - 3개를 다 붙이면 expire/orphan이 헛돈다

근데 maintenance 3개를 전부 테이블 뒤에 붙이면,

compaction은 그렇다 쳐도 expire/orphan이 불필요하게 돌게 된다.

 

그 이유는 연산이 "쓰기에 묶이는지" vs "시간에 묶이는지"가 다르기 때문이다.

연산	무엇에 트리거 되나	그래서
compaction	쓰기 - 이번 쓰기가 방금 small file을 만듦	쓰기 직후가 맞음
expire	시간 - 스냅샷이 시간 지나며 늙음 (7일 경과)	주기가 맞음
orphan	시간/실패 - 실패가 남긴 쓰레기를 이따금 청소	주기가 맞음

 

- expire: 하는 일이 "7일보다 오래된 스냅샷 제거"인데, 쓰기 한 번으로는 지울 대상이 안 생긴다(방금 만든 스냅샷은 안 늙었으니까).
매 쓰기마다 돌리면 거의 매번 "지울 것 없음" 헛바퀴.
시간당 쓰기면 하루 24번 중 23번이 빈탕이다. 하루 1번이면 그날 늙은 걸 한 번에 잡는다.

- orphan: 정상적으로 쓰면 고아가 안 생긴다(커밋 깨끗 = 다 참조됨).
고아는 실패 때나 가끔 생긴다. 게다가 orphan은 테이블 폴더 전체를 S3 LIST해서 메타와 대조한다 → 매 쓰기마다 전체 파일 목록 스캔, 거의 항상 0건인데 비용은 O(전체 파일 수). ← 이게 제일 나쁘다(스케일에서 매 쓰기마다 수백만 파일 LIST).

→ 즉 "매번 할 일(compaction)"과 "가끔 몰아서 할 일(expire/orphan)"을 섞으면 안 된다.

2-4. 결론 - 하이브리드

그래서 셋을 통짜로 인라인하지 않고 나눈다.

[메달리온 DAG]  쓰기 + compaction 인라인
   silver_merge >> compact_silver
   gold_agg     >> compact_gold        ← small file 생기는 곳만, 쓰기 직후

[GC DAG]  시간 기반 청소는 주기 분리(지금처럼)
   expire >> orphan  (+ 월간 rewrite_manifests)

• compaction = 인라인: 방금 쓴 small file 정리 + OCC 없음
  `min-input-files=5`로 self-throttle(할게 없으면 no-op, 스냅샷도 안 만듦) → 자주 따라 붙어도 안 비싸다.
• exprire/orphan = 주기 분리: 시간 지나 쌓인 것만 몰아서 청소

---

3.. 또 다른 고민 - 하이브리드 방식은 관리 포인트를 늘리는게 아닐까?

3-1. 우려

근데 이렇게 "매번 할 일(compaction)"과 "가끔 몰아서 할 일(expire/orphan)"을 나누면, 관리포인트가 늘어나는게 아닐까 생각했다.

 

예를들어 "아 maintenance 로직 좀 봐야지" 하고 들어갔는데

여기(메달리온 DAG)엔 매번 할 일, 저기 (GC DAG)엔 가끔 할일~ 이렇게 흩어져 있으면,

추후 maintenance 로직을 추가할 때 이 task별 특징(매번? 주기)까지 고려해야하는 거다.

아니면 이게 당연한건가..?

3-2. 따져본 결과 - task별 특징 고려는 부담이 아니라 당연한거다

새 maintenance를 추가할때, "이거 매번 돌려? 주기로 돌려? 얼마나 비싸? 쓰기랑 충돌해?"는

구조랑 상관없이 무조건 답할 수 있어야 하는 질문들이다.

• 예: 나중에 `rewrite_manifests`(매니페스트압축)를 추가한다 → "시간 기반 비쌈, 월 1회"라고 어차피 분류하게 된다.
• 우리 구조는 그 분류를 강제할 뿐, 없던 일을 새로 만드는건 아니다.

→ 즉 cadence(실행주기)는 maintenance의 핵심 설계 속성이라 어차피 정해야한다는것이다.

구조가 그걸 눈에 보이게 만들어주는 거다. 당연하고, 오히려 좋은 것들이다.

3-3. 우려했던 discoverability 비용은 이렇게 줄인다 - 로직은 모으고, 시점만 분리

핵심: 흩어지는 건 "코드(로직)"가 아니라 "실행 시점(스케줄)" 이어야 한다.

iceberg_maintenance.py   ← compact/expire/orphan/... 연산이 전부 여기 (단일 출처)
                            "어떤 maintenance가 있나" = 이 파일 하나만 보면 됨

DAG는 "언제 도는지"만 wiring:
  메달리온 DAG  → compact 호출      (write-driven)
  GC DAG        → expire/orphan 호출 (time-driven)

→ 그러면:

• 무엇이 있나 = 모듈 한 곳에서 다 보임
• 언제 도나 = DAG가 원릳로 분류
• 왜 그렇게 나눴나 = 매핑 문서 한 줄("연산 → cadence → write/time-driven")

즉 두 군데로 흩어졌다가 아니라, 로직은 한곳에 모이고 cadence만 DAG로 나뉘는 구조인것이다.