도입목적
- 한정적인 자원에서 대량의 데이터를 저장하고 효율적으로 읽을 수 있는 DW기법의 필요성
- 예를들어 Fact Table에 모든 데이터가 한글로 저장이 되고 있다면 각 글자 별로 2byte가 필요하게 됨. 따라서 INT와 같은 작은 숫자값을 이용하여 용량 사용의 효율성을 상승시킬 수 있다. (각 INT로 변환된 값들은 Dimension table에서 관리)
- 데이터의 용량이 작아지며 대량의 데이터를 읽어들일 때 성능의 상승효과도 노릴 수 있다.
- Snowflake 구조와 다르게 적은 join으로 데이터를 분석할 수 있으므로 조회성능이 빠르다.
구조
구성 요소
- Fact Table
- 실제 측정된 값들을 저장한 테이블 (주문이력, 주식 가격, 환율, 온도, ...)
- 기본적으로 value들은 코드값으로 저장되거나 숫자인 수치값으로 저장된다.
- 기본적으로 다양한 dimension 테이블들과의 Join을 통해 사용되므로 각 dimension key가 중요시되고 PK는 생성하지 않는 경우가 많다.
- dimension key는 위의 구조예시에서 Product ID, Time ID, Promotion ID, Customer ID가 해당된다.
- Dimension Table
- fact table에서 참고되는 마스터 데이터 테이블
- 비즈니스 프로세스에서 발생하는 이벤트에 대한 배경 설명을 담고 있다.
- 예를 들어 "판매이력" 이라는 팩트에 대해서 판매한 제품에 대한 정보를 담은 테이블, 구매한 사람에 대한 정보를 담은 테이블 등이 있다.
참고
- https://www.databricks.com/kr/glossary/star-schema
- starschema 필요성 : https://burning-dba.tistory.com/154
- fact table : https://learn.microsoft.com/ko-kr/fabric/data-warehouse/dimensional-modeling-fact-tables
- dimension table : https://learn.microsoft.com/en-us/fabric/data-warehouse/dimensional-modeling-dimension-tables
'데이터 > Architecture' 카테고리의 다른 글
CDC Architecture (0) | 2024.08.10 |
---|---|
Lambda Architecture 란 (0) | 2024.07.29 |
댓글