쿼리 성공만으로는 테이블이 건강한지 알 수 없다
Iceberg 테이블은 현재 snapshot이 manifest를 가리키고, manifest가 실제 data file을 가리키는 계층을 가진다. SQL 조회가 성공해도 작은 파일이 쌓이고 있거나, snapshot이 필요 이상으로 늘어나고 있거나, 특정 파티션에 데이터가 몰리는 문제는 숨어 있을 수 있다.
PyIceberg는 JVM 없이 Python에서 Iceberg catalog와 metadata를 읽는 라이브러리다. 리멤버 공개 사례는 S3 Tables가 유지보수 주기를 완전한 지표로 제공하지 않는 경계를 PyIceberg 기반 자체 수집기로 보완했다.
1. 먼저 알아야 할 metadata
현재 snapshot이 참조하는 data file마다 다음 정보를 가진다.
| 항목 | 운영에서 보는 이유 |
|---|---|
file_path | 어느 파일이 현재 테이블에 포함되는지 추적 |
record_count | 파일별 행 수 편차와 핫 파티션 후보 |
file_size_in_bytes | small file 비율과 compaction 결과 |
partition | 특정 파티션 집중도 |
null_value_counts | 컬럼별 결측 증가와 소스 품질 이상 |
lower_bounds / upper_bounds | 값 범위 이상과 data skipping 가능성 |
이 정보는 데이터 파일 전체를 읽지 않고도 확인할 수 있다. 그래서 대규모 테이블의 구조적 이상을 싸게 탐지하는 데 적합하다.
2. 필수 지표와 질문
Total file count
시간에 따라 계속 늘어나면 compaction이 쓰기 속도를 따라잡지 못하고 있을 수 있다. 단순 개수보다 데이터 용량과 함께 봐야 한다.
Small file ratio
목표 파일 크기의 일정 비율 미만을 small file로 분류한다. 리멤버 공개 사례는 512MB의 75% 미만을 사용했다. 다른 워크로드에서는 목표 크기부터 다시 측정해야 한다.
Average·percentile file size
평균만 보면 몇 개의 큰 파일이 수많은 작은 파일을 숨길 수 있다. p50·p90과 히스토그램을 함께 보면 분포를 읽기 쉽다.
Snapshot age·count
최신 snapshot이 오래되었다면 쓰기가 멈춘 것일 수 있다. snapshot 수가 지속적으로 늘면 만료 정책이 작동하는지 확인해야 한다.
3. 경보는 ‘이상한 값’보다 ‘이상한 변화’에 가까워야 한다
테이블마다 파일 수와 쓰기 주기가 다르다. 고정된 small_files > 100만으로는 오탐이 많아진다. 다음을 함께 쓴다.
- 평소 baseline 대비 증가율
- compaction 예상 주기를 넘긴 지속 시간
- 영향받은 테이블과 주요 쿼리 SLA
- maintenance 로그의 실패와 동일 시간대 지표
관측은 자동 복구와 같은 것이 아니다. 경보에서 어느 작업을 재시작하고, 어느 테이블의 커밋 주기를 늘리고, 언제 쿼리 소비자에게 알릴지까지 runbook으로 연결해야 한다.
4. 데이터 품질과 테이블 건강성을 구분한다
null_value_counts가 늘어나는 것은 업무 데이터 품질 문제일 수 있다. small file 급증은 테이블 물리 운영 문제에 가깝다. 두 신호를 같은 대시보드에 보여 줄 수는 있지만 소유자와 중단 기준은 달라야 한다.