데이터 웨어하우스란?

운영 시스템은 트랜잭션을 신속히 처리하는데 최적화되어있습니다. 데이터 웨어하우스는 신규 고객을 집계하고 월별 GMV를 비교하는 등의 요구사항을 처리할 수 있어야 합니다. 그러기 위해서는 운영 시스템과는 다른 구조가 필요하며 이를 다차원 모델링으로 해결합니다.

데이터 웨어하우스를 활용하는 사람들은 현업에 있는 다양한 직업을 가진 사람들입니다. 그래서 구축을 할 때는 기술보다 비즈니스 이슈를 중심으로 생각해야 합니다. 데이터 웨어하우스 구축을 위한 요구사항은 다음과 같습니다.

• 정보에 쉽게 접근 가능하도록 만들어야 한다.
• 의사결정을 위해 신뢰할 수 있는 토대가 되어야 하며 일관된 정보를 제공해야 한다. (데이터 신뢰성)
• 시스템 변화에 유연해야 한다.
• 정보를 적시에 제공해야 한다. (데이터 최신성)
• 현업에서 사용자가 받아들일 수 있어야 한다.

운영 데이터베이스는 쉽고 빠른 갱신/삽입을 위해 제 3정규화를 적용합니다. 그러나 분석을 위해 제 3정규화가 된 데이터베이스에 쿼리를 하려면 많이 복잡하고 어려운 쿼리를 작성해야 하고 높은 성능이 필요하게 됩니다. 데이터 웨어하우스에서는 스타 스키마를 통해 다차원 모델을 구현합니다. 다차원 모델은 팩트 테이블과 디멘션 테이블로 구분됩니다.

팩트 테이블(fact table)

팩트 테이블(fact table)은 비즈니스 프로세스 이벤트에서 발생하는 측정값을 저장합니다. 실세계에서 발생한 하나의 측정 이벤트가 팩트 테이블 내 하나의 로우라는 것이 다차원 모델링의 기본 바탕이 됩니다. 예를 들면 쇼핑몰에서 하나의 상품이 판매되면 하나의 로우가 되는 팩트 테이블은 다음과 같은 컬럼이 있을 수 있습니다.

- 상품 키(FK)
- 상점 키(FK)
- 프로모션 키(FK)
- 고객 키(FK)
- 점원 키(FK)
- 일자 키(FK)
- 트랜잭션 번호
- 판매 금액
- 판매 수량

 

 

모든 팩트 테이블은 외래키(foreign key)를 가지며, 추후에 이야기할 디멘션 테이블과 키가 모두 연결이 되어있어야 참조 무결성(referential integrity)을 충족할 수 있습니다. 팩트 테이블은 외래 키들의 부분집합인 복합 키(composite key)를 통해 기본 키를 가질 수 있으며 복합 키를 갖는 모든 테이블은 팩트 테이블이 됩니다.

팩트 테이블의 각 로우는 그레인(grain)이라는 상세 수준으로 데이터가 저장됩니다. 하나의 팩트 테이블에서는 모두 같은 그레인이어야 합니다. 팩트 테이블에서 그레인은 트랜잭션(transaction), 주기적 스냅샷(periodic snapshot), 점진적 스냅샷(accumulating snapshot) 중 하나입니다.

디멘션 테이블(dimension table)

디멘션 테이블은 팩트 테이블을 구체적으로 알 수 있게 해주며, 이벤트와 관련된 "누가, 언제, 어디서, 무엇을, 어떻게, 왜"를 설명해줍니다. 디멘션 테이블은 하나의 기본키를 가지고 있으며, 팩트 테이블에서 디멘션 기본키를 통해 조인하면 상세 정보를 알 수 있게 됩니다.

- 상품 키(PK)
- 상품 아이디
- 상품 설명
- 브랜드명
- 분류명
- 무게
- ...

 

 

팩트라면 측정값이고 디멘션이라면 비연속적인 값을 가지는 설명인데, 특정 데이터가 결정하기 어렵다면 설계자가 판단하고 둘 중에 하나로 선택하거나 둘 다를 선택할 수 있습니다. 그러나 연속적인 숫자가 나타난다면 보통은 팩트고 이산적으로 끊어지는 숫자라면 대부분 디멘션 속성입니다.

분석력은 디멘션 속성의 깊이와 품질에 정비례합니다. 그래서 컬럼명은 쉬우면서도 명확해야 하고, 데이터 품질을 높이거나 속성 허용 범위를 관리하는 등의 작업에 시간을 쓸 수록 좋습니다.

디멘션 테이블을 모델링 할 때 제품은 브랜드로, 브랜드는 카테고리로 계층관계를 나타내는 경우가 많습니다. 그러나 중복 데이터를 저장하더라도 정규화를 하지 않는 것이 좋습니다. 이런 상황에 정규화를 하는 것을 스노우플레이킹(snowflaking)이라고 부르는데, 단순성 및 접근 용이성이 낮아지게 됩니다.

 

스타 스키마(star schema)

스타 스키마는 위에서 이야기한 팩트 테이블과 디멘션 테이블로 구성되어 있습니다. 사용자는 팩트 테이블을 기준으로 원하는 데이터를 쿼리합니다. 상세히 알고 싶은 정보가 있다면 디멘션 테이블과 조인하여 디멘션 테이블에 있는 상세 정보를 같이 가져올 수 있습니다. 스타 스키마는 다음과 같은 장점이 있습니다.

1. 중첩되는 조인 등 복잡한 쿼리를 하지 않기 때문에 괜찮은 성능을 보입니다.
2. 복잡한 쿼리를 하지 않기 때문에 사용성이 좋습니다.
3. 데이터 웨어하우스는 사용자의 비즈니스 요구사항에 따라서 지속적인 변화가 필요합니다. 변경에 대한 대응이 쉽습니다.

 

DW/BI 아키텍처 4가지 구성요소

DW/BI 아키텍처는 원천 시스템, ETL 시스템, 프레젠테이션 영역, BI 애플리케이션 네 가지로 구분됩니다. 원천 시스템에서 ETL 시스템을 통해 데이터를 가공하며 디멘션을 표준화하고 무결성 및 일관성을 보장되도록 합니다. 프레젠테이션 영역에서는 비즈니스 프로세스별로 구조화 되어있는 스타 스키마를 통해 쿼리합니다. BI 애플리케이션에서는 임의로 쿼리하고 리포트를 생성합니다.