Databricks 데이터 엔지니어 9강

Professional 과정 첫 강은 Delta의 내부와 파일 최적화를 깊이 다룬다.

Associate에서 OPTIMIZE·VACUUM을 개념으로 배웠다면, 여기서는 작은 파일 문제·데이터 스킵·클러스터링을 성능 관점에서 파고든다.

이 강의 목표는 다음과 같다.

• 작은 파일 문제가 왜 성능을 해치는지 이해한다.
• ZORDER와 데이터 스킵의 관계를 안다.
• Liquid Clustering이 파티셔닝을 어떻게 대체하는지 이해한다.

1. 작은 파일 문제

스트리밍·잦은 쓰기는 작은 파일을 대량으로 만든다.

• 파일마다 메타데이터·열기 비용이 들어 쿼리가 느려진다.
• 해결: OPTIMIZE로 작은 파일을 적정 크기(수백 MB)로 병합(compaction)한다.

OPTIMIZE sales;
OPTIMIZE sales WHERE date >= '2026-07-01';   -- 일부만

2. 데이터 스킵과 ZORDER

Delta는 파일별 min/max 통계로 필요 없는 파일을 건너뛴다(데이터 스킵).

• ZORDER BY는 자주 필터하는 컬럼을 다차원으로 정렬해, 관련 데이터를 같은 파일에 모은다.
• 그러면 스킵 효율이 올라가 스캔량이 준다.

OPTIMIZE sales ZORDER BY (customer_id, product_id);

3. Liquid Clustering

전통적 파티셔닝은 컬럼 카디널리티가 높으면 과분할(작은 파일 폭증)이나 스큐를 낳는다.

• Liquid Clustering(CLUSTER BY)은 파티션 디렉터리 없이 클러스터링을 자동 관리한다.
• 파티션 컬럼을 잘못 골라 생기는 문제를 피하고, 클러스터 키를 나중에 바꿀 수도 있다.

CREATE TABLE sales (...) CLUSTER BY (customer_id);
ALTER TABLE sales CLUSTER BY (region);        -- 키 변경

4. VACUUM 주의

VACUUM은 미참조 파일을 지워 비용을 줄이지만, 보존 기간을 너무 짧게 잡으면 Time Travel과 진행 중인 읽기가 깨질 수 있다. 기본 7일을 함부로 낮추지 않는다.

예제

예제) 고카디널리티 컬럼(user_id)으로 파티셔닝했더니 디렉터리가 수백만 개로 쪼개져 성능이 나빠졌다. 어떻게 고치나?

해설) 파티셔닝을 제거하고 Liquid Clustering(CLUSTER BY user_id)으로 바꾼다. 파티션 디렉터리 폭증 없이 클러스터링으로 관련 데이터를 모아 스킵 효율을 유지하며, 필요하면 클러스터 키를 나중에 조정한다.

샘플 문제

문) 자주 필터하는 컬럼으로 데이터 스킵 효율을 높이는 명령은?

• (A) VACUUM ... RETAIN 0 HOURS
• (B) OPTIMIZE ... ZORDER BY (col)
• (C) DESCRIBE HISTORY
• (D) REFRESH TABLE

정답: (B). ZORDER는 컬럼을 다차원 정렬해 관련 데이터를 같은 파일로 모아 min/max 스킵 효율을 높인다.

정리

• 작은 파일은 성능을 해치므로 OPTIMIZE로 병합한다.
• Delta는 min/max 통계로 파일을 스킵하며, ZORDER가 스킵 효율을 높인다.
• Liquid Clustering(CLUSTER BY)은 파티셔닝의 과분할·스큐 문제를 대체한다.
• VACUUM 보존 기간을 과도하게 줄이면 Time Travel이 깨진다.

다음 강에서는 상태 기반의 고급 스트리밍을 다룬다.