데이터 마트의 기본구조
데이터 분석을 위하여 BI도구(Tableau, Redash, PowerBI, Looker ..)에서 데이터를 시각화하려면 시각화에 필요한 정보를 모아놓은 데이터 마트가 필수입니다. 데이터 마트의 설계에 기본이 되는 개념을 정리합니다.
시각화에 적합한 데이터 마트 만들기(OLAP)
데이터 분석, 데이터 시각화에서 가장 핵심적인 개념은 OLAP(Online Analytical Processing)입니다.
OLAP는 사용자가 정보에 직접 접근하여 대화식으로 정보를 분석하고 의사결정에 활용하는 과정을 말합니다.
OLAP의 개념을 몰라도 BI도구를 사용할 수 있지만 데이터 마트를 구축할 때는 지식이 필요해 보입니다.
다차원 모델과 OLAP 큐브
데이터 웨어하우스를 모델링할 때 사실(Fact) 테이블과 차원(Dimension) 테이블 간 상호 관계를 정의하여 다차원으로 구현한 모델이 다차원 모델입니다. OLAP 에서는 이렇게 구현된 다차원 모델을 MDX(Multi-Dimensional eXpressions) 쿼리 언어로 집계합니다.
사실(Fact) 테이블과 차원(Dimension) 테이블 밑에서 다시 설명하겠습니다.
- MDX : OLAP용 쿼리 언어
데이터 분석을 위하여 만들어진 다차원 데이터를 OLAP 큐브(OLAP cube)라고 부르며 데이터를 집계하는 과정을 OLAP라고 합니다.
MPP 데이터 베이스와 비정규화 테이블
컴퓨터 성능이 좋지 않은 예전에는 데이터 분석(OLAP)을 위하여 데이터 집계의 결과를 미리 계산하여 쿼리가 실행되면 이미 집계된 결과를 반환하는 방식으로 분석을 진행하였지만 이제는 MPP 데이터베이스와 BI도구를 조합하여 미리 계산하는 일 없이 데이터 분석(OLAP)을 수행합니다.
BI도구에서 만들고 싶은 그래프에 맞추어 '다차원 모델'을 설계하는데 MPP 데이터 베이스에는 '다차원 모델'의 개념이 없기 때문에 '비정규화 테이블'을 만들어 데이터 분석을 합니다.
- 데이터베이스를 공부하면 항상 나오는 개념이 정규화(Normalization)입니다.
- 정규화는 쉽게 이야기하면 데이터의 중복을 제거하며 테이블을 분해시키는 작업입니다.
- 하지만 비정규화(Denomarlization)는 정규화에 의해 분해된 테이블을 최대한 결합하여 하나의 테이블로 만드는 작업입니다.
테이블을 비정규화 하기
데이터베이스를 설계할 때 종종 테이블을 '트랜잭션'과 '마스터'로 구분합니다.
'트랜잭션'은 시간과 함께 생성되는 데이터를 기록하는 것을 말하고 한번 기록하면 변화하지 않지만
'마스터'는 트랜잭션에 사용되는 각 정보를 담은 것을 말하고 상황에 따라 수정되기도 합니다.
위의 그림과 같이 '판매이력' 만이 트랜잭션이고 '상품', '점포', 고객' 마스터로 취급되는 것을 볼 수 있습니다.
사실(Fact) 테이블과 차원(Dimension) 테이블
데이터 웨어하우스에서는 트랜잭션 처럼 사실(Fact)가 기록된 것을 Fact Table 이라고 하고 마스터처럼 트랜잭션에 참고되는 것을 Dimension Table이라고 합니다.
집계에 기반이 되는 '판매액'과 같은 숫자 데이터는 Fact Table에 기록되고 Dimension Table에는 주로 데이터를 분류하기 위한 속성값으로 사용됩니다.
스타 스키마와 비정규화
데이터 마트를 만들때에는 Fact Table을 중심으로 여러 Dimension Table을 결합하는 것이 좋습니다.
위의 그림처럼 정규화에서 비정규화를 거쳐서 Fact Table로 만들어지는데 중간에 스타 스키마가 있는 것을 확인할 수 있습니다.
스타 스키마는 Fact Table을 중심으로 여러 Dimension Table이 결합하는 별모양 형태의 스키마입니다.
스타 스키마는 단순해서 이해하기가 쉽고 데이터 분석을 쉽게 할 수 있다는 장점을 가지고 있습니다.
SELECT *
FROM 판매이력
LEFT JOIN 상품 ON 상품.상품ID = 판매이력.상품ID
LEFT JOIN 점포 ON 점포.점포ID = 판매이력.점포ID
LEFT JOIN 고객 ON 고객.고객ID = 판매이력.고객ID
여러 BI도구에서 위와 같이 쿼리문을 입력하여 스타 스키마의 테이블을 SQL로 결합할 수 있습니다.
데이터양이 증가하면 자연스럽게 Fact Table의 데이터양이 증가하고 데이터 집계시간도 증가하게 됩니다.
Fact Table은 ID와 같은 키값만 남겨두고 나머지는 Dimension Table로 옮겨 Fact Table이 메모리를 초과하여 디스크 I/O가 발생하는 일을 예방해야 합니다.
비정규화 테이블(Denormalized Table) - Result Table
예전에는 위의 방법처럼 데이터를 다루었다면 요즘에는 MPP 데이터베이스와 같은 열 지향 스토리지의 등장으로 스타 스키마를 이용하지 않아도 괜찮습니다.
열 지향 스토리지에서 칼럼 단위로 데이터가 저장되면서 칼럼의 수가 아무리 늘어나도 성능에 거의 영향을 주지 않습니다.
그래서 처음부터 Fact Table에 모든 칼럼을 포함시키고 쿼리 실행시 테이블 결합을 하지 않는 편이 더 간단합니다.
또한 컬럼 단위로 데이터를 압축할 수 있어 디스크 I/O가 억제되기 때문에 Result Table과 같이 거대한 Fact Table만 존재하면 충분합니다.
데이터 마트에서 거대한 Fact Table을 비정규화 테이블(Denormalized Table)이라고 합니다. 대부분의 경우 비정규화 테이블로 만들어 사용하는 것이 가장 단순하고 효율적인 방법일 것입니다.
하지만 데이터를 축적하는 데이터 웨어하우스의 구조에서는 스타 스키마를 이용하여 Fact Table과 Dimension Table로 분리해두고 데이터를 축적하며 데이터 마트를 만드는 과정에서 테이블을 결합하여 비정규화 테이블을 만들어 사용하는 것이 좋겠습니다.
'데이터 엔지니어링' 카테고리의 다른 글
[빅데이터를 지탱하는 기술] 대규모 분산 처리의 프레임워크 # 2 (0) | 2023.05.19 |
---|---|
[빅데이터를 지탱하는 기술] 대규모 분산 처리의 프레임워크 # 1 (0) | 2023.05.18 |
[빅데이터를 지탱하는 기술] 빅데이터의 탐색 # 2 (0) | 2023.05.17 |
[빅데이터를 지탱하는 기술] 빅데이터의 탐색 # 1 (0) | 2023.05.16 |
[빅데이터를 지탱하는 기술] 빅데이터 시대의 데이터 분석 # 2 (0) | 2023.04.18 |