iceberg , 아이스버그 개념 및 아키텍처

 

#  히스토리 

원래는 오픈 소스 분산 컴퓨팅 프레임워크인 하둡과 그 구성 요소인 HDFS 파일 시스템을 사용하여 
저렴한 컴퓨터 클러스터에 걸쳐 대량의 정형 및 비정형 데이터 세트를 저장하고 처리했다.
하지만 단순히 이 모든 데이터를 저장하는 것만으로는 충분하지 않았다. 
하둡 생태계에는 MapReduce라는 분석 프레임워크가 포함되어 있었는데, 이를 통해 자바로 분석 작업을 작성하고 하둡 클러스터에서 실행할 수 있었다.
MapReduce 작업을 작성하는 것은 장황하고 복잡했으며, 많은 분석가들은 Java보다 SQL을 작성하는 데 더 익숙했기 때문에 
SQL 문을 MapReduce 작업으로 변환하기 위해 Hive가 만들어졌다.

SQL을 작성하려면 저장소에 있는 파일 중 특정 데이터 세트 또는 테이블에 속하는 파일을 구분하는 메커니즘이 필요했다.
이로 인해 디렉토리와 그 안의 파일들을 테이블로 인식하는 Hive 테이블 형식이 탄생했다.

Parquet가 파일 수준의 저장 효율 문제를 해결한 반면, 그 파일들의 집합을 "테이블"로 관리하는 체계는 오랫동안 Hive Metastore에 의존해왔으나
곧, 기존  Hive 기반 테이블 관리가 갖는 구조적 결함(디렉토리 기반 파티션, 스키마 진화 불가, 트랜잭션 부재)에 직면했다.

(Hive의 테이블 관리 방식은 본질적으로 "특정 HDFS 디렉토리에 있는 파일들의 집합 = 테이블"이라는 디렉토리 기반 패러다임에 기초한다.)

1. 파티션 관리의 경직성
파티션 컬럼을 추가하거나 파티셔닝 전략을 변경하려면 기존 데이터 전체를 새 디렉토리 구조로 물리적으로 이동하거나 재작성해야 한다.

2. 원자적 트랜잭션(Atomic Transaction)의 부재 
Hive에서 데이터를 업데이트하려면 해당 파티션 디렉토리의 파일을 덮어쓰거나 삭제하고 새 파일을 쓰는 방식을 취하는데, 
이 과정 중 다른 쿼리가 해당 파티션을 읽으면 절반만 완성된 상태의 데이터를 보게 된다.
이는 ACID 4가지 속성(Atomicity·Consistency·Isolation·Durability) 중 Isolation(격리성)이 전혀 보장되지 않음을 의미한다.

3. 스키마 진화의 불안전성 
 Hive에서 컬럼을 추가하거나 타입을 변경하면, 이미 디스크에 존재하는 구 포맷의 Parquet 파일과 신규 스키마 사이의 정합성을 Metastore가 보장하지 못한다.

컬럼 이름 기반으로 필드를 매핑하기 때문에, 컬럼 이름이 같더라도 의미가 다른 경우 데이터 오염이 발생한다.

⇒ 즉, 데이터 수정 (update/delete) 가 불안정하고 트랜잭션 관리가 안된다. 스키마 변경시 보장되지 않는다.

 

---

# 기본 철학

Table Format (테이블 포맷): 개별 파일 단위가 아닌, 전체 데이터 집합을 하나의 테이블 단위로 관리하는 규격.
File-level Tracking: 디렉토리 경로가 아니라 파일 목록을 직접 관리하여 성능 최적화.
Engine Agnostic: 임팔라(Impala)뿐만 아니라 Spark, Flink, Trino 등 다양한 엔진에서 공용 가능.

 

# 왜 Iceberg를 사용하는가?

대규모 데이터셋에 적합한 성능과 확장성
    - 테이블 메타데이터를 계층적으로 관리해 수십만~수백만 개 파일도 빠르게 탐색 가능
    - 기존 Hive 테이블에서 발생하는 느린 메타데이터 스캔 문제 해결

스키마 진화 및 파티션 진화 지원
    - 컬럼 추가, 삭제, 이름 변경 등 스키마 변경을 안전하게 수행 가능
    - 파티션 필드도 변경 가능 (기존 Hive는 불가능)

ACID 트랜잭션 지원
    - 데이터 읽기/쓰기 시 일관성 보장
    - 복수 클라이언트 동시 쓰기 지원
    - RDBMS의 Update, Delete와 같은 작업을 반영할 수 있음

시간 여행 (Time Travel) 쿼리 기능
    - 과거 특정 시점 테이블 데이터 조회 가능
    - 실수로 삭제한 데이터 복구 가능

효율적인 스캔과 푸쉬다운 필터
     - 메타데이터 기반의 데이터 파일 필터링으로 불필요한 데이터 읽기 최소화

다양한 처리 엔진 지원
     - Apache Spark, Flink, Trino, Presto 등 여러 엔진과 호환됨

⇒ 파케이로 구성된 파일 집합을 어떻게 잘 관리 할 것인가? 주요 포인트이다.

# 핵심 아키텍처 요약

Snapshot (스냅샷): 특정 시점의 테이블 상태를 나타내는 최상위 개념.
Metadata File (JSON): 테이블의 스키마, 파티션 정보, 현재 스냅샷 포인터를 포함한 파일.
Manifest List (Avro): 특정 스냅샷을 구성하는 매니페스트 파일들의 목록.
Manifest File (Avro): 실제 데이터 파일(Parquet/ORC)의 경로와 통계 정보(최소/최댓값 등)를 담은 파일.
Data File: 실제 사용자 데이터가 저장된 물리 파일 (주로 Parquet 포맷).

 

 

 

이 구조는 5가지로 구성된다.

- Catalog (카탈로그) : 테이블 이름과 최근 활성화된 Metadata File의 위치 간의 매핑을 저장하는 서비스
- Metadata File(메타데이터 파일) : 테이블의 스키마 이력 전체, 파티션 스펙 이력 전체, 그리고 지금까지 생성된 모든 Snapshot의 목록과 현재 Snapshot ID를 담는 JSON 파일
- Manifest List( 매니페스트 리스트): 특정 Snapshot 시점에 매니페스트 파일 목록과 해당 매니페스트에 대한 통계 정보를 기록 (파티션별 value count, null count, lower bound 등) 
- Manifest File (매니페스트 파일): 각 데이터 파일의 위치/경로와 해당 데이터 파일에 대한 주요 메타데이터가 포함
- Data File(데이터 파일): Data File은 실제 데이터가 저장된 물리 파일로, 대부분의 경우 Apache Parquet 형식

 

 

동작원리 

쓰기 연산시 동작 과정

 

Iceberg의 모든 쓰기 연산(INSERT, OVERWRITE)은 다음의 순서로 진행된다.

1. Writer가 새 Parquet Data File(들)을 오브젝트 스토리지에 기록한다. (새 .parquet 파일 생성)

2. Writer가 신규 Data File을 포함하는 새로운 Manifest File을 생성한다.

3. Writer가 기존 Manifest File/ 새 Manifest File을 포함하는 새로운 Manifest List를 생성한다.

4. Writer가 새 Snapshot(새 Manifest List를 가리키는)을 포함하는 새로운 Metadata File을 생성한다.

5. Writer가 Catalog에 현재 Metadata File 경로를 새 Metadata File 경로로 교체해달라는 Commit 요청을 보낸다.

    이 Commit 요청은 CAS 연산으로, Catalog가 현재 가리키는 경로가 Writer가 읽었던 경로와 동일할 때만 성공한다.

    (metadata.json 원자적 교체 (current-snapshot-id 변경)

 

 

# 주요 기능

Hidden Partitioning (숨겨진 파티셔닝): 사용자가 쿼리에 파티션 칼럼을 명시하지 않아도 엔진이 알아서 최적의 데이터를 찾는 기능.
Schema Evolution (스키마 진화): 기존 데이터를 건드리지 않고 칼럼 추가, 삭제, 이름 변경, 타입 변경 가능.
Partition Evolution(파티션 진화): 데이터 재구성 없이 파티션 정책을 중간에 변경 가능.
Time Travel (타임 트래블): 과거의 특정 스냅샷 ID나 시점으로 돌아가 데이터를 조회.
ACID Transactions: 다수의 엔진이 동시에 읽고 써도 데이터 일관성을 보장 (낙관적 동시성 제어).

 

히든 파티셔닝 

Hive의 파티셔닝 방식부터 이해해야 한다. 
Hive에서 날짜 기준 파티션을 쓰려면 테이블에 dt라는 파티션 컬럼을 별도로 만들고, 데이터를 쓸 때 dt='2024-01-15' 값을 직접 채워야 했다. 
쿼리할 때도 WHERE dt = '2024-01-15'처럼 파티션 컬럼을 명시해야만 파티션 pruning이 동작했다. 
이 컬럼을 빠뜨리면 전체 데이터를 풀스캔했다. 이 방식의 문제는 두 가지다. 
첫째, 파티션 컬럼 관리가 사용자 책임이라 실수하기 쉽다.  event_timestamp에서 날짜를 추출해서 dt에 채워 넣는 ETL 로직을 매번 작성해야 한다. 
둘째, 사용자가 파티션 구조를 알고 있어야만 효율적인 쿼리를 쓸 수 있다. 테이블 내부 구현이 쿼리 작성 방식을 강제하는 것이다.

Iceberg는 파티션을 컬럼이 아니라 변환 함수(transform)로 정의한다.


CREATE TABLE orders (
    order_id    BIGINT,
    customer_id BIGINT,
    event_ts    TIMESTAMP,
    amount      DECIMAL(10,2)
)
PARTITIONED BY (day(event_ts), bucket(16, customer_id));

 

 

Schema Evolution

운영 중인 테이블의 스키마는 반드시 변한다. 

서비스가 성장하면서 새로운 속성이 추가되고, 컬럼 이름이 더 명확한 것으로 바뀌고, 타입이 좁아서 widening이 필요해진다. 

기존 Hive에서는 스키마 변경이 기존 파일과의 불일치를 만들어 데이터가 깨지는 경우가 많았다.

 

Iceberg가 스키마 진화를 안전하게 구현하는 핵심은 컬럼에 고유한 정수 ID를 부여하는 것이다.

컬럼 이름: user_name  →  컬럼 ID: 3

컬럼 이름: email      →  컬럼 ID: 5

컬럼 이름: age        →  컬럼 ID: 7

 

컬럼 이름을 user_name에서 username으로 바꿔도, ID는 3으로 유지된다.

 Iceberg는 Parquet 파일을 읽을 때 컬럼 이름이 아니라 이 ID로 매핑한다. 

따라서 이름이 바뀌어도 기존 파일을 재작성할 필요가 없다.

 

파티션 진화

 

 

파티션 전략은 데이터 규모와 쿼리 패턴에 따라 최적점이 달라진다. 
초기에 데이터가 적을 때는 월(month) 단위 파티션으로 충분하지만, 데이터가 쌓이면 일(day) 단위가 필요하고, 더 커지면 시간(hour) 단위로 세분화해야 한다.

기존 Hive에서 파티션 전략을 바꾸는 것은 전체 데이터를 재파티셔닝하는 작업을 의미했다. 
수십 TB의 데이터라면 며칠이 걸리는 작업이고, 그 동안 테이블 운영이 중단된다.

Iceberg에서 파티션 전략을 변경하면, 변경 이전에 작성된 파일과 이후에 작성된 파일이 서로 다른 파티션 레이아웃을 갖게 된다.
Iceberg는 이것을 Partition Spec이라는 버전으로 관리한다.

[초기]
Partition Spec v1: month(event_ts)
→ 작성된 파일들: /data/month=2023-01/, /data/month=2023-02/ ...

[파티션 전략 변경]
ALTER TABLE orders SET PARTITION SPEC (day(event_ts));

Partition Spec v2: day(event_ts)
→ 이후 작성 파일들: /data/day=2024-01-15/, /data/day=2024-01-16/ ...

 

 

<재작성 없이 전환이 가능한 이유>

 

Iceberg의 메타데이터 레이어가 이 복잡성을 흡수하기 때문이다. 
데이터 파일 자체는 한 번 쓰여지면 변하지 않는다. 어떤 파티션 전략으로 그 파일을 읽을지는 메타데이터가 결정한다. 
물리적 데이터와 논리적 파티션 전략을 분리한 것이 핵심 설계 결정이다.

단, 파티션 전환 이후 완전히 새로운 파티션 전략으로만 구성된 테이블을 원한다면 기존 파일을 새 전략으로 rewrite하는 작업이 별도로 필요하다. 
파티션 진화는 그 재작성이 즉시 필요하지 않게 해줄 뿐이다.

 

 

Time Travel

Iceberg의 모든 쓰기 작업은 새로운 스냅샷을 만들고, 이전 스냅샷은 만료되기 전까지 보존된다. 
각 스냅샷은 고유한 snapshot-id와 생성 timestamp를 가진다.

 

snapshot-id: 1001  |  timestamp: 2024-01-14 09:00:00
snapshot-id: 1002  |  timestamp: 2024-01-15 10:30:00  ← current
snapshot-id: 1003  |  timestamp: 2024-01-15 14:00:00


< 보존 기간과 비용의 트레이드오프 >
스냅샷이 보존되는 동안은 그 스냅샷이 참조하는 파일도 삭제할 수 없다. 
즉, 타임 트래블 범위가 길수록 스토리지 비용이 높아진다. 삭제된 데이터조차 스냅샷이 살아있는 동안은 실제로 삭제되지 않는다.

 

ACID Transactions

ACID

Atomicity — 
쓰기가 완전히 성공하거나 완전히 실패한다. 
절반만 쓰여진 상태가 존재하지 않는다. Iceberg는 새 metadata.json을 원자적으로 교체하는 것으로 이를 구현한다.
 파일 작성이 다 끝난 후 metadata만 교체하므로, 교체 전까지는 새 데이터가 보이지 않는다.

Consistency — 
모든 읽기는 항상 완전한 상태의 테이블을 본다. 쓰기가 진행 중인 상태의 데이터를 읽는 것이 불가능하다.

Isolation — 
여러 엔진이 동시에 같은 테이블에 접근해도 서로 영향을 주지 않는다. 
읽기는 항상 특정 스냅샷을 고정해서 읽으므로, 읽는 도중 새로운 쓰기가 완료되어도 읽기 결과가 변하지 않는다(Snapshot Isolation).

Durability —
metadata.json이 성공적으로 교체된 이후에는 시스템 장애가 발생해도 그 커밋은 영구히 보존된다.
파일이 S3 같은 내구성 높은 스토리지에 있기 때문이다.

낙관적 동시성 제어 (Optimistic Concurrency Control)

Iceberg는 비관적 잠금(pessimistic lock) 대신 낙관적 동시성 제어를 사용한다.
이것이 데이터 레이크 환경에 더 적합한 이유는 분산 환경에서 중앙 잠금 서버를 두는 것이 성능 병목이 되기 때문이다. 
낙관적 방식의 흐름은 이렇다.

Writer A와 Writer B가 동시에 같은 테이블에 쓰려 한다.

1. 둘 다 현재 metadata 버전(v5)을 읽는다.
2. 둘 다 각자의 변경 작업을 수행한다 (파일 작성).
3. Writer A가 먼저 metadata v5 → v6 교체를 시도하고 성공한다.
4. Writer B가 metadata v5 → v6 교체를 시도하지만,
   현재 metadata가 이미 v6이 되어 있음을 감지한다.
5. Writer B는 충돌로 판단하고 retry한다.
   v6을 base로 다시 계획을 수립하고 교체를 시도한다.

충돌 감지는 Catalog(Hive Metastore, Nessie, REST Catalog 등)가 담당한다. 
Catalog는 metadata 파일의 현재 버전을 관리하며, 교체 요청 시 base version이 현재 version과 일치하는 경우에만 교체를 허용한다.

< 기존 데이터 레이크와의 차이 >
[기존 S3 + Hive 방식] 
Writer A: file_a.parquet 작성 중 
Writer B: 동시에 같은 파티션에 file_b.parquet 작성 중 
→ 둘 다 성공, 테이블은 두 파일을 모두 보유 
→ 어느 것이 최신인지 알 수 없음 
→ Reader는 불완전한 상태를 읽을 수 있음 

[Iceberg 방식] 
Writer A: 파일 작성 완료 → metadata 교체 성공 
Writer B: 파일 작성 완료 → metadata 교체 실패 감지 → retry 
→ Reader는 항상 완전한 스냅샷만 읽음 
→ 어떤 타이밍에 읽어도 일관된 결과

 

 

---

# 운영 최적화 및 고도화 (Optimization & Ops)  

Compaction (컴팩션): 작게 쪼개진 여러 파일을 큰 파일로 합쳐 읽기 효율을 높이는 작업.
Snapshot Retention: 오래된 스냅샷을 삭제하여 저장 공간을 확보하는 정책.
Copy-on-Write (CoW): 데이터 수정 시 전체 파일을 새로 쓰는 방식 (읽기 최적화).
Merge-on-Read (MoR): 변경 사항만 별도 파일(Delete file)에 기록하고 읽을 때 합치는 방식 (쓰기 최적화).
Catalog (카탈로그): 아이스버그의 최신 메타데이터 위치를 가리키는 중앙 저장소 (Hive Metastore, Hadoop, AWS Glue 등).

 

 

 Compaction (컴팩션)

 

Iceberg 테이블을 운영하다 보면 시간이 지날수록 두 가지 문제가 자연스럽게 발생한다.

1. Small File Problem 
스트리밍 파이프라인이나 잦은 배치 쓰기는 매번 소규모 Parquet 파일을 만들어낸다. 
Spark Structured Streaming이 10초마다 커밋하면 하루에 8,640개의 파일이 생긴다. 
한 달이면 26만 개다. 쿼리 엔진이 이 파일들을 읽으려면 S3에 수십만 번의 파일 오픈 요청을 보내야 한다. 
S3는 파일 하나를 여는 데 수십ms의 latency가 있으므로, 파일 수 자체가 쿼리 성능의 병목이 된다.

2.  Delete File Accumulation 
 MoR 방식에서 업데이트와 삭제는 delete file을 쌓는다. 이 파일들이 쌓일수록 읽기 시 병합 비용이 늘어난다.
Compaction은 이 두 문제를 모두 해결하는 주기적 유지보수 작업이다.

두 가지 Compaction 유형

rewrite_data_files 
여러 개의 작은 데이터 파일을 읽어서 최적 크기의 큰 파일로 재작성한다. 
이 과정에서 delete file에 기록된 변경 사항도 실제 데이터에 반영하여 delete file을 제거한다.

rewrite_position_delete_files 
여러 개의 position delete 파일을 하나로 합친다. 
데이터 파일 자체는 건드리지 않고 delete 파일만 정리한다. rewrite_data_files보다 가볍고 빠르다.

Compaction 전략 — Binpacking vs Sorting

Compaction은 단순히 파일을 합치는 것 이상을 할 수 있다.
Binpacking은 기본 전략이다. 
여러 파일을 target 크기에 맞게 묶어서 재작성한다. 파일 수를 줄이는 것이 목적이다.

Sorting은 재작성할 때 특정 컬럼 기준으로 데이터를 정렬한다. 
정렬된 데이터는 Parquet의 Row Group 통계가 훨씬 정확해지고, Predicate Pushdown의 효과가 극대화된다. 
예를 들어 customer_id로 정렬하면 특정 고객 데이터를 읽을 때 전체 파일의 극히 일부만 스캔하면 된다.

** 참고 : 
Compaction 자체가 compute를 소비하므로, 쓰기 TPS와 Compaction throughput 사이의 균형을 설계해야 한다. 
쓰기 속도보다 Compaction이 느리면 파일은 계속 쌓인다.

Compaction과 스냅샷의 관계

Compaction은 새 스냅샷을 생성한다. 
기존 파일을 지우는 게 아니라, 새로 재작성된 파일을 가리키는 새 스냅샷을 만든다. 
기존 파일과 스냅샷은 만료 정책에 따라 나중에 정리된다. 
따라서 Compaction 직후에는 오히려 파일 수와 스토리지 사용량이 일시적으로 늘어난다.

 

Copy-on-Write (CoW) page.87

copy-on-Write는 수정이 발생할 때, 해당 행이 포함된 파일 전체를 다시 쓴다. 
수정된 행을 반영한 새 파일로 교체하고, 기존 파일은 폐기(다음 스냅샷에서 더 이상 참조 안 됨)한다. 
읽기는 단순하다 . 항상 완전한 Parquet 파일만 존재하므로 그냥 읽으면 된다.

 

CoW:
  쓰기: 파일 전체 재작성 (비용 큼)
  읽기: 단순 파일 스캔 (비용 작음)

읽기 빈도가 높고 쓰기(수정)가 드문 테이블에는 CoW가 적합하다. 
실시간 CDC처럼 수정이 빈번하고 읽기 빈도가 상대적으로 낮은 경우에는 MoR가 유리하다. 
다만 MoR는 시간이 지날수록 델타 파일이 쌓여 읽기 성능이 저하되므로, 주기적인 compaction(파일 병합 및 재작성)이 필요하다.

< 자주 하는 오해>
MoR이 항상 더 빠르다고 생각하는 경우가 있다. 
쓰기는 빠르지만, 읽기 성능은 델타 파일이 쌓일수록 점점 나빠진다. 
compaction을 게을리하면 쿼리가 수백 개의 작은 파일을 읽고 병합해야 해서 오히려 훨씬 느려진다. 
MoR는 compaction 정책을 함께 설계해야 제대로 동작하는 전략이다.

 

운영 관점에서 CoW의 특성

CoW 테이블은 관리가 단순하다. 
파일은 항상 clean한 상태이므로 delete file이 쌓이지 않는다. 
읽기 성능이 시간이 지나도 저하되지 않는다. Compaction의 주된 목적이 small file 병합으로 한정된다.

대신 수정 작업이 비싸다. 특히 광범위한 UPDATE나 DELETE는 테이블 전체를 재작성에 가까운 작업이 될 수 있다.

정기적인 배치 덮어쓰기(overwrite)가 주된 패턴인 경우에 잘 맞는다. 
예를 들어 매일 전날 데이터를 통째로 재계산해서 파티션 단위로 overwrite하는 DW 집계 테이블, 
또는 수정이 거의 없고 append-only에 가까운 이벤트 로그 테이블이 전형적인 CoW 사용처다. 

 

Merge-on-Read(MoR)

수정이 발생해도 기존 파일을 건드리지 않는다. 
대신 "무엇이 바뀌었는가"를 기록하는 델타 파일을 새로 만든다. 
읽는 시점에 원본 파일과 델타 파일을 병합해서 최종 상태를 만들어낸다.

 

델타파일은 다음 두 종류이다.

Position Delete File은 "어떤 파일의 몇 번째 행을 무시하라"는 위치 정보를 담는다. 삭제 또는 업데이트(=삭제 + 삽입)의 "삭제" 부분을 표현한다.
Equality Delete File은 "특정 컬럼 값이 이것인 행을 무시하라"는 조건을 담는다. 위치를 모르더라도 값으로 삭제를 표현할 수 있다.

MoR:
  쓰기: 델타 파일만 추가 (비용 작음)
  읽기: 원본 + 델타 병합 필요 (비용 큼)

읽기 비용

읽기 시점에 쿼리 엔진은 세 가지를 처리해야 한다.

첫째, Manifest를 열어서 해당 데이터 파일과 연관된 delete 파일이 있는지 확인한다. 
둘째, 데이터 파일을 읽으면서 delete 파일에 기록된 위치의 행을 걸러낸다. 
셋째, 걸러낸 결과와 신규 삽입 파일을 합쳐 최종 결과를 만든다.

delete 파일이 많아질수록 이 과정이 무거워진다. 
특히 Position Delete는 행 단위 위치를 체크해야 하므로 벡터화 연산이 어렵고, Parquet의 Predicate Pushdown 효율도 저하된다.

파일 증가 문제

MoR의 더 큰 문제는 시간이 지날수록 파일이 기하급수적으로 쌓인다는 점이다. 
업데이트가 계속 되면 delete 파일과 소규모 삽입 파일이 계속 생긴다. 이른바 "small file problem"이다.

MoR은 필수로 Compaction 이 필요하다

MoR이 제대로 동작하려면 compaction이 함께 설계되어야 한다. 
Compaction은 쌓인 델타 파일들을 주기적으로 병합해서 clean한 Parquet 파일로 재작성하는 과정이다. 
결과적으로 CoW의 상태로 되돌리는 작업이다.

운영 관점에서 MoR의 특성

MoR 테이블은 쓰기가 빠른 대신 시간이 지날수록 읽기가 느려진다는 특성이 있다. 
운영의 핵심은 이 성능 저하를 Compaction으로 주기적으로 초기화하는 것이다.

Delete file의 유형을 구분해서 관리하는 것이 중요하다.

Position Delete File은 "file X의 row Y를 무시하라"는 위치 기반 삭제 정보다. 
특정 파일과 강하게 결합되어 있어서, 해당 데이터 파일이 Compaction으로 재작성되면 함께 소멸한다.

Equality Delete File은 "column A = value B인 행을 무시하라"는 조건 기반 삭제 정보다.
 특정 파일에 종속되지 않아서 더 유연하지만, 읽기 시 전체 데이터에 대해 조건을 평가해야 하므로 성능 비용이 더 크다. 

MoR 운영의 핵심 지표

파일당 평균 delete rate	전체 행 중 삭제 표시된 비율 , 10% 초과 시 Compaction 권장
delete file 개수	급격히 늘면 Compaction 지연 신호
파일 수 대비 data file 비율	delete file이 data file의 20% 초과 시 경고
쿼리 실행 시간 트렌드	점진적 증가는 Compaction 부족 신호