SQL

스노우플레이크 스키마 — 저장 공간 절약, JOIN 추가

스노우플레이크 스키마는 차원 테이블을 하위 차원으로 정규화한다. category_name과 department_name을 그대로 담은 평평한(flat) dim_product 대신, 이를 dim_category와 dim_department로 나누고 외래 키로 연결한다. 이렇게 하면 차원 내부의 중복은 줄지만 쿼리 시점에 JOIN이 늘어난다. BigQuery, Snowflake, Redshift 같은 대부분의 현대 컬럼형 웨어하우스에서는 저장 공간이 저렴하고 JOIN이 비싼 편이므로 스타 스키마가 선호된다. 특별한 이유(매우 큰 차원에 고도로 중복된 계층 데이터가 있는 경우 등)가 없다면 스노우플레이크로 갈 이유는 크지 않다.

Data Vault — Hub, Link, Satellite

Data Vault는 감사 가능성(auditability)과 유연성을 위해 설계된 모델링 방법론이다. Hub(비즈니스 키), Link(Hub 간의 관계), Satellite(전체 이력을 담은 설명적 속성) 세 가지 핵심 테이블 유형을 사용한다. Hub는 고유 비즈니스 키와 로드 메타데이터(로드 날짜, 레코드 소스)를 저장한다. Link는 두 개 이상의 Hub 사이의 관계를 캡처하는, 사실상 N:M 연관 테이블이다. Satellite는 Hub나 Link에 대한 설명적 속성과 변경 이력을 유효 날짜와 함께 저장한다. 핵심 통찰은 Hub와 Link는 거의 변하지 않고(비즈니스 키와 관계는 안정적), 변동성은 전부 Satellite가 흡수한다는 점이다.

Data Vault는 소스 시스템 변화에 매우 강하지만 그 대가로 복잡도가 늘어난다 — 테이블 5개짜리 단순한 스타 스키마가 Data Vault에서는 15개 이상의 테이블이 될 수 있다. 실무적으로는 웨어하우스의 원본/vault 레이어에 Data Vault를 적용하고, 그 위에 프레젠 테이션 레이어로 스타 스키마를 쌓는 조합이 이상적이다.

One Big Table(OBT)과 정크 디멘션

One Big Table(OBT) 접근법은 모든 차원을 미리 조인해 하나의 넓고 완전히 역정규화된 테이블로 만든다. Looker, Metabase 같은 BI 도구가 단일 소스 테이블에서 가장 잘 동작하고, 컬럼형 저장소는 넓은 테이블도 저렴하게 다룰 수 있어 현대 분석 스택에서 인기가 있다. 트레이드오프는 갱신 복잡도다 — 고객 속성 하나를 바꾸려면 그 고객을 참조하는 모든 행을 갱신해야 한다. OBT는 변환 계층의 제대로 된 모델링을 대체하는 것이 아니라, 서빙 계층 최적화로 이해해야 한다.

정크 디멘션(junk dimension)은 기존 차원 어디에도 속하지 않는 잡다한 저카디널리티 플래그와 지표들을 모은다. is_gift_wrapped, is_expedited, payment_method(3가지 값) 같은 컬럼들로 팩트 테이블을 어지럽히는 대신, 가능한 모든 조합을 담은 하나의 정크 디멘션으로 묶는다 — 바이너리 플래그 4개짜리 정크 디멘션은 최대 16행밖에 안 된다. 이는 팩트 테이블을 좁고 깔끔하게 유지해 수십억 행 규모에서 특히 중요하다.