Orc’s WIKI

Orc Hwang

소개
Data-Engineering-Essential 오버뷰 시리즈는 데이터 엔지니어링 수명주기 전체의 지도를 그렸습니다. 그 4단계 데이터 저장(Storage)에서 우리는 데이터 웨어하우스·레이크·레이크하우스의 차이를 짚고, 레이크 위에 ACID와 시간여행을 얹는 오픈 테이블 포맷(Apache Iceberg·Delta Lake·Hudi)을 개념 소개 선에서 다뤘습니다. 다만 거기서는 “저장 지도 안에서 테이블 포맷이 어떤 역할을 하는가”까지만 짚고, 메타데이터 구조·트랜잭션·진화·운영의 깊은 이야기는 별도 시리즈로 미뤄 두었습니다. 이 글이 바로 그 예고된 스핀오프, Lakehouse-Essential 시리즈의 마스터 로드맵입니다.
2026년 현재 오픈 테이블 포맷은 더 이상 “선택 사항”이 아니라 레이크하우스의 사실상 표준이 되었고, 그 중심에는 Apache Iceberg가 트랜잭션 워크로드의 de facto standard로 자리 잡았습니다(AWS·Google·Snowflake·Databricks·Dremio 등 광범위한 채택, REST Catalog를 중심으로 한 거버넌스). 이 시리즈는 그래서 Iceberg를 축으로 삼되, 마지막 단계에서 Delta·Hudi·Paimon과 나란히 놓고 비교합니다.
이 시리즈는 그 내부로 들어갑니다. 왜 파일 위에 테이블 계층이 필요한가(문제의식)에서 출발해, Iceberg가 그 계층을 어떻게 구현하는지 — 메타데이터·매니페스트 구조, 그 위에서 성립하는 ACID·스냅샷·시간여행, 재작성 없이 스키마와 파티션을 바꾸는 진화, 작은 파일과 스냅샷 누적을 다스리는 compaction·유지보수, 카탈로그 표준과 접근 제어를 세우는 REST Catalog·거버넌스 — 를 차례로 파고든 뒤, 마지막으로 Iceberg vs Delta vs Hudi vs Paimon 비교로 전체를 조망합니다. 각 단계를 정복할 때마다 상세 딥다이브 포스트를 작성하고 체크박스를 채우는 도장깨기 방식으로 진행합니다.
학습 흐름
7단계는 아래 순서대로 진행하는 것을 권장합니다. 먼저 왜 테이블 포맷이 필요한가(문제의식)로 동기를 세우고, 그것을 실제로 구현하는 Iceberg의 메타데이터 구조를 익힌 뒤, 그 구조 위에서 성립하는 ACID·스냅샷·시간여행과 재작성 없는 진화로 “무엇을 할 수 있는가”를 이해합니다. 그다음 실무에서 반드시 부딪히는 compaction·유지보수와 REST Catalog·거버넌스로 “어떻게 운영하는가”를 다루고, 마지막으로 다른 포맷과의 비교로 안목을 완성하는 흐름입니다.
학습 진행 현황
완료한 항목에는 상세 포스트 링크가 연결됩니다. 학습이 진행될 때마다 체크박스와 진행률을 갱신합니다.
현재 완료한 항목: 0개
전체 항목: 7개
진행률: 0%
1단계: 오픈 테이블 포맷의 문제의식 — 왜 파일 위에 테이블 계층이 필요한가
시리즈의 출발점이자 동기입니다. 오브젝트 스토리지에 Parquet 파일을 잔뜩 쌓는 것만으로는 “테이블”이 되지 않습니다. Hive 테이블처럼 디렉터리와 파일 목록에 의존하면 원자적 커밋이 불가능하고, 동시 쓰기에서 읽는 쪽이 깨진 상태를 보며, 파일 목록을 매번 스캔하느라 느려집니다. 이 단계에서는 이 파일 기반 레이크의 근본 문제 — 원자성·일관성·성능·메타데이터 확장성 — 를 정리하고, 그 위에 테이블 계층(테이블 포맷)을 얹는다는 발상이 무엇을 해결하는지를 이해합니다.
파일 레이크의 한계: 디렉터리·파일 목록 기반 Hive 테이블의 원자성·일관성 문제, listing 비용
테이블 포맷이 여는 것: 파일 집합 위에 스냅샷·스키마·통계를 얹어 “테이블”로 만들기
레이크하우스와의 관계: 오버뷰 4단계에서 본 웨어하우스·레이크·레이크하우스 구도에서 테이블 포맷의 자리
2단계: Iceberg 메타데이터 · 매니페스트 구조 — 스냅샷·매니페스트·데이터 파일 계층
Iceberg의 모든 능력이 여기서 나옵니다. Iceberg 테이블은 세 계층으로 구성됩니다 — 테이블의 현재 상태(스키마·파티션 스펙·스냅샷 목록)를 가리키는 메타데이터 파일, 어떤 데이터 파일이 어느 스냅샷에 속하는지를 담은 매니페스트 파일(과 그것들을 묶는 매니페스트 리스트), 그리고 실제 데이터 파일(Parquet/ORC/Avro). 이 계층 구조와 파일마다 저장된 통계(min/max·null count)가 어떻게 파일 프루닝과 빠른 플래닝을 가능하게 하는지를 익힙니다. 이 그림을 손에 쥐면 이후 스냅샷·진화·compaction이 모두 이 구조 위에 얹힙니다.
3계층 구조: 메타데이터 파일 → 매니페스트 리스트/매니페스트 → 데이터 파일
스냅샷과 매니페스트: 각 스냅샷이 참조하는 매니페스트 집합, 파일 추가/삭제의 표현
통계와 프루닝: 파일 수준 통계(min/max·null)로 스캔을 줄이는 플래닝 최적화
3단계: ACID · 스냅샷 · 시간여행 — 트랜잭션과 스냅샷 격리
테이블 포맷이 “레이크에 웨어하우스를 얹는다”는 약속을 지키는 핵심 단계입니다. Iceberg는 메타데이터 포인터를 원자적으로 교체(optimistic concurrency)하여 커밋의 원자성을 보장하고, 각 커밋이 새로운 스냅샷을 만들기 때문에 읽기는 항상 일관된 한 시점을 봅니다(스냅샷 격리). 이 스냅샷 이력 덕분에 특정 시점이나 스냅샷 ID로 과거를 조회하는 시간여행(time travel)과 이전 스냅샷으로 되돌리는 롤백이 가능합니다. 여기에 동시 쓰기가 충돌할 때의 재시도 모델까지 이해합니다.
원자적 커밋과 격리: 메타데이터 포인터 스왑 기반 optimistic concurrency, 스냅샷 격리
시간여행과 롤백: 스냅샷 ID/타임스탬프 조회, 잘못된 커밋의 되돌리기
동시성: 충돌 감지와 커밋 재시도, 여러 writer가 붙을 때의 동작
4단계: 파티션 진화 · 스키마 진화 — 재작성 없는 진화
Iceberg가 Hive 테이블과 결정적으로 갈라지는 지점입니다. Iceberg는 컬럼을 이름이 아니라 고유 ID로 추적하기 때문에, 컬럼 추가·삭제·이름 변경·순서 변경 같은 스키마 진화를 데이터 재작성 없이 안전하게 수행합니다. 파티션도 마찬가지로, 물리 경로에 파티션 값을 박아 넣는 대신 숨은 파티셔닝(hidden partitioning)으로 표현하므로, 파티션 전략 자체를 바꾸는 파티션 진화가 기존 데이터를 다시 쓰지 않고도 가능합니다. “테이블을 통째로 재작성하지 않고 진화시킨다”는 이 성질이 왜 대규모 운영에서 결정적인지를 익힙니다.
스키마 진화: 컬럼 ID 기반 추적, add/drop/rename/reorder의 안전성, full/backfill 없는 변경
숨은 파티셔닝: 파티션을 물리 경로가 아닌 메타데이터로 표현, 파티션 변환(transform)
파티션 진화: 기존 데이터 재작성 없이 파티션 전략 바꾸기, 진화 전후 파일의 공존
5단계: compaction · 유지보수 — 작은 파일 문제·스냅샷 만료
“돌아가는 테이블”과 “빠르고 저렴하게 운영되는 테이블”은 다릅니다. 스트리밍이나 잦은 소량 쓰기는 작은 파일을 양산해 스캔을 느리게 만들고, 커밋마다 쌓이는 스냅샷과 오래된 파일은 스토리지 비용과 메타데이터 부담을 키웁니다. 이 단계에서는 작은 파일을 큰 파일로 합치는 compaction(및 데이터 재정렬·클러스터링), 더 이상 필요 없는 스냅샷을 정리하는 스냅샷 만료(expire snapshots), 어떤 스냅샷에서도 참조되지 않는 파일을 지우는 고아 파일 정리(orphan file removal) 같은 유지보수 작업을 익힙니다. 이 운영 지식이 있어야 레이크하우스가 오래 건강하게 굴러갑니다.
작은 파일과 compaction: 작은 파일 문제의 원인과 비용, rewrite/bin-pack·정렬 기반 compaction
스냅샷 만료: 스냅샷 이력 관리와 만료 정책, 시간여행 보존 기간과의 균형
파일 정리: 고아 파일 제거, 매니페스트 리라이트, 정기 유지보수 잡 설계
6단계: REST Catalog · 거버넌스 — 카탈로그 표준과 접근 제어
테이블이 어디에 있고 누가 무엇을 할 수 있는지를 관리하는 계층입니다. Iceberg 테이블은 카탈로그를 통해 이름으로 찾고 커밋을 조율하는데, 초기의 Hive·Hadoop·JDBC·Glue 카탈로그를 넘어 2026년에는 엔진 중립적인 REST Catalog가 사실상의 표준 인터페이스로 자리 잡았습니다. 이 단계에서는 카탈로그의 역할, REST Catalog 스펙이 왜 상호운용성의 핵심인지, 그리고 그 위에서 이뤄지는 거버넌스 — 테이블·네임스페이스 수준의 접근 제어, 자격 증명 벤딩(credential vending), 감사 — 를 다룹니다. 여러 엔진(Spark·Trino·Flink·Snowflake)이 하나의 테이블을 안전하게 공유하는 그림이 여기서 완성됩니다.
카탈로그의 역할: 테이블 식별·커밋 조율, Hive/Glue/JDBC vs REST Catalog
REST Catalog: 엔진 중립 표준 인터페이스와 상호운용성, 커밋 프로토콜
거버넌스: 네임스페이스/테이블 접근 제어, credential vending, 감사와 정책
7단계: Iceberg vs Delta vs Hudi vs Paimon — 오픈 테이블 포맷 비교
마지막은 Iceberg를 다른 포맷들과 나란히 놓고 조망하는 단계입니다. 앞선 여섯 단계에서 익힌 개념(메타데이터 구조·트랜잭션·진화·compaction·카탈로그)을 축으로, Delta Lake(트랜잭션 로그 기반, Databricks 생태계), Apache Hudi(업서트·증분 처리 강점, copy-on-write vs merge-on-read), Apache Paimon(스트리밍 레이크하우스, LSM 기반)이 같은 문제를 어떻게 다르게 푸는지를 비교합니다. 어떤 워크로드(배치 vs 스트리밍, 조회 중심 vs 업서트 중심)에서 어떤 포맷이 유리한지, 그리고 포맷 간 상호운용(예: 하나의 데이터에 여러 포맷 메타데이터를 얹는 접근)의 현황까지 정리하며 시리즈를 마무리합니다.
설계 축으로 비교: 메타데이터/트랜잭션 모델, 진화, 카탈로그 지원의 포맷별 차이
워크로드 적합성: 배치 vs 스트리밍, 조회 중심 vs 업서트 중심에서의 선택 기준
생태계와 상호운용: 엔진·클라우드 채택 현황, 포맷 간 호환·전환 접근
핵심 포인트
파일은 테이블이 아니다: 오브젝트 스토리지에 Parquet를 쌓는 것과 신뢰할 수 있는 테이블을 갖는 것은 다릅니다. 테이블 포맷은 그 파일 집합 위에 스냅샷·스키마·통계라는 메타데이터 계층을 얹어 원자성·일관성·성능을 부여합니다.
메타데이터 구조가 모든 능력의 뿌리다: ACID·시간여행·진화·프루닝은 모두 Iceberg의 3계층(메타데이터→매니페스트→데이터) 구조에서 나옵니다. 구조를 알면 나머지 기능이 왜 가능한지가 보입니다.
재작성 없는 진화가 결정적이다: 컬럼 ID 추적과 숨은 파티셔닝 덕분에 스키마·파티션을 데이터 재작성 없이 바꿀 수 있습니다. 대규모 운영에서 이 성질 하나가 유지보수 비용을 가릅니다.
테이블은 운영해야 건강하다: compaction·스냅샷 만료·고아 파일 정리 같은 유지보수 없이는 작은 파일과 누적 스냅샷이 성능과 비용을 갉아먹습니다. 운영은 선택이 아니라 설계의 일부입니다.
표준(REST Catalog)이 상호운용을 만든다: 2026년의 레이크하우스는 여러 엔진이 하나의 테이블을 공유하는 세계이고, 그것을 가능하게 하는 것이 엔진 중립적 카탈로그 표준과 그 위의 거버넌스입니다.
추천 학습 순서
위 단계 번호 순서대로 진행하는 것을 권합니다.
왜·무엇으로(1~2단계) — 왜 테이블 포맷이 필요한지 동기를 세우고, Iceberg가 그것을 구현하는 메타데이터·매니페스트 구조를 익힙니다. 이 구조 없이 기능부터 보면 “왜 가능한지”를 놓칩니다.
무엇을 할 수 있나(3~4단계) — ACID·스냅샷·시간여행과 재작성 없는 진화로, 테이블 포맷이 실제로 어떤 능력을 주는지를 이해합니다.
어떻게 운영·선택하나(5~7단계) — compaction·유지보수로 테이블을 건강하게 유지하고, REST Catalog·거버넌스로 여러 엔진이 안전하게 공유하게 만든 뒤, 다른 포맷과 비교하며 선택 안목을 완성합니다.
각 단계는 앞 단계의 토대 위에 쌓이므로, 순서대로 정복하며 체크박스를 채워 나가길 권합니다.
결론
오픈 테이블 포맷은 “오브젝트 스토리지 위의 값싼 파일들”에 “웨어하우스의 신뢰성”을 얹으려는 시도이고, Apache Iceberg는 2026년 현재 그 시도의 사실상 표준입니다. 개별 기능은 계속 진화하지만, 파일 집합 위에 메타데이터 계층을 얹어 스냅샷으로 관리한다는 뼈대와 “스키마·파티션을 재작성 없이 진화시킨다”는 원리는 오래 갑니다. 이 7단계를 순서대로 정복하면, Iceberg 테이블의 내부 구조를 읽고, 진화·유지보수를 설계하며, 여러 포맷 사이에서 워크로드에 맞는 선택을 내리는 안목을 갖추게 됩니다.
이 Lakehouse-Essential 시리즈는 Data-Engineering-Essential 오버뷰가 예고한 심화 스핀오프 중 저장(4단계) 갈래이며, 처리 갈래인 자매 시리즈 Spark-Essential과 이어집니다. Spark 시리즈의 마지막 Iceberg/Delta 연동 단계가 바로 이 레이크하우스 테이블 포맷을 Spark에서 읽고 쓰는 지점이니, 두 시리즈를 함께 정복하면 “레이크하우스 위에서 처리하는” 그림이 완성됩니다.
다음 학습 (Next Learning)
데이터 저장(Storage): 웨어하우스·레이크·레이크하우스와 파일·테이블 포맷 — 이 시리즈가 갈라져 나온 오버뷰 4단계, 테이블 포맷의 위치를 복습
Data Engineering Essential Curriculum — 전체 데이터 엔지니어링 로드맵으로 돌아가기
Spark Essential Curriculum — 자매 심화 시리즈, 마지막 단계에서 Iceberg/Delta를 Spark로 다룸

Lakehouse Essential Curriculum (Apache Iceberg) — 레이크하우스 에센셜 커리큘럼

댓글