Liquid Clustering 상세 가이드

-- 기존 파티셔닝 방식
CREATE TABLE catalog.schema.orders (
    order_id BIGINT,
    customer_id BIGINT,
    amount DECIMAL(10, 2),
    order_date DATE
) PARTITIONED BY (order_date);

-- 기존 Z-Order 방식
OPTIMIZE catalog.schema.orders
ZORDER BY (customer_id, order_date);

-- CLUSTER BY로 클러스터링 키를 지정합니다
CREATE TABLE catalog.schema.orders (
    order_id BIGINT,
    customer_id BIGINT,
    product STRING,
    amount DECIMAL(10, 2),
    order_date DATE,
    region STRING
) CLUSTER BY (region, order_date);

-- 기존 테이블에 Liquid Clustering 활성화
ALTER TABLE catalog.schema.orders
CLUSTER BY (region, order_date);

-- 쿼리 패턴이 바뀌면 키를 자유롭게 변경할 수 있습니다
ALTER TABLE catalog.schema.orders
CLUSTER BY (customer_id, order_date);

-- Liquid Clustering 비활성화
ALTER TABLE catalog.schema.orders
CLUSTER BY NONE;

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

-- ✅ 좋은 선택: 날짜와 지역으로 자주 필터링하는 경우
CLUSTER BY (order_date, region)

-- ✅ 좋은 선택: 고객 ID와 날짜로 자주 조회하는 경우
CLUSTER BY (customer_id, event_date)

-- ❌ 나쁜 선택: Boolean 컬럼 (카디널리티가 2밖에 안 됨)
CLUSTER BY (is_active)

-- ❌ 나쁜 선택: 고유 ID만 사용 (범위 필터에 부적합)
CLUSTER BY (uuid)

-- region과 order_date로 클러스터링된 테이블
SELECT * FROM catalog.schema.orders
WHERE region = 'APAC' AND order_date BETWEEN '2025-03-01' AND '2025-03-31';

-- Liquid Clustering이 적용되어 있으면:
-- 전체 1,000개 파일 중 관련된 50개 파일만 읽습니다
-- → 95%의 파일을 건너뛰어 쿼리 시간이 대폭 단축됩니다

계산해 봅시다:
- order_date: 365일/년 × 3년 = 1,095 파티션
- store_id: 200개 매장
- category: 50개 카테고리

총 파티션 수: 1,095 × 200 × 50 = 10,950,000 (약 1,100만 개!)

-- 상황 A: 대부분의 쿼리가 날짜 범위 필터만 사용
-- → 단일 키가 최적
CLUSTER BY (event_date)

-- 상황 B: 날짜 + 고객 ID로 필터링하는 쿼리가 70% 이상
-- → 복합 키, 카디널리티 낮은 것을 앞에 배치
CLUSTER BY (event_date, customer_id)

-- 상황 C: 다양한 컬럼으로 필터링하는 ad-hoc 쿼리가 많음
-- → 가장 빈번한 2~3개만 선택, 나머지는 포기
CLUSTER BY (region, event_date)

-- 가장 자주 필터링에 사용되는 컬럼 파악
-- (Unity Catalog 시스템 테이블 활용)
SELECT
    filter_column,
    COUNT(*) AS query_count,
    AVG(duration_ms) AS avg_duration_ms
FROM (
    -- 쿼리 히스토리에서 WHERE 절 파싱
    -- 실제로는 query_text를 분석
    SELECT * FROM system.query.history
    WHERE statement_type = 'SELECT'
      AND start_time > current_date() - INTERVAL 30 DAYS
)
GROUP BY filter_column
ORDER BY query_count DESC
LIMIT 10;

-- 매일 밤 3시에 수동으로 OPTIMIZE + Z-Order 실행
-- 이 작업만 45분 소요, 전체 데이터를 재정렬하므로 매일 비용 발생
OPTIMIZE prod.finance.transactions
ZORDER BY (account_id, transaction_date);

-- Step 1: Liquid Clustering 활성화 (기존 데이터는 그대로 유지)
ALTER TABLE prod.finance.transactions
CLUSTER BY (account_id, transaction_date);

-- Step 2: 첫 OPTIMIZE로 기존 데이터 클러스터링 (1회성, 시간 소요)
OPTIMIZE prod.finance.transactions;
-- → 첫 실행은 전체 데이터를 클러스터링하므로 2시간 소요

-- Step 3: 이후부터는 증분 OPTIMIZE (새 데이터만 처리)
-- Predictive Optimization 활성화하면 자동 실행
ALTER TABLE prod.finance.transactions
SET TBLPROPERTIES ('delta.enableDeletionVectors' = true);

-- Predictive Optimization 활성화 (카탈로그 레벨)
ALTER CATALOG prod SET DBPROPERTIES ('predictive_optimization' = 'ENABLE');

-- 이후 Liquid Clustering 테이블에 대해:
-- 1. 새 데이터가 충분히 쌓이면 자동으로 OPTIMIZE 실행
-- 2. 쿼리 패턴을 분석하여 최적의 시점에 클러스터링
-- 3. VACUUM도 자동 실행
-- → 데이터 엔지니어가 유지보수에 쓰는 시간: 0