Z-Order 클러스터링과 데이터 스킵핑 완벽 가이드

Delta Lake의 Z-Order 클러스터링과 데이터 스킵핑 메커니즘을 실무 중심으로 배웁니다. 빅데이터 쿼리 성능을 획기적으로 개선하는 최적화 기법을 초급 개발자도 쉽게 이해할 수 있도록 설명합니다.

---

목차

1. Z-Order 클러스터링 원리
2. 효과적인 Z-Order 컬럼 선택
3. 데이터 스킵핑 메커니즘
4. 파일 통계와 Min/Max 값 활용
5. 파티셔닝 vs Z-Order 비교
6. 복합 최적화 전략

---

1. Z-Order 클러스터링 원리

어느 날 김개발 씨는 회사의 데이터 엔지니어링 팀에 배치되었습니다. 선배 박시니어 씨가 "이 테이블에 Z-Order를 적용해볼까요?"라고 말했을 때, 김개발 씨는 멍한 표정으로 고개만 끄덕였습니다.

Z-Order가 대체 무엇이고, 왜 필요한 걸까요?

Z-Order 클러스터링은 다차원 데이터를 일차원 공간에 효율적으로 배치하는 최적화 기법입니다. 마치 도서관에서 여러 주제의 책을 가장 찾기 쉬운 순서로 배열하는 것과 같습니다.

이를 통해 쿼리 성능이 10배 이상 향상될 수 있으며, 특히 여러 컬럼을 동시에 필터링하는 경우 더욱 효과적입니다.

다음 코드를 살펴봅시다.

from delta.tables import DeltaTable

# Z-Order 클러스터링 적용 전 테이블 상태 확인
delta_table = DeltaTable.forPath(spark, "/data/transactions")

# Z-Order 클러스터링 실행
# user_id와 transaction_date 컬럼을 기준으로 데이터 재배치
delta_table.optimize().executeZOrderBy("user_id", "transaction_date")

# 최적화 후 통계 확인
spark.sql("""
  DESCRIBE DETAIL delta.`/data/transactions`
""").show()

김개발 씨는 입사 한 달 차 데이터 엔지니어입니다. 오늘 아침, 마케팅 팀에서 급한 요청이 들어왔습니다.

"지난 3개월간 특정 지역 사용자들의 거래 데이터를 뽑아주세요. 빨리요!" 김개발 씨는 서둘러 쿼리를 실행했지만, 30분이 지나도 결과가 나오지 않았습니다.

박시니어 씨가 모니터를 보더니 한숨을 쉬었습니다. "이 테이블, Z-Order 적용 안 했죠?

한번 해볼까요?" Z-Order 클러스터링이란 정확히 무엇일까요? 쉽게 비유하자면, Z-Order는 마치 대형 서점의 책 배치 전략과 같습니다.

서점에서는 요리책을 모아두되, 그 안에서도 한식, 중식, 양식을 구분하고, 다시 난이도별로 배치합니다. 이렇게 하면 손님이 "초급자용 한식 요리책"을 찾을 때 서점 전체를 뒤질 필요가 없습니다.

Z-Order도 마찬가지로 비슷한 값들을 가진 데이터를 물리적으로 가까운 곳에 배치합니다. Z-Order가 없던 시절에는 어땠을까요?

빅데이터 시스템에서 데이터는 보통 입력된 순서대로 저장됩니다. 1월 1일에 서울 사용자 A의 데이터가 들어오고, 바로 다음에 부산 사용자 B의 데이터가 들어올 수 있습니다.

그 다음엔 대구 사용자 C, 다시 서울 사용자 D... 이런 식으로 무작위로 섞여 있습니다.

이제 "서울 지역에서 지난 3개월간 거래한 사용자"를 찾으려면 어떻게 해야 할까요? 시스템은 모든 파일을 하나하나 열어보며 서울 데이터인지 확인해야 합니다.

1테라바이트 데이터 중 실제 필요한 건 10기가바이트뿐인데, 전체를 스캔해야 하는 비효율이 발생합니다. Z-Order의 등장으로 모든 것이 바뀌었습니다.

Z-Order를 적용하면 지역과 날짜가 비슷한 데이터들이 같은 파일에 모이게 됩니다. 서울 지역의 1월 데이터, 서울 지역의 2월 데이터...

이런 식으로 자연스럽게 그룹화됩니다. 이제 "서울 지역 3개월 데이터"를 찾을 때 시스템은 관련 파일 몇 개만 열어보면 됩니다.

Z-Order 알고리즘의 핵심은 다차원 공간을 Z자 모양으로 순회한다는 점입니다. 2차원 좌표평면을 생각해봅시다.

(0,0), (0,1), (1,0), (1,1) 같은 점들이 있을 때, 이를 어떤 순서로 나열할까요? 일반적으로는 X축 우선 또는 Y축 우선으로 정렬합니다.

하지만 Z-Order는 특별한 비트 인터리빙 기법을 사용합니다. 좌표 (2, 3)이 있다면, 2의 이진수는 10, 3의 이진수는 11입니다.

Z-Order는 이 비트들을 번갈아가며 섞습니다. 1(Y) 1(X) 1(Y) 0(X) = 1110.

이렇게 만들어진 값으로 데이터를 정렬하면, 가까운 점들이 일차원 상에서도 가까운 위치에 놓이게 됩니다. 위 코드를 단계별로 살펴보겠습니다. 먼저 DeltaTable.forPath로 최적화할 테이블을 지정합니다.

그 다음 optimize().executeZOrderBy를 호출하면서 중요한 컬럼들을 나열합니다. 여기서는 user_id와 transaction_date를 선택했습니다.

이 명령이 실행되면 Delta Lake는 내부적으로 파일들을 읽어서 Z-Order 값을 계산하고, 데이터를 재배치한 새 파일들을 작성합니다. 실무에서는 어떻게 활용할까요? 전자상거래 회사를 예로 들어보겠습니다.

거래 데이터 테이블에는 사용자 ID, 상품 ID, 거래 날짜, 결제 수단 등 다양한 컬럼이 있습니다. 분석가들은 자주 "특정 기간 동안 특정 사용자들의 거래"를 조회합니다.

이 경우 user_id와 transaction_date에 Z-Order를 적용하면, 쿼리 시간이 30분에서 3분으로 단축될 수 있습니다. 하지만 주의할 점도 있습니다. Z-Order는 만능이 아닙니다.

너무 많은 컬럼에 적용하면 오히려 효과가 떨어집니다. 일반적으로 2~4개의 핵심 컬럼에만 적용하는 것이 좋습니다.

또한 Z-Order 작업 자체가 데이터를 재작성하는 과정이므로 시간과 컴퓨팅 비용이 듭니다. 따라서 테이블이 자주 변경되지 않는 시간대에 수행해야 합니다.

카디널리티가 낮은 컬럼에 Z-Order를 적용하는 것도 비효율적입니다. 예를 들어 성별(남/여) 같은 컬럼은 값이 2가지뿐이므로 Z-Order의 이점을 보기 어렵습니다.

반면 사용자 ID나 타임스탬프처럼 값이 다양한 컬럼이 적합합니다. 김개발 씨의 이야기로 돌아가봅시다. 박시니어 씨가 Z-Order를 적용하고 같은 쿼리를 다시 실행했습니다.

이번에는 불과 3분 만에 결과가 나왔습니다. 김개발 씨는 놀란 표정으로 물었습니다.

"어떻게 이렇게 빨라진 거예요?" 박시니어 씨가 웃으며 대답했습니다. "마법이 아니라 과학이죠.

데이터를 똑똑하게 배치한 덕분입니다." Z-Order 클러스터링을 제대로 이해하면 빅데이터 시스템의 성능을 극적으로 개선할 수 있습니다. 여러분도 자주 조회하는 컬럼 조합을 찾아서 Z-Order를 적용해 보세요.

실전 팁

💡 - 카디널리티가 높은 컬럼 2~4개를 선택하여 Z-Order 적용

• 쿼리 패턴 분석을 통해 가장 자주 함께 필터링되는 컬럼 조합 찾기
• 주기적인 최적화: 데이터가 계속 쌓이면 다시 Z-Order 실행 필요

---

2. 효과적인 Z-Order 컬럼 선택

Z-Order를 배운 김개발 씨는 의욕이 넘쳤습니다. "그럼 모든 컬럼에 Z-Order를 적용하면 더 빠르지 않을까요?" 박시니어 씨가 고개를 저었습니다.

"그게 그렇지 않아요. 컬럼 선택이 핵심입니다."

효과적인 Z-Order 컬럼 선택은 쿼리 성능 최적화의 핵심입니다. 모든 컬럼이 Z-Order에 적합한 것은 아니며, 잘못 선택하면 오히려 성능이 저하될 수 있습니다.

쿼리 패턴 분석, 카디널리티 평가, 컬럼 간 상관관계를 종합적으로 고려해야 최적의 결과를 얻을 수 있습니다.

다음 코드를 살펴봅시다.

# 쿼리 패턴 분석을 통한 컬럼 선택
from pyspark.sql.functions import col, approx_count_distinct

# 1. 카디널리티 분석
df = spark.read.format("delta").load("/data/transactions")
df.select([
    approx_count_distinct("user_id").alias("user_id_card"),
    approx_count_distinct("product_id").alias("product_id_card"),
    approx_count_distinct("region").alias("region_card"),
    approx_count_distinct("payment_method").alias("payment_card")
]).show()

# 2. 최적 컬럼 조합으로 Z-Order 적용
# 카디널리티가 높고 자주 조회되는 컬럼 선택
delta_table.optimize().executeZOrderBy("user_id", "transaction_date", "product_id")

김개발 씨는 첫 번째 Z-Order 성공에 고무되어 모든 테이블에 Z-Order를 적용하기 시작했습니다. 하지만 이상한 일이 벌어졌습니다.

어떤 테이블은 빨라졌지만, 어떤 테이블은 오히려 느려졌습니다. 심지어 Z-Order 작업 자체가 하루 종일 걸리는 경우도 있었습니다.

박시니어 씨가 김개발 씨의 모니터를 보며 한숨을 쉬었습니다. "이 테이블엔 10개 컬럼에 Z-Order를 적용했네요?

너무 많아요." 컬럼 선택의 과학은 생각보다 복잡합니다. 마치 요리할 때 재료를 선택하는 것과 같습니다.

맛있는 김치찌개를 만들려면 김치, 돼지고기, 두부가 핵심 재료입니다. 여기에 소금, 설탕, 간장, 고춧가루, 마늘, 생강, 파, 양파...

모든 양념을 다 넣는다고 더 맛있어지지 않습니다. 오히려 맛이 어지러워집니다.

Z-Order 컬럼 선택도 마찬가지입니다. 첫 번째 기준은 카디널리티입니다.

카디널리티란 컬럼이 가질 수 있는 고유한 값의 개수입니다. 성별 컬럼은 카디널리티가 2 정도(남/여)지만, 사용자 ID는 수백만이 될 수 있습니다.

Z-Order는 카디널리티가 높은 컬럼에서 빛을 발합니다. 왜 그럴까요?

카디널리티가 낮으면 데이터가 몇 개 그룹으로만 나뉩니다. 성별로 Z-Order를 적용하면 남성 그룹과 여성 그룹, 두 덩어리만 생깁니다.

이건 단순한 파티셔닝과 다를 바 없습니다. 반면 사용자 ID는 수백만 개 값으로 세밀하게 데이터를 배치할 수 있습니다.

두 번째 기준은 쿼리 패턴입니다. 아무리 카디널리티가 높아도, 실제 쿼리에서 사용하지 않는 컬럼이라면 의미가 없습니다.

회사의 쿼리 로그를 분석해보세요. 어떤 컬럼이 WHERE 절에 자주 등장하나요?

어떤 컬럼 조합이 자주 함께 사용되나요? 예를 들어 전자상거래 회사에서 분석가들이 항상 "특정 기간, 특정 지역, 특정 상품 카테고리"로 필터링한다면, transaction_date, region, product_category가 Z-Order 후보가 됩니다.

세 번째 기준은 컬럼 개수 제한입니다. 이론적으로는 Z-Order에 많은 컬럼을 지정할 수 있지만, 실무에서는 2~4개가 적당합니다.

왜일까요? Z-Order는 다차원 공간을 1차원으로 매핑하는 과정에서 필연적으로 정보 손실이 발생합니다.

차원이 너무 많아지면 이 손실이 커져서 효과가 반감됩니다. 코드를 자세히 살펴보겠습니다. 첫 번째 단계는 각 컬럼의 카디널리티를 측정하는 것입니다.

approx_count_distinct 함수를 사용하면 대략적인 고유값 개수를 빠르게 파악할 수 있습니다. 정확한 COUNT DISTINCT는 시간이 오래 걸리므로, 근사값으로 충분합니다.

결과를 보니 user_id는 5백만, product_id는 10만, region은 20, payment_method는 5라고 나왔습니다. 이 중에서 카디널리티가 높은 user_id와 product_id가 좋은 후보입니다.

transaction_date도 날짜/시간 데이터라 카디널리티가 높습니다. 실무 사례를 하나 더 들어보겠습니다. 어느 스트리밍 서비스 회사는 사용자들의 시청 기록을 저장합니다.

테이블에는 user_id, content_id, watch_timestamp, device_type, region 등의 컬럼이 있습니다. 데이터 분석팀이 가장 자주 하는 쿼리는 "특정 기간 동안 특정 콘텐츠를 본 사용자 목록"이었습니다.

처음에는 user_id, content_id, watch_timestamp 세 컬럼에 Z-Order를 적용했습니다. 하지만 성능 향상이 기대만큼 크지 않았습니다.

왜일까요? 쿼리 로그를 더 자세히 분석해보니, 대부분의 쿼리가 content_id로 먼저 필터링한 후 기간을 지정했습니다.

즉, content_id와 watch_timestamp의 조합이 핵심이었던 것입니다. 컬럼 순서도 중요할까요? Delta Lake의 Z-Order 구현에서는 컬럼 순서가 큰 영향을 미치지 않습니다.

Z-Order 알고리즘 특성상 모든 컬럼을 동등하게 고려하여 비트 인터리빙을 수행하기 때문입니다. 하지만 가독성을 위해 가장 중요한 컬럼을 먼저 나열하는 것이 좋습니다.

잘못된 선택의 예를 살펴봅시다. 신입 개발자 이주니어 씨는 로그 테이블에 Z-Order를 적용하려고 합니다.

이 테이블에는 log_level(INFO, WARN, ERROR), timestamp, user_id, message 컬럼이 있습니다. 이주니어 씨는 "모든 컬럼이 중요하니까 다 넣자"고 생각했습니다.

하지만 log_level은 카디널리티가 3~5 정도로 매우 낮습니다. message는 카디널리티는 높지만 거의 필터링에 사용되지 않습니다.

결국 timestamp와 user_id만 Z-Order에 포함하는 것이 최선입니다. 김개발 씨는 교훈을 얻었습니다. "아, 많다고 좋은 게 아니구나.

정말 중요한 컬럼만 골라야겠어요." 박시니어 씨가 만족스러운 표정으로 고개를 끄덕였습니다. "이제 제대로 이해했네요.

데이터 최적화는 기술이면서 동시에 예술입니다." 여러분도 Z-Order를 적용하기 전에 충분히 분석하고, 신중하게 컬럼을 선택하세요. 그것이 진정한 성능 향상의 지름길입니다.

실전 팁

💡 - 쿼리 로그 분석 도구 활용하여 실제 사용 패턴 파악

• 카디널리티 1000 이상 컬럼을 우선 고려
• 컬럼 조합 테스트: 여러 조합을 시도하여 최적 성능 찾기

---

3. 데이터 스킵핑 메커니즘

Z-Order를 적용한 후, 김개발 씨는 쿼리가 정말 빨라진 것을 확인했습니다. 하지만 내부적으로 어떻게 작동하는지 궁금했습니다.

"시스템이 어떻게 필요 없는 파일을 건너뛰는 거죠?" 박시니어 씨가 화이트보드에 그림을 그리며 설명하기 시작했습니다.

데이터 스킵핑은 쿼리 실행 시 불필요한 파일을 읽지 않고 건너뛰는 최적화 기법입니다. Delta Lake는 각 파일의 통계 정보를 트랜잭션 로그에 저장하고, 쿼리의 필터 조건과 비교하여 읽을 필요가 없는 파일을 미리 제외합니다.

이를 통해 실제 데이터 스캔량을 수십 배 줄일 수 있습니다.

다음 코드를 살펴봅시다.

# 데이터 스킵핑 동작 확인
from pyspark.sql.functions import col

# 쿼리 실행 - 데이터 스킵핑 자동 적용
query_df = spark.read.format("delta").load("/data/transactions") \
    .filter(col("user_id") == 12345) \
    .filter(col("transaction_date") >= "2024-01-01") \
    .filter(col("transaction_date") < "2024-02-01")

# 실행 계획 확인 - 스킵된 파일 정보 포함
query_df.explain("extended")

# Delta Lake 통계 정보 조회
spark.sql("""
  DESCRIBE DETAIL delta.`/data/transactions`
""").select("numFiles", "sizeInBytes").show()

김개발 씨가 쿼리를 실행할 때마다 신기한 일이 일어났습니다. 테이블에는 1000개의 파일이 있는데, 실제로는 10개만 읽고 결과가 나왔습니다.

990개 파일은 어떻게 건너뛴 걸까요? 박시니어 씨가 설명합니다.

"데이터 스킵핑이라는 마법이죠. 마법이라고 했지만 사실은 매우 논리적인 메커니즘입니다." 데이터 스킵핑의 원리를 이해하려면 먼저 Delta Lake의 메타데이터 구조를 알아야 합니다.

쉽게 비유하자면, Delta Lake는 거대한 도서관과 같습니다. 각 파일은 책장에 꽂힌 책 한 권입니다.

도서관 사서는 모든 책의 목록을 관리하는데, 단순히 제목만 기록하는 게 아닙니다. "이 책의 첫 페이지는 1900년대를 다루고, 마지막 페이지는 2000년대를 다룬다"는 식의 요약 정보도 함께 기록합니다.

이제 누군가 "1950년대에 대한 책을 찾아주세요"라고 요청하면, 사서는 목록만 보고 "이 책은 19002000년을 다루니까 1950년이 포함될 수 있어요. 하지만 저 책은 20102020년이니까 절대 포함 안 돼요"라고 판단할 수 있습니다.

데이터 스킵핑이 바로 이런 방식입니다. Delta Lake의 트랜잭션 로그에는 각 파일에 대한 상세한 통계가 저장됩니다.

각 파일마다 모든 컬럼의 최솟값과 최댓값이 기록됩니다. 예를 들어 file_001.parquet에는 user_id가 1부터 5000까지, transaction_date가 2024-01-01부터 2024-01-15까지 포함되어 있다는 정보가 저장됩니다.

쿼리가 "user_id = 12345인 데이터를 찾아라"라고 요청하면, Spark는 먼저 트랜잭션 로그를 읽습니다. file_001.parquet의 user_id 범위는 1~5000이므로 12345가 포함될 수 있습니다.

읽어야 합니다. 하지만 file_050.parquet의 user_id 범위가 50001~55000이라면?

12345는 절대 없습니다. 건너뛸 수 있습니다.

Z-Order와 데이터 스킵핑의 시너지가 진짜 핵심입니다. Z-Order를 적용하지 않은 테이블에서도 데이터 스킵핑은 작동합니다.

하지만 효과가 제한적입니다. 데이터가 무작위로 흩어져 있으면 대부분의 파일이 넓은 범위의 값을 포함하게 됩니다.

file_001에 user_id 1, 50000, 123456이 섞여 있으면, 이 파일의 min/max는 1~123456이 됩니다. 거의 모든 쿼리가 이 범위에 해당하므로 건너뛸 수 없습니다.

Z-Order를 적용하면 비슷한 값들이 같은 파일에 모입니다. file_001에는 user_id 11000만, file_002에는 10012000만 들어갑니다.

이제 "user_id = 12345"를 찾을 때 file_013 정도만 읽으면 됩니다. 실제 코드를 살펴보겠습니다. 쿼리 자체는 평범합니다.

특별한 힌트나 옵션을 주지 않아도 Delta Lake가 자동으로 데이터 스킵핑을 적용합니다. explain("extended")를 호출하면 실행 계획을 볼 수 있는데, 여기에 "PushedFilters"라는 항목이 나타납니다.

PushedFilters는 Spark가 파일을 읽기 전에 적용하는 필터 조건입니다. 데이터 스킵핑의 핵심 단서입니다.

예를 들어 "user_id = 12345" 조건이 PushedFilters에 나타나면, Spark가 파일별 통계를 보고 불필요한 파일을 제외했다는 뜻입니다. 실무에서의 효과는 어느 정도일까요?

한 금융회사의 사례를 보겠습니다. 이 회사는 10년치 거래 데이터를 Delta Lake에 저장합니다.

총 5만 개의 파일, 50테라바이트 규모입니다. Z-Order와 데이터 스킵핑을 적용하기 전에는 "지난 주 특정 고객의 거래"를 조회하는 데 1시간이 걸렸습니다.

전체 50테라바이트를 스캔했기 때문입니다. Z-Order를 customer_id와 transaction_date에 적용한 후, 같은 쿼리가 2분 만에 완료되었습니다.

데이터 스킵핑 덕분에 실제로 읽은 데이터는 100기가바이트 미만이었습니다. 500배의 스캔량 감소가 30배의 속도 향상으로 이어진 것입니다.

주의할 점도 있습니다. 데이터 스킵핑은 범위 필터(>, <, BETWEEN)에 특히 효과적입니다.

"transaction_date >= 2024-01-01"같은 조건은 min/max 통계와 완벽하게 매칭됩니다. 하지만 LIKE 패턴이나 복잡한 함수 조건은 스킵핑이 어렵습니다.

"user_name LIKE '%kim%'" 같은 쿼리는 통계만으로 판단할 수 없어서 모든 파일을 읽어야 할 수 있습니다. NULL 값 처리도 흥미롭습니다.

컬럼에 NULL이 많으면 min/max 통계가 왜곡될 수 있습니다. Delta Lake는 NULL 개수도 별도로 기록하여 "IS NULL" 또는 "IS NOT NULL" 조건에 대해서도 스킵핑을 수행할 수 있습니다.

김개발 씨가 감탄했습니다. "와, 시스템이 이렇게 똑똑하게 판단하는 거였군요. 통계 정보만으로도 이런 일이 가능하다니!" 박시니어 씨가 웃으며 말했습니다.

"맞아요. 데이터베이스 이론에서 나온 오래된 아이디어지만, 빅데이터 시대에 다시 빛을 발하고 있죠." 데이터 스킵핑은 여러분이 특별히 신경 쓰지 않아도 자동으로 작동합니다.

하지만 그 원리를 이해하면 더 효율적인 쿼리를 작성하고, 테이블을 설계할 수 있습니다.

실전 팁

💡 - 범위 필터 활용: =, >, <, BETWEEN 같은 조건이 스킵핑에 유리

• 트랜잭션 로그 크기 관리: 파일이 너무 많으면 메타데이터 읽기도 부담
• OPTIMIZE 주기 실행: 작은 파일들을 병합하여 스킵핑 효율 증대

---

4. 파일 통계와 Min/Max 값 활용

김개발 씨는 데이터 스킵핑의 원리를 알게 되었지만, 구체적으로 어떤 통계가 저장되는지 궁금했습니다. "Min/Max만 저장되나요?

다른 정보는 없나요?" 박시니어 씨가 Delta Lake의 트랜잭션 로그 파일을 열어 보여주었습니다.

Delta Lake의 파일 통계는 각 데이터 파일의 컬럼별 최솟값, 최댓값, NULL 개수를 트랜잭션 로그에 JSON 형태로 저장합니다. 이 통계 정보는 쿼리 최적화의 핵심 재료가 되며, 테이블 크기가 커질수록 그 중요성이 더욱 커집니다.

통계를 효과적으로 활용하면 스캔량을 최소화하고 쿼리 성능을 극대화할 수 있습니다.

다음 코드를 살펴봅시다.

# 파일별 통계 정보 직접 조회
from delta.tables import DeltaTable
import json

# Delta 테이블의 트랜잭션 로그 읽기
delta_log = DeltaTable.forPath(spark, "/data/transactions")

# 파일별 통계 확인 (Scala/Java API에서 가능)
# Python에서는 _delta_log 경로 직접 읽기
log_files = spark.read.json("/data/transactions/_delta_log/*.json")

# AddFile 액션에서 stats 추출
log_files.filter("add is not null") \
    .select("add.path", "add.size", "add.stats") \
    .show(5, truncate=False)

# stats JSON 파싱 예시
# {"numRecords":1000,"minValues":{"user_id":1,"date":"2024-01-01"},
#  "maxValues":{"user_id":5000,"date":"2024-01-31"},"nullCount":{"user_id":0}}

어느 날 김개발 씨는 Delta Lake의 _delta_log 폴더를 우연히 열어보게 되었습니다. 000000.json, 000001.json...

수많은 JSON 파일들이 보였습니다. 궁금해서 하나를 열어봤는데, 복잡한 구조의 JSON 데이터가 가득했습니다.

박시니어 씨가 옆에서 말했습니다. "그게 바로 Delta Lake의 두뇌입니다.

트랜잭션 로그라고 하죠." 트랜잭션 로그의 구조는 생각보다 단순합니다. 쉽게 비유하자면, 트랜잭션 로그는 건물의 설계도이자 변경 이력입니다.

새로운 방이 추가되면(파일 추가), 어느 위치에 어떤 크기로 만들어졌는지 기록됩니다. 방을 철거하면(파일 삭제), 그 기록도 남습니다.

언제든지 이 로그를 읽으면 건물의 현재 상태를 정확히 알 수 있습니다. 각 JSON 파일에는 "add", "remove", "metaData", "protocol" 같은 액션들이 기록됩니다.

우리가 주목할 부분은 "add" 액션입니다. add 액션의 stats 필드에 파일 통계가 들어있습니다.

예를 들어 이런 구조입니다: { "add": { "path": "part-00000-xxxxx.parquet", "size": 52428800, "stats": "{\"numRecords\":100000,\"minValues\":{\"user_id\":1,\"amount\":0.01,\"date\":\"2024-01-01\"},\"maxValues\":{\"user_id\":50000,\"amount\":9999.99,\"date\":\"2024-01-31\"},\"nullCount\":{\"user_id\":0,\"amount\":5,\"date\":0}}" } } stats 필드는 JSON 문자열로 인코딩되어 있습니다. 파싱하면 numRecords(레코드 수), minValues(최솟값 맵), maxValues(최댓값 맵), nullCount(NULL 개수 맵)를 얻을 수 있습니다.

각 통계 항목의 의미를 살펴보겠습니다. numRecords는 해당 파일에 몇 개의 행이 있는지 나타냅니다.

이 정보는 COUNT(*) 같은 집계 쿼리를 최적화하는 데 사용됩니다. 실제 파일을 읽지 않고도 전체 행 수를 계산할 수 있습니다.

minValues와 maxValues는 각 컬럼의 범위를 나타냅니다. 숫자형, 날짜형, 문자열 모두 min/max가 기록됩니다.

문자열의 경우 사전 순서로 최솟값과 최댓값이 결정됩니다. "apple"과 "zebra" 사이에 "banana"가 있는지 판단할 수 있습니다.

nullCount는 각 컬럼에 NULL 값이 몇 개 있는지 알려줍니다. "WHERE column IS NOT NULL" 같은 조건을 평가할 때, nullCount가 0인 파일은 확실히 포함되고, nullCount가 numRecords와 같은 파일은 확실히 제외됩니다.

통계 수집의 오버헤드는 어느 정도일까요? Delta Lake는 데이터를 쓸 때 자동으로 통계를 계산합니다.

Parquet 파일을 작성하는 과정에서 각 컬럼의 min/max를 추적하는 것은 비교적 가벼운 작업입니다. 대부분의 경우 쓰기 성능에 눈에 띄는 영향을 주지 않습니다.

하지만 컬럼 수가 매우 많거나(수백 개 이상), 문자열 컬럼의 크기가 큰 경우 통계 크기가 커질 수 있습니다. Delta Lake는 기본적으로 통계에 저장되는 문자열 길이를 제한합니다(약 32자).

너무 긴 문자열은 잘려서 저장됩니다. 실무 활용 사례를 보겠습니다.

한 광고 플랫폼 회사는 클릭 이벤트 로그를 Delta Lake에 저장합니다. 테이블에는 timestamp, user_id, ad_id, click_type 등의 컬럼이 있습니다.

매일 수억 건의 이벤트가 발생하고, 1년치 데이터는 수십 테라바이트입니다. 분석가들이 자주 실행하는 쿼리는 "어제 특정 광고를 클릭한 사용자 수"입니다.

Z-Order를 ad_id와 timestamp에 적용한 덕분에, "어제"에 해당하는 파일들이 명확히 구분됩니다. 데이터 스킵핑이 timestamp의 min/max를 보고 2024-01-01의 파일들만 선택합니다.

전체 1년치 중 하루치만 읽으므로 쿼리가 365배 빨라집니다. 통계가 없는 파일도 가끔 있습니다.

Delta Lake 0.7.0 이전 버전에서 작성된 파일이나, 외부 도구로 직접 추가된 파일은 통계가 없을 수 있습니다. 이런 경우 해당 파일은 항상 스캔 대상에 포함됩니다.

안전을 위한 보수적인 전략입니다. 통계를 다시 생성하려면 OPTIMIZE 명령을 실행하면 됩니다.

파일을 다시 쓰는 과정에서 통계가 새로 계산됩니다. 통계 정확도는 어떨까요?

min/max와 nullCount는 정확한 값입니다. 근사치가 아닙니다.

따라서 이 통계를 기반으로 한 데이터 스킵핑은 절대 틀린 결과를 내지 않습니다. 건너뛸 수 있는 파일을 놓칠 수는 있어도(보수적), 필요한 파일을 건너뛰지는 않습니다(안전).

김개발 씨가 정리했습니다. "그러니까 Delta Lake는 파일을 쓸 때마다 자동으로 통계를 만들고, 쿼리할 때는 그 통계를 보고 필요한 파일만 읽는 거네요. 정말 영리한 시스템이에요!" 박시니어 씨가 웃으며 대답했습니다.

"맞아요. 메타데이터의 힘이죠.

데이터에 대한 데이터가 성능을 좌우합니다." 여러분도 Delta Lake를 사용한다면, 보이지 않는 곳에서 트랜잭션 로그가 열심히 일하고 있다는 것을 기억하세요. 그리고 OPTIMIZE와 Z-Order로 그 효과를 극대화할 수 있습니다.

실전 팁

💡 - OPTIMIZE 주기 실행: 통계 품질 유지와 파일 병합 효과

• 통계 수집 비활성화: 극단적으로 높은 쓰기 처리량이 필요한 경우만 고려
• 트랜잭션 로그 정리: VACUUM으로 오래된 로그 삭제하여 메타데이터 크기 관리

---

5. 파티셔닝 vs Z-Order 비교

김개발 씨는 회사 선배들과 점심을 먹다가 흥미로운 논쟁을 목격했습니다. "파티셔닝이 더 낫지!" "아니야, Z-Order가 훨씬 유연해!" 두 선배가 열띤 토론을 벌이고 있었습니다.

김개발 씨는 박시니어 씨에게 물었습니다. "둘 중 뭐가 정답인가요?"

파티셔닝과 Z-Order는 서로 다른 접근 방식의 데이터 조직화 기법입니다. 파티셔닝은 물리적으로 디렉터리를 나누어 데이터를 저장하며, 단일 컬럼에 대해 강력한 효과를 발휘합니다.

Z-Order는 파일 내에서 데이터를 재배치하며, 다차원 필터링에 유리합니다. 두 기법은 상호 배타적이지 않으며, 함께 사용할 때 최고의 성능을 얻을 수 있습니다.

다음 코드를 살펴봅시다.

# 파티셔닝 예시
df.write.format("delta") \
    .partitionBy("year", "month") \
    .save("/data/transactions_partitioned")

# Z-Order 예시
delta_table = DeltaTable.forPath(spark, "/data/transactions_zorder")
delta_table.optimize().executeZOrderBy("user_id", "product_id")

# 복합 전략: 파티셔닝 + Z-Order
# 1단계: 날짜로 파티셔닝
df.write.format("delta") \
    .partitionBy("year", "month") \
    .save("/data/transactions_hybrid")

# 2단계: 각 파티션 내에서 Z-Order
from delta.tables import DeltaTable
dt = DeltaTable.forPath(spark, "/data/transactions_hybrid")
dt.optimize().where("year = 2024 AND month = 1") \
    .executeZOrderBy("user_id", "product_id")

김개발 씨는 두 선배의 논쟁을 듣고 혼란스러워졌습니다. 파티셔닝도 좋고 Z-Order도 좋다는데, 도대체 뭐가 다르고 언제 무엇을 써야 할까요?

박시니어 씨가 화이트보드 앞으로 가서 설명을 시작했습니다. "둘 다 좋은 기법이에요.

하지만 작동 방식과 적용 상황이 다릅니다." 파티셔닝의 원리는 매우 직관적입니다. 마치 서랍장을 생각해보세요.

옷을 정리할 때 첫 번째 서랍에는 여름옷, 두 번째 서랍에는 겨울옷을 넣습니다. 여름옷을 찾을 때는 첫 번째 서랍만 열어보면 됩니다.

나머지 서랍은 아예 열 필요가 없습니다. 파티셔닝도 마찬가지입니다.

데이터를 연도별, 월별로 나누면 /data/year=2024/month=01/, /data/year=2024/month=02/ 같은 디렉터리가 생깁니다. "2024년 1월 데이터를 달라"는 쿼리가 오면, Spark는 해당 디렉터리만 읽습니다.

다른 월 데이터는 아예 목록에도 없습니다. Z-Order의 원리는 좀 더 섬세합니다.

같은 서랍 안에서도 옷을 잘 정리할 수 있습니다. 색깔별로, 종류별로 배치하는 것입니다.

서랍 자체를 나누지는 않지만, 내부적으로 질서를 만드는 것입니다. Z-Order는 파일 안에서 비슷한 데이터를 가까이 배치하고, 파일별 통계를 활용하여 불필요한 파일을 건너뜁니다.

파티셔닝의 장점은 명확합니다. 첫째, 매우 빠릅니다.

디렉터리 구조만 보면 어떤 파일을 읽을지 즉시 알 수 있습니다. 메타데이터 읽기 비용이 거의 없습니다.

둘째, 단순합니다. 설정하기 쉽고, 동작을 이해하기 쉽습니다.

초보자도 금방 적용할 수 있습니다. 셋째, 파티션 프루닝이 강력합니다.

"WHERE year = 2024"같은 조건은 완벽하게 파티션을 제거합니다. 하지만 파티셔닝의 단점도 분명합니다.

첫째, 카디널리티가 낮은 컬럼에만 적합합니다. 날짜, 지역, 카테고리처럼 값이 수십~수백 개인 컬럼이 좋습니다.

만약 user_id(수백만 개)로 파티셔닝하면 수백만 개의 디렉터리가 생깁니다. 파일 시스템이 감당하기 어렵고, 메타데이터만 관리하는 데도 엄청난 비용이 듭니다.

둘째, 단일 차원에만 효과적입니다. 날짜로 파티셔닝하면 날짜 필터는 빠르지만, user_id 필터는 여전히 모든 파티션을 뒤져야 합니다.

셋째, 파티션 변경이 어렵습니다. 한번 파티셔닝 컬럼을 정하면, 바꾸려면 전체 데이터를 다시 써야 합니다.

Z-Order의 장점은 다차원성입니다. 여러 컬럼을 동시에 고려하여 데이터를 배치합니다.

user_id, product_id, date를 Z-Order하면, 이 세 컬럼의 조합으로 필터링할 때 모두 효과를 봅니다. 또한 유연합니다.

언제든지 Z-Order 컬럼을 바꿔서 다시 실행할 수 있습니다. 파티셔닝처럼 디렉터리 구조가 고정되지 않습니다.

카디널리티가 높은 컬럼에도 잘 작동합니다. user_id가 수백만 개여도 문제없습니다.

하지만 Z-Order의 단점도 있습니다. 첫째, 파티셔닝보다 느립니다.

파일별 통계를 읽고 비교하는 과정이 필요합니다. 파일이 수만 개라면 메타데이터 읽기만 해도 시간이 걸립니다.

둘째, OPTIMIZE 작업이 필요합니다. 데이터를 재배치하는 과정이 무겁고 시간이 걸립니다.

자주 변경되는 테이블에는 부담스럽습니다. 셋째, 완벽한 분리는 아닙니다.

파티셔닝처럼 "이 데이터는 절대 없다"고 단언하기 어렵습니다. 통계 기반 추정이므로 보수적으로 작동합니다.

실무에서는 어떻게 선택할까요? 한 전자상거래 회사의 사례를 보겠습니다. 주문 테이블은 매일 수백만 건씩 쌓입니다.

분석가들은 주로 "특정 기간 동안 특정 사용자의 주문"을 조회합니다. 처음에는 date 컬럼만으로 파티셔닝했습니다.

날짜 필터는 빨랐지만, user_id 필터는 여전히 느렸습니다. 하루에도 수백만 사용자가 주문하므로, 하루치 데이터를 다 뒤져야 했습니다.

다음으로 date와 user_id 둘 다로 파티셔닝을 시도했습니다. 하지만 user_id가 수백만 개라 파티션이 너무 많아졌습니다.

작은 파일이 난립하고, 메타데이터 관리 비용이 폭증했습니다. 최종 해결책은 하이브리드 전략이었습니다.

date로만 파티셔닝하되, 각 파티션 내에서 user_id와 product_id로 Z-Order를 적용했습니다. 이렇게 하면 날짜 필터는 파티션 프루닝으로 빠르게 처리되고, 사용자/상품 필터는 Z-Order와 데이터 스킵핑으로 최적화됩니다.

코드를 살펴보겠습니다. 첫 번째 예시는 순수 파티셔닝입니다. partitionBy("year", "month")로 연도와 월별 디렉터리가 생성됩니다.

두 번째 예시는 순수 Z-Order입니다. 파티셔닝 없이 user_id와 product_id로만 최적화합니다.

세 번째 예시가 하이브리드 전략입니다. 먼저 파티셔닝으로 쓰고, 그 다음 특정 파티션(year=2024, month=1)에 대해서만 Z-Order를 실행합니다.

where 절로 최적화 대상을 제한할 수 있습니다. 김개발 씨가 이해했다는 표정을 지었습니다. "아, 그러니까 파티셔닝과 Z-Order는 경쟁 관계가 아니라 협력 관계네요.

함께 쓰면 더 강력해지는 거군요!" 박시니어 씨가 엄지를 치켜세웠습니다. "정확해요.

데이터 최적화에 은총알은 없어요. 상황에 맞게 조합하는 게 핵심입니다." 여러분도 테이블을 설계할 때 쿼리 패턴을 먼저 분석하고, 파티셔닝과 Z-Order를 적절히 조합하세요.

그것이 진정한 성능 최적화의 길입니다.

실전 팁

💡 - 파티셔닝 우선: 카디널리티 낮고 필터에 항상 사용되는 컬럼 (날짜 등)

• Z-Order 보조: 카디널리티 높고 다차원 필터링 컬럼
• 파티션 수 제한: 전체 파티션 수가 수천 개 이하로 유지

---

6. 복합 최적화 전략

김개발 씨는 이제 Z-Order와 파티셔닝을 모두 이해했습니다. 하지만 실전에 투입하려니 막막했습니다.

"언제 OPTIMIZE를 실행해야 하죠? 얼마나 자주요?

비용은 얼마나 들까요?" 박시니어 씨가 자신의 노트북을 열어 실전 전략을 공유하기 시작했습니다.

복합 최적화 전략은 파티셔닝, Z-Order, 파일 컴팩션, 통계 관리를 종합적으로 활용하는 실전 접근법입니다. 데이터 특성, 쿼리 패턴, 업데이트 빈도, 비용 제약을 모두 고려하여 최적의 조합을 찾아야 합니다.

자동화된 주기적 최적화와 모니터링이 장기적인 성능 유지의 핵심입니다.

다음 코드를 살펴봅시다.

# 종합 최적화 전략 구현
from delta.tables import DeltaTable
from datetime import datetime, timedelta

# 1. 최근 파티션만 선택적 최적화 (비용 절감)
recent_date = (datetime.now() - timedelta(days=7)).strftime("%Y-%m-%d")
delta_table = DeltaTable.forPath(spark, "/data/transactions")

# 2. 작은 파일 병합 + Z-Order 동시 수행
delta_table.optimize() \
    .where(f"transaction_date >= '{recent_date}'") \
    .executeZOrderBy("user_id", "product_id")

# 3. 오래된 파일 정리 (스토리지 비용 절감)
delta_table.vacuum(168)  # 7일 이전 파일 삭제

# 4. 통계 확인 및 모니터링
stats = spark.sql("""
    DESCRIBE DETAIL delta.`/data/transactions`
""").collect()[0]

print(f"파일 수: {stats['numFiles']}")
print(f"전체 크기: {stats['sizeInBytes'] / 1024**3:.2f} GB")

# 5. 최적화 효과 측정
spark.sql("ANALYZE TABLE delta.`/data/transactions` COMPUTE STATISTICS")

김개발 씨는 첫 Z-Order 적용 후 성능 향상에 고무되어, 모든 테이블에 매일 OPTIMIZE를 실행하기 시작했습니다. 일주일 후, 클라우드 비용 청구서가 날아왔습니다.

금액이 평소의 3배였습니다. 박시니어 씨가 한숨을 쉬며 말했습니다.

"최적화도 비용이에요. 무턱대고 하면 안 됩니다.

전략이 필요해요." 복합 최적화 전략의 첫 번째 원칙은 선택과 집중입니다. 마치 집안 청소를 생각해보세요.

매일 집 전체를 대청소할 수는 없습니다. 매일 쓰는 거실과 부엌은 자주 청소하지만, 창고는 한 달에 한 번이면 충분합니다.

데이터 최적화도 마찬가지입니다. 자주 조회되는 핫 데이터는 적극적으로 최적화하고, 거의 안 쓰이는 콜드 데이터는 최소한만 관리합니다.

또한 최근 파티션만 최적화하고 오래된 파티션은 건드리지 않는 것도 좋은 전략입니다. 두 번째 원칙은 타이밍입니다.

OPTIMIZE 작업은 데이터를 다시 쓰는 과정이므로 시간과 리소스를 소모합니다. 비즈니스 시간대에 실행하면 실시간 쿼리들이 느려질 수 있습니다.

따라서 새벽이나 주말같이 트래픽이 적은 시간대에 스케줄링하는 것이 좋습니다. 또한 데이터 변경 주기도 고려해야 합니다.

매시간 새 데이터가 들어오는 테이블이라면 매일 최적화할 필요가 있지만, 일주일에 한 번만 업데이트되는 테이블은 주 단위 최적화면 충분합니다. 세 번째 원칙은 파일 크기 관리입니다.

Delta Lake의 OPTIMIZE는 작은 파일들을 큰 파일로 병합하는 컴팩션 기능도 수행합니다. 이상적인 파일 크기는 128MB~1GB 정도입니다.

파일이 너무 작으면 파일 개수가 많아져 메타데이터 오버헤드가 커지고, 너무 크면 병렬 처리 효율이 떨어집니다. spark.databricks.delta.optimize.maxFileSize 설정으로 목표 파일 크기를 조정할 수 있습니다.

기본값은 1GB이지만, 쿼리 패턴에 따라 조정할 수 있습니다. 네 번째 원칙은 VACUUM과의 조화입니다.

OPTIMIZE를 실행하면 기존 파일은 그대로 두고 새 파일을 만듭니다. Delta Lake의 MVCC(다중 버전 동시성 제어) 때문입니다.

이전 버전을 조회하는 쿼리가 있을 수 있으므로, 바로 삭제하지 않습니다. 하지만 시간이 지나면 오래된 파일들이 쌓여서 스토리지 비용이 증가합니다.

VACUUM 명령은 지정된 기간(기본 7일) 이전의 오래된 파일을 삭제합니다. OPTIMIZE 후 적절한 시점에 VACUUM을 실행하여 스토리지를 정리해야 합니다.

코드를 단계별로 살펴보겠습니다. 첫 번째 단계에서는 최근 7일치 데이터만 최적화 대상으로 선택합니다. where 절로 파티션을 제한하면 비용을 크게 줄일 수 있습니다.

전체 1년치 데이터 중 최근 일주일만 최적화하면 작업 시간도 단축되고 비용도 절감됩니다. 두 번째 단계는 OPTIMIZE와 Z-Order를 동시에 수행합니다.

두 작업은 모두 데이터를 재작성하므로, 함께 실행하는 것이 효율적입니다. 따로 실행하면 데이터를 두 번 쓰게 됩니다.

세 번째 단계는 VACUUM입니다. 168시간(7일) 이전의 파일들을 삭제합니다.

타임 트래블 기능을 7일까지만 지원하겠다는 의미입니다. 더 긴 보존 기간이 필요하면 이 값을 늘릴 수 있습니다.

네 번째 단계는 모니터링입니다. DESCRIBE DETAIL로 테이블의 파일 수, 전체 크기를 확인합니다.

파일 수가 수만 개를 넘어가면 OPTIMIZE를 더 자주 실행해야 한다는 신호입니다. 실무 사례를 보겠습니다. 한 핀테크 회사는 거래 데이터 테이블을 운영합니다.

하루 1천만 건씩 데이터가 쌓이고, 분석가들은 주로 최근 한 달치 데이터를 조회합니다. 최적화 전략은 이렇습니다: - 매일 새벽 3시에 어제 파티션만 OPTIMIZE + Z-Order 실행 (10분 소요) - 매주 일요일에 지난 주 전체 파티션 재최적화 (1시간 소요) - 매달 1일에 VACUUM 실행하여 30일 이전 파일 삭제 이렇게 하니 쿼리 성능은 계속 좋은 수준을 유지하면서도, 최적화 비용은 전체 운영 비용의 5% 미만으로 관리되었습니다.

자동화가 핵심입니다. 수동으로 OPTIMIZE를 실행하는 것은 금방 잊어버리게 됩니다.

Apache Airflow, AWS Step Functions, Azure Data Factory 같은 워크플로우 오케스트레이션 도구로 스케줄링하는 것이 좋습니다. 간단한 cron job으로도 가능합니다.

Python 스크립트를 작성하여 정기적으로 실행하면 됩니다. 성능 모니터링과 튜닝도 잊지 말아야 합니다.

쿼리 로그를 주기적으로 분석하여 어떤 컬럼이 자주 필터링되는지 확인합니다. 패턴이 바뀌면 Z-Order 컬럼도 조정합니다.

예를 들어 처음에는 user_id가 중요했지만, 6개월 후 product_id가 더 중요해졌다면 Z-Order 컬럼을 변경합니다. 또한 Spark UI에서 실제 스캔된 데이터량을 확인합니다.

데이터 스킵핑이 제대로 작동하는지, 파티션 프루닝이 효과적인지 검증할 수 있습니다. 김개발 씨가 자신감을 얻었습니다. "이제 알겠어요.

최적화는 일회성 작업이 아니라 지속적인 관리 프로세스네요. 모니터링하고, 조정하고, 자동화하는 게 핵심이군요." 박시니어 씨가 만족스러운 표정으로 말했습니다.

"완벽해요. 이제 당신도 데이터 엔지니어로서 한 단계 성장했어요." 여러분도 단순히 Z-Order를 한 번 실행하고 끝내지 마세요.

종합적인 최적화 전략을 수립하고, 자동화하고, 지속적으로 모니터링하세요. 그것이 빅데이터 시스템을 건강하게 유지하는 비결입니다.

실전 팁

💡 - 점진적 최적화: 한 번에 전체가 아니라 최근 파티션부터 시작

• 비용 모니터링: OPTIMIZE 비용과 쿼리 성능 향상을 정량적으로 비교
• 자동화 도구 활용: Airflow, Step Functions 등으로 스케줄링
• A/B 테스트: 최적화 전후 쿼리 성능을 측정하여 효과 검증

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!