Apache Amoro(Lakehouse Management System) Iceberg Data cleaning 기능 간단 분석
Lakehouse Management System인 Apache Amoro(이하 아모로)의 기능 중에 Data Cleaning 동작 방식을 간단하게 분석해 보았다.
(** 혹시나 내용에 틀린 부분이 있다면 편히 댓글로 알려주시면 감사하겠습니다)
아모로는 말그대로 데이터레이크를 관리해주는 시스템인데 특히 Iceberg를 대상으로 하고 있다. 자체적으로 Mixed format 등을 지원하고 있지만 여기서 필자인 경우 Iceberg 포맷만을 대상으로 아모로가 Data Cleaning(데이터 정리)를 어떻게 해주고 있는지. 그리고 어떤 설정을 해야 의도대로 동작하는지를 정리해 본다.
Iceberg와 Amoro의 공식 설정 정보
Configuration - Apache Iceberg™
Configuration Table properties Iceberg tables support table properties to configure table behavior, like the default split size for readers. Read properties Property Default Description read.split.target-size 134217728 (128 MB) Target size when combining d
iceberg.apache.org
Configurations
Table Configurations Multi-level configuration management Amoro provides configurations that can be configured at the Catalog, Table, and Engine levels. The configuration priority is given first to the Engine, followed by the Table, and finally by the Cata
amoro.apache.org
Data Cleaning 종류
Iceberg 에서 제공하는 데이터 정리 방법은 대표적으로 두 가지다 바로 스냅샷 정리와 고아파일 삭제다. 사실상 이 두개를 잘 동작시키는게 중요한데, 여기서 아모로는 정리하는 방식을 몇가지 더 자체적으로 제공하고 있다. 바로 데이터 만료처리(Data expiration)다. 우리가 일반적으로 알고 있는 Retention(보관기간) 개념이다. 그냥 주기적으로 Delete Query를 날려준다고 생각하면 된다.
필자가 이 데이터 정리 기능들을 정리하면서 확실히 이해하고 싶었던 부분은 바로 "논리/물리적인 삭제" 와 물리적인 삭제에 있어 Iceberg 라이브러리가 어디까지 관여하고 있냐 였다.
논리 삭제
데이터 기간 만료(Data expiration)
특정 기간이 지난 데이터를 delete query로 삭제한다. 논리적으로만 삭제하므로 물리적으로 스토리지 공간을 확보하는 과정이 아니다. 이 작업이 진행된 후 아래 설명할 스냅샷 만료를 동반해야 물리적인 공간을 확보하게 된다.
아모로 고유 속성이다. 원래 iceberg에서는 스냅샷 만료 부분으로만 얘기한다.
데이터 만료처리를 하면 아모로는 주기적으로 Executor를 실행하여 기간이 만료된 데이터들을 Delete query로 삭제한다.
Executor의 주기는 설정할 수 있고, 전체 테이블 갯수를 고려하여 스레드 갯수도 조절 가능하다.
이 데이터 만료처리는 테이블 별로 가능하다. 아모로의 장점이자 단점인데, 테이블별로 데이터 정리를 설정할 수 있다는 점이 큰 장점이나 반대로 처리를 위한 테이블 속성을 설정해야하는데 이 설정 값이 너무 "일반적"인 이름을 쓰고 있어 iceberg 에서 사용하는 고유 설정과 헷갈린다는 점이다(amoro 라는 prefix라도 붙여주지 좀..)
데이터 만료처리 기능을 사용하고 싶다면 기본적으로 다음의 테이블 속성을 설정해야 한다. 참고로 공식 문서에는 좀 더 다양한 설정을 할 수 있다.
| data-expire.enabled | 기능 활성화 여부(true or false) |
| data-expire.field | 삭제기준이되는 timestamp 컬럼필드 이름 |
| data-expire.retention-time | 삭제 기준이 되는 만료기간(d, h, min 등으로 단위 표시 가능) |
만료 작업후 생성되는 스냅샷에는 다음과 같은 정보가 셋팅된다.
snapshot.producer: DATA_EXPIRATION (이외에 OPTIMIZE, CLEAN_DANGLING_DELETE 가 있다)이 부분이 중요한데, 스냅샷 만료처리 시에 아모로는 이 3가지의 동작 정보가 기록된 스냅샷의 생성 시점을 기준으로 삼지 않는다.(무시한다는 얘기)
논리 & 물리 삭제
댕글링 삭제파일 제거(clean dangling delete files)
아모로 고유 동작이다. 데이터파일 적용이 더이상 안되는 pos-delete, eq-delete 파일을 제거하는 작업이다. 여기서는 설명하지 않지만 아모로의 대표적인 기능인 옵티마이징(https://amoro.apache.org/docs/latest/self-optimizing/)으로 인한 고아파일들을 정리하는데 주로 쓰인다. 사실 이는 고아파일 제거 작업에 포함되는거라서 굳이 사용해야하나 싶은데, 아무래도 update,delete가 잦은 CDC인 경우 강력한 효과를 발휘하는 아모로의 옵티마이징 기능이 동작함에 있어, 고아파일 정리로 인한 부하를 줄이기 위해 이 댕글링 삭제파일을 제거하는 걸 별도 분리하여 동작시키는 걸로 보인다.
스냅샷 만료(Snapshot expiration)
가장 중요한 작업중 하나이다. 물리적인 파일 삭제는 아모로 에서는 자체적으로 구현하고 있다. 즉 어떤 스냅샷과 파일들을 지울지는 iceberg api를 통해 결정하나 실제 물리적인 파일 삭제 작업은 아모로에서 직접 한다. 스냅샷 executor는 1시간 마다 동작하도록 실행주기가 고정되어 있다.
아모로는 기본적으로 테이블의 스냅샷을 12시간 기준으로 만료처리한다. 이 값을 변경하고 싶다면 다음의 테이블 속성을 설정해야 한다.
snapshot.base.keep.minutes: (기본값: 720)참고로 delete query를 통해서 생성한 스냅샷이라도 어떤 파일들이 delete 되었는지 스냅샷에 포함되기 때문에 삭제기록된 파일들은 물리적으로 삭제되지 않는다. → 다음 스냅샷에서 해당 파일들이 삭제되는 스냅샷에만 포함되기 때문에 삭제 처리가 된다.
예시: 데이터 삽입(1번 스냅샷 생성) → 데이터 삭제(2번 스냅샷 생성) → 1번 스냅샷 만료 처리(2번에 삭제 기록이 되어있지만 그것조차 ref되어 있는 거라서 물리적인 삭제가 되지 않음) → 데이터 삽입(3번 스냅샷 생성) → 2번 스냅샷 만료 처리(이제서야 물리적인 파일 삭제됨)
또한 위에서 언급한 데이터 만료처리시에 생성된 스냅샷은 기준점으로 삼지 않는다. 가령 데이터 삭제로 인해서 스냅샷이 생성된 시점이 12시이고 그 전에 일반적으로 생성된 스냅샷이 11시라면, 아모로는 스냅샷 만료처리 기준을 12시가 아닌 11를 기준으로 12시간을 넘어간 스냅샷을 만료처리한다.
고아파일 제거(clean orphan files)
고아파일제거는 스냅샷 만큼이나 가장 중요한 작업중 하나이다. 물리적인 파일 삭제는 아모로 에서는 자체적으로 구현하고 있다. 이 기능은 기본적으로 아모로에서는 비활성화 되어있다. 그러므로 그냥 아모로만 적용하면 알아서 물리파일을 삭제해주겠지 생각하면 안된다는 것이다.
다음의 테이블 속성을 설정해야 아모로 에서 고아파일 삭제를 진행한다. 이 executor도 스냅샷과 같이 실행주기가 고정되어 있다. 고아파일 정리는 실행주기가 1일 이다.
| clean-orphan-file.enabled | 고아파일 제거 기능 활성화 여부(true or false) |
| clean-orphan-file.min-existing-time-minutes | 고아파일이더라도 현재 기준 특정 시간이내에 생성된 파일이라면 지우지 않는다. 기본값 2880(2일) |
스냅샷 만료와의 차이
스냅샷 만료인 경우 삭제되는 스냅샷에서 지울 파일을 찾아서 지운다. 하지만 고아파일은 모든 파일을 확인한 후, 유효한 메니페이스에서 참조가 없는걸 지운다. 한마디로 어마어마한 부하가 발생할 수 있다.
데이터 파일 제거
data 디렉토리에 있는 모든 데이터 파일을 확인해서 고아파일을 삭제한다.
메타데이터 파일 제거
metadata 디렉토리에 있는 모든 파일(메타데이터, 매니페스트리스트, 매니페스트)을 확인한다.
pointing 되는 메타데이터를 보면 metadata-log 필드가 존재하고, 여기에는 기존 메타데이터 파일들에 대한 기록이 있다. 여기에 없는 메타데이터 파일을 삭제한다.
참고로 아래 두 개 설정을 추가로하지 않으면, 아모로는 메타데이터 디렉토리의 메타데이터 파일은 정리하지 않는다. 다음 두개 설정은 아모로가 아닌 iceberg 고유 속성이다. 또한 clean-orphan-file.min-existing-time-minutes 를 적용하더라도 아래 속성에 해당되면 삭제하지 않는다.
| write.metadata.delete-after-commit.enabled | 메테데이터 정리 여부 (true or false) |
| write.metadata.previous-versions-max | 메타데이터 파일을 최대 몇개까지 유지할지 결정할 수 있다. |
매니페스트 리스트와 메니페스트는 위 속성과 관계없이 삭제된다.
아모로는 clean-orphan-file.min-existing-time-minutes 기능을 제공하여 커밋과 고아파일 삭제의 타이밍 이슈를 방지한다.(데이터 파일을 생성하고 커밋을 하기전 고아파일정리가 동작하면 데이터가 없는 메타데이터파일 생성되는 문제)
속성값 총 정리
아모로를 적용할 때 테이블에 적용해야할 기본적인 설정값들은 다음과 같다.
공통
clean-orphan-file.enabled: true
write.metadata.delete-after-commit.enabled: true
data-expire.enabled: true테이블별
data-expire.retention-time: 100d # 100일 지난 데이터를 삭제(delete query). 기본값 NULL(없음)
data-expire.field: 컬럼이름 # 삭제 기준 필드(timestamp인 컬럼),기본값 NULL(없음, 그냥 enabled만 하면 에러남)
write.metadata.previous-versions-max: 10 # metadata-log에 남길 최대 기존 metadata 파일 갯수. 기본값 없음(iceberg 고유속성)
clean-orphan-file.min-existing-time-minutes: 2880 (2d) # 현재시간 기준 2일이 지난 고아파일 삭제. 기본값 2일
snapshot.base.keep.minutes: 720 (12h) # 스냅샷 TTL (최소 유지갯수는 무조건 1개). 기본값 12시간
정리
이렇게 해서 아모로의 데이터 정리 기능에는 어떤 것들이 있나 간단히 살펴보았다. 사실 분석을 하고나서보니 코드가 어렵지 않아서 직접 구현하여 적용하는게 좀 더 낫지 않을까 생각도 들었다. 아모로가 인큐베이팅 수준인지라 현재 최신버전이 0.7.1 버전을 적용하더라도 iceberg 라이브버전이 1.4.3 이라는 점이다. 이는 현재 빠르게 버전업이 이루어지고 있는 iceberg 에 비해서 늦다는 생각이 들고, 성능면에서 차라리 스파크를 이용하는게 낫지 않나(옵티마이징은 다행히 스파크나 플링크를 쓸수 있지만) 싶다. 특히 AMS 컴포넌트에서 스레드를 이용해서 하고 있는데, 관리해야할 데이터가 많아질수록 병렬처리를 감당할수 있을까 하는 물음이 있다. (테스트상 AMS 단일 Pod가 먹는 메모리고 꽤 된다)
Iceberg가 오픈테이블 포맷이다 보니 이를 다루는 다양한 테크닉들이 있는거 같다. 아마도 아모로보다도 더 성능좋고 안정적인 프로젝트가 나오지 않을까 예상도 해본다.