참조 아키텍처: 데이터 웨어하우스 / 분석

분석 쿼리(보고, 집계, 광범위한 스캔)는 OLTP 트랜잭션과 근본적으로 다르다: 수는 적지만 매우 넓고 오래 실행되는 쿼리다. 이 트리는 분석을 OLTP에서 분리하는 결정에서 출발해 적재 방식(ETL vs ELT), 컬럼형/columnstore 저장소, 스타 스키마 모델링, 파티셔닝 + 압축, materialized view를 이용한 사전 계산 같은 구성 요소를 단계별로 다루며, 동시성과 처리량 간의 트레이드오프를 함께 따진다.

분석 워크로드가 OLTP와 같은 데이터베이스에서 실행되는가?

가장 흔한 실수는 운영 중인 트랜잭션 DB에서 무거운 보고서를 실행해 OLTP 지연을 악화시키는 것이다. 첫 결정은 분리다: 분석이 아직 OLTP 인스턴스에서 실행되는가, 별도 분석 환경을 구축 중인가, 아니면 데이터를 그곳으로 옮기는 방법을 결정하는 중인가?

• 보고서가 아직 운영 OLTP에서 실행되어 OLTP를 느리게 함
• 별도 웨어하우스가 있음, 데이터를 어떻게 적재해야 하는가?
• 웨어하우스가 있지만 쿼리가 여전히 느림, 어떻게 모델링해야 하는가?

변환은 어디서 할 것인가: 적재 전인가, 적재 후인가?

원본에서 웨어하우스로 데이터를 옮길 때, 적재 전에 별도 처리 계층에서 정제/변환할 것인가(ETL), 아니면 원시 데이터를 먼저 웨어하우스에 적재하고 강력한 웨어하우스 엔진 내부에서 SQL로 변환할 것인가(ELT)? 결정은 웨어하우스의 처리 능력과 스키마 유연성 요구에 달려 있다.

• 변환이 복잡하거나 외부에서 수행됨, 적재 전에 처리
• 웨어하우스가 강력함, 원시 데이터를 적재하고 내부에서 SQL로 변환

쿼리 병목은 저장 구조에 있는가, 데이터 모델에 있는가?

분석이 느리다면 두 가지 주요 수단이 있다. 광범위한 스캔은 행 기반 저장소에서 행 전체를 읽는다. 컬럼형 저장소는 필요한 컬럼만 읽고 압축률도 높다. 모델 측면에서는 과도한 정규화로 조인이 많아지면 쿼리가 느려진다. 스타 스키마(fact + dimension)는 분석을 단순화한다.

• 광범위한 집계 스캔이 느림, 읽는 컬럼은 적음
• 조인이 너무 많음, 복잡한 정규화 스키마
• 같은 무거운 보고서가 같은 결과를 반복해서 생성함

권장: 분석을 OLTP에서 분리

트랜잭션 워크로드와 분석 워크로드는 같은 엔진에서 서로를 압박한다: 긴 보고서가 락/IO를 붙잡아 짧은 트랜잭션을 지연시킨다. 분석을 별도 대상(읽기 복제본 또는 별도 분석 웨어하우스)으로 옮기면 양쪽 모두 부담이 줄어든다.

권장: ETL(적재 전 변환)

ETL에서는 원본에서 데이터를 추출(Extract)하고, 별도 처리 계층에서 정제 및 변환(Transform)한 뒤에야 웨어하우스에 적재(Load)한다. 정제되고 모델에 맞는 데이터만 웨어하우스에 들어간다.

권장: ELT(웨어하우스 내부 변환)

ELT에서는 원시 데이터를 먼저 웨어하우스에 적재하고 웨어하우스 자체의 강력한 SQL 엔진 내부에서 변환한다. 최신 컬럼형 웨어하우스는 처리 능력이 높으므로 변환을 데이터로 가져가는 대신 데이터를 한 번 옮기고 내부에서 처리한다.

권장: 컬럼형 / columnstore 저장소 + 압축

분석 쿼리는 대개 모든 행에서 소수의 컬럼을 스캔한다. 컬럼형 저장소는 데이터를 컬럼 단위로 보관하므로 필요한 컬럼만 읽고, 유사한 값이 인접해 압축률이 매우 높으며, IO가 크게 줄어든다.

권장: 스타 스키마(fact + dimension)

분석 모델에서는 측정값을 담은 fact 테이블이 중심에 있고 설명용 dimension 테이블이 둘러싼다. 과도하게 정규화된 스키마에 비해 조인 수가 줄고, 쿼리가 단순해지며, 엔진이 더 나은 실행 계획을 만든다.

권장: materialized view로 사전 계산

같은 무거운 집계(일일 매출, 월간 요약)가 반복 실행되어 같은 결과를 낸다면 결과를 materialized view에 물리적으로 저장하고 보고서가 사전 계산된 결과를 읽게 한다. 무거운 계산은 한 번만 실행되고 쿼리는 즉시 반환된다.