54. 오픈 테이블 포맷 (Apache Iceberg, Delta Lake, Apache Hudi)

⚠️ 이 문서는 싸고 거대하지만 데이터 수정이 불가능했던 아마존 S3 같은 객체 스토리지(데이터 레이크)에 쏟아진 무수한 Parquet 파일 덩어리들 위에 투명한 메타데이터 장막을 씌워, 마치 값비싼 RDBMS(오라클, MySQL)처럼 데이터 수정/삭제(ACID 트랜잭션)와 과거 시점 롤백(Time Travel)을 가능하게 만들어 '데이터 레이크하우스(Data Lakehouse)'를 완성하는 혁신적 논리 계층인 오픈 테이블 포맷을 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: S3 버킷에 무식하게 흩어져 있는 수백만 개의 파일들을 하나의 '테이블'처럼 보이게 묶어주고 관리해 주는 고도의 메타데이터(Metadata) 관리 계층이다.
  2. 가치: 기존 하둡(Hive) 시대에는 S3에 저장된 데이터 한 줄을 수정(Update)하려면 100GB짜리 파일 전체를 덮어써야 했으나, 이제는 오라클 DB처럼 레코드 단위의 트랜잭션(ACID 제어)과 여러 명이 동시에 읽고 써도 깨지지 않는 동시성 제어를 지원한다.
  3. 기술 체계: 스키마가 변경(컬럼 추가 등)되어도 과거 파일을 모두 뜯어고칠 필요가 없는 **스키마 에볼루션(Schema Evolution)**과, 커밋 이력을 스냅샷으로 관리하여 실수로 데이터를 지워도 1초 만에 어제 데이터로 돌아가는 타임 트래블(Time Travel) 기능을 공통으로 제공한다.

Ⅰ. 하둡과 하이브(Hive)의 몰락: 늪이 된 데이터 레이크

과거 빅데이터 기술은 무식한 '덮어쓰기' 외에는 답이 없었다.

  1. 데이터 레이크의 치명적 한계 (No ACID):
    • S3나 HDFS에 데이터를 Parquet 포맷으로 쌓아두면 보관은 싸고 빠르지만, 만약 고객 한 명이 탈퇴해서 그 사람의 데이터 1줄만 삭제(Delete)해야 한다고 치자.
    • S3는 파일의 일부만 수정하는 것이 불가능하다. 결국 1줄을 지우기 위해 1GB짜리 파일 전체를 메모리로 불러와서 수정하고 다시 S3에 통째로 엎어 쳐야(Overwrite) 하는 끔찍한 I/O 폭풍이 발생했다.
  2. 더러운 읽기 (Dirty Read):
    • 데이터 엔지니어가 파일을 덮어쓰고 있는 5분 동안, 데이터 분석가가 그 폴더를 조회(Select)하면 파일이 반쪽짜리거나 깨진 상태로 조회되는 심각한 오류가 발생했다 (격리성 부족).
  3. Hive 메타스토어의 한계:
    • 폴더 단위로 데이터를 관리하던 Hive는 파일이 1만 개만 넘어가도 "어떤 파일이 있는지 목록만 보여줘"라는 ls 명령어를 치는 데 수 분이 걸리는 병목을 일으켰다.

📢 섹션 요약 비유: 데이터 레이크가 거대한 창고에 서류 뭉치를 산더미처럼 쌓아둔 것이라면, 하이브(Hive) 시대에는 서류 한 장의 글자 하나를 고치기 위해 창고 문을 닫아걸고 서류 뭉치 전체를 파쇄한 뒤 처음부터 다시 타이핑해서 책상에 올려놔야 하는 미련하고 위험한 사무실이었습니다.

Ⅱ. 세상을 바꾼 오픈 테이블 포맷의 삼국지

넷플릭스, 우버, 데이터브릭스가 이 문제를 각각 해결하며 3대 포맷을 내놓았다.

  1. Apache Iceberg (넷플릭스 창시):
    • 파일 폴더 트리를 뒤지는 짓을 버리고, 파일의 목록과 상태를 거대한 '메타데이터 파일 트리(스냅샷, 매니페스트)'에 철저하게 기록하는 방식을 택했다. 엄청난 안정성과 대규모 확장에 강해 현재 업계의 사실상 표준(De facto)으로 승기를 잡고 있다.
  2. Delta Lake (데이터브릭스 창시):
    • 스파크(Spark)를 만든 데이터브릭스가 주도하며, 트랜잭션 로그(JSON 포맷)를 순차적으로 기록하여 ACID를 보장한다. 스파크 생태계와의 미친듯한 호환성과 속도가 장점이다.
  3. Apache Hudi (우버 창시):
    • "Hadoop Upserts Deletes and Incrementals"의 약자. 이름에서 알 수 있듯 실시간으로 쏟아지는 스트리밍 데이터를 빠르게 Update/Delete 하는 성능에 가장 먼저 초점을 맞췄다.

📢 섹션 요약 비유: 서류를 엎어 치는 대신, 앞에 '똑똑한 총무(오픈 테이블 포맷)'를 한 명 앉혀뒀습니다. 총무는 창고 안의 수백만 장의 서류 위치를 완벽한 장부(메타데이터)에 적어놓습니다. 누군가 글자를 수정하면, 서류를 다시 쓰지 않고 "A 서류의 두 번째 줄은 무효고, 방금 쓴 새 종이를 읽으세요"라고 장부에만 체크(스냅샷 갱신)해버려 속도와 완벽한 보안을 유지합니다.

Ⅲ. 테이블 포맷이 제공하는 3대 마법 기능

이 기능들 덕분에 데이터 웨어하우스(비싼 DB)를 버리고 레이크하우스로 넘어올 수 있게 되었다.

  1. ACID 트랜잭션 보장:
    • 데이터 팀이 데이터를 쏟아붓고(Write) 있는 와중에도 분석가는 아무런 락(Lock) 없이 완벽하게 이전 버전의 데이터를 안전하게 조회(Read)할 수 있다 (스냅샷 격리).
  2. 타임 트래블 (Time Travel):
    • 모든 데이터 변경이 스냅샷 버전으로 저장된다. "어제 오전 10시 시점의 테이블 상태로 조회해 줘"라는 쿼리 한 줄(AS OF SYSTEM_TIME)이면, 백업 복원 과정 없이 즉시 어제 데이터로 시간 여행을 떠날 수 있다.
  3. 스키마 에볼루션 (Schema Evolution):
    • 테이블에 '이메일' 컬럼을 새로 추가하거나 컬럼 타입을 바꾸더라도, 과거에 쌓아둔 수백 테라바이트의 옛날 파일들을 다시 포맷팅할 필요가 없다.
    • 메타데이터 엔진이 "오늘부터 10번 컬럼은 이메일이야. 옛날 파일에서 이 컬럼을 부르면 그냥 빈값(NULL)으로 보여줘"라고 지능적으로 매핑해 버린다.

📢 섹션 요약 비유: 마치 영화감독이 필름을 자르지 않고(파일 원본 보존), 영상 편집기(테이블 포맷) 상에서 씬을 교체하고 삭제했다는 명령(트랜잭션)만 기록하는 것과 같습니다. 편집 프로그램 덕분에 언제든 Ctrl+Z를 눌러 1시간 전 편집 상태로 돌아가거나(타임 트래블), 중간에 새 캐릭터를 끼워 넣어도(스키마 진화) 원본 필름은 조금도 훼손되지 않는 우아한 마법입니다.