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

아이스버그 스펙의 문제점

• 아이스버그 스펙의 심각한 문제: 아이스버그 스펙은 대규모 데이터 레이크의 메타데이터 문제를 해결하기 위한 진지한 시도가 아니다.
• 역사적 교훈: 첫 번째 부분에서 과거의 교훈을 배우기 위해 역사로 돌아갔으며, 데이터베이스가 해결해야 할 "공간 관리 문제"를 소개하였다.
  • 문제의 요소:
    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 산업에서 이러한 문제가 발생하는 이유에 대해 질문을 던진다.