Polaris 에 트랜잭션 더하기 (Extending Polaris, SIGMOD 2024)

출처

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

한눈에

• POLARIS 는 원래 읽기 전용 분산 질의 엔진이었습니다. 이 논문은 여기에 INSERT, UPDATE, DELETE, 대량 적재를 더해 Microsoft Fabric 의 T-SQL 웨어하우스를 만든 과정을 설명합니다.
• 데이터는 OneLake 의 변경 불가능한 Parquet 파일과 삭제 벡터로, 테이블 버전은 매니페스트 파일로 표현하는 로그 구조 테이블(LST)을 씁니다.
• 어떤 매니페스트가 커밋되었는지는 SQL 카탈로그 테이블이 기록하고, 낙관적 MVCC 로 다중 문장, 다중 테이블 트랜잭션에 스냅샷 격리(SI)를 제공합니다.
• 압축, 체크포인트, 가비지 컬렉션 같은 저장 최적화를 사용자 개입 없이 자동으로 돌리고, 시점 조회와 제로 복사 클론을 메타데이터만으로 구현합니다.

왜 나왔나

1장은 당시 흔한 구성을 문제로 꼽습니다. 데이터 준비는 레이크하우스에서 하고, 대화형 보고를 위해 다시 웨어하우스로 복사하는 두 단계 구조입니다. 저자들은 하나의 갱신 가능한 Parquet 기반 형식 위에서 두 작업을 모두 하자는 목표를 세웁니다. 설계 목표는 다섯 가지입니다. 데이터, 메타데이터, 트랜잭션 상태를 계산에서 떼어 내 탄력성을 얻을 것(Fabric 은 쓴 자원 곱하기 시간으로 과금), 열 지향이고 변경 불가능한 공개 형식인 Parquet 를 쓸 것, 버전과 시점 조회와 클론 같은 계보(lineage) 기능을 줄 것, 읽기와 쓰기가 서로 막지 않는 SI 의미를 줄 것, 그리고 구성 요소 사이에 상태를 공유하지 않아 트랜잭션도 질의처럼 Polaris 에 맡길 수 있을 것입니다. 다만 TPC-C 처럼 갱신이 아주 잦은 작업은 행 저장소가 더 낫다고 범위를 분명히 합니다.

핵심 아이디어

로그 구조 테이블

2장은 갱신 가능한 Parquet 저장 방식을 비교합니다. 파일 전체를 다시 쓰는 copy-on-write 와, 새 행은 새 파일에 쓰고 지운 행은 삭제 비트맵으로 표시하는 merge-on-read 가 있고, 쌓인 조각은 백그라운드 압축으로 정리합니다. 물리 배치는 세 층입니다(그림 1). 논리 메타데이터는 SQL 카탈로그에, 물리 메타데이터는 매니페스트 파일과 체크포인트로, 데이터는 OneLake 의 Parquet 파일로 둡니다. Delta Lake 나 Iceberg 가 두 메타데이터 층을 모두 객체 저장소에 두는 것과 다른 점입니다. Parquet 데이터는 Polaris 의 셀로 나뉘어 계산 노드에 배정됩니다(그림 2).

카탈로그 확장과 읽기 쓰기 흐름

3장은 SQL 카탈로그에 두 테이블을 더합니다(그림 4). Manifests 테이블은 테이블별로 커밋된 매니페스트 파일, 순서 번호, 트랜잭션 ID 를 기록하고, WriteSets 테이블은 테이블별 갱신 카운터를 둡니다. 커밋된 트랜잭션만 기록하므로, 중단된 트랜잭션이 남긴 파일은 나중에 가비지 컬렉션으로 지웁니다.

읽기는 트랜잭션 시작 전까지 커밋된 매니페스트 목록으로 스냅샷을 재구성하고, 계산 노드가 이를 메모리에 캐시합니다. 쓰기는 각 작업이 Parquet 파일과 삭제 벡터를 새로 쓰고, 그 목록을 ADLS 블록 Blob API 로 매니페스트 블록에 올립니다. 블록은 프런트엔드가 최종 커밋을 해야만 보이게 됩니다(그림 3). 분산 트랜잭션은 질의처럼 계획되어, 프런트엔드의 SQL 루트 트랜잭션 아래 각 작업이 자기 변경을 비공개로 만들고 Polaris 가 그 결과를 모읍니다(그림 5).

스냅샷 격리

4장의 동시성 제어는 낙관적 MVCC 입니다. 읽기 단계에서는 스냅샷을 읽으며 자기 트랜잭션 매니페스트에 변경을 적습니다. 검증 단계는 프런트엔드가 중앙에서 처리하며 네 단계입니다.

1. 갱신하거나 삭제한 테이블마다 WriteSets 행을 upsert 합니다.
2. 커밋 락을 잡아 커밋 순서를 정합니다.
3. 수정한 테이블의 트랜잭션 매니페스트를 Manifests 에 넣습니다.
4. SQL 트랜잭션을 커밋하고 락을 풉니다.

같은 테이블을 고친 두 트랜잭션이 겹치면, WriteSets 행에 대한 SQL 엔진의 스냅샷 격리 때문에 나중에 커밋하는 쪽이 실패하고 롤백됩니다. 즉 쓰기 충돌 검사를 SQL 카탈로그의 검증된 트랜잭션 엔진에 맡긴 것입니다. 그림 6은 여러 트랜잭션이 겹칠 때 누가 무엇을 보고 누가 실패하는지 예로 보여 줍니다. 기본 충돌 단위는 테이블이지만, 4.4.1절은 같은 데이터 파일(정확히는 그 삭제 벡터)을 고친 경우에만 충돌로 보는 파일 단위 확장을 설명합니다. RCSI 와 직렬화 가능 격리도 SQL 카탈로그의 격리 수준을 바꿔 확장할 수 있고, 고유 키 제약은 적재 성능 때문에 강제하지 않습니다.

자동 저장 최적화

5장은 삭제로 인한 단편화, 작은 파일, 길어지는 매니페스트 목록, 고아 파일을 자동으로 다룹니다. 압축은 SELECT 질의 중에 모은 통계로 필요를 판단해 별도 SI 트랜잭션으로 돌고, 체크포인트는 매니페스트가 일정 수 쌓이면 전체 상태 파일을 만들며, 가비지 컬렉션은 실행 중인 어떤 트랜잭션보다 오래된 미참조 파일만 지웁니다. 또 Delta Lake 메타데이터를 비동기로 게시해 다른 엔진이 OneLake 에서 같은 데이터를 복사 없이 읽게 합니다.

계보 기능

6장은 같은 메타데이터로 시점 조회(Query As Of), 시점 클론(Clones As Of), 제로 데이터 복사 백업과 복원을 구현합니다. 클론은 논리 메타데이터만 복사하고 이후 원본과 독립적으로 변합니다.

실험과 결과

7장은 실제 Fabric Data Warehouse 운영 토폴로지에서 잽니다.

• 적재 확장(그림 7): TPC-H lineitem 테이블을 1GB 에서 10TB 까지 적재했습니다. 데이터는 10GB 에서 10TB 로 1000배 늘었지만 적재 시간은 약 3배만 늘었고, 막대 위 숫자는 쓰인 자원의 상대 배수입니다.
• 고정 자원과 탄력 자원(그림 8): 1TB 와 10TB 적재에서 이전 Synapse 세대처럼 고정 용량을 쓰는 경우와 탄력 자원을 쓰는 경우를 비교해, 자원 곱하기 시간 과금 아래 비슷한 비용으로 더 나은 성능을 보였다고 설명합니다.
• 질의 성능(그림 9): 1TB TPC-H 22개 질의를 같은 테이블에 동시 적재가 있을 때와 없을 때 비교했습니다(콜드 1회 뒤 웜 3회 평균).
• 자동 최적화(그림 10~12): LST-Bench 의 장기 실행 시나리오(TPC-DS 1TB)에서 데이터 유지 단계가 만든 저장 상태 악화를 압축이 몇 분 안에 찾아 고쳤습니다. 각 유지 단계는 INSERT 2개와 DELETE 6개로 매니페스트 8개를 만들고, 매니페스트 10개가 쌓이면 체크포인트가 만들어집니다.
• 읽기 쓰기 동시성(그림 13): 동시 유지 작업이 있으면 질의가 눈에 띄게 느려지며, 원인으로 커밋, 통계 갱신, 캐시 미스, 압축 복사를 꼽습니다.

지금 Azure 에서는

이 논문이 설명하는 엔진은 Microsoft Fabric 의 Data Warehouse 입니다. Fabric Warehouse 가 다중 테이블 트랜잭션과 스냅샷 격리를 지원하고, 테이블 데이터를 OneLake 에 Delta Lake 형식으로 노출해 다른 Fabric 엔진이 복사 없이 읽게 하며, 시점 조회(time travel)와 제로 복사 클론을 제공하는 것이 모두 이 논문의 설계에서 나옵니다.

함께 읽기

• Microsoft Fabric, OneLake, Data Factory, Event Hubs, Databricks: 이 사이트의 기능 문서
• POLARIS: 셀과 작업 DAG 를 정의한 원 논문
• Socrates: SQL Server 를 계산과 저장으로 나눈 OLTP 쪽 사례
• arXiv 공개본