paper delta 3.1

Author: getChan

_posts/2025-05-30-paper_review_delta_lake.md

@@ -104,4 +104,42 @@ Delta Lake 개념
 
 **3. Metadata in Object Stores**
 - delta lake의 접근법으로 트랜잭션 로그와 메타데이터를 오브젝트 스토어에 직접 저장한다.
-- parquet 포맷으로 저장하고 다른 도구에서 접근할 수 있다.
+- parquet 포맷으로 저장하고 다른 도구에서 접근할 수 있다.
+
+# Delta Lake Storage Format And Access Protocol
+델타 레이크 테이블은데이터 객체와 트랜잭션 로그로 이루어진 디렉토리다. 클라이언트는 동시성 제어 규약을 통해 데이터 구조를 갱신한다.
+
+## Storage Format
+> 원본 그림 2 참조
+
+### Data Objects
+- 파케이 객체로 저장된다. 하이브 파티션 네이밍 규약에 따라 디렉토리로 구성된다.
+- 각 데이터 객체는 고유한 이름을 가진다. 일반적으로 writer가 생성하는 GUID를 사용한다. 
+- 각 버전에 테이블에 어떤 객체가 속하는지는 트랜잭션 로그에 의해 결정된다.
+
+### Log
+- 로그는 `_delta_log` 디렉토리에 저장된다. 로그 레코드를 저장하는 json객체들로 구성된다.
+- 체크포인트 파일도 함께 저장된다. 해당 포인트까지의 로그 객체를 요약한 것이다.
+- 몇몇 접근 규약은 새 로그 엔트리나 체크포인트를 생성하고 트랜잭션 순서에 대해 클라이언트의 동의를 받는다.
+- 각 로그 레코드 객체는 *action* 배열을 포함한다. 액션은 이전 버전의 테이블에 적용하여 다음 버전의 테이블로 만드는 것이다. 가용한 액션은 아래와 같다.
+  - `Change Metadata`: 테이블 메타데이터를 변경한다. 현 테이블 메타데이터를 완전히 덮어쓴다. 
+  - `Add or Remove Files`: 각 데이터 객체를 추가 또는 제거한다. 클라이언트는 로그에서 추가되었으나 제거되지 않은 객체 집합을 찾아서 테이블을 만든다. 
+    - '추가'레코드는 통계값을 포함한다. 
+    - '제거'는 타임스탬프를 포함한다. 물리적 삭제는 유저가 명시한 리텐션이 지난 후에 수행된다. '제거' 로그는 물리적 삭제가 수행되기 전까지는 남아있어야 한다.
+    - 각 레코드의 '데이터변경' 플래그를 `false`로 하면 객체가 갱신되지 않았음을 나타낸다. 재정렬이나 통계 추가 등의 작업이 수행되었음을 나타낸다.
+  - `Protocol Evolution`: 델타 프로토콜의 버전업시 사용한다. 
+  - `Add Provenance Information`: 출처를 기록한다. 즉 감사로그
+  - `Update Application Transaction IDs`: 스트리밍 시스템에서 'exactly-once' 시맨틱을 보장하기 위해 사용한다. Spark Structured Streaming내 Delta Lake 커넥터가 사용한다.
+
+### Log Checkpoints
+- 성능을 위해 로크를 체크포인트로 압축해야 한다. 체크포인트는 중복되지 않는 모든 액션을 저장한다. 
+  - 동일 데이터 객체에 대한 add이후 remove 액션시 add 로그 제거
+  - 동일 데이터 객체에 대한 add는 마지막 것으로 대체. 새것이 통계를 추가하기 때문.
+  - 동일 app id의 여러 트랜잭션 액션은 최신것으로 대체. 
+  - 메타데이터 변경과 프로토콜 진화 액션은 최신것으로 대체.
+- 결과 체크포인트 파케이 파일은 테이블 메타데이터 쿼리에 적합하다. 
+- 클라이언트는 주어진 레코드 ID까지 체크포인트 생성을 시도한다. `03.parquet`는 `03.json`의 체크포인트를 나타낸다.
+  - 기본값으로 10개 트랜잭션마다 체크포인트를 생성한다.
+  - LIST없이 마지막 체크포인트를 효율적으로 찾기 위해 체크포인트 writer는 `_delta_log/_last_cehckkpoint`파일을 쓴다. 
+
+## Access Protocol