delta lake 2

Author: getChan

_posts/2025-05-30-paper_review_delta_lake.md

@@ -51,4 +51,33 @@ Delta Lake 개념
 결과적으로 위 기능들은 객체 저장소 데이터의 운영효율과 성능을 개선하고 "lakehouse" 패러다임을 가능하게 한다.
 - **웨어하우스, 레이크, 스트리밍 별개로 운영하는 것이 아니라, 통합된 데이터 운영을 가능하게 한다.**
 
-# MOTIVATION: CHARACTERISTICS AND CHALLENGES OF OBJECT STORES
+> 여기서부터는 대충 내 방식대로 정리
+
+# MOTIVATION: CHARACTERISTICS AND CHALLENGES OF OBJECT STORES
+
+## Object Store APIs
+- 오브젝트 스토어는 키-값 구조로 쉽고 확장하기 쉬운 구조다
+  - 각 객체는 이진 블롭으로 TB범위까지 확장 가능. 
+  - 객체는 키로 식별된다. 
+- 파일시스템 경로와 다르게 디렉터리나 객체의 rename이나 list과 같은 메타데이터 API가 무겁다.
+- 바이트 범위 요청을 지원하기 때문에 큰 객체를 범위로 나눠 읽는 것이 효율적이다.
+- 객체를 갱신하려면 전체 객체를 재작성해야 한다. 이 연산은 원자적이다. append도 가능하다.
+- 이외에도 small files, 여러 디렉토리에 대한 원자 갱신 등의 문제가 존재하는데, 이는 분산파일시스템에도 동일한 문제다.
+
+## Consistency Properties
+- 오브젝트 스토어는 일반적으로 key에 대한 eventual consistency를 제공한다. across key 일관성은 보장하지 않는다.
+  - 여러 객체로 이루어진 데이터셋은 일부 객체가 갱신되었을 때, 다른 객체가 갱신되지 않은 상태로 남아있을 수 있다.
+  - S3는 read-after-write consistency를 제공한다. 읽기 연산은 쓰기 연산 이후임을 보장한다. 다만 예외로, 존재하지 않던 객체를 먼저 읽고 쓰인 뒤 다시 읽는 경우 객체를 읽지 못할 수 있다. negative caching 때문에.
+  - S3의 list연산은 eventual consistency를 제공한다. 객체가 갱신되면, list연산은 갱신된 객체를 포함하지 않을 수 있다.
+
+## Performance Characteristics
+- 오브젝트 스토어에서 고처리량을 달성하기 위해서는 큰 순차 입출력과 병렬도 간 균형이 필요하다.
+  - 읽기 시 최소 5ms의 지연시간이 발생한다. 이후 50MB/s로 데이터를 읽을 수 있다. 따라서 최대 처리량에 근접하려면 수MB를 읽어야 한다. 또한 VM의 네트워크 대역폭은 최소 10Gb/s이므로 처리량을 높이려면 병렬로 읽어야 한다.
+  - list 연산또한 병렬화가 필요하다. s3는 요청당 1000개 객체를 반환할 수 있다. 따라서 큰 디렉토리를 list하려면 병렬화해야 한다. 
+  - 쓰기는 전체 개체를 대체하거나 append한다. 만약 테이블이 부분 갱신이 필요하다면 객체는 작게 유지되어야 한다. 이는 대량 읽기와 상충된다. 대안으로, 한쪽이 로그 기반 저장 포맷을 사용할 수 있다.
+- 위 성능 특성은 분석 워크로드에 3가지 고려사항을 수반한다.
+  - 1) 자주 접근하는 데이터는 순차적으로 가깝게 위치시킨다. 컬럼 기반 포맷을 사용하면 달성 가능.
+  - 2) 객체를 크지만 너무 크지 않게 유지한다. 큰 객체는 갱신 비용을 증가시킨다. 
+  - 3) list 연산을 피하라. 가능하다면 사전식 키 범위로 요청하라.
+
+## Existing Approaches for Table Storage