데이터 마트

데이터 마트는 한 부서가 쓸 분석 데이터만 따로 떼어 모아 줍니다. 회사 전체 데이터를 모은 데이터 웨어하우스에서 그 부서 몫만 골라 다시 담습니다. 부서 사람들은 커다란 웨어하우스를 뒤지지 않고 자기 질문에 맞는 테이블 몇 개만 봅니다.

쉽고 빠른 이해

데이터 마트는 한 부서가 쓸 분석 데이터만 모아 둔 작은 저장소입니다. 쇼핑몰의 마케팅 팀이라면 광고 클릭, 광고비, 광고로 들어온 주문만 담은 마트를 씁니다.

회사 전체를 모은 웨어하우스에는 테이블이 아주 많습니다. 필요한 테이블을 찾아 이어 붙이고 더하는 일을 질문마다 되풀이하면 느립니다. 급여처럼 다른 부서가 보면 안 되는 데이터까지 열어 주게 되는 것도 곤란합니다.

어떻게 도나:

1. 웨어하우스에서 그 부서에 필요한 데이터만 골라 옵니다
2. 그 부서가 자주 묻는 질문에 맞게 미리 이어 붙이고 더해 둡니다
3. 부서 사람들과 그들이 보는 지표 화면(대시보드)은 마트에만 질문합니다

마트는 웨어하우스를 거쳐 한 번 더 복사해 옵니다. 그래서 방금 들어온 주문처럼 바로 보여야 하는 데이터에는 맞지 않습니다. 여러 부서에 걸친 질문도 마트 하나로는 답하기 어렵습니다. 부서마다 마트를 따로 만들면 같은 「매출」이 마트마다 다르게 나오기도 합니다.

상세

대학 중앙도서관에는 모든 분야의 책이 있습니다. 경영학과는 그중 자주 찾는 경영학 책만 골라 학과 자료실에 둡니다. 경영학과 학생은 도서관 전체를 뒤지지 않고 자료실 서가 몇 칸에서 필요한 책을 찾습니다.

학과 자료실이 그 과 몫의 책을 골라 두듯, 데이터 마트는 한 부서나 한 주제에 필요한 데이터만 따로 모아 둔 분석용 저장소입니다. 온라인 쇼핑몰이라면 마케팅 팀의 마트에 광고 클릭 기록, 광고비, 광고로 들어온 주문이 들어갑니다. 재무 팀의 마트에는 매출, 환불, 비용이 들어갑니다.

마트가 흔히 데이터를 받아 오는 곳은 데이터 웨어하우스입니다. 웨어하우스는 회사의 여러 시스템에 흩어진 데이터를 한곳에 모아 분석용으로 정리해 둔 저장소입니다. 마트는 그 웨어하우스를 한 부서의 눈높이로 좁힌 것입니다.

이 절은 쇼핑몰의 마케팅 팀 하나를 따라갑니다. 웨어하우스를 두고도 마트를 또 두는 이유부터 봅니다.

웨어하우스만으로 모자란 이유

회사 전체를 담은 웨어하우스에는 테이블이 아주 많습니다. 주문, 회원, 재고, 배송, 급여, 광고가 모두 한곳에 있습니다. 마케팅 분석가는 광고 성과 하나를 보려 해도 이 가운데 무엇을 써야 하는지부터 찾아야 합니다.

찾은 뒤에도 일이 남습니다. 광고 클릭 테이블과 주문 테이블을 같은 고객끼리 이어 붙여야 합니다. 조인은 테이블 둘을 같은 값끼리 이어 붙이는 연산입니다.

이어 붙인 다음에는 날짜별, 광고별로 금액을 더합니다. 여러 행을 합계나 평균 같은 값 하나로 줄이는 이 계산을 집계라고 합니다. 질문할 때마다 조인과 집계를 처음부터 다시 돌리면 결과를 기다리는 시간이 길어집니다.

마트는 이 일을 미리 해 둡니다. 「날짜별·광고별 클릭 수와 매출」 테이블을 만들어 두면 분석가는 그 테이블 하나만 읽습니다. 매일 보는 질문일수록 미리 해 둔 덕을 크게 봅니다.

한 저장소를 여러 부서가 같이 쓰면 서로의 작업이 부딪힙니다. 재무 팀이 월말 결산으로 수백만 행을 훑는 집계를 돌리는 동안 마케팅 팀의 화면이 느려집니다. 마트를 떨어진 저장소에 두면 한 부서의 큰 작업이 다른 부서를 붙잡지 않습니다.

누가 무엇을 볼 수 있는지도 갈라집니다. 웨어하우스에는 직원 급여나 고객 연락처처럼 아무나 보면 안 되는 데이터가 섞여 있습니다. 마케팅 마트에 광고 분석에 필요한 것만 담으면 마케팅 팀에는 그 마트만 열어 주면 됩니다. 접근 제어는 이처럼 사용자마다 볼 수 있는 범위를 정하는 일입니다.

마트가 채워지는 길

마트는 스스로 데이터를 만들지 않습니다. 다른 저장소에서 복사해 옵니다. 복사는 세 단계를 거칩니다. 먼저 필요한 데이터를 뽑아 옵니다. 다음에 모양을 다듬습니다. 마지막으로 마트 테이블에 넣습니다.

이 세 단계를 ETL(Extract, Transform, Load, 추출·변환·적재)이라고 부릅니다. 웨어하우스를 채울 때 쓰는 방식과 같습니다. 다른 것은 출발점입니다.

웨어하우스로 데이터를 내주는 주문 데이터베이스나 광고 클릭 로그를 원천 시스템이라고 부릅니다. 웨어하우스는 원천 시스템에서 뽑아 옵니다. 마트는 대개 웨어하우스에서 뽑아 옵니다.

각 팀은 자기 마트를 대시보드로 봅니다. 대시보드는 자주 보는 지표를 그래프와 표로 한 화면에 모아 보여 줍니다. 아래 그림은 웨어하우스 하나가 부서별 마트 여럿으로 갈라지는 모양입니다. 각 팀의 대시보드는 웨어하우스가 아니라 자기 마트를 읽습니다.

flowchart TD
    subgraph 원천["원천 시스템"]
        A["주문 데이터베이스"]
        B["광고 클릭 로그"]
    end
    원천 --> W["데이터 웨어하우스"]
    W --> M1["마케팅 마트"]
    W --> M2["재무 마트"]
    M1 --> U1["마케팅 팀 대시보드"]
    M2 --> U2["재무 팀 대시보드"]

이 복사는 대개 정해진 때에 몰아서 돕니다. 밤에 원천에서 웨어하우스로 복사한 뒤 이어서 웨어하우스에서 마트로 복사하는 식입니다. 모아 두었다가 한 번에 처리하는 이 방식이 배치 처리입니다.

종속 마트와 독립 마트

마트는 웨어하우스를 거쳐 받느냐로 흔히 두 갈래로 나뉩니다. 앞의 그림처럼 웨어하우스에서 받는 마트를 종속 데이터 마트라고 부릅니다. 웨어하우스에 기대어 선다는 뜻입니다.

웨어하우스 없이 원천 시스템에서 바로 받는 마트도 있습니다. 이것이 독립 데이터 마트입니다. 마케팅 팀이 광고 클릭 로그와 주문 데이터베이스에서 직접 뽑아 자기 마트를 채우는 식입니다.

독립 마트는 빨리 만들 수 있습니다. 회사 전체를 아우르는 웨어하우스를 먼저 짓지 않아도 한 부서의 질문에 바로 답합니다. 대가는 부서마다 숫자가 갈린다는 것입니다.

마케팅 마트는 매출을 결제한 금액으로 셉니다. 재무 마트는 결제 금액에서 환불을 뺀 금액으로 셉니다. 같은 달 매출이 두 팀의 보고서에서 다르게 나옵니다. 이렇게 부서마다 따로 쌓여 서로 맞춰지지 않는 데이터를 데이터 사일로라고 부릅니다.

종속 마트는 이 문제를 줄입니다. 매출을 세는 법은 웨어하우스에서 한 번만 정합니다. 마트들은 그 정의를 나눠 받습니다. 이처럼 모두가 기준으로 삼는 한 곳을 단일 진실 원천이라고 부릅니다.

두 갈래를 나란히 놓으면 이렇습니다.

두 갈래는 웨어하우스를 거치느냐로 가른 것입니다. 이 둘 밖의 출발점도 있습니다. 마트가 데이터 레이크에서 받아 오는 경우입니다.

데이터 레이크는 원본을 가공하지 않고 형식도 가리지 않은 채 쌓아 두는 저장소입니다. 거기서 한 주제에 필요한 것만 골라 표 모양으로 다듬어 마트에 넣습니다.

마트 안의 테이블 모양

서비스를 돌리는 데이터베이스는 같은 값이 두 번 저장되지 않게 테이블을 잘게 나눕니다. 이렇게 나누는 일을 정규화라고 합니다. 잘게 나눌수록 분석 질문 하나에 붙는 조인이 늘어납니다.

그래서 마트는 테이블을 덜 나눕니다. 분석 질문에 맞춰 테이블을 짜는 이 방법이 차원 모델링입니다. 차원 모델링은 테이블을 두 종류로 가릅니다.

첫째는 팩트 테이블입니다. 일어난 일을 숫자로 적습니다. 마케팅 마트라면 광고 클릭 한 번이나 광고로 들어온 주문 한 건이 한 행이 됩니다.

둘째는 차원 테이블입니다. 그 숫자를 가를 기준을 담습니다. 언제 일어났나, 어느 광고였나, 누구였나가 각각 날짜 차원, 광고 차원, 고객 차원이 됩니다.

마케팅 마트에서는 광고 성과 팩트 테이블 하나를 이 세 차원이 둘러쌉니다. 그리면 아래와 같습니다.

flowchart TD
    D1["날짜 차원"] --- F["광고 성과 팩트 테이블"]
    D2["광고 차원"] --- F
    F --- D3["고객 차원"]

이처럼 팩트 테이블 하나를 가운데 두고 차원 테이블 여럿이 둘러싸는 모양을 스타 스키마라고 부릅니다. 마트는 한 주제만 다루므로 대개 별 하나나 몇 개로 끝납니다.

마트가 여럿일 때는 날짜나 고객 같은 차원 테이블을 하나 만들어 함께 쓰기도 합니다. 그러면 마케팅 마트의 고객과 재무 마트의 고객이 같은 번호로 이어집니다. 여러 마트가 함께 쓰는 이런 차원을 공통 차원(conformed dimension)이라고 부릅니다.

마트를 두는 방식

마트가 꼭 따로 떨어진 데이터베이스일 필요는 없습니다. 흔한 방식은 셋입니다. 셋 가운데 뷰는 데이터를 꺼내는 질의(쿼리)에 이름을 붙여 저장해 둔 것입니다.

둘째 줄의 스키마는 한 데이터베이스 안에서 테이블을 묶는 이름공간입니다. 마케팅 마트의 테이블을 마케팅용 스키마 하나에 모아 두면 다른 부서의 테이블과 섞이지 않습니다.

셋째 줄의 뷰는 테이블처럼 읽지만 따로 저장된 데이터가 없습니다. 읽을 때마다 질의를 돌려 결과를 만듭니다.

그래서 수백만 행을 훑는 집계를 담은 뷰는 읽을 때마다 느립니다. 계산 결과를 저장해 두고 정해진 때에 새로 고치는 뷰가 구체화 뷰입니다. 복사본을 두는 방식과 매번 계산하는 방식 사이에 섭니다.

마트가 맞지 않는 경우

마트의 데이터는 웨어하우스보다도 늦습니다. 원천에서 웨어하우스로, 다시 웨어하우스에서 마트로 두 번 복사해 오기 때문입니다. 방금 들어온 주문을 보여 줘야 하는 화면에는 맞지 않습니다.

복사 작업은 마트 수만큼 늘어납니다. 웨어하우스 테이블 하나의 구조(열 이름이나 값의 뜻)가 바뀌면 그 테이블을 쓰는 마트의 변환이 모두 영향을 받습니다. 마트가 쌓일수록 어느 숫자가 어디서 왔는지 따라가기도 어려워집니다.

부서를 넘나드는 질문에도 맞지 않습니다. 「광고로 들어온 손님의 환불 금액」은 마케팅 마트와 재무 마트에 반씩 걸쳐 있습니다. 이런 질문은 대개 회사 전체를 담은 웨어하우스에 직접 묻습니다.

관련 항목

데이터 마트가 속하는 상위 분류

데이터 엔지니어링 · 데이터 분석 · 비즈니스 인텔리전스 · 데이터베이스

데이터 마트에 데이터를 내주는 저장소

데이터 웨어하우스 · 데이터 레이크 · 데이터 레이크하우스 · 운영 데이터 저장소 · 원천 시스템

데이터 마트를 채우는 처리 단계

ETL · ELT · 배치 처리 · 변경 데이터 캡처 · 데이터 파이프라인 · 변환

데이터 마트의 테이블을 짜는 모델링 기법

차원 모델링 · 팩트 테이블 · 차원 테이블 · 스타 스키마 · 스노우플레이크 스키마 · 공통 차원 · 정규화 · 반정규화

데이터 마트를 구현하는 저장 방식

뷰 · 구체화 뷰 · 스키마 · 열 지향 저장 · OLAP · OLAP 큐브

데이터 마트에 질문을 던지는 도구

SQL · 질의 · 집계 · 조인 · 대시보드

마트가 부서마다 흩어질 때 생기는 문제와 대책

데이터 사일로 · 단일 진실 원천 · 데이터 거버넌스 · 데이터 계보 · 접근 제어