상태 없는 분산 SQL 엔진 (POLARIS, VLDB 2020)

출처

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

한눈에

• Polaris 는 Azure SQL Data Warehouse 의 쿼리 처리 계층을 다시 설계한 것으로, 데이터 웨어하우스와 빅데이터 작업의 수렴, 그리고 계산과 상태의 분리라는 두 목표를 내걸었습니다.
• 모든 데이터를 사용자 파티션과 시스템 해시 분산의 조합인 "셀(cell)"로 추상화하고, 질의를 셀 단위 작업(task)의 DAG 로 바꿔 실행합니다.
• 계산 노드는 상태를 갖지 않으므로 실행 중에도 노드를 늘리거나 줄이고, 고장 난 노드의 작업만 다시 돌릴 수 있습니다.
• 각 작업은 노드 안의 SQL Server 엔진이 그대로 실행해, 수십 년 다듬어진 단일 노드 최적화를 재사용합니다. 1PB 규모에서 TPC-H 22개 질의를 모두 실행한 결과를 보고합니다.

왜 나왔나

전통적인 MPP 데이터 웨어하우스는 노드마다 데이터 일부를 로컬에 들고 있는 상태 있는(stateful) 구조였습니다. 이 구조에서는 노드 하나가 죽으면 그 노드가 가진 데이터와 실행 상태를 되살려야 하고, 노드 수를 바꾸려면 데이터를 다시 나눠야 합니다. 그래서 확장과 축소가 느리고, 장애 복구도 질의 전체를 다시 돌리는 식이 되기 쉽습니다. 동시에 고객의 데이터는 점점 데이터 레이크의 Parquet, CSV 같은 파일로 쌓여 갔고, 웨어하우스로 옮기지 않고 그 자리에서 질의하고 싶다는 요구가 커졌습니다.

2장은 이 대비를 그림 1로 설명합니다. Polaris 는 데이터, 트랜잭션 로그, 메타데이터를 모두 계산 바깥에 두는 상태 없는(stateless) 구조를 택합니다. 계산 노드에 남는 것은 언제든 다시 만들 수 있는 캐시뿐입니다.

핵심 아이디어

데이터 셀

3장의 셀 추상화가 Polaris 의 기초입니다. 데이터셋의 각 행은 사용자가 정한 파티션 함수 p(r) 와 시스템이 정한 해시 분산 함수 h(r) 에 따라 셀 C(i,j) 하나에 들어갑니다(그림 2). 셀은 저장 형식과 무관한 논리 단위라서, 셀 단위로 효율적으로 읽을 수만 있다면 데이터 레이크의 파일이든 트랜잭션 저장소든 원본이 될 수 있습니다(그림 3). 이 덕분에 계산은 "어느 노드가 어떤 셀을 처리할지"만 정하면 되고, 데이터가 어느 노드에 묶여 있는지 신경 쓰지 않아도 됩니다.

셀을 계산에 대응시키기

4장은 분산 최적화를 다룹니다. 조인이나 집계가 올바르게 병렬 실행되려면 입력 데이터가 특정 분산 상태(해시 분산, 단일 버킷, 분산 안 됨)를 만족해야 합니다. 옵티마이저는 이 분산 속성을 정확성 조건이자 탐색 공간의 관심 속성으로 다루고, 조건이 맞지 않으면 해시 재분배나 브로드캐스트 같은 데이터 이동 연산자를 끼워 넣습니다(그림 4). 부록은 연산자마다 요구하는 분산 속성을 표로 정리합니다.

질의에서 작업 DAG 로

5장은 컴파일 과정을 설명합니다. 먼저 SQL Server 의 Cascades 옵티마이저가 MEMO 를 만들고, 그 위에서 분산 비용 기반 최적화를 한 번 더 합니다. 결과 계획은 데이터 이동 연산자를 경계로 잘려 작업 템플릿이 되고, 템플릿을 셀마다 인스턴스로 만든 것이 작업(task)입니다(그림 5, 그림 6). 각 작업은 다시 T-SQL 로 표현되어 계산 노드의 SQL Server 인스턴스에서 그대로 실행됩니다. 분산은 Polaris 가, 단일 노드 실행은 SQL Server 가 맡는 분업입니다.

작업 오케스트레이션과 스케줄링

6장은 수백만 개의 셀과 작업, 수천 대의 노드를 다루기 위해 실행을 계층적 상태 기계로 모델링합니다. 질의 DAG, 작업 템플릿, 작업 각각이 준비, 실행, 대기, 성공, 실패 같은 상태를 가지며, 상태 전이를 기록해 두므로 실패한 작업만 골라 다시 실행할 수 있습니다(그림 7).

7장의 스케줄러는 질의 하나가 아니라 실행 중인 모든 질의의 작업을 하나의 전역 작업 그래프로 봅니다. 작업마다 CPU, 메모리, 임시 디스크 요구량을 다차원으로 표시하고, FIFO, 요구량 순, 루트와의 거리 순 같은 정책으로 남은 용량에 맞춰 작업을 배치합니다(그림 8).

서비스 구조와 탄력성

8장은 서비스 구성을 보여 줍니다(그림 9). SQL Server 프런트엔드가 컴파일과 인증, 메타데이터를 맡고, 분산 쿼리 처리기(DQP)가 작업을 배치하며, 계산 서버마다 실행 서비스와 SSD 캐시를 가진 SQL Server 인스턴스가 돕니다. 메타데이터와 트랜잭션 서비스는 Azure SQL Database 위에 만들었습니다. 형태로는 사용한 만큼 0에서 N 까지 늘어나는 서버리스 방식과, 용량을 예약하고 자동 확장하는 방식을 모두 지원합니다.

9장은 탄력성입니다. 실행 중에 노드가 늘어나면 새 작업은 새 토폴로지에 배치되고 진행 중인 작업은 기존 노드에서 마칩니다. 노드가 죽으면 그 노드의 작업만 건강한 노드에서 다시 시작합니다(그림 10). 셀을 작업에 일관되게 대응시켜 토폴로지가 바뀌어도 캐시를 최대한 재사용합니다.

실험과 결과

10장의 평가는 세 가지입니다.

• 동시성(그림 11): Parquet 형식 1TB TPC-DS 데이터에 대해 세션 5,000개가 각기 다른 질의를 동시에 보냈습니다. 계산 노드 10대에서 작업 템플릿 약 5만 개, 작업 약 55만 개가 만들어졌고, 한때 약 9천 개 작업이 10대에 동시에 배치되었습니다.
• 페타바이트 규모(그림 12): TPC-H 1PB(Parquet 파일 약 12만 개, 압축 후 360TB)에서 22개 질의를 모두 실행했습니다. 실행 서비스 420개를 썼고, 가장 무거운 Q9 와 Q21 도 두 시간 안에 끝났습니다. 저자들은 100TB 를 넘는 규모의 TPC-H 22개 질의 실행 보고로는 처음이라고 적지만, 공인된 TPC-H 벤치마크 결과는 아니라고 밝힙니다.
• 이질적인 데이터(그림 13): 1TB TPC-H 의 테이블을 원시 CSV, 단순 Parquet, 중첩 타입 Parquet 로 섞어 둔 상태에서 100코어 미만으로 22개 질의를 모두 실행했습니다.

지금 Azure 에서는

Polaris 는 Azure Synapse Analytics 의 SQL 엔진으로 공개되었고, 이후 Microsoft Fabric 의 Data Warehouse 가 이 엔진 위에 만들어졌습니다. Fabric 쪽 확장은 2024년 논문 Polaris 에 트랜잭션 더하기가 직접 설명합니다. 2024년 논문에 따르면 셀 추상화, 상태 없는 계산 노드, 노드 안 SQL Server 실행이라는 이 논문의 골격은 Fabric Data Warehouse 에서도 유지되고, 두 단계로 나뉘어 있던 컴파일을 프런트엔드 한곳으로 합치는 식의 변화가 더해졌습니다.

함께 읽기

• Microsoft Fabric, OneLake, Data Factory, Event Hubs, Databricks: 이 사이트의 기능 문서
• Polaris 에 트랜잭션 더하기: Fabric Data Warehouse 로 이어진 후속 논문
• Socrates: 같은 SQL Server 엔진을 OLTP 쪽에서 계산과 저장으로 나눈 사례
• Microsoft Research 논문 페이지