S3 데이터 파티셔닝, 이렇게 하면 망한다: 잘못된 방법과 제대로 하는 법

S3에서 데이터 파티셔닝을 단순하게 시간 단위(연/월/일) 계층으로 설계하면 편해 보이지만, 실제 업무에서는 오히려 쿼리 성능과 관리 측면 모두에서 큰 골칫거리가 될 수 있습니다. 이 글은 그 이유와, 대신 어떤 방식이 실질적으로 더 좋은지에 대해 경험을 바탕으로 설명합니다.

---

1. 연/월/일 파티셔닝의 안락한 함정 😬

처음 데이터 레이크를 설계할 때, 다들 익숙하게 이렇게 제안합니다.

"연도, 월, 일로 파티셔닝합시다!"

실제로 많은 팀이 다음과 같이 구조를 만들죠.

s3://bucket/data/year=2025/month=01/day=01/events.parquet

보기에는 참 분명하고, 폴더처럼 깔끔하게 정리됩니다. 비즈니스 분석가들도 쉽게 탐색할 수 있다는 점이 매력적이죠.

하지만 문제는 실제로 쿼리를 실행하는 순간 시작됩니다.

---

2. 현실의 쿼리: 문제는 바로 여기서

예를 들어, 2024년 1월 1일부터 2025년 2월 10일까지의 데이터를 조회하려고 한다고 해볼까요?

"2024년 1월 1일부터 2025년 2월 10일까지 모든 데이터를 추출해줄 수 있나요?"

겉보기엔 간단한 요청이지만, 실제 쿼리는 어마어마하게 복잡해집니다.

WHERE (year = '2024' AND month = '01' AND day = '01')
   OR (year = '2024' AND month = '01' AND day = '02')
   OR ...
   OR (year = '2025' AND month = '02' AND day = '10')

매일이 추가될수록 OR 조건이 무한정 늘어납니다. 이로 인해 여러 문제가 생깁니다.

"이 정도면 원숭이가 자동으로 만들어냈다고 해도 믿을 쿼리문이죠."

---

3. 연/월/일 파티셔닝의 치명적인 단점들

1. 쿼리 복잡도의 폭발

날짜가 하나 늘어날 때마다 OR 조건이 하나씩 추가돼, 쿼리가 길어지고 관리가 어려워집니다.

2. 파티션 프루닝 비효율

쿼리 엔진이 원하는 날짜만 똑똑하게 선택(파티션 프루닝)하지 못하고, 불필요한 S3 파티션까지 죄다 스캔하게 됩니다.

3. 쿼리 길이 제한

Athena나 Presto 등의 쿼리 엔진은 쿼리 길이에 제한이 있는데, 날짜 수천 개에 걸친 쿼리라면 바로 한계에 부딪힙니다.

4. 성능 저하와 비용 증가

불필요한 S3 API 호출이 많아져서 쿼리 지연이 심해지고, 그만큼 비용도 올라갑니다.

"파티션 개수가 11만 개나 되다니, 도대체 무슨 일이 벌어진 거지? 단순히 데이터 몇 줄 뽑는데도 분보다 훨씬 오래 걸렸어요."

이런 문제를 이야기하면 주변에서 흔히 듣는 세 가지 핑계가 있습니다. 예를 들어, "Hive에서는 잘 되던데?", "연, 월 파티셔닝이 탐색에 좋아요!" 등등. 하지만 S3는 HDFS와 완전히 다르고 관리방식 역시 전혀 다릅니다.

"Hive 파티셔닝은 온프레미스, HDFS 환경에서는 메타데이터가 저장 공간과 강하게 연동되어서 잘 작동했지만, S3는 전혀 그렇지 않아요."

---

4. 잘못된 합리화와 실제 S3의 특성

잘못된 생각 1: "옛날 Hive 방식이니까 믿을 수 있어요."

• Hive의 파티셔닝 방식은 자체 파일 시스템(HDFS)에서만 빠르게 동작합니다. S3에서는 단순히 파티션이 늘어나면,
  • 메타데이터 스캔 많아짐
  • S3 API 호출 증가
  • 전반적인 쿼리 성능 저하 로 이어질 뿐입니다.

잘못된 생각 2: "연/월/일로 폴더를 나누면 인간이 보기 좋아요!"

• S3의 디자인 목표는 고성능, 병렬 처리, 확장성입니다. 인간이 보기 좋은 폴더 구조는 오히려 쿼리 엔진이 비효율적으로 작동하게 만듭니다.

잘못된 생각 3: "연이나 월로만도 자주 조회하니까요!"

• 대다수 쿼리는 특정 범위 조회(BETWEEN)이며, 그런 경우에는 연/월 파티셔닝이 오히려 발목을 잡습니다.

---

5. S3 파티셔닝, 이렇게 해야 한다! 💡

정답: ISO 8601 날짜 단일 파티셔닝

이런 식으로 바꿔보세요.

s3://bucket/data/dt=2025-01-01/events.parquet

장점

• 알파벳 순정렬이 자연스레 날짜 순서와 일치하여, 범위 쿼리가 심플하고 빠르게 동작합니다.

• 쿼리 예시:

  WHERE dt >= '2025-01-01' AND dt <= '2025-02-10'

• 쿼리 엔진은 원하는 날짜 범위에 해당하는 파티션만 깔끔하게 스캔(=파티션 프루닝)하고, 불필요한 논리 연산이나 추가 API 호출 없이 성능도 빨라집니다!

"날짜가 날짜처럼 작동한다는 게 얼마나 아름다운 일인가요!"

반론에 대한 답

간혹, 연 단위 조회가 군더더기 없이 더 짧았으면 좋겠다고 말합니다.

"WHERE dt >= '2025-01-01' AND dt <= '2025-12-31'이 WHERE year = '2025'보다 길어요."

하지만 이런 드문 케이스를 위해 매일 반복적으로 겪는 복잡성과 저조한 성능을 감수한다면 오히려 손해입니다.

실제 효과

• 파티션 1:1 매핑으로 파티션 개수 관리도 편함
• 쿼리 성능 대폭 향상
• 쿼리 작성 심플하고 한눈에 이해 가능

---

6. 한눈에 비교: 연/월/일 vs. ISO 8601 날짜 파티셔닝

---

7. 결론

S3에 데이터를 저장할 때, 연, 월, 일처럼 계층적으로 파티셔닝하는 건 보기엔 편리해도 현실 쿼리에서는 심각한 비효율로 이어집니다.
파티션 키로 ISO 8601(YYYY-MM-DD) 전체 날짜 값을 사용하면 쿼리 성능, 관리 편의성, 비용 절감까지 모두 잡을 수 있습니다.
시간을 아끼고 효율을 높이고 싶다면, 이제부터 날짜 파티셔닝 방식을 바꿔보세요! 🚀