Data Warehouse
데이터 웨어하우스
분석을 위해 정제된 데이터 저장소. Snowflake, BigQuery, Redshift.
데이터 웨어하우스
분석을 위해 정제된 데이터 저장소. Snowflake, BigQuery, Redshift.
데이터 웨어하우스(Data Warehouse)는 여러 소스에서 수집한 데이터를 분석 목적에 맞게 통합하고 정제하여 저장하는 중앙 집중식 저장소입니다. OLTP(Online Transaction Processing) 시스템과 달리 OLAP(Online Analytical Processing)에 최적화되어 복잡한 분석 쿼리를 빠르게 실행할 수 있습니다.
데이터 웨어하우스의 핵심 설계 패턴은 스타 스키마(Star Schema)입니다. 중앙에 사실 테이블(Fact Table)이 있고, 주변에 차원 테이블(Dimension Table)이 별 모양으로 연결됩니다. 사실 테이블에는 측정값(매출액, 수량 등)이, 차원 테이블에는 분석 관점(날짜, 제품, 지역 등)이 저장됩니다.
클라우드 기반 데이터 웨어하우스인 Snowflake, BigQuery, Redshift는 컴퓨팅과 스토리지를 분리하여 탄력적인 확장이 가능합니다. 필요할 때만 컴퓨팅 리소스를 늘렸다가 분석이 끝나면 줄일 수 있어 비용 효율적입니다. 특히 Snowflake의 가상 웨어하우스 개념은 여러 팀이 독립적으로 쿼리를 실행하면서도 동일한 데이터에 접근할 수 있게 합니다.
최근에는 데이터 레이크하우스(Data Lakehouse) 아키텍처가 등장하여 데이터 레이크의 저비용 저장과 데이터 웨어하우스의 성능을 결합합니다. Delta Lake, Apache Iceberg 같은 테이블 포맷이 이를 가능하게 합니다.
-- Star Schema 설계 예제: 판매 분석 데이터 웨어하우스
-- 1. 차원 테이블: 날짜 차원
CREATE TABLE dim_date (
date_key INT PRIMARY KEY,
full_date DATE NOT NULL,
year INT,
quarter INT,
month INT,
month_name VARCHAR(20),
week INT,
day_of_week INT,
day_name VARCHAR(20),
is_weekend BOOLEAN,
is_holiday BOOLEAN
);
-- 2. 차원 테이블: 제품 차원
CREATE TABLE dim_product (
product_key INT PRIMARY KEY,
product_id VARCHAR(50),
product_name VARCHAR(200),
category VARCHAR(100),
subcategory VARCHAR(100),
brand VARCHAR(100),
unit_price DECIMAL(10, 2)
);
-- 3. 차원 테이블: 고객 차원
CREATE TABLE dim_customer (
customer_key INT PRIMARY KEY,
customer_id VARCHAR(50),
customer_name VARCHAR(200),
segment VARCHAR(50), -- Enterprise, SMB, Consumer
region VARCHAR(100),
country VARCHAR(100),
city VARCHAR(100)
);
-- 4. 사실 테이블: 판매 사실 (중앙)
CREATE TABLE fact_sales (
sale_key BIGINT PRIMARY KEY,
date_key INT REFERENCES dim_date(date_key),
product_key INT REFERENCES dim_product(product_key),
customer_key INT REFERENCES dim_customer(customer_key),
-- 측정값 (Measures)
quantity INT,
unit_price DECIMAL(10, 2),
discount_amount DECIMAL(10, 2),
total_amount DECIMAL(12, 2),
profit DECIMAL(10, 2)
);
-- 분석 쿼리 예제: 월별 카테고리별 매출
SELECT
d.year,
d.month_name,
p.category,
SUM(f.total_amount) AS total_sales,
SUM(f.profit) AS total_profit,
COUNT(DISTINCT f.customer_key) AS unique_customers
FROM fact_sales f
JOIN dim_date d ON f.date_key = d.date_key
JOIN dim_product p ON f.product_key = p.product_key
WHERE d.year = 2024
GROUP BY d.year, d.month, d.month_name, p.category
ORDER BY d.month, total_sales DESC;
데이터엔지니어: "현재 OLTP DB에서 직접 리포트 쿼리를 실행하고 있는데, 운영 DB에 부하를 주고 있어요. 데이터 웨어하우스 구축을 제안합니다."
분석가: "그럼 실시간 데이터는 못 보는 건가요?"
시니어: "배치로 1시간마다 동기화하면 대부분의 분석에는 충분해요. 정말 실시간이 필요한 대시보드는 별도로 스트리밍 파이프라인을 구축하는 게 좋습니다."
면접관: "스타 스키마와 스노우플레이크 스키마의 차이점을 설명해주세요."
지원자: "스타 스키마는 차원 테이블이 비정규화되어 조인이 단순합니다. 스노우플레이크 스키마는 차원을 정규화해서 저장 공간은 절약되지만 조인이 복잡해져요. 현대 클라우드 DW는 컴퓨팅 파워가 충분해서 스타 스키마를 선호합니다. 쿼리 성능과 이해 용이성이 더 중요하거든요."
리뷰어: "이 사실 테이블에 surrogate key 대신 natural key를 사용했네요. 왜 그렇게 했나요?"
작성자: "아, surrogate key로 변경하겠습니다. SCD(Slowly Changing Dimension) 처리할 때 문제가 생길 수 있겠네요."
원인: 분석가가 실수로 전체 테이블 스캔 쿼리를 무한 루프로 실행, 비용 제한 미설정
영향: 주말 동안 5TB 테이블 1000회 스캔, 예상치 못한 $30,000 청구
해결: 쿼리 강제 중단, Google 서포트에 비용 검토 요청
교훈: 쿼리 바이트 제한 설정, 슬롯 예약제 사용, 비용 알림 구성
원인: 소스 시스템 스키마 변경을 ETL 파이프라인이 감지하지 못함
영향: 2주간 매출 리포트 수치 오류, 경영진 잘못된 의사결정
해결: 소스 데이터와 DW 데이터 일관성 검증 후 재적재
교훈: 데이터 품질 검증 자동화, 스키마 변경 감지 알림, 데이터 리콘실리에이션 프로세스 구축
Q1. 스타 스키마(Star Schema)에서 사실 테이블(Fact Table)에 저장되는 것은?
Q2. 클라우드 데이터 웨어하우스(Snowflake, BigQuery)의 핵심 장점은?
Q3. SCD Type 2(Slowly Changing Dimension Type 2)의 특징은?
이 페이지에 오류가 있거나 추가하고 싶은 내용이 있다면 알려주세요!