[Apache Iceberg] Iceberg 이전의 Table Format, Hive

🧊 Apache Iceberg: The Definitive Guide 책을 바탕으로 작성되었습니다.

 

📍 Chapter 1. Introduction to Apache Iceberg 글 모아보기 : 

► 1편 : [Apache Iceberg] 등장 배경 (1) : OLAP와 Data Warehouse
► 2편 : [Apache Iceberg] 등장 배경 (2) : Data Lake와 Data Lakehouse
► 4편 : [Apache Iceberg] Iceberg 설계 아키텍처 및 주요 특징

 

 

💡 들어가며

지난 글에서는 Data Lake와 Data Lakehouse에 대해 살펴보았습니다.
이번 글에서는 Apache Iceberg가 등장하게 될 때까지 Table Format의 역사 흐름에 대해 짧게 살펴보도록 하겠습니다.

---

 

1️⃣  Table Format 이라는 개념이 생기기까지

 

Table Format은 여러 파일들을 하나의 "테이블"로 구조화하는(structuring) 방법을 말합니다. 

이 테이블에 어떤 데이터가 있는지 테이블에 대한 추상화(abstraction)을 제공해주는 것입니다.

 

RDBMS의 시절, Table Format이라는 용어는 사용되지 않았는데,

이는 당시 데이터베이스의 Storage Engine이 데이터와 관련된 모든 동작을 담당했기 때문입니다.

 

데이터가 어디에 어떻게 저장되는지는 추상화 되어 사용자가 모르는 것이 당연하게 여겨졌습니다.

그러나 목적에 맞는 다양한 Compute Engine을 사용하게 되면서 해당 문제가 수면 위로 올라오게 되었습니다.

 

데이터가 AWS S3, GCS와 같은 Storage에 파일로 저장되면서, 어떤 데이터 파일이 테이블에 포함되는지를 계속해서 정의해주는 일은

매우 번거로울 뿐만 아니라, 데이터의 불일치(inconsistency)까지로 이어졌습니다.

 

따라서 "이 테이블에 어떤 데이터가 있는지"를 나타내는 표준화 된 방법이 만들어지게 되었습니다.

 

 

 

---

 

2️⃣  "Hive" Table Format의 시대

Hadoop을 사용하던 때 MapReduce를 사용하기 위해서는 Java로 복잡하고 어렵게 Job을 작성해야 했습니다.

이를 해결하기 위해 SQL을 MapReduce job으로 바꿔주는 프레임워크인 Hive가 등장했습니다.

 

SQL을 사용하기 위해서 Hadoop 스토리지에 있는 어떤 데이터가 테이블을 나타내는지에 대한 체계와 테이블을 추적(tracking)하는

Hive Table Format과 Hive Metastore가 탄생했습니다.

 

Hive Table Format은 하나의 테이블을 특정 디렉토리(prefix)에 있는 파일들로 정의했습니다.

파티션은 서브디렉토리로 나뉘어졌습니다.

 

Hive metastore는 이러한 디렉토리 경로를 추적해서 Query Engine이 Query에 사용할 데이터가 어디 있는지 알 수 있도록 했습니다.

 

폴더(디렉토리)로 구분되는 테이블과, 서브디렉토리로 구분되는 파티션

 

 

그렇다면 Hive Table Format의 장단점에 대해 살펴보도록 하겠습니다.

 

🟢 Hive Table Format의 장점

• 파티셔닝(Partitioning)과 버켓팅(bucketing) 지원 → 테이블을 Full Scan 하지 않고 효율적으로 Query할 수 있다.
• File Format과 독립적으로 동작한다.
• 테이블의 파티션에 대해서 원자적(atmoic) 변화를 지원한다.
• 많은 곳에서 표준으로 사용되고 있다.

 

🔴 Hive Table Format의 단점

• Partition 단위는 가능하지만 File 하나만 원자적으로 교체하는 것은 불가능하다.
• 여러 Partition을 하나의 트랜잭션에서 업데이트 할 수 없다.
• 여러 사용자가 동시에 쓰는 작업이 불안정적이다.
• 파일과 디렉토리 목록을 읽어오는 작업도 시간이 걸리는 작업이다(=느려진다)
• 파티셔닝이 적용된 컬럼을 정확히 알고 있어야 Full Table Scan이 발생하지 않는다.
• 테이블 통계 수집이 별도로 이뤄져 오래될 수 있기 때문에 쿼리 최적화가 어려워진다.
  (ANALYZE TABLE ... COMPUTE STATISTICS 같은 명령을 실행해야 통계를 갱신한다)
• Object Storage에서 동일한 prefix에 대한 동시 다발적 요청을 제한(throttling)하면서 성능이 저하된다.

데이터의 크기가 커질수록, 이런 문제가 커졌기 때문에

이를 해결하기 위한 새로운 Table Format이 필요해졌습니다.

 

---

 

3️⃣  새로운 Table Format이 필요해지다

Hive Table Format의 문제를 해결하기 위해서는 다른 접근 방식이 필요했습니다.

Hive Table에서 근본적으로 테이블을 디렉토리의 내용이라 정의하지, 개별 데이터 파일에 기반하지 않았습니다.

 

Apache Iceberg, Apache Hudi, Delta Lake와 같은 현대 Table Format은

테이블을 파일 목록으로 정의하고, 엔진에게 어떤 디렉토리가 아닌 어떤 파일로 테이블이 이뤄졌는지에 대한 메타데이터를 제공합니다.

 

이렇게 무엇이 테이블인지 정의를 더욱 세분화하면서 다양한 기능이 가능해졌습니다.

1. ACID 트랜잭션이 가능해졌습니다.
2. 여러명이 쓰기를 해도 안전한 트랜잭션이 가능해졌습니다.
3. 테이블의 통계 정보와 메타데이터가 더 효율적으로 제공됩니다.

 

---

 

이번 글에서 Table Format에 대해 살펴보면서, 문득 지난 1편에서의 도서관 비유가 잘못 된 것 같다는 생각이 들었습니다.

하지만 어떻게 수정해야 할지까지는 방향성이 잡히지 않는 이해 수준 상태인 것 같습니다.

 

알아갈수록 더 모르겠는 것이 공부겠지요. 이제 정말 Apahce Iceberg에 대해 다음 글에서 알아보도록 하겠습니다.

읽어주셔서 감사합니다.