Data Mart, Semantic Layer, BI
이 세션의 목표
Data Warehouse가 회사 전체의 분석 기반이라면, Data Mart는 특정 팀이나 목적에 맞춘 작은 소비용 데이터셋이다. Semantic Layer와 BI는 그 위에서 사용자가 지표를 같은 의미로 보게 만드는 계층이다.
이번 세션의 핵심은 다음이다.
Mart는 테이블이고, Semantic Layer는 의미의 계약이며, BI는 사람이 보는 화면이다.
Data Mart란
Data Mart는 특정 부서, 제품, 업무 목적을 위해 정리된 데이터 묶음이다.
예를 들어 다음은 모두 Mart가 될 수 있다.
mart_sales_daily: 영업팀의 일자별 매출 분석mart_customer_health: CS팀의 고객 상태 분석mart_vulnerability_package: 보안 데이터팀의 패키지별 취약점 집계mart_sync_lag: 운영팀의 고객사 동기화 지연 모니터링
Mart는 보통 Warehouse나 Gold layer에서 만들어진다.
왜 Mart가 필요한가
분석 사용자가 raw table이나 wide fact를 직접 보면 다음 문제가 생긴다.
- 같은 지표를 사람마다 다르게 계산한다.
- join 경로가 복잡해 실수하기 쉽다.
- dashboard가 너무 느리다.
- 개인정보나 내부 운영 컬럼이 노출된다.
- source schema 변경이 BI 화면까지 바로 깨뜨린다.
Mart는 이런 문제를 줄이기 위해 소비자가 필요한 형태로 데이터를 미리 정리한다.
Data Mart 종류
| 종류 | 설명 | 장점 | 주의점 |
|---|---|---|---|
| Dependent Mart | 중앙 Warehouse에서 파생 | 지표 일관성 높음 | 중앙 모델이 늦으면 mart도 늦음 |
| Independent Mart | 부서가 독립적으로 구축 | 빠르게 만들 수 있음 | 지표 파편화 위험 |
| Virtual Mart | view/semantic model로 제공 | 저장 중복 적음 | 원본 쿼리 부하와 권한 관리 필요 |
실무에서는 dependent mart가 가장 운영 안정성이 높다. 단, 너무 중앙팀 병목이 심하면 일부 virtual mart를 허용하기도 한다.
Semantic Layer란
Semantic Layer는 데이터의 비즈니스 의미를 정의하는 계층이다.
예를 들어 revenue라는 지표가 있을 때 다음이 정해져야 한다.
- 환불은 차감하는가?
- 세금 포함인가 제외인가?
- 주문일 기준인가 결제일 기준인가?
- 테스트 계정은 제외하는가?
- 통화 환산 기준은 무엇인가?
이 정의가 SQL, BI tool, notebook마다 흩어지면 지표가 달라진다. Semantic Layer는 지표 정의, dimension, relationship, access policy를 한 곳에서 관리하려는 시도다.
BI: dashboard는 마지막 결과물일 뿐이다
BI 도구는 Tableau, Power BI, Looker, Superset, Metabase, Grafana 등 다양하다. 하지만 BI 화면에서 문제가 보이면 원인이 BI에만 있지는 않다.
정리된 공통 데이터 → Data Mart
업무별 소비 데이터 → Semantic Layer
지표 정의 · 관계 · 권한 → BI Dashboard
사람이 보는 화면
BI 장애의 흔한 원인은 다음이다.
- mart refresh 실패
- 지표 정의 변경 미반영
- warehouse 비용 제한으로 쿼리 실패
- dimension join cardinality 문제
- dashboard filter가 partition pruning을 못 타는 문제
- 권한 정책 변경
DBA·플랫폼 엔지니어의 책임 경계
Mart와 BI는 분석팀만의 일이 아니다. DB 플랫폼 엔지니어는 다음을 같이 봐야 한다.
| 영역 | 체크할 것 |
|---|---|
| 성능 | dashboard query가 scan을 과하게 하지 않는가 |
| 신뢰성 | refresh 실패 시 stale data 표시가 되는가 |
| 권한 | mart에서 민감 컬럼이 제거되거나 masking되는가 |
| 비용 | ad-hoc BI query가 warehouse credit을 태우지 않는가 |
| 변경관리 | source schema 변경이 mart contract를 깨지 않는가 |
좋은 Mart의 조건
- 목적이 명확하다.
- grain이 문서화되어 있다.
- owner가 있다.
- refresh 주기와 SLA가 있다.
- 지표 정의가 포함되어 있다.
- 민감 정보 처리 기준이 있다.
- 더 이상 쓰지 않는 mart는 폐기된다.
세션 과제
현재 만들고 싶은 dashboard 하나를 골라 Mart 설계를 해보자.
| 항목 | 답 |
|---|---|
| Dashboard 목적 | |
| 사용자 | |
| 필요한 지표 | |
| 필요한 dimension | |
| Mart grain | |
| Refresh 주기 | |
| 민감 컬럼 | |
| owner |
References
- https://www.ibm.com/think/topics/data-mart
- https://learn.microsoft.com/en-us/power-bi/guidance/star-schema
- https://cloud.google.com/learn/what-is-a-data-warehouse
- https://www.getdbt.com/analytics-engineering/modular-data-modeling-technique