Amazon Redshift 중첩 물리 뷰로 쿼리 성능 최적화와 자동 새로 고침 구축 전략

Amazon Redshift 중첩 물리 뷰를 활용한 쿼리 성능 최적화와 자동 새로 고침 전략

데이터 웨어하우스를 운영하면서 반복되는 고비용 쿼리 처리로 인해 리소스 낭비와 응답 속도 저하 문제를 겪는 경우가 많습니다. Amazon Redshift는 이러한 문제를 해결하기 위해 물리 뷰(Materialized View)를 지원하며, 최근에는 중첩 물리 뷰(Nested Materialized View)와 CASCADE 새로 고침 옵션까지 제공하여 복잡한 쿼리 구조와 효율적인 자동화 운영을 가능하게 만들었습니다. 본 포스팅에서는 이러한 기능을 어떻게 활용할 수 있는지, 배포 가이드를 중심으로 다루고 주요 구성 아키텍처와 함께 실사용 예제를 통해 비교와 최적화 방안을 살펴봅니다.

중첩 물리 뷰란?

중첩 물리 뷰는 하나의 물리 뷰가 다른 물리 뷰를 기반으로 정의되는 계층적 구조를 말합니다. 이 기능을 활용하면 데이터 변환 파이프라인을 계층적으로 구성할 수 있고, 쿼리 성능은 물론 모델링 유지보수 효율성까지 함께 향상시킬 수 있습니다.

대표적인 사용 예시는 다음과 같습니다.

1. 모듈형 데이터 파이프라인 구성
2. 점진적 데이터 집계
3. 다단계 데이터 검증
4. 히스토리 스냅샷 관리
5. BI 리포팅 성능 최적화

중첩 물리 뷰의 주요 장점

• 쿼리 성능 향상: 각 계층에서 미리 계산된 데이터를 저장하여, 쿼리 시 복잡한 연산을 생략하고 결과만 빠르게 반환
• 연산 오버헤드 절감: 정기적인 물리 뷰 새로 고침 과정에서 연산을 처리하면, 실시간 쿼리 수행 시 시스템 리소스를 적극 절감 가능
• 데이터 모델링 유연성 확보: 계층별로 명확한 비즈니스 개념을 정의해 확장성과 재사용성 확보
• 증분 새로 고침: DML 작업에 따라 변경된 데이터만 새로 고침함으로써 데이터 일관성과 성능을 동시에 유지
• 자동화된 ELT 처리: ELT 기반 업무 구조에서도 수작업 없이 점진적 리프레시가 연계되어 자동화 수준을 끌어올림

아키텍처 구성

중첩 물리 뷰 구조는 다음과 같습니다.

1. Base Table(s): 로우데이터를 보관하는 기본 테이블입니다.
2. Base Materialized View(s): 기본 테이블 위에 정의된 1차 물리 뷰로, 공통 집계 또는 조인 구문을 포함합니다.
3. Nested Materialized View(s): 기본 뷰를 기반으로 추가 필터 또는 조합을 적용한 중첩 뷰입니다.
4. BI Tool / Dashboard: 사용자는 최상위 중첩 물리 뷰를 기반으로 효율적으로 리포트를 생성합니다.

활용 예제

아래는 STORE, STORE_SALES, CUSTOMER, CUSTOMER_ADDRESS 테이블로 구성한 대표 BI 쿼리를 통한 활용 사례입니다.

SELECT 쿼리를 아래와 같은 계층적 물리 뷰로 분리 구성해 성능을 최적화할 수 있습니다.

1. 기본 뷰: STORE_SALES + CUSTOMER 조인

CREATE MATERIALIZED VIEW StoreSalesCust as
SELECT cust.c_customer_id,
cust.c_first_name,
cust.c_last_name,
sales.ss_item_sk,
sales.ss_store_sk,
sales.ss_quantity,
cust.c_current_addr_sk
FROM store_sales sales
INNER JOIN customer cust
ON sales.ss_customer_sk = cust.c_customer_sk;

2. 중간 뷰: + STORE 조인 추가

CREATE MATERIALIZED VIEW StoreSalesCustStore as
SELECT storesalescust.c_customer_id,
storesalescust.c_first_name,
storesalescust.c_last_name,
storesalescust.ss_item_sk,
storesalescust.ss_quantity,
storesalescust.c_current_addr_sk,
store.s_store_name
FROM StoreSalesCust storesalescust
INNER JOIN store store
ON storesalescust.ss_store_sk = store.s_store_sk;

3. 최종 뷰: + CUSTOMER_ADDRESS 조인 추가

CREATE MATERIALIZED VIEW StoreSalesCustAddress as
SELECT storesalescuststore.c_customer_id,
storesalescuststore.c_first_name,
storesalescuststore.c_last_name,
storesalescuststore.ss_item_sk,
storesalescuststore.ss_quantity,
addr.ca_state
FROM StoreSalesCustStore storesalescuststore
INNER JOIN customer_address addr
ON storesalescuststore.c_current_addr_sk = addr.ca_address_sk;

자동 새로 고침(CASCADING REFRESH) 가이드

기존에는 중첩된 물리 뷰를 갱신하기 위해 순서대로 수동으로 새로 고침해야 했습니다. 하지만 이제는 아래와 같이 단 한 줄 명령어로 계층 전체를 자동 갱신할 수 있습니다.

REFRESH MATERIALIZED VIEW StoreSalesCustAddress CASCADE;

이 명령어는 StoreSalesCust, StoreSalesCustStore도 함께 순차적으로 갱신해줍니다. 반대로 StoreSalesCustStore만 갱신할 경우에는 StoreSalesCust까지 갱신하지만, 최상위 뷰는 유지됩니다. 이를 통해 유연한 데이터를 유지하면서 시스템 자원도 절약할 수 있습니다.

SVL_MV_REFRESH_STATUS 시스템 뷰를 활용하면 각 물리 뷰의 갱신 순서를 정확히 확인할 수 있습니다.

운영 자동화를 위한 배포 전략

• 쿼리 최적화: 물리 뷰 생성 시 SELECT 문 자체를 성능 위주로 최적화 필수
• AUTOMATIC REFRESH 제한 사항: 뷰가 중첩형이면 자동 새로 고침을 사용할 수 없으므로, EventBridge + Step Functions 조합 등으로 배포 가이드 수립
• 분산 키/정렬 키 지정: 쿼리 패턴에 따라 물리 뷰에 적합한 SORT KEY, DIST KEY는 필수 설정 요소
• 증분 새로 고침: 가능한 경우 증분 갱신 설정으로 전체 리빌드 부담 해소
• 자동 물리 뷰(Auto-MV) 기능도 병행 검토: Redshift가 워크로드를 모니터링하여 자동으로 뷰를 생성

마무리 정리

Amazon Redshift의 중첩 물리 뷰와 CASCADE 새로 고침 기능을 통해 반복적인 분석 쿼리의 성능을 극대화하고 ETL 또는 BI 워크로드에서 불필요한 연산을 줄일 수 있습니다. 특히 다단계 뷰를 계층적으로 적용하는 전략은 데이터 처리 자동화의 관점에서도 매우 유용합니다. 실무에서 이를 어떻게 효율적으로 활용할 수 있을지에 대해 설계부터 배포, 자동화까지 꼼꼼하게 준비하는 것이 중요합니다.

https://aws.amazon.com/blogs/big-data/harnessing-the-power-of-nested-materialized-views-and-exploring-cascading-refresh/