저장과 컴퓨트를 나눈 클라우드 웨어하우스 (Snowflake Elastic Data Warehouse, SIGMOD 2016)

출처

참고 이 페이지는 원문 번역이 아니라 한국어 해설이에요. 정확한 표현과 수치는 원문을 확인하세요.

한눈에

• 기존 데이터 웨어하우스는 고정된 서버 묶음을 전제로 한 shared-nothing 구조라, 클라우드의 탄력성을 살리지 못했습니다.
• Snowflake 는 데이터는 S3 에 두고, 계산은 가상 웨어하우스(VW)라는 EC2 노드 묶음이 맡게 해 저장과 컴퓨트를 분리했습니다. 메타데이터와 최적화, 트랜잭션은 다중 테넌트 클라우드 서비스 계층이 관리합니다.
• 바뀌지 않는 파일과 MVCC 위에 스냅숏 격리, 최소값과 최대값 기반 프루닝, 타임 트래블, 무복사 클론을 얹었습니다.
• JSON 같은 반정형 데이터를 VARIANT 타입으로 그대로 넣고, 내부에서 열로 쪼개 관계형에 가까운 성능을 냈습니다(그림 4). 이 구조가 지금 Snowflake 의 기본 골격입니다.

왜 나왔나

논문은 2012년 말 개발을 시작해 2015년 6월 정식 출시한 시스템을 설명합니다. 저자들은 당시 웨어하우스 기술의 문제를 두 가지로 봅니다. 하나는 데이터 원천이 바뀌었다는 점입니다. 로그, 웹, 모바일, IoT 에서 오는 반정형 데이터는 미리 스키마를 정하고 변환하는 ETL 과 잘 맞지 않습니다. 다른 하나는 구조입니다. shared-nothing 구조에서는 데이터가 노드에 묶여 있으므로, 적재와 복잡한 분석처럼 성격이 다른 작업이 같은 하드웨어를 두고 다투고, 노드를 늘리거나 줄이면 대량의 데이터 재분배가 필요하며, 온라인 업그레이드도 어렵습니다. 노드 교체가 일상인 클라우드에서는 이 약점이 더 커집니다. 저자들은 Hadoop 이나 PostgreSQL 위에 짓지 않고 엔진을 처음부터 새로 만들었다고 밝힙니다.

핵심 아이디어

저장과 컴퓨트의 분리 (2절)

Snowflake 는 저장과 컴퓨트를 따로 늘리고 줄일 수 있게 했습니다. 저장은 S3, 컴퓨트는 Snowflake 자체의 shared-nothing 엔진입니다. 다만 매번 S3 에서 읽으면 느리므로, 각 컴퓨트 노드는 로컬 디스크에 테이블 데이터를 캐시합니다. 논문은 이 절충을 "multi-cluster, shared-data" 구조라고 부릅니다.

데이터 저장 (3.1절)

S3 는 지연이 크고 덮어쓰기가 안 되지만, 사용성과 가용성, 내구성이 뛰어나 직접 저장 서비스를 만드는 대신 택했습니다. 테이블은 큰 불변 파일로 나뉘고, 파일 안은 열마다 값을 모아 둔 PAX 형식입니다. 파일 헤더에 열 위치가 있어 필요한 열만 부분 GET 으로 읽습니다. 쿼리 중 넘친 임시 데이터와 큰 쿼리 결과도 S3 에 둡니다. 어떤 파일이 어떤 테이블의 어느 버전에 속하는지 같은 메타데이터는 클라우드 서비스의 트랜잭션 키값 저장소에 둡니다.

가상 웨어하우스 (3.2절)

VW 는 EC2 인스턴스 묶음이며 사용자는 X-Small 부터 XX-Large 같은 티셔츠 크기만 고릅니다. 쿼리 하나는 VW 하나에서만 실행되고, VW 끼리는 자원을 나누지 않으므로 적재 작업과 대시보드 쿼리를 다른 VW 로 나눠 서로 방해하지 않게 할 수 있습니다. 같은 비용으로 더 빨리 끝낼 수 있다는 예로, 노드 4대로 15시간 걸릴 적재를 32대로 2시간에 끝낼 수 있다고 설명합니다.

• 로컬 캐시와 파일 훔치기: 옵티마이저는 파일 이름에 일관 해싱을 적용해 파일을 노드에 배정하므로 같은 파일은 늘 같은 노드 캐시에 쌓입니다. 노드가 바뀌어도 데이터를 바로 재배치하지 않고, 일이 먼저 끝난 노드가 느린 노드의 파일을 S3 에서 직접 읽어 가는 "파일 훔치기" 로 낙오자를 줄입니다.
• 실행 엔진: 열 지향, 벡터화, 푸시 기반입니다. 수천 행 단위 배치로 연산자 사이를 흐르고, 버퍼 풀 없이 메모리를 넘치면 디스크로 내립니다.

클라우드 서비스 (3.3절)

• 최적화: Cascades 방식의 하향식 비용 기반 옵티마이저입니다. 통계는 적재와 갱신 때 자동으로 유지하고, 인덱스는 없습니다. 조인 분배 방식 같은 결정은 실행 시점으로 미룹니다.
• 동시성 제어: 파일이 불변이므로 쓰기는 파일을 더하고 빼는 일이 되고, 테이블 버전마다 파일 집합을 기록하는 MVCC 로 스냅숏 격리를 제공합니다.
• 프루닝: 인덱스 대신 파일마다 열의 최솟값과 최댓값 같은 메타데이터를 두고, 쿼리 조건으로 읽을 필요 없는 파일을 거릅니다. 해시 조인 빌드 쪽에서 모은 키 통계로 프로브 쪽 파일을 거르는 동적 프루닝도 소개합니다.

기능 (4절)

• 순수 SaaS: 튜닝 손잡이나 물리 설계 작업이 없고, 웹 UI 와 JDBC, ODBC 로 씁니다.
• 지속 가용성: S3 가 여러 가용 영역에 복제되고 클라우드 서비스도 상태 없이 여러 영역에 걸쳐 있습니다. 버전 업그레이드는 새 버전과 옛 버전을 나란히 띄우고 사용자를 점차 옮기는 방식으로 매주 이루어집니다(그림 3).
• 반정형 데이터: VARIANT, ARRAY, OBJECT 타입과 FLATTEN 같은 측면 뷰로 JSON 을 그대로 다룹니다. 파일마다 자주 나오는 경로를 통계로 찾아 타입이 정해진 별도 열로 뽑아 저장하므로 열 지향 압축과 프루닝이 그대로 적용됩니다. 문자열을 숫자나 날짜로 낙관적으로 변환하되 원래 문자열도 남겨 정보 손실을 막습니다.
• 타임 트래블과 클론: 바뀐 파일을 최대 90일 보관해 AT, BEFORE 로 과거 시점을 조회하고 UNDROP 으로 지운 객체를 되살립니다. CLONE 은 데이터 대신 메타데이터만 복사합니다.
• 보안: 루트, 계정, 테이블, 파일 네 단계의 AES-256 키 계층(그림 5)과 주기적 키 교체 및 재암호화(그림 6)를 설명합니다.

실험과 결과

본격적인 성능 비교 대신 반정형 데이터 처리 비용만 측정합니다. 그림 4는 TPC-H 형태 22개 쿼리를 규모 100(100GB)과 1000(1TB)에서, 정상 관계형 스키마와 모든 행을 VARIANT 열 하나에 넣은 스키마로 각각 돌린 결과입니다. 중간 크기 VW 에서 캐시를 데운 뒤 세 번 실행했습니다. 대부분 쿼리에서 VARIANT 쪽 추가 시간은 약 10% 였고, 규모 1000 의 Q9 와 Q17 만 고유값 추정 버그로 조인 순서가 나빠져 더 느렸다고 적습니다. 저자들은 이 결과가 TPC 공인 결과가 아니라고 밝힙니다. 그 밖에 시스템이 하루 수백만 건 쿼리와 여러 PB 데이터를 처리한다는 운영 규모를 소개합니다.

지금 Snowflake 에서는

• 가상 웨어하우스는 지금도 Snowflake 컴퓨트의 기본 단위이며, 크기를 바꾸거나 여러 클러스터로 늘리는 방식으로 확장합니다. 이 구조를 운영 데이터로 다시 분석한 것이 NSDI 2020 논문입니다.
• 불변 파일은 지금 마이크로 파티션이라고 부릅니다. 압축 전 50MB 에서 500MB 정도이며, 파일별 메타데이터 기반 프루닝은 SIGMOD 2025 프루닝 논문에서 크게 확장되었습니다.
• 저장소는 AWS S3 에서 시작해 지금은 Azure Blob Storage, Google Cloud Storage 위에서도 동작합니다.
• 타임 트래블, UNDROP, 무복사 CLONE, VARIANT 와 FLATTEN 은 이름 그대로 제품 기능입니다. 타임 트래블 기간의 최대 90일은 에디션에 따라 다르게 적용됩니다.
• 파일 단위 MVCC 와 테이블 버전 메타데이터는 이후 변경 쿼리와 스트림의 바탕이 됩니다. Change Queries 논문.

함께 읽기

• Snowflake 아키텍처: 이 사이트의 기능 문서
• 캐시 세 가지: 이 사이트의 기능 문서
• 저장 분리 엔진의 운영 데이터 분석 (NSDI 2020)
• 변경 쿼리와 스트림 (SIGMOD 2023)
• 프루닝 (SIGMOD 2025)
• 3저자 Marcin Zukowski 가 쓴 벡터화 실행 논문 MonetDB/X100 (CIDR 2005) 은 ClickHouse 사이트의 논문 채널에서 해설합니다.
• Snowflake 공식 문서: Overview of warehouses, Understanding & using Time Travel