# Iceberg 테이블 포맷, 좋은 아이디어 - 잘못 정의된 명세 - Part 2 of 2

> Clean Markdown view of GeekNews topic #22245. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=22245](https://news.hada.io/topic?id=22245)
- GeekNews Markdown: [https://news.hada.io/topic/22245.md](https://news.hada.io/topic/22245.md)
- Type: news
- Author: [stevenk](https://news.hada.io/@stevenk)
- Published: 2025-07-30T13:18:59+09:00
- Updated: 2025-07-30T13:18:59+09:00
- Original source: [database-doctor.com](https://www.database-doctor.com/posts/iceberg-is-wrong-2.html)
- Points: 2
- Comments: 0

## Topic Body

##### 아이스버그 스펙의 문제점  
  
- **아이스버그 스펙의 심각한 문제**: 아이스버그 스펙은 대규모 데이터 레이크의 메타데이터 문제를 해결하기 위한 진지한 시도가 아니다.  
- **역사적 교훈**: 첫 번째 부분에서 과거의 교훈을 배우기 위해 역사로 돌아갔으며, 데이터베이스가 해결해야 할 "공간 관리 문제"를 소개하였다.  
  - **문제의 요소**:  
    1. 공간의 단편화  
    2. 세분화된 동시성 제어  
    3. 여러 객체에 대한 원자성  
    4. 행과 파일 간의 임피던스 불일치  
    5. 메타데이터에 대한 낮은 대기 시간과 높은 처리량 접근  
- **개방형 포맷의 중요성**: 모든 스택에서 개방형 포맷을 사용하는 것에 100% 찬성하며, 테이블 구조화된 데이터에 대해 파케이(Parquet)를 공통 저장 포맷으로 사용하는 것에 대해 특히 기대하고 있다.  
- **파케이 파일과 데이터베이스 테이블의 차이**: 파케이 파일이 모여 있다고 해서 그것이 데이터베이스 테이블이 되는 것은 아니다. 데이터베이스 테이블은 단순한 행의 집합 이상이다.  
  
  
##### 메타데이터 문제 요약  
  
- **공간 관리 문제**: 데이터베이스가 해결해야 할 여러 문제를 다시 강조하였다.  
- **메타데이터의 필요성**: 여러 파케이 파일을 데이터베이스 테이블처럼 보이게 하려면 다음과 같은 메타데이터가 필요하다:  
  1. 테이블을 구성하는 모든 파일의 위치 목록  
  2. 각 파일에 대한 대략적인 메타데이터  
  3. 파일을 추가하거나 제거할 수 있는 트랜잭션 제어 메커니즘  
  4. 테이블 스키마를 진화시킬 수 있는 방법  
- **파일 위치 찾기**: 파케이 파일 세트를 단일 테이블로 취급하려면 파일을 찾는 메커니즘이 필요하다.  
- **메타데이터의 중요성**: 각 파일은 흥미로운 행을 빠르게 찾기 위해 추가 메타데이터가 필요하다.  
  
  
##### 파케이 파일과 데이터베이스 테이블  
  
- **파케이 파일의 정의**: 파케이(Parquet)는 자기 설명적이고 표 형식의 데이터 포맷을 제공한다.  
- **데이터베이스 테이블의 정의**: 데이터베이스 테이블은 단순히 행의 집합이 아니라, 여러 메타데이터와 트랜잭션 제어가 필요하다.  
- **파케이 파일을 테이블처럼 사용하기 위한 조건**:  
  1. 파일 위치 목록  
  2. 각 파일의 메타데이터  
  3. 파일 추가 및 제거를 위한 트랜잭션 제어 메커니즘  
  4. 테이블 스키마의 진화 방법  
- **파일과 테이블의 차이**: 파케이 파일이 같은 열 레이아웃을 가진다고 해서 데이터베이스 테이블처럼 보이지 않는다.  
  
  
##### 매니페스트 파일과 리스트  
  
- **데이터 추가 과정**: 아이스버그 클라이언트가 테이블에 데이터를 추가하려면 다음 단계를 거쳐야 한다:  
  1. 하나 이상의 파케이 파일을 특정 위치(예: S3)에 작성한다.  
  2. 1단계에서 작성한 파일을 가리키는 매니페스트 파일을 작성한다.  
  3. 새로운 매니페스트 리스트를 작성한다.  
- **매니페스트 파일의 형식**: 매니페스트 파일과 리스트는 AVRO 형식으로 되어 있으며, 이는 압축되고 자기 설명적이다.  
- **매니페스트 파일의 내용**: 매니페스트 파일은 파케이 파일에 대한 포인터와 각 열에 대한 메타데이터를 포함한다.  
- **메타데이터의 크기 문제**: 메타데이터를 이렇게 저장하면 필요 이상으로 커지며, 파일 간의 공통 문자열 값을 인식하여 압축할 수 없다.  
  
  
##### 클라이언트의 부담 증가  
  
- **클라이언트의 책임**: 아이스버그 스펙 전반에 걸쳐 클라이언트는 간단한 변경을 위해 엄청난 양의 기록 관리를 해야 한다.  
- **메타데이터의 정확성 문제**: 클라이언트가 일부를 잘못 작성하면 새로운 스냅샷의 커밋이 철저히 확인해야 하며, 매니페스트 데이터가 올바르게 작성되었는지 확인해야 한다.  
- **보안 문제**: 클라이언트가 모든 매니페스트 파일을 가리키는 매니페스트 리스트를 작성해야 하므로, 모든 S3 파일의 위치가 유출된다.  
- **데이터 보안의 중요성**: 데이터의 가치가 높기 때문에 스펙이 보안을 최우선으로 다루지 않는 이유를 의문시해야 한다.  
  
  
##### 행 보안의 결함  
  
- **행 보안의 필요성**: 미국과 같은 느슨하게 규제된 국가에서도 민감한 데이터를 보호하기 위해 행 수준의 보안이 필요하다.  
- **EU의 GDPR**: 유럽에서는 GDPR과 같은 법률로 인해 데이터 접근에 대해 더욱 민감해야 한다.  
- **클라이언트의 데이터 접근 문제**: 클라이언트가 테이블에 데이터를 추가할 수 있지만, 이미 존재하는 데이터에 대한 접근을 제한할 수 없다.  
- **보안 문제의 심각성**: 스펙이 보안을 우선적으로 다루지 않는 이유는 데이터 레이크 정보의 가치에 대한 의문을 제기해야 한다.  
  
  
##### 메타데이터 파일의 역할  
  
- **메타데이터 파일의 작성**: 클라이언트가 파케이 파일을 작성한 후, 해당 매니페스트 파일을 생성하고 기존 매니페스트 리스트를 읽고 새로운 매니페스트 리스트를 생성한 후, 데이터를 커밋해야 한다.  
- **커밋 과정**: 커밋은 메타데이터 파일(<prefix>.metadata.json)을 작성하여 이루어진다.  
- **JSON 형식의 선택**: 메타데이터 파일이 JSON 형식인 이유는 불분명하며, 이는 "위원회에 의한 설계"의 느낌을 준다.  
- **메타데이터의 반복성**: 메타데이터 파일은 모든 스냅샷을 나열하며, 이는 정보의 반복으로 인해 공간이 낭비된다.  
  
  
##### 커밋 과정의 복잡성  
  
- **원자성 문제**: 새로운 메타데이터 파일을 최신 파일로 만들고 이전 메타데이터 파일과 원자적으로 교체해야 한다.  
- **커밋 절차의 복잡성**: 새로운 메타데이터 버전 V+1을 커밋하기 위해 다음 단계를 수행해야 한다:  
  1. 현재 메타데이터를 기반으로 새로운 테이블 메타데이터 파일을 생성한다.  
  2. 새로운 테이블 메타데이터를 고유한 파일에 작성한다.  
  3. 메타스토어에 요청하여 테이블의 메타데이터 포인터를 V에서 V+1로 교체한다.  
- **스왑 실패 시 처리**: 스왑이 실패하면 다른 작성자가 이미 V+1을 생성한 것이므로, 클라이언트는 다시 1단계로 돌아가야 한다.  
- **경쟁 조건의 문제**: 클라이언트가 경쟁하는 경우, 이전 클라이언트가 작성한 메타데이터 파일을 다시 읽고 매니페스트 리스트와 메타데이터 파일을 재생성해야 한다.  
  
  
##### 낙관적 동시성 제어의 문제  
  
- **동시성의 사실**: 자원에 대한 경쟁이 예상되지 않는 경우, 어떤 종류의 동시성을 사용하든 상관없다.  
- **경쟁이 예상되는 경우**: 두 클라이언트가 동일한 값을 변경하려고 할 경우, 잠금 메커니즘을 사용해야 한다.  
- **낙관적 동시성 제어의 한계**: 아이스버그에서는 두 개의 동시 쓰기가 항상 충돌하게 되며, 이는 스펙의 설계 방식 때문이다.  
- **최악의 잠금 의미**: 메타데이터에 대한 최악의 잠금 의미를 사용하고 있으며, 데이터 추가만 원할 경우 클라이언트 간의 조정이 필요 없다.  
  
  
##### 메타데이터 스왑의 한계  
  
- **메타데이터 중앙 집중화**: 테이블의 메타데이터를 단일 파일에 중앙 집중화함으로써 모든 쓰기에 대한 단일 경쟁 지점을 생성하였다.  
- **재시도 시 클라이언트의 부담**: 클라이언트가 실패할 경우, 이전 클라이언트가 작성한 데이터를 읽고 매니페스트 리스트와 메타데이터 파일을 재생성해야 한다.  
- **메타데이터 스왑의 속도**: 메타데이터 스왑을 수행하는 서비스는 재시도와 함께 처리해야 하며, 이는 성능 저하를 초래한다.  
- **제한된 커밋 수**: 단순한 동시성 구현으로 인해 커밋 수가 제한되며, 이는 메타데이터 파일의 원자적 교체 시간에 의해 제한된다.  
  
  
##### 데이터베이스의 필요성  
  
- **메타데이터 파일의 위치 찾기**: 아이스버그 테이블 스냅샷은 메타데이터.json 파일로 완전히 설명된다.  
- **아이디어의 모순**: 아이스버그는 파일만으로 메타데이터 형식을 지정하려고 하지만, 결국 데이터베이스가 필요하다.  
- **데이터베이스의 장점**: 현대 데이터베이스는 수십만 건의 쓰기를 처리할 수 있으며, 분산형으로 확장할 수 있다.  
- **파일 시스템과 데이터베이스의 비교**: 메타데이터를 파일에 저장하는 것보다 데이터베이스에 저장하는 것이 더 효율적이다.  
  
  
##### 조각화 및 메타데이터 부풀림  
  
- **메타데이터.json 파일의 성장**: 메타데이터.json 파일은 최신 스냅샷을 가리키며, 각 메타데이터 파일은 이전 스냅샷에 대한 역 포인터를 포함한다.  
- **메타데이터의 지속적 증가**: 메타데이터가 지속적으로 증가하며, 이는 데이터 레이크의 성능에 부정적인 영향을 미친다.  
- **정기적인 메타데이터 정리 필요성**: 데이터 레이크에 지속적으로 데이터를 추가하는 경우, 메타데이터를 정리해야 한다.  
- **HTTP 요청 비용**: 메타데이터 파일을 삭제하는 과정에서 HTTP 요청이 발생하며, 이는 비용이 발생할 수 있다.  
  
  
##### 데이터 읽기 및 쿼리 계획  
  
- **매니페스트 파일의 역할**: 매니페스트 파일은 파케이 파일에 대한 메타데이터를 포함하고 있다.  
- **쿼리 계획의 복잡성**: 쿼리를 실행하기 위해 매니페스트 리스트와 매니페스트 파일을 순차적으로 읽어야 한다.  
- **비용 문제**: S3에서의 읽기 비용이 발생하며, 이는 쿼리 실행 속도에 영향을 미친다.  
- **메타데이터의 단편화 문제**: 메타데이터가 단편화되면 쿼리 계획이 복잡해지고, 데이터 접근이 어려워진다.  
  
  
##### 캐싱과 쿼리 계획의 어려움  
  
- **매니페스트 캐싱**: 매니페스트를 캐시할 수 있지만, 이는 메타데이터의 크기가 커지기 때문에 비효율적이다.  
- **캐시의 유효성 유지**: 캐시가 최신 상태인지 확인해야 하며, 이는 추가적인 비용과 복잡성을 초래한다.  
- **클라이언트의 부담**: 모든 클라이언트가 메타데이터를 캐시해야 하며, 이는 수백만 개의 HTTP 요청을 발생시킨다.  
- **복잡성의 증가**: 데이터 레이크의 사용이 복잡해지며, 이를 해결하기 위한 추가적인 솔루션이 필요하다.  
  
  
##### 아이디어의 결론  
  
- **아이디어의 비판**: 아이스버그 스펙은 데이터 레이크 메타데이터에 대한 진지한 스펙이 아니며, 여러 문제를 안고 있다.  
- **문제의 요약**: 아이스버그는 O(n) 작업을 사용하여 메타데이터를 추가하며, 교차 테이블 커밋을 처리하지 못하고, 메타데이터 부풀림 문제를 해결하지 못한다.  
- **스케일링의 한계**: 아이스버그는 스케일링에 적합하지 않으며, 클라이언트에게 과도한 복잡성을 이동시킨다.  
- **산업에 대한 질문**: IT 산업에서 이러한 문제가 발생하는 이유에 대해 질문을 던진다.

## Comments



_No public comments on this page._