delta lake paper

Author: getChan

_posts/2025-05-30-paper_review_delta_lake.md

@@ -0,0 +1,54 @@
+---
+title: "Delta Lake 논문"
+excerpt: "Delta Lake: High-Performance ACID Table Storage over Cloud Object Stores"
+categories:
+  - data
+tags:
+  - data
+last_modified_at: 2025-05-30T08:00:00-08:00
+---
+
+논문 [Delta Lake: High-Performance ACID Table Storage over Cloud Object Stores](https://www.vldb.org/pvldb/vol13/p3411-armbrust.pdf)
+
+# Abstract
+- s3와 같은 클라우드 오프젝트 스토어는 비용 효율적인 저장 시스템이다. 다만 내부 키-값 저장 구조는 ACID트랜잭선과 고성능을 성취하기 어렵다. 객체 listing 등이 비싸고 일관성 보장이 제한적이기 때문.
+- 이를 데이터 웨어하우스나 데이터 레이크의 저장장치로 사용하려면 Delta Lake와 같은 ACID 테이블 저장 계층이 필요하다. 
+- Delta Lake는 parquet 형태로 압축된 트랜잭션 로그를 사용한다. 이는 ACID 트랜잭션, time travel, 빠른 메타데이터 연산을 제공한다. 자동 데이터 레이아웃 최적화, upsert, 캐싱, 감사 로그와 같은 고수준 기능도 제공한다. 
+- Delta Lake는 Spark, Hive, Presto, Redshift 등 다양한 데이터 처리 엔진과 호환된다.
+
+# Introduction
+- 클라우드 오브젝트 스토어는 컴퓨팅과 저장소를 별도로 확장할 수 있어 매력적이다.
+- spark, hive, presto와 같은 주요 빅데이터 시스템은 parquet나 orc포맷을 사용해서 오브젝트 스토어에 읽고 쓴다.
+- 그러나 효율성과 가변성(mutable) 측면에서 한계가 있어서 데이터 웨어하우스의 저장소로 사용하기 어렵다.
+  - HDFS와 같은 분산 파일 시스템이나 DBMS의 커스텀 저장 엔진과 다르게 오브젝트 스토어는 키-값 저장 구조를 사용하며, 키 일관성을 보장하지 않는다.
+  - 성능또한 분산 파일 시스템과 다르게 특별한 관리를 필요로 한다.
+- 관계형 데이터셋을 오브젝트 스토어에 저장할때는 컬럼지향 저장 포맷을 사용한다. 각 테이블은 오브젝트의 집합(파일)으로 저장되며, '파티션'(date,hour)으로 클러스터된다. 파티셔닝은 스캔시 적절한 성능을 제공한다. 
+  - 그러나 *정확성*과 *성능*에서 한계가 있다.
+    - 첫째로, 여러 오브젝트의 update는 원자적이지 않아서 쿼리간 격리가 없다. 테이블 내 여러 오브젝트를 갱신할때, reader는 부분 갱신된 데이터를 보게 된다. 또한 갱신에 크래시가 생겨도 롤백하기 어렵다.
+    - 둘째로, 수백만개의 객체와 메타데이터 연산은 비싸다. parquet는 선택적 쿼리를 위해 min/max통계와 footer를 포함하는데, HDFS에서 이것은 빠르지만 오브젝트 스토어에서는 느리다. 실제 쿼리보다 메타데이터 연산이 더 느리다.
+
+Delta Lake 개념
+- write-ahead log를 사용하여 Delta 테이블 내 *어떤 객체*가 변경되었는지 유지한다. (WAL또한 오브젝트 스토리지에 저장되며 parquet포맷)
+  - 이 로그는 각 파일의 min/max 통계와 같은 메타데이터도 저장해서 빠른 조회가 가능하게 한다. (데이터 파일을 열지 않아도 됨.)
+- 트랜잭션은 최적화된 동시성 규약을 통해 보장된다. (클라우드 프로바이더별로 다름)
+  - 따라서 Delta table에 대한 상태를 유지할 서버는 필요없다.
+- 이러한 트랜잭션 설계는 다음 기능도 가능하게 했다.
+  - time travel: 이전 버전의 테이블을 조회하거나 복원할 수 있다.
+  - UPSERT, DELETE, MERGE 연산 : 효율적으로 관련 객체를 재작성할 수 있음.
+  - 효율적인 스트리밍 I/O : 스트리밍 잡이 작은 객체를 쓸 수 있게 하고, 트랜잭션을 보장하며 큰 객체로 병합할 수 있다.(성능을 위해) 결과적으로 스트림 처리가 가능하다  *스트리밍 전용 시스템보다는 당연 느리겠지 ㅎㅎ. 병합 오버헤드도 있고*
+  - 캐싱 : WAL은 불변이기때문에 연산 노드는 안전하게 로컬 스토리지에 캐싱할 수 있다. Databricks compute에서는 SSD에 캐싱 최적화되어 있다.
+  - 데이터 레이아웃 최적화 : Databricks는 객체 크기를 자동으로 최적화하고 데이터 레코드를 클러스터링한다.(Z-order로 여러 디멘션 지역성을 향상) 실행중인 쿼리에는 영향을 주지 않는다.
+  - 스키마 진화 : 테이블 스키마가 변경되어도 파일 재작성 없이 오래된 parquet 파일을 읽을 수 있다.
+  - 감사 로그 : 트랜잭션 로그는 변경사항을 기록한다.
+
+> **"Z-order로 multi-dimension 지역성을 향상"** 한다?
+> 
+> 여러 열을 동시에 고려하여 데이터를 재정렬하고, 관련 데이터들이 물리적으로 가깝게 저장되도록 함으로써, 복합 조건 쿼리 시 빠르게 접근할 수 있도록 한다는 뜻입니다.
+> - 여러 열을 Z-curve라는 방식으로 interleave(교차)하여 1차원으로 정렬
+> - 결과적으로, WHERE col1=... AND col2=... 같은 조건의 데이터들이 같은 파일 또는 블록에 뭉쳐 있게 됨
+> - 이는 스토리지 시스템 (예: Parquet, Delta Lake, Iceberg 등)에서 필터 푸시다운, 파일 스킵 등을 통해 큰 성능 이점으로 이어집니다.
+
+결과적으로 위 기능들은 객체 저장소 데이터의 운영효율과 성능을 개선하고 "lakehouse" 패러다임을 가능하게 한다.
+- **웨어하우스, 레이크, 스트리밍 별개로 운영하는 것이 아니라, 통합된 데이터 운영을 가능하게 한다.**
+
+# MOTIVATION: CHARACTERISTICS AND CHALLENGES OF OBJECT STORES