SQL 하나로 만드는 스트리밍 파이프라인 (Dynamic Tables, SIGMOD 2025)

출처

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

한눈에

• 스트리밍 파이프라인은 여전히 만들기 어렵습니다. 쿼리를 직접 증분형으로 바꿔야 하고, 엔진마다 의미가 다르며, 권한 관리나 재해 복구 같은 기업용 기능이 빠져 있습니다.
• 많은 실제 업무는 100밀리초가 아니라 몇 초에서 수십 분 지연이면 충분합니다. 이 구간을 SQL 사용자에게 열어 주는 것이 목표입니다.
• Dynamic Table(DT)은 정의 쿼리와 목표 지연만 받습니다. 결과는 언제나 "과거 어느 데이터 시점에서 정의 쿼리를 실행한 결과" 와 같다는 지연 뷰 의미론(DVS)을 보장합니다.
• 정식 출시 9개월 만에 수천 고객, 활성 테이블 100만 개를 넘겼고, 활성 DT 의 약 70% 가 증분 갱신을 씁니다.

왜 나왔나

스트림 처리기는 강력하지만 배우고 운영하는 부담이 커서, 전담 팀이 있는 고가치 업무에만 쓰여 왔습니다. 반대로 데이터베이스의 머티리얼라이즈드 뷰는 쓰기 쉽지만 중첩이나 넓은 쿼리 범위, 자원 통제 같은 파이프라인 기능이 부족했습니다. 증분 뷰 유지(IVM)는 둘을 잇는 다리이지만, 갱신이 늦게 반영되는 뷰를 읽을 때 트랜잭션 격리가 어떻게 되는지는 명확히 정의되어 있지 않았습니다. 저자들은 2023년 Change Queries 논문에서 예고한 일반 IVM 기능을 제품으로 완성하면서, 그 의미를 이론으로 정리합니다.

핵심 아이디어

무엇을 계산하나: 지연 뷰 의미론 (3.1절)

DT 의 내용은 정의 쿼리를 어느 과거 시점, 즉 데이터 시점에 실행한 결과와 같습니다. DT 가 다른 DT 를 읽을 때는 "지금 저장된 내용" 이 아니라 같은 데이터 시점의 상위 DT 버전을 읽습니다. 그래서 여러 DT 를 이어 붙인 파이프라인 전체가 하나의 과거 시점에서 계산한 것처럼 일관됩니다. 새 DT 를 만들 때는 목표 지연 안에 있는 상위 데이터 시점을 골라 시작하므로, 만든 시각보다 이른 데이터 시점을 가질 수도 있습니다.

언제 계산하나: 목표 지연 (3.2절)

목표 지연은 현재 시각과 데이터 시점 사이 간격의 상한입니다. 최소 1분의 시간 값이나, 하위 DT 가운데 가장 짧은 목표 지연을 따르는 DOWNSTREAM 을 줄 수 있습니다.

CREATE DYNAMIC TABLE delayed_trains
  TARGET_LAG = '1 minute'
  WAREHOUSE  = trains_wh
AS SELECT train_id,
          date_trunc(hour, s.expected_arrival_time) AS hour,
          count_if(arrival_time - s.expected_arrival_time > '10 minutes') AS num_delays
   FROM train_arrivals a
   JOIN schedule s ON a.schedule_id = s.id
   GROUP BY ALL;

논문 목록 1의 두 번째 DT 입니다. 열차 이벤트를 정리하는 상위 DT train_arrivals 는 TARGET_LAG = DOWNSTREAM 으로 두어, 이 DT 가 필요로 하는 만큼만 갱신되게 합니다.

어떻게 계산하나 (3.3절)

갱신은 사용자가 지정한 가상 웨어하우스에서 실행됩니다. 갱신 방식은 FULL 과 INCREMENTAL 이 있고, 증분은 투영, 필터, UNION ALL, 내부와 외부 조인, LATERAL FLATTEN, DISTINCT 와 그룹 집계, 파티션 윈도 함수를 지원합니다. 갱신마다 할 일이 없으면 NO_DATA, 아니면 FULL, INCREMENTAL, REINITIALIZE 가운데 하나를 고릅니다. 같은 DT 의 갱신은 겹쳐 돌지 않으며, 늦어지면 다음 갱신이 건너뛴 구간을 함께 처리합니다. 사용자 오류가 반복되면 DT 를 일시 정지합니다.

트랜잭션 격리 (4절)

DT 갱신을 평범한 트랜잭션으로 보면, 의존성 그래프가 읽기 왜곡(read skew)을 놓치는 경우가 생깁니다(그림 1). 논문은 순수 계산을 나타내는 "유도(derivation)" 연산을 이력에 더해, 같은 예에서 G2 순환이 드러나도록 Adya 의 격리 이론을 확장합니다(그림 2). 결론적으로 DT 하나만 읽는 트랜잭션은 스냅숏 격리(PL-SI)를, 데이터 시점이 다를 수 있는 여러 DT 를 함께 읽으면 read committed(PL-2)를 얻습니다.

구현 (5절)

• 스케줄링 (그림 4): 지연은 초당 1초씩 오르다가 갱신이 커밋되면 떨어지는 톱니 모양입니다. 데이터 시점 간격, 대기, 갱신 시간의 합이 목표 지연보다 작아야 하며, 데이터 시점을 48초에 2의 거듭제곱을 곱한 정해진 주기에 맞춰 상하위 DT 가 같은 시점에서 만나게 합니다.
• 버전 관리: 하이브리드 논리 시계와 갱신별 경계(frontier)로 어느 상위 버전을 읽을지 정합니다.
• 쿼리 미분 (5.5절): Change Queries 의 미분 프레임워크를 확장했습니다. 외부 조인은 예전의 안티 조인 방식 대신 직접 미분 규칙을 쓰고, 윈도 함수는 바뀐 파티션 전체를 다시 계산합니다. 삽입만 있는 경우를 특수화하는 최적화도 더했습니다.

실험과 결과

통제된 벤치마크 대신 운영 지표와 운영 경험을 보고합니다(6절).

• 정확성 (6.1절): 단위 테스트부터 운영 검증까지 여섯 단계 시험을 두고, DT 내용이 데이터 시점의 정의 쿼리 결과와 같은지를 수십만 개 DT 에서 속성 기반으로 확인합니다.
• 채택 (6.3절): 2024년 4월 정식 출시 뒤 2025년 4월 1일 기준 활성 테이블 100만 개 이상, 수천 고객입니다. 활성 DT 의 약 70% 가 증분 갱신을 씁니다.
• 갱신 내용: 갱신의 90% 이상이 새 데이터가 없는 갱신입니다. 사용자가 데이터 도착 주기보다 짧게 목표 지연을 잡는 경우가 많아서이며, 이런 갱신의 비용은 무시할 만하다고 적습니다. 데이터가 있는 증분 갱신의 67% 는 행의 1% 미만을 바꾸고, 21% 는 10% 넘게 바꿉니다.
• 목표 지연 분포 (그림 5): 25% 넘는 DT 가 16시간 이상, 20% 가까이가 5분 미만입니다. 실시간과 일 배치 사이 전 구간에 고르게 퍼져 있다는 점이 논문의 주장과 맞닿습니다.
• 연산자 (그림 6): 증분 DT 정의에는 조인, 집계, 윈도 함수가 모두 흔했습니다. 활성 DT 의 20% 넘게가 다른 DT 의 클론이었고 20% 는 공유 데이터베이스에 있었습니다.

지금 Snowflake 에서는

• Dynamic Tables 는 논문 그대로의 이름과 문법(CREATE DYNAMIC TABLE, TARGET_LAG, WAREHOUSE, REFRESH_MODE)으로 제공되는 정식 기능입니다.
• Iceberg 형식의 DT 도 논문 시점에 이미 정식 출시되어, 출시 한 달이 안 되어 수천 개가 활성 상태였다고 논문이 적습니다.
• 증분 갱신이 이해하는 변경분은 Change Queries 논문의 CHANGES 와 같은 기반이고, 변경 대상 파티션을 찾는 일은 마이크로 파티션 메타데이터에 기댑니다.
• 논문이 향후 과제로 적은 크론식 일정 통합, 자동 쿼리 분할, 비용 기반 미분 등이 제품에 들어갔는지는 공식 논문으로 확인하지 못해 연결하지 않습니다.

함께 읽기

• Dynamic Tables: 이 사이트의 기능 문서
• 테이블의 변경분을 쿼리하기 (SIGMOD 2023)
• 프루닝 (SIGMOD 2025): 같은 학회에 실린 Snowflake 산업 논문
• Snowflake 공식 문서: Dynamic tables