클라우드 데이터 웨어하우스와 데이터 마트 설계

분석용 데이터는 통합 저장소와 마트의 경계에서 정리된다

데이터 웨어하우스는 여러 소스 시스템에서 정제·통합한 데이터를 주제 영역별로 구조화해 분석과 의사결정에 제공하는 중앙 저장소다. ACID 트랜잭션, 컬럼 기반 저장, MPP 쿼리 엔진, 거버넌스와 보안 체계를 바탕으로 데이터의 신뢰성을 확보한다.

전통적인 DWH는 소스에서 변환한 뒤 적재하는 ETL 방식을 주로 사용했다. 반면 클라우드 DWH에서는 먼저 적재하고 웨어하우스 내부의 탄력적인 컴퓨트 자원으로 변환하는 ELT가 가능하다. 데이터 레이크하우스와 결합하면 비정형·반정형 데이터 처리와 ML 워크로드도 함께 다룰 수 있다.

모델링 방식은 목적에 따라 달라진다. 김벌(Kimball) 차원 모델링은 스타 스키마와 분석용 집계 최적화에 초점을 둔다. 인몬(Inmon)은 기업 데이터 모델을 중심에 두고 EDW에서 데이터 마트를 파생한다. 데이터 볼트(Data Vault)는 변경 이력과 감사 가능성을 강화하면서 마트 파생의 유연성을 제공한다.

컴퓨트 격리와 운영 통제가 아키텍처의 중심이다

스토리지와 컴퓨트를 분리하면 저장 영역은 저비용·고내구성으로 유지하고, 컴퓨트는 워크로드별로 독립 확장할 수 있다. 다중 가상 웨어하우스, 슬롯, 클러스터는 동시성을 격리하는 수단이 된다.

BI 대시보드, 배치 변환, 애드혹 분석, ML 추론은 서로 다른 자원 특성을 가진다. 큐잉, 우선순위, 리소스 그룹을 통해 SLA에 맞는 워크로드 관리가 필요하다.

보안과 품질 역시 별도 기능이 아니라 데이터 플랫폼의 운영 조건이다. RBAC/ABAC, 마스킹, Row/Column-Level Security, 데이터 라인리지, 민감정보 관리가 여기에 포함된다. 데이터 품질 규칙, 스키마 진화, 변경 데이터 캡처(CDC)는 데이터 신뢰성을 유지하는 기반이 된다.

비용은 컴퓨트·스토리지·스캔 사용량과 연결된다. 예약 리소스와 크레딧을 관리하고, 메트릭·로그·쿼리 프로파일을 관측성 체계에 연결해 오케스트레이션을 자동화해야 한다.

Snowflake, Redshift, BigQuery의 선택 기준

세부 사양·요금·한도는 최신 정보를 확인해야 하지만, 세 플랫폼은 다음과 같은 특성 차이를 보인다.

제품	성능	확장성	일관성	안정성	운영 편의
Snowflake	마이크로 파티션·자동 클러스터링·결과 캐시로 혼합 워크로드 강점	가상 웨어하우스 수평/수직 확장, 멀티클러스터	ACID, 타임트래블로 재현성 강화	타임트래블·Fail-safe·영역 복제	제로카피 클론·세분화 권한, 튜닝 부담 낮음
Redshift	컬럼형 MPP, 정렬/배포 키 튜닝 시 높은 성능	RA3·Concurrency Scaling·Elastic Resize	ACID, Spectrum 연계 시 S3 일관성 고려	스냅샷·교차 리전 복제	AWS 네이티브 통합 강점, 키·WLM 튜닝 요구
BigQuery	Dremel 기반 대규모 스캔 최적화, 대형 집계 우수	서버리스·슬롯 예약·오토스케일	ACID, 스트리밍은 수 초 내 최종 일관성	자동 복제·고가용성	서버리스 운영 단순, 쿼터·스캔 비용 관리 필요

소규모 다수 쿼리와 혼합 워크로드에는 Snowflake가 유리하다. AWS 생태계와 데이터 로컬리티가 중심이면 Redshift가 맞고, 초대용량 스캔과 서버리스 운영 단순성이 우선이라면 BigQuery가 적합하다.

수집에서 마트까지 이어지는 파이프라인

입력은 OLTP DB, 로그·이벤트, SaaS API, 파일 배치에서 시작한다. 수집은 Fivetran, Kafka, Batch로 수행하고, 스테이징을 거쳐 dbt, Spark, SQL로 변환한 뒤 DWH에 적재한다. 최종 소비 계층은 주제별 데이터 마트의 스타 스키마와 BI, ML, 리포트다.

배치 단위 트랜잭션 커밋과 중복 방지(Idempotency 키)를 적용해야 한다. CDC의 LSN/SCN 기반 정보와 수신 시간 기반 병합 로직은 지연 도착 데이터를 처리하는 데 쓰인다. 실패 시에는 재시도, Dead Letter Queue, 알림, 부분 롤백 전략을 함께 둔다.

데이터 카탈로그, 라인리지, 민감정보 정책은 자동화 대상으로 두고, 리소스 쿼터·최대 스캔 바이트·웨어하우스 최소/최대 사이즈 같은 코스트 가드레일을 운영 정책에 포함한다.

⤢✕

데이터 마트는 그레인과 변경 이력부터 고정한다

팩트 테이블마다 그레인을 분명히 해야 한다. 주문-라인 아이템처럼 분석 단위가 정해지면 자연키와 대체키(서로게이트 키)를 함께 사용할 수 있다. 공통 차원(Conformed Dimensions)은 도메인을 가로지르는 분석 결과의 일관성을 만든다.

속성 변경 이력은 SCD Type 2로 보존하며 valid_from/to, is_current를 사용한다. 지연 도착 팩트는 보류 큐에 두거나 상관 관계키로 다시 조인해 처리한다.

날짜·영업일 기준 파티셔닝과 자주 필터되는 키 기준 클러스터링은 성능 관리의 기본이다. 요약 테이블, 물질화 뷰, 쿼리 캐시는 비용 제어에 활용할 수 있다. 명명 규칙, 스키마 버저닝, 데이터 품질 테스트의 체크 규칙도 자동화 범위에 넣는다.

워크로드별 데이터 마트 활용

SaaS 제품 분석 플랫폼에서는 멀티 테넌트 메타데이터와 세션·액션 이벤트 팩트를 분리할 수 있다. Snowflake의 멀티 웨어하우스는 테넌트 격리와 비용·성능 SLA 분리에 활용된다.

마케팅 어트리뷰션에서는 광고, 웹·앱, CRM 데이터를 결합하고 사용자·캠페인·채널 차원을 표준화한다. BigQuery의 서버리스 환경과 대규모 조인, 세션화 UDF는 이 워크로드의 확장성에 쓰인다.

재무 마감과 규제 보고에서는 원장, 보조원장, 환율 스냅샷을 SCD2 차원과 팩트로 정규화한다. Redshift RA3 + Spectrum은 S3 히스토리를 저비용으로 보관하고, 정기 마감 처리는 클러스터에서 고성능으로 수행한다.

준실시간 운영 모니터링은 Kafka에서 스트리밍 수집을 거쳐 DWH 마이크로 배치와 Mart 갱신으로 이어질 수 있으며, 갱신 주기는 1~5분이다. 지연 도착과 중복 이벤트에는 Idempotent MERGE 규칙을 적용한다.

성능, 비용, 데이터 신뢰도에서 기대할 변화

기존 온프레 또는 자체 관리 DWH와 비교할 때 쿼리 지연은 4070% 감소하고, 대시보드 리프레시 시간은 3060% 단축될 수 있다. 총소유비용(TCO)은 운영 자동화와 서버리스·탄력 컴퓨트로 2035% 절감할 수 있으며, 동시 사용자 수는 310배 확장되고 배치 창구는 50% 이상 단축될 수 있다.

거버넌스와 보안의 일관성이 높아지고 데이터 신뢰도도 개선된다. 모델 재사용과 테스트 자동화는 변경 민첩성을 높이며, 조직 간 공통 지표 체계는 의사결정의 정합성을 강화한다.

SCD2 차원과 스타 스키마 구현 예시

전제: BigQuery Standard SQL 사용, 프로젝트/데이터셋 미리 생성. Snowflake/Redshift도 MERGE 구문으로 유사 구현 가능.

-- 차원: 고객(SCD2)
CREATE TABLE IF NOT EXISTS mart.dim_customer (
  customer_sk INT64 GENERATED ALWAYS AS IDENTITY,
  customer_id STRING,           -- 자연키
  name STRING,
  segment STRING,
  valid_from TIMESTAMP,
  valid_to   TIMESTAMP,
  is_current BOOL
);

-- 팩트: 매출
CREATE TABLE IF NOT EXISTS mart.fact_sales
PARTITION BY DATE(sale_ts)
CLUSTER BY customer_sk, product_sk AS
SELECT 0 AS customer_sk, 0 AS product_sk, TIMESTAMP '1970-01-01' AS sale_ts, 0 AS qty, 0 AS amount
WHERE FALSE;

-- 스테이징: 증분 고객 스냅샷
-- stg_customer(customer_id, name, segment, _ingested_at)

-- SCD2 MERGE (신규/변경/동일 무변경 처리)
MERGE mart.dim_customer d
USING (
  SELECT customer_id, name, segment, MAX(_ingested_at) AS asof
  FROM stg_customer
  GROUP BY 1,2,3
) s
ON d.customer_id = s.customer_id AND d.is_current = TRUE
WHEN MATCHED AND (d.name != s.name OR d.segment != s.segment) THEN
  -- 기존 레코드 종료
  UPDATE SET d.valid_to = s.asof, d.is_current = FALSE
WHEN NOT MATCHED BY TARGET THEN
  -- 신규 버전 삽입
  INSERT (customer_id, name, segment, valid_from, valid_to, is_current)
  VALUES (s.customer_id, s.name, s.segment, s.asof, TIMESTAMP '9999-12-31', TRUE);

-- 팩트 적재: 차원 매핑 후 삽입
INSERT INTO mart.fact_sales (customer_sk, product_sk, sale_ts, qty, amount)
SELECT d.customer_sk, p.product_sk, o.sale_ts, o.qty, o.amount
FROM stg_orders o
JOIN mart.dim_customer d
  ON d.customer_id = o.customer_id AND d.is_current = TRUE
JOIN mart.dim_product p
  ON p.product_id = o.product_id;

배치 단위 트랜잭션과 재시도 시 중복 방지 키를 적용한다. 파티션 프루닝과 클러스터 키는 스캔 바이트를 최소화하도록 설계하며, 고객키 누락과 음수 금액 같은 품질 규칙은 적재 전에 검증한다.