Delta Lake 실전 운용

1. 전체 테이블을 읽는다 (예: 10억 건, 500GB)
2. 메모리에서 해당 행을 찾아 수정한다
3. 전체 테이블을 새 위치에 다시 쓴다 (500GB 재작성)
4. 기존 파일을 삭제하고 새 파일로 교체한다
5. 이 과정에서 다른 쿼리가 실행되면? → 데이터 정합성 깨짐

1. 트랜잭션 로그(_delta_log)에서 파일 목록과 통계를 확인한다
2. Data Skipping으로 변경 대상이 포함된 파일만 식별한다
   → 5,000개 파일 중 3개만 해당됨을 즉시 판별
3. 해당 3개 파일만 읽고, 수정된 행을 반영하여 새 파일 3개를 쓴다
4. 트랜잭션 로그에 "파일 A,B,C 제거 → 파일 X,Y,Z 추가" 기록
5. 이 과정 전체가 ACID 트랜잭션 → 다른 쿼리는 영향 없음

MERGE INTO target_table AS target
USING source_table AS source
ON target.id = source.id
WHEN MATCHED THEN
    UPDATE SET target.name = source.name,
               target.amount = source.amount,
               target.updated_at = current_timestamp()
WHEN NOT MATCHED THEN
    INSERT (id, name, amount, created_at, updated_at)
    VALUES (source.id, source.name, source.amount, current_timestamp(), current_timestamp());

-- 소스 시스템에서 변경된 고객 데이터가 도착했다고 가정합니다
CREATE OR REPLACE TEMP VIEW updated_customers AS
SELECT * FROM VALUES
    (1, '김철수', 'cs.kim@newmail.com', '서울'),      -- 기존 고객: 이메일 변경
    (4, '한지민', 'jm.han@email.com', '대전')          -- 신규 고객
AS t(customer_id, name, email, city);

-- MERGE 실행
MERGE INTO catalog.schema.customers AS target
USING updated_customers AS source
ON target.customer_id = source.customer_id
WHEN MATCHED THEN
    UPDATE SET
        target.name = source.name,
        target.email = source.email,
        target.city = source.city
WHEN NOT MATCHED THEN
    INSERT (customer_id, name, email, city, signup_date)
    VALUES (source.customer_id, source.name, source.email, source.city, current_date());

-- 테이블 전체 최적화
OPTIMIZE catalog.schema.orders;

-- 특정 파티션만 최적화
OPTIMIZE catalog.schema.orders
WHERE order_date >= '2025-03-01';

-- Liquid Clustering 활성화하여 테이블 생성
CREATE TABLE catalog.schema.orders (
    order_id BIGINT,
    customer_id BIGINT,
    order_date DATE,
    amount DECIMAL(10,2)
) CLUSTER BY (order_date, customer_id);

-- OPTIMIZE 실행 시 자동으로 Liquid Clustering 적용
OPTIMIZE catalog.schema.orders;

-- 기본: 7일(168시간)보다 오래된 파일 삭제
VACUUM catalog.schema.orders;

-- 보존 기간 지정: 30일보다 오래된 파일만 삭제
VACUUM catalog.schema.orders RETAIN 720 HOURS;

-- 삭제될 파일 미리 확인 (DRY RUN)
VACUUM catalog.schema.orders DRY RUN;

-- 조건에 맞는 행 삭제
DELETE FROM catalog.schema.orders
WHERE status = 'CANCELLED'
  AND order_date < '2024-01-01';

-- 조건에 맞는 행 수정
UPDATE catalog.schema.orders
SET status = 'REFUNDED',
    updated_at = current_timestamp()
WHERE order_id = 1001;

-- 테이블의 물리적 정보 (파일 수, 크기, 파티션 등)
DESCRIBE DETAIL catalog.schema.orders;

-- 테이블 변경 이력
DESCRIBE HISTORY catalog.schema.orders;

-- 테이블의 컬럼 정보
DESCRIBE TABLE catalog.schema.orders;

-- 테이블 생성 DDL 확인
SHOW CREATE TABLE catalog.schema.orders;

-- 추천 운영 스크립트
OPTIMIZE catalog.schema.orders;
VACUUM catalog.schema.orders RETAIN 720 HOURS;
ANALYZE TABLE catalog.schema.orders COMPUTE STATISTICS;

-- Predictive Optimization 활성화
ALTER TABLE catalog.schema.orders
SET TBLPROPERTIES ('delta.enableOptimizeWrite' = 'true');

[상황]
- 타겟 테이블: orders (10억 건, 500GB, 파티션 없음)
- 소스 데이터: 일일 변경분 50만 건
- MERGE 조건: ON target.order_id = source.order_id
- 평소 실행 시간: 5분
- 문제 발생 후: 50분 (10배 느려짐)

[원인 1: Small File 문제]
- OPTIMIZE를 2주간 안 돌렸음
- 1MB 미만 파일이 50,000개 → 파일 열기/닫기 오버헤드 폭증

[원인 2: 클러스터링 없음]
- order_id 기준 MERGE인데, 데이터가 order_id 순서로 정렬되어 있지 않음
- 50만 건 변경이 500GB 전체 파일에 골고루 분포 → 거의 모든 파일을 재작성

[원인 3: 소스 데이터 급증]
- 블랙프라이데이 이벤트로 일일 변경분이 50만 → 500만 건으로 10배 증가

-- 최적화된 MERGE 패턴
-- 1. 타겟 테이블에 Liquid Clustering 적용
ALTER TABLE catalog.schema.orders CLUSTER BY (order_date, order_id);

-- 2. MERGE에 조건 추가로 스캔 범위 한정
MERGE INTO catalog.schema.orders AS target
USING daily_changes AS source
ON target.order_id = source.order_id
   AND target.order_date >= current_date() - INTERVAL 30 DAYS  -- 30일 이내만 스캔
WHEN MATCHED THEN
    UPDATE SET target.status = source.status,
               target.updated_at = current_timestamp()
WHEN NOT MATCHED THEN
    INSERT *;

-- MERGE 실행 후 확인해야 할 핵심 지표
DESCRIBE HISTORY catalog.schema.orders LIMIT 5;

-- 확인 항목:
-- operationMetrics.numTargetRowsInserted: 삽입된 행 수
-- operationMetrics.numTargetRowsUpdated: 업데이트된 행 수
-- operationMetrics.numTargetFilesAdded: 새로 생성된 파일 수
-- operationMetrics.numTargetFilesRemoved: 재작성된 파일 수 ← 이것이 핵심!
-- operationMetrics.executionTimeMs: 실행 시간 (ms)